Bussysteme in Rebreathern Teil 2

Wie im Teil 1 des Artikel schon angekündigt, beleuchten wir nun die einzelnen unterschiedlichen Bus-Typen. Um es dem geneigten Leser nochmal in Erinnerung zu rufen, es waren der I²C Bus, der ISCAN^TM und der DiveCAN^® die in den aktuellen Rebreathern verbaut werden.
Der I²C Bus wird in AP Diving Rebreathern, also dem Inspiration XPD, dem Inspiration EVP (früher bekannt als Evolution+) und dem Inspiration EVO (auch bekannt als Evolution) verwendet.
Den ISCAN^TM Bus wird von von Innerspace System Corp. genutzt und ist im Megalodon CCR und Pathfinder CCR eingebaut.
Der DiveCAN^® ist am weitesten verbreitet. Er wird in allen Rebreathern verbaut, die Shearwater Elektronik einsetzen. Hierzu gehört z.B. der JJ-CCR, der rEvo, der Hollis Prism2, der SF2 und der O2ptima CCR. Aktuelles Update: seit kurzem wird dieser Bus auch in den XCCR eingesetzt.

I²C Bus

Betrachten wir als aller erstes den I²C Bus da dieser am längsten in Rebreathern Verwendung findet.

I²C bedeutet ausgesprochen Inter-Integrated Circuit. Also I-^hoch2-C oder auch I-quadrat-C, englisch I-Squared-C. Er ist in den 80 Jahren von Philips entwickelt worden, um eine einfache Kommunikation zwischen Elektrobausteinen zu etablieren. Jeder von euch ist mit diesem Bus schon unbewusst mehrfach in Berührung gekommen, und trägt ihn tagtäglich in seiner Brieftasche mit sich. Die Chips der Krankenkassenkarte verwenden diesen Bus. Auch im Fernsehern und CD-Playern wird der I²C Bus verwendet. Seit Einführung der Vision Elektronik im Jahre 2005 wird dieser Bus vom AP-Diving eingesetzt. Er ermöglicht eine Übertragungsgeschwindigkeit von 1 MBit/s, so schnell wie DSL Mitte der 2000er. Es können bis zu 1136! Geräte an diesen Bus angeschlossen werden. Es ist ein so genannter Master – Slave Bus. Für alle Filmfans, das „Highländer Prinzip, es kann nur einen geben“.
Es darf nur ein Gerät Master sein und nur der Master darf senden. Alle anderen Teilnehmer im Bus sind Slave und somit Empfänger. Theoretisch wäre ein Master – Master möglich, aber diese Ausprägung des Bus ist im Rebreather nicht erwünscht und unter uns gesagt auch nicht wirklich sinnvoll. Der I²C Bus benötigt eine Taktleitung (genannt Serial Clock, SCL) und eine Datenleitung (Serial Data, SDA). Das Taktsignal, das jeder Bus braucht, wird über die Taktleitung übertragen. Der Takt wird immer vom Master initiiert. Die eigentlichen Daten werden über die SDA, die Datenleitung übertragen. Der I²C Bus arbeitet mit einer positiven Logik. Dabei werden Informationen mittels Spannungspegeln übertragen, eine Spannung von beispielsweise 5 V entspricht einem HIGH Signal also einer logischen 1, keine Spannung (also 0 V) entspricht einem LOW Pegel und somit einer logischen 0.

Im hier folgenden Bild ist das Beispiel eines Informationspaket im I²C Bus abgebildet. 

 I2C-Bus, Quelle: www.i2c-bus.org

Wir wollen hier gar nicht das komplette Bild auseinander nehmen, wichtig ist hier zu sagen, dass der Beginn eines Paket immer mit einem Start Signal und das Ende eines Paket mit einem Stop Signal versehen ist. Wie diese Signale aussehen wird im Layer 2 (Data Link Layer) des ISO/OSI Referenz Model definiert.

