A A A
| Sitemap | Kontakt | Impressum | Datenschutz
ETZ Logo VDE Verlag Logo

CANopen im Operationsroboter

Bild 1. Prototyp des Operationsroboters mit über CANopen vernetzten Komponenten

Bild 2. Das Bildschirmfoto der Roboter-Benutzeroberfläche zeigt die dreidimensionale Navigation

CANopen ist ein auf dem international genormten CAN-Protokoll (ISO 11898-1) basierendes technisches Kommunikationssystem, das in vielen medizinischen Geräten und in industriellen Handhabungssystemen eingesetzt wird. Deshalb ist es naheliegend, in medizinisch-technischen Robotern ebenfalls CANopen-Netzwerke zu verwenden. Das Surgical Planning Laboratory des Brigham and Women’s Hospital in Boston/USA untersuchte deshalb, ob CANopen-Netzwerke für Operationsroboter geeignet sind. Es wurde hierzu eine Software entwickelt, die Navigationssensoren in ein CANopen-Netzwerk einbindet.

Für den Operationsroboter (Bild 1) des Surgical Planning Laboratory des Brigham and Women’s Hospital kommt soweit wie möglich standardisierte Software zum Einsatz, die als Open-Source-Programm verfügbar ist. Dies hilft, die Entwicklungszeiten zu verkürzen.
Als CANopen-Protokollstack entschied man sich für Canfestival, ein Open-Source-Programm, welches ursprünglich aus Frankreich stammt. Außerdem wurde die entwickelte Software in das „Image-Guided Surgery Toolkit“ integriert, was die Fehleranfälligkeit reduzierte. Die Software wurde exemplarisch bei einem Robotersystem zum Positionieren einer Nadel verwendet. Dieses System eignet sich sowohl für Biopsien als auch für Prostatakrebsbehandlungen.
Mithilfe eines Magnetresonanztomographen (MRI: magnetic resonance imaging) kann dabei jederzeit die Position der Nadel überprüft werden (Bild 2). Während die Verwendung eines MRI-Scanners hohe magnetische Felder und wenig Handlungsfreiheit für einen Chirurgen mit sich bringt, kann ein Roboter unter diesen Bedingungen ohne Einschränkungen arbeiten. Das Robotersystem bewegt die Nadel durch Zielpunkte, die vorher von dem Chirurgen festgesetzt werden.

Das CANopen-Netzwerk dient als Kommunikationssystem zwischen der Steuerung und dem Navigationsmodul. Der Prototyp wurde an der Johns Hopkins Univeristät in Baltimore/USA in Kooperation mit dem oben erwähnten Labor in Boston realisiert.
Der Test der entwickelten Software erfolgte zusammen mit einem elektromagnetischen Nachführgerät. Auch dieser Test war erfolgreich. Die maximale Datenübertragungsrate von 1 Mbit/s auf dem CANopen-Netzwerk sowie die Robustheit (elektromagnetische Verträglichkeit) und die Zuverlässigkeit (Restfehlerwahrscheinlichkeit) der CAN-Hard-ware erfüllten die Anforderungen der Medizintechniker. Auch die hohe Flexibilität und Konfigurierbarkeit von Prozessdatenobjekten erwies sich als vorteilhaft.
Allerdings gibt es noch keine standardisierten CANopen-Profile für Naviga-tionssensoren und Nachführeinheiten. Die bereits für medizintechnische Anwendungen realisierten CANopen-Profile (CiA 412: Kollimator und Dosismeter; CiA 425: Kontrastmittelinjektor) können als Vorbilder für eine Standardisierung auf der Anwendungsebene dienen.

Optimierung der PDO-Kommunikation
Eine der wichtigen Eigenschaften von CANopen ist die Optimierung der Kommunikation von Prozessdatenobjekten (PDO). Diese nutzen eine CAN-Nachricht, die bezüglich der Übertragung und der Inhalte konfigurierbar ist. Jedes CANopen-Gerät kann theoretisch bis zu 512 PDO empfangen und bis zu 512 PDO senden.
Viele Systemdesigner möchten Prozessdaten periodisch übertragen, da auch die geräteinterne Datenbearbeitung periodisch erfolgt. Dazu kann man in CANopen den PDO-Event-Timer ungleich Null setzen. Dieser Parameter ist im Objektverzeichnis mithilfe der SDO-Dienste (Servicedatenobjekt) konfigurierbar.
Diese Übertragungsart ist aus Sicht der Busbandbreite allerdings nicht optimal. Die Busbandbreite ist in CAN-basierten Systemen ein kritischer Wert, da er von der Länge des Netzwerks determiniert ist. Je länger der Bus, desto geringer ist die maximale Datenrate (von 1 Mbit/s bei 25 m bis zu 50 kbit/s bei 1 km).

