Achtung : Skript gibt mündlichen Vortrag nur unvollständig wieder !!
   Achtung : Skript noch nicht abgeschlossen !
                        

1. Einführung

Ausgangspunkt der folgenden Überlegungen ist die Einsicht aus der letzten VL, dass Systeme zur Ausführung ihrer Prozesse Zeit benötigen. Bei Realzeitsystemen --und Prozessrechner sind überwiegend Realzeitsysteme-- bedeutet dies, dass für bestimmte Aufgaben ein maximaler Zeitbedarf nicht überschritten werden darf, um die geforderte Aufgabe erfüllen zu können. Ferner spielt die Zuverlässigkeit eine zentrale Rolle, da nur Systeme, die bzgl. MTTF und MTTR gewisse untere Schranken garantieren, zum Einsatz kommen können.

Als neuer Gesichtspunkt kommt nun noch hinzu, dass Prozessrechner in vielen Fällen nicht isoliert auftreten, sondern im Verbund; man hat es also mit einem verteilten Realzeitsystem zu tun. Dieser Aspekt soll heute und in den verbleibenden Vorlesungen weiter beleuchtet werden.

START

2. Systemkommunikation allgemein

In einem Verbund von verteilten Realzeitsystemen müssen die verschiedenen beteiligten Systeme sich miteinander verständigen können. Wie aus dem Bild "Realzeit-Kommunikation: Basis" zu entnehmen ist, kann man hier grob die folgenden Komponenten unterscheiden:

1. Die beteiligten Realzeitsysteme selbst (im Beispiel S₁ - S₃)




2. Einen Kommunikationskanal




3. Die Datenpakete, die durch einen Kommunikationskanal 'hindurch' geschickt werden können




4. Ein Interface, das den Kommunikationskanal mit einem konkreten Realzeitsystem verbindet.

Wenn man davon ausgeht, dass der Kommunikationskanal samt Datenpaketen für alle beteiligten Systeme 'gleich' ist und man ferner davon ausgeht, dass die beteiligten Systeme aufgrund der Variationsbreite möglicher Aufgaben sehr unterschiedlich sein können, dann besteht die Notwendigkeit, alle diese verschiedenen Systeme an den einen gleichen Kommunikationskanal 'anzupassen'; dies geschieht durch eine Schnittstelle ('interface') (siehe Bild "Realzeit-Kommunikation: Interface").

Eine Schnittstelle ist so gesehen eigentlich ein 2-Weg-Übersetzer: vom System zum Kommunikationskanal werden die internen Zustände eines konkreten Systems in das Format der Datenpakete übersetzt (enkodiert, 'encoded')

INTERF_ENCODING: STATES_S ---> EXPRESSIONS

und umgekehrt werden die Datenpakete zurückübersetzt in die internen Zustände eines konkreten Systems (dekodiert, 'decoded')

INTERF_DECODING: EXPRESSIONS ---> STATES_S

Der gemeinsame Kommunikationskanal bietet also die Möglichkeit, dass unterschiedliche Systeme --bei Vorhandensein einer geeigneten Schnittstelle-- miteinander kommunizieren können.

Aus der Sicht der physikalischen Realisierung von Kommunikation gilt, dass digitale Kommunikation mit Hilfe von binären Signalzuständen (siehe z.B.: Signale und binäre Schaltzustände) realisiert wird. Einem binären Zustand entspricht physikalisch ein definiertes Signal das entweder eine '1' ('high') repräsentiert oder eine '0' ('low') (siehe Bild "Realzeit-Kommunikation: Daten und Signale").

Entsprechend dieser physikalischen Realisierung gibt es auf einer 'höheren konzeptuellen Ebene' eine symbolische Darstellung dieser physikalischen Signalfolgen in Form von binären Zahlen, die man als Bitfelder auffasst und die als Frames organisiert werden. 'Oberhalb' dieser Bitfelder kann es weitere 'abstrakte Darstellungsebenen' geben, die allgemeine Eigenschaften der Kommunikation kodieren. Wir wollen im folgenden davon ausgehen, dass ein Kommunikationskanal also mindestens 2 --möglicherweise aber auch mehr als 2 (siehe Tabelle)-- Ebenen ('layer') umfasst: eine physikalische Ebene, auf der tatsächlich und real Signale zwischen Kommunikationspartnern ausgetauscht werden können, und einer Daten-Ebene, auf der symbolisch Signale als Zeichen repräsentiert werden, die Bitfelder/ Frames/ Datenpakete realisieren.

In der Regel enthält ein Datenpaket ('frame') mehr binäre Zustände als ein Kommunikationskanal parallel übertragen kann. Dies bedeutet, dass die Übertragung der binären Zustände eines Datenpaketes seriell erfolgen muss, wobei 'seriell' nicht ausschliesst, dass die einzelne gesendete Einheit mehr als 1 Bit umfassen kann (z.B. 8-Bit bei einem 8-Bit Bus).