Der Beginn einer Datenübertragung, die Start Bedingung, durch einen I²C Master sieht wie folgt aus: Der Master zieht die Datenleitung (SDA) von HIGH auf LOW herunter, während die Taktleitung (SCL) auf HIGH bleibt. Dazwischen werden dann die eigentlichen Daten übertragen. Ein Datenbit kann, wie in der Digitaltechnik üblich 2 Zustände einnehmen 1 und 0 oder einfacher Spannung oder keine Spannung. Die Daten sind gültig wenn die Taktleitung (SCL) auf HIGH liegt. Ein LOW Pegel auf der Datenleitung (SDA) bedeutet 0, ein HIGH bedeutet 1, die zuvor beschrieben positive Logik.

Beendet wird das Informationspaket durch die Stopp Bedingung. Der Master zieht die Datenleitung (SDA) von LOW auf HIGH, während die Taktleitung SCL auf HIGH bleibt. Die Übertragung ist beendet. Aus Sicht des I²C Masters unterscheidet man zwischen Read und Write Sequenzen. Bei einer Read Sequenz liest der I²C Master Daten vom Slave. Bei einer Write Sequenz sendet der I²C Master Daten zum Slave. Das ist wichtig, da in einem Rebreather die Daten die z.B. ein CO₂ Sensor zur Verfügung stellt, vom Controller gelesen und interpretiert werden müssen.

Im Inspiration von AP Diving ist der I²C Bus wie im folgenden Bild implementiert. Controller C1 und C2 (Chips die im Kopf des Inspiration verbaut sind) sind die Hauptsteuereinheiten in diesem Umfeld. Dabei kann immer nur ein Controller (meist C1) der Master sein, der andere Controller (C2) bleibt Slave. Beide Controller überwachen sich gegenseitig. Sollte der Master Controller ausfallen, wird automatisch der Slave Controller zum Master. Die Daten der Handgelenksanzeige, des Drucksensor, des CO2 Sensor und des Temp-Stik werden über die READ Sequenz auf dem BUS eingespeist und die Daten werden vom Controller verarbeitet und interpretiert. Sollte beispielsweise der CO₂ Pegel im Atemkreislauf zu hoch sein, empfängt der Master Controller die Daten des CO₂ Sensor über den Bus (READ Sequenz) und gibt auf der Handgelenksanzeige eine Warnung „CO2 hoch!“ aus (Write Sequenz). Gleichzeitig wird über diese Write Sequenz eine Warnanzeige auf das Head Up Display und an den Head Up Screen gesendet. 

Wenn ich ein Fazit über den I²C Bus ziehen soll, lasst sich als positiv sagen,

• er hat eine sehr einfache aber effektive Fehlerbehandlung,
• Peripheriegeräte lassen sich sehr einfach integrieren wenn sie den selben Bus verwenden
• Die Zusatzgeräte sind hot plugable (im laufenden Rebreather einsteckbar, werden erkannt und verwendet)
• Sehr hohe Anzahl an Zusatzgeräten möglich (1136 Stück)

Als negative Aspekte ließe sich sagen:

• Die Übertragungsgeschwindigkeit ist langsamer, als in anderen Bussystemen möglich wäre
• Er ist störanfällig gegenüber slektromagnetischen Impulsen
• Probleme kann es an den Kontaktstellen der Zusatzgeräte geben
• I2C Bus ist ungeeignet zur Überbrückung von großen Entfernungen (max. 100m)

DiveCAN® + ISCAN ^TM

Ich fasse in diesem Teil den DiveCAN® und den ISCAN^TM zusammen, da sich Beide sehr ähnlich sind und den gleichen Ursprung haben, den CAN Bus.
CAN steht für Controller Area Network und wurde für die Fahrzeugindustrie entwickelt. Im Teil 1 habe ich einiges über die Anforderungen der Automobileindustrie schon geschrieben, deswegen will ich hier gar nicht weiter darauf eingehen.

Der CAN Bus wurde in Zusammenarbeit von Bosch und Intel entwickelt. Er findet mittlerweile sehr weite Verbreitung in anderen Industriezweigen. So werden Feuerlöschanlagen über den FIRECAN implementiert (wurde wohl nicht am neuen Berliner Flufhafen eingesetzt ;-) ). E-Bikes verwenden den EnergyBUS, Kampfjets und zivile Flugzeuge verwenden den CANAEROSPACE die alle auf dem CAN Bus aufsetzen. Die im CAN Bus verwendete Leitung ist eine zweiadrige, symmetrisch verdrehte Leitung (twisted pair) mit einem Durchmesser von 0,35 mm². Die Enden des CAN-Busses müssen mit 120 Ohm Abschlusswiderständen terminiert werden.

