SOFTWARE-ENTWICKLUNG & BUSSYSTEME

Die Anwendung ist entscheidend

Die Software ist massgeblich für die Funktionalität mechatronischer Systeme. Doch kauft man diese besser von der Stange oder entwickelt diese lieber in Eigenregie oder in Kooperation mit einem Dienstleister? Und auf was ist bei der Wahl des Bussystems zu achten? Die Antworten darauf gibt dieser Beitrag.

Die Entwicklung der mobilen «Dosiereinheit 2030» bei der Karl Schnurr AG* läuft auf Hochtouren. Während die für die Motoransteuerung verantwortlichen Ingenieure sich an der Frage reiben, ob besser Standard-Elektronik oder aber eine passgenaue Lösung zum Tragen kommen soll, generiert die Software-Abteilung bereits fleissig Codes. Und von diesen braucht es viel! Schliesslich soll die Infusionspumpe im Vergleich zum Vorgängermodell alle gängigen Schnittstellenstandards integrieren, damit diese unter anderem an externe Patientendatenmanagementsysteme (PDMS) sowie in klinische Netzwerke eingebunden werden kann.

Insbesondere mit letztem Punkt möchte Firmeninhaber Karl Schnurr seinen Verkäufern ein starkes Argument an die Hand geben. So soll sich die «Dosiereinheit 2030» mithilfe einer speziellen Software von jedem Rechner innerhalb des Krankenhausnetzwerks aus über einen Web-Browser bedienen lassen. Diese Fähigkeit soll es Spitälern ermöglichen, die Patientenüberwachung über alle Ebenen und Stockwerke hinweg zu zentralisieren.

Bedeutung von Librarys

Nun ist es nicht so, dass die Software-Ingenieure bei der Karl Schnurr AG*  deutlich entscheidungsfreudiger als ihre Kollegen aus der Antriebsabteilung sind. Allerdings stand im Falle der «Dosiereinheit 2030» gleich von Beginn an fest, dass diese ihre Funktionalität nicht durch Standard-Software, sondern durch eigenentwickelten Code erhalten soll. Von den Vorgängermodellen der mobilen Infusionspumpe sowie diversen anderen Projekten sind umfangreiche Bibliotheken vorhanden, die sich mit relativ geringem Aufwand implementieren lassen.

Für Mo Aakti, Leiter Technik bei der Antrimon Group AG, eine nachvollziehbare Entscheidung: «Die Karl Schnurr AG*  verfügt bereits über Librarys, die sie einfach adaptieren kann. Zudem fallen auch bei der Verwendung von Standard-Software Kosten an, nämlich für die Implementierung und die Lizenz.»

Daraus nun abzuleiten, dass eine Eigenentwicklung günstiger ist, wäre jedoch der falsche Schluss! Letztlich, so Mo Aakti, sei es immer eine Abwägungsfrage, bei der unter anderem die Stückzahlen und die Verwendung bereits vorhandener Librarys eine Rolle spielten. Da die Software-Entwickler bei der Karl Schnurr AG*  ausserdem klar zwischen hardwareabhängigen und hardwareunabhängigen Modulen trennen, können sie vorhandenen Code ohne grossen Aufwand adaptieren.

Ein weiterer Vorteil dieser sauberen Trennung:

Da bei einer Abkündigung von Produkten oder Komponenten nicht immer eine 100-prozentige Kompatibilität gewährleistet ist, muss beim modularen Software-Aufbau nur der entsprechende Treiber ersetzt werden.

Schnittstellendefinition

Die Möglichkeit, die «Dosiereinheit 2030» in externe PDMS und klinische Netzwerke einbinden zu können, bedarf einer sauberen Schnittstellendefinition. Dabei stellt sich zunächst die Frage, welche Anforderungen es an die Kommunikation zwischen den einzelnen Modulen braucht? Müsste die mobile Infusionspumpe beispielsweise mehrere Achsen im Mikrosekunden-Takt synchronisieren, kämen die Entwickler an einem echtzeitfähigen Bussystem wie EtherCAT oder Powerlink nicht vorbei. Da jedoch lediglich über die Kolbenbewegung die verabreichte Dosis ermittelt und im Display dargestellt wird, genügt eine einfache CAN-Anbindung.

Vorteil dieses Lösungsansatzes: Die meisten Mikrocontroller integrieren standardmässig die für die CAN-Kommunikation benötigten Treiber und Funktionalitäten.

Offene und geschlossene Bussysteme

Die Geschwindigkeit ist ein Kriterium bei der Wahl des Busses. Ein anderes ist, ob die Kommunikation über ein offenes oder ein geschlossenes Bussystem erfolgen soll? «In manchen Anwendungen ist das Bussystem durch das Design vorgegeben», weiss Mo Aakti aus seinem Alltag. Ist dieser jedoch nicht festgelegt, gibt es verschiedene Kriterien, diesen zu bestimmen. Eines kann beispielsweise der Overhead eines Standard-Bussystems sein, der zu Lasten des Prozessors geht. Ein anderes Kriterium ist der Know-how-Schutz. «Ein proprietäres System macht ein Reverse-Engineering schwierig bis unmöglich», beschreibt Mo Aakti die Vorzüge eines geschlossenen Bussystems.

*Firmen- und Produktname geändert

Software-Schnittstellen

Softwareseitige Datenschnittstellen sind logische Berührungspunkte in einem Softwaresystem und regeln den Austausch von Kommandos und Daten zwischen verschiedenen Prozessen und Komponenten. Bei den Software-Schnittstellen erfolgt dabei grundsätzliche Unterscheidung:

  • Datenorientierte Schnittstellen – Diese Schnittstellen werden ausschliesslich zur Kommunikation benutzt und tauschen die Informationen zwischen den beteiligten Systemen aus. Ein Beispiel hierfür wären Adressübergaben mit Verweis auf zu verwendende Daten/Informationen bei Aufruf von Unterprogrammen.
  • Funktionale Schnittstellen – Diese Schnittstellen führen eine bestimmte Funktionalität aus, um die primär beteiligten Systemteile zu synchronisieren oder zu unterstützen. Ein Beispiel hierfür wären Druckertreiber.

Ihr Kontakt

Fabian Siebold
Head of Software & Digitalization

THE ANTRIMON GROUP TURNS MECHATRONICS INTO SUCCESS

Wir bringen unsere Kunden vorwärts und verhelfen ihnen zum Erfolg. Daher unser Slogan: moving forward