Ferner ist es der Normalfall, dass an einen Kommunikationskanal mehr als 1 System angeschlossen ist --dazu wurde der Kommunikationskanal ja gerade eingeführt--. Dies bedeutet, dass zum gleichen Zeitpunkt möglicherweise mehr als ein System Daten über den Kommunikationskanal verschicken will. Es gibt also hier einen Ressourcenkonflikt, der nur durch ein geeignetes Nutzungsschema ('scheduling') gelöst werden kann. Das Nutzungsschema muss so angelegt sein, dass es für den 'schlechtest anzunehmenden Fall' ('worst case') alle anfallenden Kommunikationsanforderungen im Rahmen einer garantierten Zeit abwickeln kann. Dazu ist es u.a. notwendig, dass der Zeitbedarf der einzelnen Kommunikations- und Verwaltungsakte im richtigen Verhältnis zur Leistungsmöglichkeit (Bandbreite, 'bandwidth') des Kommunikationskanals steht.

Für die Nutzung eines Kommunikationskanals im Rahmen einer Realzeit-Kommunikation ist es ferner unabdingbar, dass, falls Fehler auftreten, diese schnell genug entdeckt werden können, damit in einer garantierten Zeit eine geeignete Fehlerbehandlung stattfinden kann. Es muss ferner 'garantiert' werden, dass die maximale Zahl der Fehler einen gewissen Grenzwert nicht überschritet, da ansonsten die Realzeitanforderungen nicht mehr eingehalten werden können.

Schliesslich ist noch festzuhalten, dass es zu jeder Ebene eine Menge von Regeln (Protokoll, 'protocol') gibt, die festlegen, wie die kleinsten Einheiten jeder Ebene überhaupt zu grösseren Einheiten (Signalfolgen, Bitfelder, Pakete, Frames) zusammengesetzt werden dürfen, wie diese kontrolliert werden, in welcher Abfolge wer was senden bzw. empfangen darf/ kann, usw. Da es zu jeder Ebene ein Protokoll gibt, bedeutet dies für einen Kommunikationskanal mit n > 2 Ebenen ('layer'), dass ein ganzer Stapel von Protokollen ('protocol stack') abzuarbeiten ist, wenn eine Nachricht gesendet oder empfangen wird. Es hat sich eingebürgert, dass man von einem Kommunikationsprotokoll ('communication protocol') spricht, wenn man einen Kommunikationskanal mit einem bestimmten charakteristischen Satz von Protokollen sprechen will, d.h. man identifiziert den Kommunikationskanal über die Protokolle, die ihn definieren.

START

3. Einige bekannte Realzeit-Protokolle

In der folgenden Tabelle ist eine kleine Auswahl bekannter und verbreiteter Realzeit-Protokolle aufgeführt. Die Aufzählung soll zukünftig erweitert werden. Ausserdem muss sie vereinheitlicht werden; aktuell sind dies Texte aus unterschiedlichen Quellen mit unterschiedlichen Aussageabsichten. Was aber u.a. deutlich wird, das ist der z.T. der 'industriepolitische' Charakter von Protokollen; ferner fällt auf, dass die Protokolle sich z.T. eng an bestimmte Anwendungsbereiche anlehnen (Militär, Flugzeugindustrie, Automobilindustrie usw.).

Von diesen verschiedenen Bussen soll das CAN-Protokoll noch weiter untersucht werden.

START

4. Das CAN-Protokoll

Ein kurzer Überblick zur Geschichte des CAN-Protokolls und seines Einsatzes --ohne CANopen!-- vermittelt das folgende Schaubild, das einer Slideshow der Firma KVASER entnommen ist:

Ein Blick auf ein konkretes Netzwerk von CAN-Komponenten aus Produktsicht vermittelt das folgende Schaubild (ebenfalls von der Firma KVASER (s.o)):

Schliesslich noch ein Blick in den schematischen Aufbau eines CAN-Moduls:

Hier eine erste etwas ausführlichere Darstellung zum CAN-Protokoll von CiA := CAN in Automation, a non-profit CAN-usergroup.

CiA schreibt zum CAN-Protokoll:

The CAN protocol is an international standard defined in the ISO 11898. Beside the CAN protocol itself the conformance test for the CAN protocol is defined in the ISO 16845, which guarantees the interchangeability of the CAN chips.

CAN is based on the so-called broadcast communication mechanism. This broadcast communication is achieved by using a message oriented transmission protocol. Thus not defining stations and station addresses, it only defines message. These messages are identified by using a message identifier. Such a message identifier has to be unique within the whole network and it defines not only the content but also the priority of the message. This will be important when several stations compete for bus access.

A high degree of system and configuration flexibility is achieved as a result of the content-oriented addressing scheme. It is very easy to add stations to a existing CAN network without making any hardware or software modifications to the existing stations as long as the new stations are purely receivers. This allows the concept of modular electronics and also permits multiple reception and the synchronization of distributed processes: data needed as information by several stations can be transmitted via the network in such a way that it is unnecessary for each station to have to know who the producer of the data is. This allows easy servicing and upgrading of networks as data transmission is not based on the availability of specific types of stations.

In real-time processing the urgency of messages to be exchanged over the network can differ greatly: a rapidly changing dimension, e.g. engine load, has to be transmitted more frequently and therefore with less delays than other dimensions, e.g. engine temperature.