Die Signale werden auf beide Leitungen gleichzeitig gelegt, aber mit einer gegensinnigen Potenzänderung. Es gibt 2 Signalpegel CAN HIGH und CAN LOW. Wie diese Signale dargestellt werden hängt ab, ob es sich um einen Highspeed CAN oder Low Speed CAN handelt. Der DiveCAN® verwendet den High-Speed CAN nach ISO 11898 2 deswegen werden wir hier nur diesen beleuchten. Es gibt ein rezessives Signal und ein dominates Signal. Beim rezessiven liegt die Spannung auf beiden Leitungen bei 2,5V. Das entspricht einer logischen 1. 

 

CAN-Bus Pegel, Quelle: Lawrenz W CAN Grundlagen und Praxis

Für ein dominates Signal muss der Pegel auf dem CAN HIGH auf 3,5 V angehoben werden und auf CAN LOW auf 1,5 V abgesenkt werden. Damit wird die logische 0 dargestellt. Also wenn die Spannung auf beide Leitungen gleich ist, ist es eine 1. Bei einer Spannung Differenz von 2 V zwischen CAN HIGH und CAN LOW ist es eine 0. Das entspricht dem genauen Gegenteil des I²C Bus und wird als negative Logik bezeichnet. 

CAN-Bus Frame Aufbau, Quelle: www.wikipedia.de

Die eigentliche Datenübertragung erfolgt in so genannten Frames (siehe Bild oben). Diese haben immer einen Start Frame, das ist immer eine logische 0. Anschließend werden die Daten übertragen. Auch hier gibt es noch weitere Unterteilungen innerhalb des Frames, die ich gar nicht tiefer erörtern möchte, da es den Rahmen hier sprengen würde. Wichtig ist nur zu erwähnen, dass ein Frame Ende immer mit 7 Bit rezessiven Signals, also 7 aufeinanderfolgenden 1en dargestellt wird. 

Shearwater Research hat den CAN-Bus ausgewählt und daraus den schon oben genannten DiveCAN® entwickelt, der speziell auf die Bedürfnisse der Kreislauftauchgeräte angepasst wurde. Es basiert, wie ebenfalls schon erwähnt, auf dem ISO 11898-2 Standard. Ist aber herstellerspezifisch (proprietär) angepasst. So verwendt Shearwater beispielsweise einen 560 Ohm Abschlusswiederstand am Master. Dadurch benötigen die angeschlossenen Geräte keinen Abschlusswiederstand mehr, aber die Anzahl der anschliessbaren Geräte reduziert sich auf 9. Weiterhin bedeutet das ein DiveCAN® Controller eines rEvo nicht mit einem JJ-CCR funktionieren würde, obwohl sie beide den DiveCAN® Controller Bus verwenden. Der Grund dafür ist recht simpel, jeder Rebreather erwartet bestimmte Geräte die an seinem Bus angeschlossen sind. 

 

Schema DiveCAN Bus, Quelle www.shearwater.com

Somit würde beispielsweise ein rEvo Controller mit RMS an ein Prism2 anschliessbar sein, würde aber ein Fehler melden da der Controller die RMS Geräte nicht finden würde.

Der DiveCAN® kann die Datenpakete nach Wichtigkeit priorisieren und ist in der Lage, die Daten in Echtzeit zu übertragen. So hat zum Beispiel eine Warnmeldung im DiveCAN® die MeldungsID "0x02" hingegen der pO₂ die MeldungsID "0x04". Der Umgebungsdruck/Tiefe hat die MeldungsID "0x08"  Je niedriger die MeldunsID, desto wichtiger ist die Meldung. In diesem Fall würde also die Warnmeldung immer vor dem pO₂ vom Bus übertragen und angezeigt werden. Erst nach diesen 2 Informationen würde die aktuelle Tiefe übertragen und dargestellt. Was auch deutlich Sinn macht.