Bei einer periodischen Übertragung wird der Wert auch gesendet, wenn er sich nicht geändert hat. Er ist also aus Anwendungssicht redundant. In CAN-Netzwerken ist deshalb eine Übertragung zu bevorzugen, bei der nur dann gesendet wird, wenn sich eine der gemappten Prozessdaten geändert hat. Mit dieser Scheduling-Methode kann man die Buslast auf ein Minimum reduzieren. Diese asynchrone „Change-of-state“-Übertragung ist deshalb zu bevorzugen.
Der Systementwickler muss allerdings berücksichtigen, dass sich alle Prozessdaten zum gleichen Zeitpunkt ändern können und sozusagen eine PDO-Flut ausgelöst wird. Die periodische PDO-Übertragung löst dieses Problem jedoch auch nicht: Da der Event Timer von der lokalen Uhr getriggert wird, die nicht mit den Uhren der anderen Teilnehmer synchronisiert ist, werden zu einem Zeitpunkt alle PDO getriggert und erzeugen so eine hohe permanente Buslast.

Gleichmäßige Buslast
Um eine möglichst gleichmäßige Buslast zu erzeugen, gibt es deshalb in CANopen die synchrone Übertragung von PDO. Dabei sendet ein Teilnehmer die Sync-Nachricht. Wenn diese empfangen wird, erfassen die CANopen-Geräte die Sensor- und Status-Prozessdaten und senden diese in sogenannten synchron-zyklischen PDO. Dabei hat der Systementwickler die Möglichkeit, das synchrone PDO so zu konfigurieren, dass es bei jeder Sync-Nachricht die Daten erfasst oder bei jeder zweiten, dritten oder bis zur 240sten. So lässt sich die benötigte Busbandbreite für niederfrequente Prozessdaten reduzieren.
Trotzdem kann es passieren, dass Prozessdaten redundant übertragen werden, da sich der Wert über einen längeren Zeitraum nicht ändert. Um dies zu vermeiden, gibt es in CANopen die synchron-azyklischen PDO. Diese werden nur ausgelöst, wenn eine Sync-Nachricht empfangen wurde und eine „Change-of-state“-Bedingung vorliegt, also sich der Wert gegenüber dem letzten Wert verändert hat.
Mit den unterschiedlichen Scheduling-Arten kann der Systementwickler die PDO-Kommunikation an seine Anwendung optimal anpassen. Selbstverständlich unterstützen ihn dabei die am Markt angebotenen CANopen-Konfigurationstools. Dies geht soweit, dass die Werkzeuge die gesamte Optimierung vornehmen. Der Anwender muss also keine tiefen CANopen-Kenntnisse haben; er muss sich allerdings auf die im Tool implementierten Optimierungsalgorithmen verlassen.

Optimierung mittels Mapping
Sind alle für eine Anwendung relevanten und zusammengehörigen Prozessdaten in demselben PDO untergebracht, muss der Anwender nichts optimieren. Werden aber beispielsweise ein Byte aus einem PDO und ein weiteres Byte aus einem anderen PDO für eine Aufgabe benötigt, so hat der Systementwickler die Möglichkeit, die beiden Werte in ein PDO zu packen (engl.: to map). Dazu kann man ein neues PDO kreieren oder eines der beiden vordefinierten PDO ummappen. Dazu gibt es im CANopen-Objektverzeichnis für jedes PDO eine Zeigerliste, die auf die zu mappenden Prozessdaten verweist. Die Zeigerliste enthält die „Adressen“ (16-bit-Index und 8-bit-Subindex) der Prozessdaten, die in dem jeweiligen PDO zu übertragen sind.
Theoretisch kann man bis zu 64 1-bit-Prozessdaten in einem PDO übertragen. Man muss allerdings nicht die gesamte Länge des PDO (8 Byte) ausnutzen. Wenn man nur 4-Byte-Prozessdaten benötigt, wird man, um die Buslast zu reduzieren, ein entsprechend kurzes PDO versenden. Dies erhöht zwar relativ den Anteil des Protokoll-Overheads, reduziert jedoch den absoluten Anteil an der Busbandbreite.

Viele am Markt befindliche E/A-Module unterstützen solch ein variables PDO-Mapping. Es kann komfortabel mithilfe von Softwarewerkzeugen genutzt werden. Bei einigen Tools erfolgt die Optimierung der PDO von E/A-Modulen sogar automatisch oder zumindest semi-automatisch. Von variablem PDO-Mapping spricht man, wenn die Konfiguration im Netzwerkmanagement-Zustand (NMT-Status) „pre-operational“ erfolgt. In diesem Zustand darf das CANopen-Gerät keine PDO senden und empfangen. Somit muss der Systementwickler bei der Konfiguration nicht darauf achten, dass die PDO-Sender und -Empfänger jederzeit konsistent konfiguriert sind. Erst wenn die an der PDO-Kommunikation beteiligten Geräte in den NMT-Status „operational“ geschaltet werden, müssen Sende- und Empfangsseite konsistent konfiguriert sein.

Der Beitrag als pdf

Autor: Sandra Gussner ist Studentin der Elektrotechnik und absolviert ein Praktikum beim CAN in Automation (CiA) e. V. in Nürnberg.

Autor: Dipl.-Ing. Holger Zeltwanger ist Initiator und geschäftsführendes Vorstandsmitglied der Anwender- und Herstellervereinigung CAN in Automation (CiA) e. V.