The priority at which a message is transmitted compared to another less urgent message is specified by the identifier of each message. The priorities are laid down during system design in the form of corresponding binary values and cannot be changed dynamically. The identifier with the lowest binary number has the highest priority.

Bus access conflicts are resolved by bit-wise arbitration on the identifiers involved by each station observing the bus level bit for bit. This happens in accordance with the "wired and" mechanism, by which the dominant state overwrites the recessive state. The competition for bus allocation is lost by all those stations (nodes) with recessive transmission and dominant observation. All those "losers" automatically become receivers of the message with the highest priority and do not re-attempt transmission until the bus is available again.

Transmission requests are handled in the order of the importance of the messages for the system as a whole. This proves especially advantageous in overload situations. Since bus access is prioritized on the basis of the messages, it is possible to guarantee low individual latency times in real-time systems.

The CAN protocol supports two message frame formats, the only essential difference being in the length of the identifier. The so-called CAN standard frame, also known as CAN 2.0 A, supports a length of 11 bits for the identifier, and the so-called CAN extended frame, also known as CAN 2.0 B, supports a length of 29 bits for the identifier.

A message in the CAN standard frame format begins with the start bit called "Start Of Frame (SOF)", this is followed by the "Arbitration field" which consist of the identifier and the "Remote Transmission Request (RTR)" bit used to distinguish between the data frame and the data request frame called remote frame. The following "Control field" contains the "IDentifier Extension (IDE)" bit to distinguish between the CAN standard frame and the CAN extended frame, as well as the "Data Length Code (DLC)" used to indicate the number of following data bytes in the "Data field". If the message is used as a remote frame, the DLC contains the number of requested data byte. The "Data field" that follows is able to hold up to 8 data byte. The integrity of the frame is guaranteed by the following "Cyclic Redundant Check (CRC)" sum (this information is taken from the URL: http://www2.rad.com/networks/1994/err_con/crc_how.htm). The "ACKnowledge (ACK) field" compromises the ACK slot and the ACK delimiter. The bit in the ACK slot is sent as a recessive bit and is overwritten as a dominant bit by those receivers which have at this time received the data correctly. Correct messages are acknowledged by the receivers regardless of the result of the acceptance test. The end of the message is indicated by "End Of Frame (EOF)". The "Intermission Frame Space (IFS)" is the minimum number of bits separating consecutive messages. If there is no following bus access by any station the bus remains idle.

A message in the CAN extended frame format is likely the same as a message in CAN standard frame format. The difference is the length of the identifier used. The identifier is made up of the existing 11-bit identifier (so-called base identifier) and an 18-bit extension (so-called identifier extension). The distinction between CAN standard frame format and CAN extended frame format is made by using the IDE bit which is transmitted as dominant in case of a frame in CAN standard frame format, and transmitted as recessive in case of a frame in CAN extended frame format. As the two formats have to co-exist on one bus, it is laid down which message has higher priority on the bus in the case of bus access collision with different formats and the same identifier / base identifier: The message in CAN standard frame format always has priority over the message in extended format.

CAN controllers which support the messages in CAN extended frame format are also able to send and receive messages in CAN standard frame format. When CAN controllers which only cover the CAN standard frame format are used in one network, then only messages in CAN standard frame can be transmitted in the entire network. Messages in CAN extended frame format would be misunderstood. However there are CAN controllers which only support CAN standard frame format but recognize messages in CAN extended frame format and ignore them (version 2.0 B passive).

Unlike other bus systems, the CAN protocol does not use acknowledgement messages but instead signals any errors immediately as they occur. For error detection the CAN protocol implements three mechanisms at the message level:

• Cyclic Redundancy Check (CRC).
  The CRC safeguards the information in the frame by adding redundant check bits at the transmission end. At the receiver these bits are re-computed and tested against the received bits. If they do not agree there has been a CRC error.

• Frame check.
  This mechanism verifies the structure of the transmitted frame by checking the bit fields against the fixed format and the frame size. Errors detected by frame checks are designated "format errors".

• ACK errors.
  As already mentioned frames received are acknowledged by all receivers through positive acknowledgement. If no acknowledgement is received by the transmitter of the message an ACK error is indicated.

The CAN protocol also implements two mechanisms for error detection at the bit level:

• Monitoring.
  The ability of the transmitter to detect errors is based on the monitoring of bus signals. Each station which transmits also observes the bus level and thus detects differences between the bit sent and the bit received. This permits reliable detection of global errors and errors local to the transmitter.

• Bit stuffing.
  The coding of the individual bits is tested at bit level. The bit representation used by CAN is "Non Return to Zero (NRZ)" coding, which guarantees maximum efficiency in bit coding. The synchronization edges are generated by means of bit stuffing. That means after five consecutive equal bits the transmitter inserts into the bit stream a stuff bit with the complementary value, which is removed by the receivers.

If one or more errors are discovered by at least one station using the above mechanisms, the current transmission is aborted by sending an "error flag". This prevents other stations accepting the message and thus ensures the consistency of data throughout the network. After transmission of an erroneous message that has been aborted, the sender automatically re-attempts transmission (automatic re-transmission). There may again competition for bus allocation.

However effective and efficient the method described may be, in the event of a defective station it might lead to all messages (including correct ones) being aborted. If no measures for self-monitoring were taken, the bus system would be blocked by this. The CAN protocol therefore provides a mechanism to distinguishing sporadic errors from permanent errors and local failures at the station. This is done by statistical assessment of station error situations with the aim of recognizing a stations own defects and possibly entering an operation mode where the rest of the CAN network is not negatively affected. This may go as far as the station switching itself off to prevent messages erroneously from being recognized as incorrect .

START

5. Einfaches Fallbeispiel

Im folgenden wird ein einfaches Beispiel analysiert, um die bisherigen Konzepte zu illustrieren. Diese Analyse wird zusätzliche Fragen aufwerfen, die dann in der nachfolgenden VL im Rahmen der HLPs ('higher level protocols') weiter analysiert werden.

5.1 Problemstellung/Anforderungen

Für die folgende Aufgabenstellung soll das Aufzug-Problem aus VL8 ein wenig abgewandelt werden (siehe auch die Aufzug-Webseite mit Links zu realen Aufzugsprojekten). Die Ausarbeitung zu diesem Beispiel erhebt weder den Anspruch, die optimale Lösung darzustellen, noch eine volltändige.

In der Praxis geht der Aufstellung solch eines Anforderungskataloges in der Regel ein längerer Klärungsprozess voraus, im Rahmen dessen unterschiedliche Beteiligte interviewt und Sachfragen geklärt werden müssen.

Folgende Annahmen sollen gelten:

1. Es soll sich um einen Personanaufzug handeln, mit Seilantrieb und Elektromotor. Die Fahrgast-Kabine kann 675 kg ( := 9 Personen) aufnehmen und wird mit einer Geschwindigkeit von 1m/sec bewegt. Der Weg zwischen zwei Stockwerken wird mit 2,50m veranschlagt. Bei Betriebsbeginn befindet sich die Fahrgast-Kabine in Stockwerk 0. Der Aufzug bedient die Stockwerke 0 ... 6.

   
   

2. Auf jedem Stockwerk gibt es einen Anforderungsknopf SA_i mit i in {0,6}. Wenn jemand im 3. Stock den Aufzug anfordert, dann sendet das Modul von SA₃ eine Nachricht an das Kontrollmodul des Aufzugs, aus der hervorgeht, dass im 3.Stockwerk eine Anforderung vorliegt. Liegt keine Anforderung vor, dann sendet ein Anforderungsmodul SA_i den Wert '-1'.




3. Wenn das Kontrollmodul eine Anforderung von SA_i empfängt entscheidet das Programm des Kontrollmoduls, wann diese Anforderung bedient wird.




4. Das Programm des Kontrollmoduls kann den Motor des Aufzugs --der über dem 6.Stockwerk angebracht ist-- jeweils um ein Stockwerk abwärts (= down, = 1) oder aufwärts (=up, =2) steuern oder nichts tun (=nil, =0).




5. Das Programm des Kontrollmoduls des Aufzugs hat jederzeit Informationen über ein aktuelles Ziel Z und über das aktuelle Stockwerk S, in dem sich die Fahrgastzelle des Aufzugs befindet. Zu Beginn gilt Z==0 und S==0. Wenn gilt: S == Z, dann sendet das Programm des Kontrollmoduls eine Botschaft an die Tür der Fahrgastzelle, dass diese sich öffnet, falls der Öfffnungszeitzähler DOPEN < DOPEN_MAX ist. DOPEN_MAX ist die Anzahl der Sekunden, nach wievielen Sekunden spätestens eine geöffnete Tür bei freier Lichtschranke LI wieder geschlossen werden soll. LI hat die Werte {0 := not free, 1 := free}.




6. Wenn die Tür geschlossen wurde wertet das Programm des Kontrollmoduls die Zieleingaben SI aus. Diese können Werte aus {0,...,6} enthalten, und zwar maximal 6, für jedes Stockwerk ein Wert, ausgenommen das aktuelle Stockwerk. Diese Werte werden erzeugt, wenn ein Fahrgast auf einen Knopf SI_j mit der Stockwerkszahl j drückt.




7. Aus den Werten SA_i sowie SI_j ermittelt das Programm das aktuelle Ziel Z. Ist Z grösser als das aktuelle Stockwerk S, dann muss die Fahrgastkabine nach oben bewegt werden, ist Z < S, dann nach unten.

START

5.2 Strukturanalyse: Systeme und Interaktionj

Will man die vorausgehenden Anforderungen in ein ablauffähiges System umsetzen, muss zunächst ein Modell ausgearbeitet werden, aus dem hervorgeht, welche Systeme auftreten und wie diese interagieren; anschliessend müssen diese Systeme eventuell noch weitergehender analysiert werden.

In dieser Vorlesung benutzen wir zur Systembildung nicht das objektorietierte Paradigma, sondern das Systemparadigma. Wie schon mehrfach festgestellt, lassen sich beide Modellierungskontrukte theoretisch eineindeutig aufeinander abbilden.

Im Rahmen der systemtheoretischen Analyse fragen wir zunächst, welche Systeme möglicherweise bei dem Problem beteiligt sind und wie diese untereinander zusammenhängen. Das nachfolgende Diagramm zeigt eine mögliche Analyse von beteiligten Systemen.

1. SA_i: Steuersignale aussen senden Botschaften an die Kontrolleinheit.




2. LI: die Lichtschrabke LI sendet die Botschaft 'not free' oder 'free' zur Kontrolleinheit.




3. SI_j: Steuersignale innen senden Botschaften {0,...,6} zur Kontrolleinheit.




4. CLOCK: die Uhr sendet jede Sekunde eine Botschaft n zur Kontrolleinheit; n := Anzahl der Sekunden seit Start.




5. CONTROL: die Kontrolleinheit sendet Botschaften an den Motor MOTOR {0,1,2}, an die Tür DOOR {0,1} sowie an die Anzeige LED {0,...,6}.

Um aus diesen Daten eine ablauffähige Anwendung zu machen, muss man als nächstes klären, wie die Abfolge der Botschaften aussehen soll. Daraus ergibt sich ein Interaktionsdiagramm.

Dieses Interaktionsdiagramm gibt eine mögliche Variante wieder, und diese auch nicht vollständig detailliert.

1. Das obige Interaktionsdiagramm geht davon aus, dass es für alle Module ausser CONTROL Startwerte gibt, die während der Initialisierung INIT gesetzt werden.

2. Ferner wird angenommen, dass es eine Uhr CLOCK gibt, die die Kontrolleinheit CONTROl jede Sekunde mit einer Zeitangabe n versorgt; n repräsentiert die Anzahl der Sekunden seit Start des Systems. Die Uhr hat im System die höchste Priorität.

3. Es können dann Anforderungen SA_i auftreten.

4. Die Kontrolleinheit fragt den Zustand der Lichtschranke ab; sobald die Lichtschranke LI lange genug kein Hindernis mehr gemeldet hat, wir die Tür DOOR geschlossen.

5. Es wird dann das innere Steuersignal SI abgefragt.

6. Schliesslich wird berechnet, ob die Fahrgastkabine stehen bleibt oder sich nach oben oder unten bewegen soll; dies wird dem Motor MOTOR mitgeteilt.

7. Bei Erreichen eines neuen Stockwerkes wird der LED ein entsprechendes Signal gesendet und die Tür DOOR wird geöffnet, falls dieses Stockwerk ein aktuelles Ziel Z ist.

8. Danach beginnt die Prozedur wieder von vorne bei Nr.2

In diesem Diagram erscheint es so, als ob die äusseren Steuersignale nur zu einem bestimmten Zeitpunkt auftreten können; dem ist aber nicht so. Aufforderungen können jederzeit entstehen. Eine mögliche Behandlung dieser Aufforderungsereignisse wäre die Annahme, dass alle beliebig oft auftretenden Anforderungen in einem zentralen Register in der Folge ihres Auftretens gesammelt werden; jedes Stockwerk genau einmal (Liste ? Stack ? Queue ? ). Dieses Register wird dann von dem Kontrollmodul immer dann ausgewertet, wenn es in der Schleife die neue Zielberechnung vornimmt.

Bevor nun auf die einzelnen Komponenten genauer eingegangen wird, muessen die Randbedingungen der Kommunikation geklärt werden. Dabei wird hier von der annahme Gebrauch gemacht, dass für die Kommunikation das Protokoll CAN 2.0A benutzt werden soll; Alternativen werden an dieser Stelle nicht analysiert (ein alternatives Szenario mit VME-Bus und Ethernet wird im kommenden Semester untersucht werden).

START

5.3 Kommunikation mit CAN 2.0A allgemein

Für die weitere Analyse gehen wir von der Zuordnung aus, dass das, was im Kontext des CAN-Protokolls ein CAN-Modul genannt wird, aus den Komponenten SYSTEM + INTERFACE besteht: das Interface realisiert die OSI-Schichten 1 +2. Das eigentliche CAN 2.0A-Protokoll bildet die Schicht 2. In dem Beispiel gehen wir ferner davon aus, dass die ankommenden Botschaften in einem bestimmten Speicherbereich (RAM-INPUT) in der Reihenfolge ihres Auftretens abgelegt werden. Dieser RAM-INPUT-Bereich ist als Queue implementiert. 'Neue' Botschaften werden 'hinten' angefügt, 'alte' Botschaften 'vorne' abgefragt. Umgekehrt legt das System seine Botschaften, die als Output gedacht sind, ebenfalls in einen dezidierten Speicherbereich RAM-OUTPUT (ebenfalls eine Queue); von dort holt sich der Kontroller seine Informationen, um sie als Botschaften zu verschicken.

Es ergibt sich damit eine Situation, wie sie das nachfolgende Diagramm darstellt: alle Systeme aus dem vorausgehenden Interaktionsdiagramm sind über Schnittstellen mit dem Kommunikationskanal verbunden. Die Schnittstellen realiseren ein CAN 2.0A-Protokoll.

Für die weitere Analyse sollen folgende Annahmen gelten:

1. Als Kanalkapazität wird eine Leistung von 20 KBits/sec angenommen (maximale verfügbare Kapazität heute ist 1 MBits/sec).




2. Für alle CAN-Module wird angenommen, dass sie mindestens eine Bandbreite von 20 KBits/sec besitzen.




3. Bei den Botschaften gilt die Repräsentation der Zeit von der Uhr CLCK als jene mit den meisten Bytes: 1 Jahr entspricht 31.536.000 sec, das entspricht einem binären Polynom mit 2²⁴ Bits, also 3 Bytes. Nimmt man an, dass der Aufzug spätestens nach 1 Jahr aus Sicherheitsgründen gewartet werden muss, wird die Zahl 31.536.000 niemals überschritten.

Botschaften werden in Form von Frames übermittelt. Es wird unterschieden zwischen Sender ('transmitter') und Empfänger ('receiver') von Frames. Folgende Typen von Frames gibt es:

• DATA FRAME: Daten vom Sender zum Empfänger




• REMOTE FRAME: Anfrage eines Moduls am Bus für einen Frame mit dem gleichen IDENTIFIER




• ERROR FRAMe: wird von jedem Modul geschickt, das einen Bus-Error entdeckt




• OVERLOAD FRAME: soll eine zusätzliche Verzögerung ('delay') im Falle eines vorausgehenden oder nachfolgenden DATA- oder REMOTE FRAMEs erzeugen.




• DATA FRAMEs und REMOTE FRAMEs sind von den vorausgehenden Frames getrennt durch einen INTERFRAME SPACE.

Im Standard CAN 2.0A heisst es zu den einzelnen Feldern eines DATA FRAMES:

• START OF FRAME (SOF): marks the beginning of DATA FRAMES and REMOTE FRAMES. It consists of a single 'dominant' bit /* dominant bit := '0' */. A station is only allowed to start transmission when the bus is idle (see BUS IDLE). All stations have to synchronize to the leading edge caused by START OF FRAME (see 'HARD SYNCHRONIZATION') of the station starting transmission first.

• ARBITRATION FIELD: The ARBITRATION FIELD consists of the IDENTIFIER and the RTR-BIT.

• IDENTIFIER: The IDENTIFIER's length is 11 bits. These bits are transmitted in the order from ID-10 to ID-0. The least significant bit is ID-0. The 7 most significant bits (ID-10 - ID-4) must not be all 'recessive'.

• RTR BIT: Remote Transmission Request BIT In DATA FRAMEs; the RTR BIT has to be 'dominant' /* := '0' */. Within a REMOTE FRAME the RTR BIT has to be 'recessive' /* := '1' */.

• CONTROL FIELD: The CONTROL FIELD consists of six bits. It includes the DATA LENGTH CODE and two bits reserved for future expansion. The reserved bits have to be sent 'dominant'. Receivers accept 'dominant' and 'recessive' bits in all combinations.

• DATA LENGTH CODE: The number of bytes in the DATA FIELD is indicated by the DATA LENGTH CODE. This DATA LENGTH CODE is 4 bits wide and is transmitted within the CONTROL FIELD: < r0, r1 | DCL3, DCL2, DCL1, DCL0 > in the DATA FRAME is the admissible numbers of data bytes: {0,1,....,7,8}. Other values may not be used.

• DATA FIELD: The DATA FIELD consists of the data to be transferred within a DATA FRAME. It can contain from 0 to 8 bytes, which each contain 8 bits which are transferred MSB first.

• CRC FIELD: contains the CRC SEQUENCE followed by a CRC DELIMITER.

• CRC SEQUENCE: The frame check sequence is derived from a cyclic redundancy code best suited for frames with bit counts less than 127 bits (BCH Code). In order to carry out the CRC calculation the polynomial to be divided is defined as the polynomial, the coefficients of which are given by the destuffed bit stream consisting of START OF FRAME, ARBITRATION FIELD, CONTROL FIELD, DATA FIELD (if present) and, for the 15 lowest coefficients, by 0. This polynomial is divided (the coefficients are calculated modulo-2) by the generator-polynomial: X¹⁵ + X¹⁴ + X¹⁰ + X⁸ + X⁷ + X⁴ + X³ + 1. The remainder of this polynomial division is the CRC SEQUENCE transmitted over the bus. In order to implement this function, a 15 bit shift register CRC_RG(14:0) can be used. If NXTBIT denotes the next bit of the bit stream, given by the destuffed bit sequence from START OF FRAME until the end of the DATA FIELD, the CRC SEQUENCE is calculated as follows:

  
  
  1. CRC_RG = 0; // initialize shift register
  2. REPEAT CRCNXT = NXTBIT EXOR CRC_RG(14);
  3. CRC_RG(14:1) = CRC_RG(13:0); // shift left by
  4. CRC_RG(0) = 0; // 1 position
  5. IF CRCNXT THEN CRC_RG(14:0) = CRC_RG(14:0) EXOR (4599hex);
  6. ENDIF
  7. UNTIL (CRC SEQUENCE starts or there is an ERROR condition)

  After the transmission / reception of the last bit of the DATA FIELD, CRC_RG contains the CRC sequence.

• CRC DELIMITER: The CRC SEQUENCE is followed by the CRC DELIMITER which consists of a single 'recessive' bit.

• ACK FIELD: The ACK FIELD is two bits long and contains the ACK SLOT and the ACK DELIMITER. In the ACK FIELD the transmitting station sends two 'recessive' bits. A RECEIVER which has received a valid message correctly, reports this to the TRANSMITTER by sending a 'dominant' bit during the ACK SLOT (it sends 'ACK').

• ACK SLOT: All stations having received the matching CRC SEQUENCE report this within the ACK SLOT by superscribing the 'recessive' bit of the TRANSMITTER by a 'dominant' bit.

• ACK DELIMITER: The ACK DELIMITER is the second bit of the ACK FIELD and has to be a 'recessive' bit. As a consequence, the ACK SLOT is surrounded by two 'recessive' bits (CRC DELIMITER, ACK DELIMITER).

• END OF FRAME: Each DATA FRAME and REMOTE FRAME is delimited by a flag sequence consisting of seven 'recessive' bits.

Der Empfänger bestimmter Daten kann diese explizit anfordern, indem er dem potentiellen Sender einen REMOTE FRAME schickt, der die Anzahl der gewünschten Bytes enthält, aber natürlich keine Daten. Im einzelnen enthält eine REMOTE FRAME folgende Felder:

• START OF FRAME (SOF):

• ARBITRATION FIELD:; in a REMOTE FRAME the RTR BIT has to be 'recessive' /* := '1' */.

• CONTROL FIELD:

• CRC FIELD:

• ACK FIELD:

• END OF FRAME:

The ERROR FRAME consists of two different fields. The first field is given by the superposition of ERROR FLAGs contributed from different stations. The following second field is the ERROR DELIMITER.

In order to terminate an ERROR FRAME correctly, an 'error passive' node may need the bus to be 'bus idle' for at least 3 bit times (if there is a local error at an 'error passive' receiver). Therefore the bus should not be loaded to 100%.

ERROR FLAG: There are 2 forms of an ERROR FLAG: an ACTIVE ERROR FLAG and a PASSIVE ERROR FLAG.

1. The ACTIVE ERROR FLAG consists of six consecutive 'dominant' bits.

2. The PASSIVE ERROR FLAG consists of six consecutive 'recessive' bits unless it is overwritten by 'dominant' bits from other nodes.

An 'error active' station detecting an error condition signals this by transmission of an ACTIVE ERROR FLAG. The ERROR FLAG's form violates the law of bit stuffing (see CODING) applied to all fields from START OF FRAME to CRC DELIMITER or destroys the fixed form ACK FIELD or END OF FRAME field. As a consequence, all other stations detect an error condition and on their part start transmission of an ERROR FLAG. So the sequence of 'dominant' bits which actually can be monitored on the bus results from a super- position of different ERROR FLAGs transmitted by individual stations. The total length of this sequence varies between a minimum of six and a maximum of twelve bits. An 'error passive' station detecting an error condition tries to signal this by transmission of a PASSIVE ERROR FLAG. The 'error passive' station waits for six consecutive bits of equal polarity, beginning at the start of the PASSIVE ERROR FLAG. The PASSIVE ERROR FLAG is complete when these 6 equal bits have been detected.

ERROR DELIMITER: The ERROR DELIMITER consists of eight 'recessive' bits. After transmission of an ERROR FLAG each station sends 'recessive' bits and monitors the bus until it detects a 'recessive' bit. Afterwards it starts transmitting seven more 'recessive' bits.

The OVERLOAD FRAME contains the two bit fields OVERLOAD FLAG and OVERLOAD DELIMITER. There are two kinds of OVERLOAD conditions, which both lead to the transmission of an OVERLOAD FLAG:

1. The internal conditions of a receiver, which requires a delay of the next DATA FRAME or REMOTE FRAME.

2. Detection of a 'dominant' bit during INTERMISSION.

The start of an OVERLOAD FRAME due to OVERLOAD condition 1 is only allowed to be started at the first bit time of an expected INTERMISSION, whereas OVERLOAD FRAMEs due to OVERLOAD condition 2 start one bit after detecting the 'dominant' bit.

At most two OVERLOAD FRAMEs may be generated to delay the next DATA or REMOTE FRAME.

OVERLOAD FLAG consists of six 'dominant' bits. The overall form corresponds to that of the ACTIVE ERROR FLAG.

The OVERLOAD FLAG's form destroys the fixed form of the INTERMISSION field. As a consequence, all other stations also detect an OVERLOAD condition and on their part start transmission of an OVERLOAD FLAG. (In case that there is a 'dominant' bit detected during the 3rd bit of INTERMISSION locally at some node, the other nodes will not interpret the OVERLOAD FLAG correctly, but interpret the first of these six 'dominant' bits as START OF FRAME. The sixth 'dominant' bit violates the rule of bit stuffing causing an error condition).

OVERLOAD DELIMITER consists of eight 'recessive' bits.

The OVERLOAD DELIMITER is of the same form as the ERROR DELIMITER. After transmission of an OVERLOAD FLAG the station monitors the bus until it detects a transition from a 'dominant' to a 'recessive' bit. At this point of time every bus station has finished sending its OVERLOAD FLAG and all stations start transmission of seven more 'recessive' bits in coincidence.

DATA FRAMEs and REMOTE FRAMEs are separated from preceding frames whatever type they are (DATA FRAME, REMOTE FRAME, ERROR FRAME, OVERLOAD FRAME) by a bit field called INTERFRAME SPACE. In contrast, OVERLOAD FRAMEs and ERROR FRAMEs are not preceded by an INTERFRAME SPACE and multiple OVER- LOAD FRAMEs are not separated by an INTERFRAME SPACE. INTERFRAME SPACE contains the bit fields INTERMISSION and BUS IDLE and, for 'error passive' stations, which have been TRANSMITTER of the previous message, SUSPEND TRANSMISSION.

For stations which are not 'error passive' or have been RECEIVER of the previous message: no Suspend Transmission.

For 'error passive' stations which have been TRANSMITTER of the previous message: with Suspend Transmission.

INTERMISSION consists of three 'recessive' bits. During INTERMISSION no station is allowed to start transmission of a DATA FRAME or REMOTE FRAME. The only action to be taken is signalling an OVERLOAD condition.

BUS IDLE: The period of BUS IDLE may be of arbitrary length. The bus is recognized to be free and any station having something to transmit can access the bus. A message, which is pending for transmission during the transmission of another message, is started in the first bit following INTERMISSION. The detection of a 'dominant' bit on the bus is interpreted as START OF FRAME.

SUSPEND TRANSMISSION: After an 'error passive' station has transmitted a message, it sends eight 'recessive' bits following INTERMISSION, before starting to transmit a further message or recognizing the bus to be idle. If meanwhile a transmission (caused by another station) starts, the station will become receiver of this message.

MESSAGE VALIDATION: The point of time at which a message is taken to be valid, is different for the transmitter and the receivers of the message. Transmitter: The message is valid for the transmitter, if there is no error until the end of END OF FRAME. If a message is corrupted, retransmission will follow automatically and according to prioritization. In order to be able to compete for bus access with other messages, re- transmission has to start as soon as the bus is idle. Receivers: The message is valid for the receivers, if there is no error until the last but one bit of END OF FRAME.

BIT STREAM CODING: The frame segments START OF FRAME, ARBITRATION FIELD, CONTROL FIELD, DATA FIELD and CRC SEQUENCE are coded by the method of bit stuffing. Whenever a transmitter detects five consecutive bits of identical value in the bit stream to be transmitted it automatically inserts a complementary bit in the actual transmitted bit stream. The remaining bit fields of the DATA FRAME or REMOTE FRAME (CRC DELIMITER, ACK FIELD and END OF FRAME) are of fixed form and not stuffed. The ERROR FRAME and the OVERLOAD FRAME are of fixed form as well and not coded by the method of bit stuffing. The bit stream in a message is coded according to the Non-Return-to-Zero (NRZ) method. This means, that during the total bit time the generated bit level is either 'dominant' or 'recessive'.

Error Detection: There are 5 different error types (which are not mutually exclusive):

• BIT ERROR: A unit that is sending a bit on the bus also monitors the bus. A BIT ERROR has to be detected at that bit time, when the bit value that is monitored is different from the bit value that is sent. An exception is the sending of a 'recessive' bit during the stuffed bit stream of the ARBITRATION FIELD or during the ACK SLOT. Then no BIT ERROR occurs when a 'dominant' bit is monitored. A TRANSMITTER sending a PASSIVE ERROR FLAG and detecting a 'dominant' bit does not interprete this as a BIT ERROR.

• STUFF ERROR: A STUFF ERROR has to be detected at the bit time of the 6th consecutive equal bit level in a message field that should be coded by the method of bit stuffing.

• CRC ERROR The CRC sequence consists of the result of the CRC calculation by the transmitter. The receivers calculate the CRC in the same way as the transmitter. A CRC ERROR has to be detected, if the calculated result is not the same as that received in the CRC sequence.

• FORM ERROR: FORM ERROR has to be detected when a fixed-form bit field contains one or more illegal bits.

• ACKNOWLEDGEMENT ERROR: An ACKNOWLEDGEMENT ERROR has to be detected by a transmitter whenever it does not monitor a 'dominant' bit during ACK SLOT.

Error Signalling A station detecting an error condition signals this by transmitting an ERROR FLAG. For an 'error active' node it is an ACTIVE ERROR FLAG, for an 'error passive' node it is a PASSIVE ERROR FLAG. Whenever a BIT ERROR, a STUFF ERROR, a FORM ERROR or an ACKNOWLEDGEMENT ERROR is detected by any station, transmission of an ERROR FLAG is started at the respective station at the next bit. Whenever a CRC ERROR is detected, transmission of an ERROR FLAG starts at the bit following the ACK DELIMITER, unless an ERROR FLAG for another error condition has al- ready been started.

START

5.4 Beispiel einer Kommunikation mit CAN 2.0A

START

5.5 Individuelle Systemanalyse

START

6. Aufgabenstellung

In der Übung

START