Aber wie ist so ein DiveCAN® System nun aufgebaut?

Die minimalste Konfiguration wäre nur ein Bus und zwar der Control Bus. Da aber die meisten Rebreather auf redundante Systeme Wert legen, wird ein zweiter unabhängiger Bus eingebaut, der Monitoring Bus. Beide stecken zwar in einem Gehäuse, sind aber getrennt und vollkommen unabhängig voneinander.

 

Der DiveCAN® Control Bus 

Der Control Bus besteht aus den SOLO-Board (Solenoid & Oxygen) und dem Controller. Das SOLO-Board hat Verbindung zu den Sauerstoff-Sensoren und zu dem Solenoid. Der Bus kann über einen optionalen Port erweitert werden, dem Auxiliary Port. Darüber können zusätzlich Geräte angeschlossen werden, z.B. eine Kalküberwachung (das so genannte rMS, rEvo Monitoring-System). Sollte im Bus ein Gerät erwartet werden aber nicht erkannt werden, so wird dieses Gerät als fehlerhaft angesehen und markiert. Lässt man sich am Shearwater Petrel die Geräte anzeigen die an dem Bus angeschlossen sind, erhält man folgende Anzeige.

 

 

Der DiveCAN® Monitoring Bus

Der Monitoring Bus ist ein eigenständiger Bus, der keinerlei Verbindung zum Control Bus hat. Er ist an der OBOE (Oxygen Board Electronic) angeschlossen. Dieses Board hat ausschließlich Zugriff auf Sauerstoffsensoren, und hat keinen Zugriff auf den Solenoid. Wie der Name schon sagt, hat er eine reine Monitoring Funktion, also rein überwachend. Schließt man einen Controller oder ein NERD (dieser muss für den Monitoring-Bus konfiguriert sein) an diesen Bus an, kann man sich ebenfalls die angeschlossenen Geräte anzeigen lassen und bekommt diese Anzeige.

Beide Busse sind High Speed Busse und können somit eine Übertragungsrate von bis zu 3 Mbit erreichen. Alle Systemkritischen Funktionen verfügen somit über Redundanz. So kann zum Beispiel das SOLO-Board das Solenoid steuern, für den Fall, das der angeschlossene Controller ausgefallen ist. Signale die auf dem Bus gesendet werden, werden nur richtig empfangen oder werden sofort verworfen. Somit ist eine Verarbeitung fehlerhafter Werte ausgeschlossen.

Wenn ich auch ein Fazit über den DiveCAN Bus ziehen soll, lässt sich als positiv sagen:

• er hat eine sehr robuste, auf Fehler überwachte Kommunikation
• basiert auf einem ISO Standard (weltweit gleich)
• Die Zusatzgeräte sind hot plugable (im laufenden Rebreather einsteckbar, werden erkannt und verwendet)
• Echtzeitübertragung der Daten ist möglich

Als negative Aspekte ließe sich sagen:

• Derzeit nur bis 9 Geräte erweiterbar
• Die verwendeten Kabel sind sehr teuer
• Ebenfalls ungeeignet zur Überbrückung von großen Entfernungen (max 100m)

In den ECC-Rebreathern ist diese Technologie nicht mehr weg zu denken. Meiner Meinung nach, ist es ein riesiger Zugewinn an Sicherheit. Es werden einfach Fehlerquellen minimiert, und die Task-Load des Tauchers in einer Stresssituation drastisch verringert. Diese Technologie lässt zudem den Weg in die Zukunft offen, um neue Geräte und Erweiterungen anzuschließen und einfach integrieren zu können. So könnten bald Flaschendrucksensoren, Temperatursensoren, oder auch eine Near Field Comunication an die Bussysteme angeschlossen werden. Trotz aller tollen Technik, die hier beschrieben wurde, muss der Rebreather Taucher trotzdem die Funktionsweise seines Rebreathers kennen und verstanden haben! Die Notfall-Skills müssen weiterhin trainiert werden, und er sollte immer seinen Kopf beim Tauchen einschalten! Bussysteme werden dem Taucher trotz High-Tec nicht das Denken und Wissen abnehmen können.