Bereits in den Anfängen des Controller Area Networks (CAN) erkannte die Firma Philips Medical Systems die Vorteile von CAN und hat sich für den Einsatz dieses Kommunikationsprotokolls bei der Vernetzung verschiedenster Komponenten, wie z.B. Blenden, Generatoren und Patiententischen, in ihren Röntgensystemen entschieden.
Für die Realisierung eines modularen und offenen Systems wurde hierbei von Philips Medical Systems, geleitet durch Tom Suters, das erste höhere Protokoll für CAN entwickelt, die CAN-Nachrichtenspezifikation "CMS", welche 1992 erstmalig veröffentlicht wurde. CMS diente als Gerüst für das erste offizielle CAN-basierte Kommunikationsprotokoll CAL "CAN Application Layer", spezifiziert durch die Nutzervereinigung "CAN in Automation e.V.". Mit dem CAL-Protokoll konnte jedoch nur eine geringe Marktdurchdringung erreicht werden. Grund hierfür könnte unter anderem die fehlende Funktionalität in Hinsicht auf eine durchgängige Beschreibung von generischen Geräte- oder Anwendungsprofilen sein.
Aus diesem Grund wurde der CANopen-Application-Layer und das CANopen-Kommunikationsprofil als "CAN in Automation" Standard definiert und 1996 offiziell veröffentlicht. Mit CANopen wurde das Rad nicht neu erfunden, sondern es wurden wesentliche Elemente des CAL-Protokolls weiterverwendet und durch fehlende aber notwendige Funktionen erweitert, wie z.B. dem Objektverzeichnis, mit dem auf einfache Weise eine Beschreibung und Referenzierung von Anwendungsdaten möglich ist. Tatsächlich wird CANopen heute als grundlegende Technologie für den Einsatz von CAN in vielen verschiedenen Anwendungen anerkannt.
Vorteile von CANopen beim Einsatz in medizinischen Systemen
Die Notwendigkeit von Datenkommunikationssystemen in medizinischen Anwendungen wird heutzutage immer offensichtlicher. Gründe hierfür sind die steigenden Anforderungen in Bezug auf:
- Interoperabilität, die vorrangig für den Datenaustausch zwischen medizinischen Geräten erforderlich ist, aber auch die Realisierung von modularen Architekturen bei medizinischen Geräten ermöglicht. Gleichzeitig ermöglicht die Interoperabilität eine zentrale Steuerung von verschiedenen medizinischen Geräten. Dies ist ein wichtiger Faktor zur Entwicklung von verbesserten und schonenderen bzw. erträglicheren Untersuchungsverfahren.
- Verbesserung des autarken Betriebs von medizinischen Geräten für unbeaufsichtigte Untersuchungen und die Verbesserung der Patientensicherheit.
- Kostenreduzierung aufgrund einer höheren Modularität von medizinischen Geräten und einer schnelleren Durchführung von Untersuchungen und Behandlungen.
Der Einsatz von Ethernet TCP/IP oder eines der aufkommenden industriellen beziehungsweise Real-Time-Ethernet-Protokolle als Datenkommunikationssystem für Steuerungszwecke wie z.B. für die Übertragung von Steuerungsdaten, Befehlen oder Parametern, ist nicht unbedingt sinnvoll.
Im Vergleich zu CAN, werden beim Einsatz von Ethernet leistungsstärkere und deshalb teurere CPUs benötigt, was zu einer Verteuerung der Hardware führt (dies trifft besonders bei hochqualitativen PHYs, Umformern und Steckverbindern zu). Eine sichere und verlustlose Datenübertragung ist nur mit Protokollen möglich, bei denen ein Bestätigungsmechanismus bereits implementiert ist oder die über eine zyklischen Datenübertragung verfügen.
Bei freien bzw. willkürlichen Technologien ist die Verdrahtung von CAN-Installationen in der Regel kostengünstiger, verglichen mit Ethernet-Netzwerken bei denen zusätzliche Topologiekomponenten wie Switches oder Hubs eingesetzt werden müssen.
Dennoch ist die Verwendung der Ethernet-Technologie in medizinischen Systemen sinnvoll, z.B. zur Übertragung von großen Datenmengen (Patientendaten oder Diagnoseergebnisse), welche nicht zeitkritisch sind und typischerweise mittels einer Peer-to-Peer-Verbindung zwischen Sender und Empfänger ausgetauscht werden.
Medizinische Geräte haben sehr spezifische Anforderungen an die verwendeten Kommunikationssysteme, besonders in Hinsicht auf die Gerätesteuerung. Diese Anforderungen sind: Sehr hohe Zuverlässigkeit und Fehlerrobustheit bei der Datenübertragung, kurze Wartezeiten bei der Übertragung von wichtigen und hochprioren Daten, kurze Fehlererholzeiten, Datenübertragung im Broadcast- (Producer/Consumer-Prinzip) und auch im Client/Server-Betrieb, niedrige Einführungskosten und einfache Handhabung.
Die Anforderungsanalyse eines Röntgensystems zeigt, dass sich CANopen sehr gut als internes Kommunikationsnetzwerk für die Verbindung der Module und Funktionen innerhalb des Systems sowie zur Anbindung von externen Erweiterungen an das Röntgensystem eignet. Aufgrund der Natur von CAN, bietet CANopen eine sehr hohe Fehlerzuverlässigkeit, kurze Warte- und Fehlererholzeiten, eine robuste Datenübertragung, vielfältige Möglichkeiten zur Modularisierung von Systemen und Netzwerken, Plug&Play-Unterstützung und standardisierte Systemdienste. Dies ermöglicht die Realsierung von flexiblen Netzwerktopologien zu niedrigen Preisen. Des weiteren ist die CAN- und CANopen-Technologie bereits vom TÜV Deutschland und dem FDA in den USA für den Einsatz in medizinischen Systemen anerkannt, da hier bereits eine Reihe von zugelassenen Anwendungen diese Technologie nutzen.
Innerhalb des CAN in Automation e.V. arbeitet eine "Special Interest Group" an der Spezifikation von Geräten und Anwendungsprofilen für medizinische Geräte und Anwendungen (SIG Medical Devices), mit einem speziellen Fokus auf Röntgensysteme. Der aktuelle Status in Hinsicht auf verfügbare oder geplante CANopen-Profile für medizinische Geräte ist in der Textbox auf dieser Seite aufgeführt.
|
Implementierung einer CANopen-Master-Schnittstelle
Bei der Implementierung einer CANopen-Master-Schnittstelle in ein medizinisches Gerät (z.B. Röntgensystem) sollte bereits in der frühen Designphase auf die spätere einfache Einrichtung und Wartung des modularen CANopen-Netzwerkes geachtet werden.
Das Röntgengerät selber besteht aus einer Vielzahl von Funktionsmodulen, wie z.B. dem Generator, der Blende, dem Patiententisch, einem Dosierungsmesssystem und optionalen Geräten zur Erweiterung des Systems, welche in das Netzwerk integriert werden können um die Gesamtfunktionalität des Systems zu erhöhen. Zusätzliche externe medizinische Geräte können mit dem Röntgensystem verbunden werden und sollten von dem Röntgensystem, abhängig von den Anforderungen der Untersuchung, gesteuert werden. Typische Beispiele für solche externen Geräte sind Kontrastmittelinjektoren oder Elektrokardiographen.
Die von IXXAT vorgeschlagene CANopen-Master-Schnittstellenlösung basiert auf der klaren Trennung von Anwendung und Kommunikationssoftware. Der Vorteil dieses Ansatzes ist, dass bestehende Anwendungen leichter mit einer CANopen-Kommunikationsschnittstelle ausgerüstet werden können, ohne dass hierfür größere Änderungen an der bestehenden Software durchgeführt werden müssen. Mögliche Seiteneffekte, welche durch die Ausführung der CANopen-Protokollsoftware als Teil der Geräteanwendung auftreten können, werden auf diese Weise minimiert.
Im Regelfall besteht die Hauptsteuereinheit bei Röntgensystemen aus einem PC oder einem embedded PC mit Windows, Linux oder QNX als Betriebssystem sowie einer PCI oder PCIe Schnittstelle. Somit können für die Implementierung der CANopen-Master-Funktionalität aktive PCI oder PCIe CAN-Karten zum Einsatz kommen. Durch die CPU auf der aktiven CAN-Karte können der Datenaustausch und die CANopen-Dienste unabhängig von der Steuerungsanwendung des Röntgengerätes ausführen werden, empfange oder zu sendende Daten werden über eine Dual-Ported-Memory Schnittstelle mit der Steuerungsanwendung ausgetauscht. Die CAN-Karte muss hierbei den elektrischen Anforderungen der IEC60601-1 (Bild 1) entsprechen.
Bild 1: Aktives PCI/PCI-Express CAN-Interface von IXXAT Automation GmbH für den Einsatz in medizinischen Geräten, elektrisch Konform gemäß IEC60601-1.
Der CANopen-Master basiert auf der CANopen-Manager-Protokollsoftware von IXXAT. Dieses Softwarepaket beinhaltet eine vollständige Implementierung eines CANopen-Masters, inklusive der standardisierten Boot-Up-Prozedur gemäß CiA302-2, einem Konfigurations-Manager gemäß CiA302-3 sowie der Handhabung von PDO-Daten als Netzwerkvariablen gemäß CiA302-4.
Die standardisierte Boot-Up-Prozedur beinhaltet Mechanismen zur Überprüfung der Netzwerkkonsistenz. Hierbei wird geprüft ob alle zu erwartenden Slave-Knoten im System vorhanden sind und ob deren Typ und Version übereinstimmt. Hierdurch wird sichergestellt, dass die Knoten mit genau der Konfiguration arbeiten, die dem Netzwerk und der Anwendung entspricht. Ergänzend zu den Standard-Mechanismen, stellt die CANopen-Manager Implementierung von IXXAT eine einzigartige automatische Boot-Up-Funktionalität zur Verfügung, bei der das Netzwerk ohne CANopen-Slave-Geräteliste gestartet wird und bei der alle CANopen-Geräte während des Boot-Up-Vorgangs selbstständig gesucht und identifiziert werden. Vor dem Start des Röntgengerätes und der Untersuchung muss die Steuerungsanwendung nur prüfen, ob alle erwarteten (mandatory) Geräte im CANopen-Netzwerk verfügbar sind und funktionieren.
Ein Vorteil dieser Lösung ist, dass sich die Anzahl und Art der CANopen-Slave-Geräte in einem CANopen-Netzwerk ändern kann, ohne dass bei jeder Änderung neue Netzwerkkonfigurationsdaten generiert und in den CANopen-Manager heruntergeladen werden müssen. Die Steuerungsanwendung des Röntgensystems kennt in der Regel die verschiedenen Netzwerkkonfigurationen und ist in der Lage zu prüfen, ob die im CANopen-Netzwerk vorhanden Geräte der Konfiguration entsprechen. Ein typisches Szenario ist hierbei z.B. der Einsatz verschiedener Injektoren, welche je nach Art der Untersuchung zum Einsatz kommen und mit dem Röntgengerät verbunden werden müssen.
Des weiteren identifiziert der Boot-Up-Mechanismus welche Daten von den Geräten übertragen werden. Diese Information kann für die Implementierung fest zugeordneter Softwaremodule für die verschiedenen Geräte im Netzwerk verwendet werden und ermöglicht den Austausch von gerätespezifischen Daten mit der Anwendung.
Bild 2: CANopen-Manager-Softwarearchitektur für Steuerungsanwendungen in Röntgengeräten.
Bild 2 zeigt die vollständige Softwarearchitektur des im Röntgengerät befindlichen PCs. Die CANopen-Manager-API stellt die Verbindung zur CANopen-Manager-Software her, die auf der aktiven CAN-Karte ausgeführt wird. Die API besteht aus einer Kommandoschnittstelle für die Steuerung des CANopen-Masters (mit Diensten wie Init, Reset, Start Boot-up, Netzwerk-Start/Stop), einer Diagnose- und Zustandsschnittstelle und einer Prozessdatenschnittstelle. Basierend auf der CANopen-Manager-API werden für jeden Gerätetyp angepasste Softwaremodule implementiert, welche eine für die Steuerung des jeweiligen Gerätes angepasste Anwendungsschnittstelle zur Verfügung stellen. Ein Modul für eine Blende könnte so z.B. API-Funktionen wie CollimatorShutterPosition(), ReportShutterStatus(), SetCommand(), ReportRuler(), ReportTemperature() und weitere zur Verfügung stellen. Die API-Funktionen für einen Injektor wären z.B. SetInjectorState(), ReadInjectorState(), SetVolume() oder GetCurrentFlowRate().
Bei Verwendung dieser API-Funktionen würde die Steuerungsanwendung des Röntgengerätes keine Kenntnis über CANopen-spezifische Aspekte benötigen (z.B. Geräte Node-ID, Index und Sub-Index für die Adressierung von Parametern und PDO-Mapping). Die gerätespezifischen Softwaremodule würden all diese erforderlichen Informationen grundsätzlich wissen und Informationen, die laufzeit- oder konfigurationsspezifisch sind, vom CANopen-Manager abrufen. Ein Softwaremodul mit einer API für die Systemsteuerung ist schlussendlich für die Steuerung des System-Start/Stop und für die Systemkonsistenz verantwortlich.
Eine Trennung von der Steuerungsanwendung des Röntgengerätes auf dem (embedded) PC und der CANopen-Protokollverarbeitung auf der aktiven CAN-Interfacekarte hat den Vorteil, dass bei einer Fehlfunktion der Steuerungsanwendung im Röntgengerät der CANopen-Manager immer noch in der Lage ist das Netzwerk kontrolliert herunterzufahren. Um diese Funktionalität zu realisieren ist ein Überwachungs- und Watch-Dog-Mechanismus zwischen CANopen-Manager und der Steuerungsanwendung des Röntgengerätes implementiert.
Implementierung einer CANopen-Slave-Schnittstelle
Für die Implementierung einer CANopen-Slave-Schnittstelle in ein medizinisches Gerät stehen zwei Möglichkeiten zur Verfügung: die Implementierung des CANopen-Slaves auf der gleichen CPU, auf der auch die Geräteanwendung läuft, oder die Verwendung eines separaten aktiven CAN-Schnittstellenmoduls, auf welchem die CANopen-Slave-Funktionalität implementiert wird.
Bild 3: Softwarearchitektur eines medizinischen Gerätes basierend auf dem IXXAT CANopenRT-Protokollsoftware.
Bei der ersten Variante wird die CANopen-Slave-Protokollsoftware zusammen mit der Anwendung implementiert, wobei die Anwendung direkt auf die im Objektverzeichnis definierten Daten und Parameter zugreift. Abhängig von der Funktionalität und Komplexität des medizinischen Gerätes kann, z.B. wenn eine Anwendung aus verschiedenen Tasks besteht, welche mit der CANopen-Protokollsoftware interagieren sollen, ein Betriebssystem zum Einsatz kommen.
Vor allem in Hinsicht auf diese Art der Systemarchitektur bietet IXXAT mit CANopenRT einen CANopen-Protokollsoftware an, der speziell für den Einsatz in Echtzeit- oder Multitasking-Betriebssystemen entwickelt wurde. Im Vergleich zur normalen CANopen-Protokollsoftware, die zwar im Prinzip multitaskingfähig ist, jedoch andere Tasks solange blockieren bis ein Task eine API-Funktion des CANopen-Protokollsoftware ausgeführt hat (sogar wenn der andere Task eine höhere Priorität hat), verfügt die CANopenRT-Software über eine API, welche die Verwendung der API durch mehrere Tasks ohne eine gegenseitige Blockierung ermöglicht (Bild 3).
Die zweite Lösung, also die Verwendung eines aktiven CAN-Schnittstellenmoduls, ist eine interessante Alternative für Anwendungen, bei denen das medizinische Gerät bereits als Hard- und Software existiert und eine Erweiterung um eine CANopen-Slave-Schnittstelle ohne größere Änderungen an dieser Hard- und Software implementiert werden soll. Bei derartigen Lösungen kann das aktive CAN-Schnittstellenmodul mittels lokaler Schnittstelle (PCI, PCIe, Ethernet, USB oder lokalem Adress-/Datenbus) mit der Steuerungshardware des medizinischen Gerätes verbunden werden.
Ein Beispiel für eine solche Lösung sind Injektoren, die mit einer CANopen-Schnittstelle gemäß CiA425-1/2 erweitert werden müssen. Typischerweise kommt bei Injektoren ein Anwender-Terminal zum Einsatz, welches auf einem embedded System mit Display und Windows, Linux oder QNX als Betriebssystem basiert. Das Terminal steuert alle Funktionen des Injektors und stellt eine Anwenderschnittstelle für die Bedienung zur Verfügung. Die sicherheitsrelevante Steuerung zur Durchführung der Injektion wird von einem speziellen zweiten embedded System durchgeführt. Das zweite System erhält seine Befehle vom Anwender-Terminal und sendet Status-Informationen an dieses zurück.
Die CANopen-Schnittstelle, zur Steuerung des Injektors vom Röntgengerät (Scanner) aus, muss im Anwender-Terminal implementiert werden. Um hierbei größere Änderungen an der Terminal Hard- und Software zu vermeiden, kann ein aktives CAN-Schnittstellenmodul entwickelt werden, welches über eine bereits im Terminal vorhandene Schnittstelle mit diesem verbunden wird (z.B. USB oder Ethernet) und das von seiner Form und dem Gehäuse zum Terminal passt (möglicherweise ist auch die direkte Integration im Terminal-Gehäuse möglich).
Die vollständige CANopen-Slave-Funktionalität, mit Injektor-Objektverzeichnis, wird dann auf dem aktiven CAN-Schnittstellenmodul implementiert. Der CANopen-Slave bearbeitet alle PDO und SDO Schreib- und Lesezugriffe auf die Objektverzeichniseinträge, abhängig von der momentanen Injektor-Betriebsart sowie des Status der Injektor Zustandsmaschine, jedoch ohne die Daten zu bearbeiten oder Übertragungen innerhalb der Injektor-Zustandsmaschine auszuführen. Alle Daten und Status-Informationen die von dem aktiven CAN-Schnittstellenmodul empfangen werden, werden der auf dem Terminal laufenden Injektor-Anwendung über die Terminal-Schnittstelle mitgeteilt. Die Injektor-Anwendung verarbeitet die Daten, entscheidet wann Zustandsänderungen in der Injektor-Zustandsmaschine ausgeführt werden und bearbeitet die Daten, die über das CAN-Schnittstellenmodul an den CANopen-Master (Röntgensystem) gesendet werden.
Für den Daten-, Status und Befehlsaustausch zwischen der Injektor-Anwendung auf dem Terminal und dem CANopen-Slave auf dem aktiven CAN-Schnittstellenmodul wird eine schlanke API bereitgestellt.
Da alle CANopen relevanten Funktionen, Mechanismen und Zeiteinteilungen auf dem aktiven CAN-Schnittstellenmodul bearbeitet und ausgeführt werden, müssen von der Injektor-Anwendung nur die Prozess- und Anwendungsdaten bearbeitet sowie die Zustandsänderungen der Injektor-Zustandsmaschine ausgeführt werden. Die API kann somit für gewöhnlich ohne grundlegende Änderungen an der Softwarearchitektur und ohne Einfluss auf das Zeitverhalten in die Injektor-Anwendung implementiert werden.