Ein tragbares Prüfsystem für Beatmungsgeräte: Ein Fall für Embedded Linux

Größe: px

Ab Seite anzeigen:

Download "Ein tragbares Prüfsystem für Beatmungsgeräte: Ein Fall für Embedded Linux"

Marcus Vogel
vor 8 Jahren
Abrufe

1 Ein tragbares Prüfsystem für Beatmungsgeräte: Ein Fall für Embedded Linux Hans Heinrich Heitmann Fachbereich Elektrotechnik und Informatik 1

2 Übersicht Gerätevorstellung Softwareentwicklung Entwicklungsumgebung Softwarearchitektur Zeitverhalten Fazit 2

3 Zweck Durchführung der Wartung lt. Prüfkarte Beatmungsgeräte Narkosesysteme Check der Gerätefunktionen Überprüfung der Sensoren Flow, Druck Gasanalyse: O 2, CO 2, Narkosegas Überprüfung der Aktoren Dichtigkeit, Strömungswiderstand Gasmischung Ventilsteuerungen... 3

Gerätefunktionen Überprüfung der Sensoren Flow, Druck Gasanalyse:

4 Das Gerät 4

5 Gerätebestandteile Sensoren 5 Drucksensoren (CanOpen) 5 Flowsensoren (RS232) O 2 -, CO 2 - und Anästhesiegasmessung Aktoren 20 Ventile 1 Proportionalventil Prüfabläufe zur Zeit ca. 25 unterschiedliche Prüfungen Bildschirmseiten zur Zeit ca. 80 verschiedene Seiten 5

Aktoren 20 Ventile 1 Proportionalventil Prüfabläufe zur Zeit ca.

6 Elektronik CPU-Board ETX-Format Geode CPU, 266 MHz 24 MByte RAM 64 MByte Flash Card Display LCD mit 320 x 240 Pixel 6

7 Übersicht Gerätevorstellung Softwareentwicklung Entwicklungsumgebung Softwarearchitektur Zeitverhalten Fazit 7

8 Effizienzsteigerungen Komfortable Entwicklungsumgebung Kurze Debugzyklen Umfangreiche Testmöglichkeiten Moderne Anwendungsarchitektur Objekttechnologie Zustandsautomaten Skriptsprachen Geringe Komplexität Keine aufwändigen Nebenläufigkeiten Keine komplizierten Ereignissteuerungen 8

Anwendungsarchitektur Objekttechnologie Zustandsautomaten

9 Übersicht Gerätevorstellung Softwareentwicklung Entwicklungsumgebung Softwarearchitektur Zeitverhalten Fazit 9

10 Entwicklungsumgebung Teilaspekte Filesystem Beschleunigung des Debugzyklusses Für Auslieferung: Readonly Filesystem Grafische Benutzeroberfläche Kompromiss zwischen Funktionenvielfalt und Ressourcenverbrauch Integrierter Webserver Hilfreich für Fehlersuche und automatisches Testen 10

Benutzeroberfläche Kompromiss zwischen Funktionenvielfalt und

11 Inbetriebnahme Host Target Bootloader Kernel Filesystem Daten Bootloader: PXE Kernel: TFTP Filesystem: NFS Anwendungsdaten: NFS Compact Flash Linux Netzwerk 11

12 Entwicklungsphase Host Target Filesystem Daten Filesystem: NFS Anwendungsdaten: NFS Bootloader Kernel Compact Flash Linux Netzwerk 12

13 Auslieferung Aufteilung des Filesystems: Target Readonly R/W Bootloader Kernel Filesystem Persistente Anwendungsdaten z.b. Konfiguration RAM-Disk Flüchtige Anwendungsdaten z.b. Logdateien Bootloader Kernel Filesystem Daten Compact Flash 13

14 Embedded Filesysteme Filesystem Readonly Platzbedarf für 27 MByte Lesen von 27 MByte Dauer CPU-Belastung Minix Nein 27 MByte 33 s 51 % Romfs Ja 27 MByte 73 s 28 % Cramfs Ja 16 MByte 36 s 70 % Cloop Ja 14 MByte 33 s 88 % Cloop Verwendung: Knoppix Live CD Filesystem ist in einer großen Datei abgelegt Kann für Softwareupdate einfach ausgetauscht werden 14

16 MByte 36 s 70 % Cloop Ja 14 MByte 33 s 88 % Cloop Verwendung: Knoppix Live CD

15 Grafische Benutzeroberfläche Anforderungen geringer Ressourcenbedarf Umfangreiche Bibliothek Unterstützung für spezielle Bedienelemente Hardkeys Touchpanels Linux bietet Vielzahl von Grafiksystemen, auch speziell für eingebette Systeme 15

spezielle Bedienelemente Hardkeys Touchpanels Linux bietet

16 X Window und GTK Host Target Display X Server GTK Anwendung X Window und GTK, weil bewährte Software große Entwicklergemeinde hohe Flexibilität während der Entwicklung 16

17 Tiny-X Server Host Target Display Tiny-X Server GTK Anwendung Tiny-X Server Bestandteil von XFree Speziell entwickelt für Low-Memory-Systeme Speicherbedarf < 1 MByte 17

18 Tiny-X Server Host Target Display Tiny-X Server GTK Anwendung 18

19 Integration Webserver Eingebetteter Webserver ermöglicht: Fernabfrage aller Mess- und Steuerwerte Setzen von Mess- und Steuerwerten Fernsteuerung des Gerätes Zum Testen: per http und einfachen Skripten können automatisierte Testläufe programmiert werden 19

Steuerwerten Fernsteuerung des Gerätes Zum Testen: per http und

20 Übersicht Gerätevorstellung Softwareentwicklung Entwicklungsumgebung Softwarearchitektur Zeitverhalten Fazit 20

21 Blockdiagramm 20 Ventile Proportionalventil Benutzeroberfläche ca. 80 Bildschirmseiten Manager Bildschirm Bildschirm Datenhaltung Prüfalgorithmus Manager Prüfalgorithmus P U P U U Gas ca. 25 Algorithmen 5 CANopen Drucksensoren 5 RS232 Flowsensoren RS232 Gasanalyse Signalverarbeitung 21

22 Softwarearchitektur Sensor Software- Entwickler Objektfabrik- CanOpen 1 erzeugt CanOpensensor RS232Flow 1 1 Objektfabrik- 1 erzeugt RS232- sensor C++ Anwendungsfachmann erzeugt PressS1 canid=6 PressS2 canid=9 erzeugt FlowS9 device=ttys3 FlowS8 device=ttys7 Skriptsprache Lua 22

23 Beispiel Skript Konfiguration mittels einfacher Skriptsprache LUA direkt durch den Anwendungsfachmann Lua: Entwickelt von der Tecgraf in Rio machtvolle Konstrukte zur Datenbeschreibung gern verwendet von Spieleprogrammierer PRESS_SDOS_100 ="0x1a00,1,0x ,4/".. -- pdo mapping "0x210A,0,2,1/".. -- switch to 100 Hz sampling "0x210B,0,200,1" devices.presssensor1 = {'DeviceCanopen', {node=6,sdos=press_sdos_100}} params.presss1 = {'PressSensor1', {index=0,format='float',factor=1.0}} 23

24 Software-Architektur Timer Sensor 0..n 0..n Parameter Datenhaltung tick statemachine schreiben lesen triggern Periodische Aktivierung der Objekte Herzstück: Statemachine Messwerte und Ereignisse über Datenhaltung Ereignisse werden gepollt 24

25 Tickende Objekte Ermöglichen einfache Überwachung des Zeitverhaltens Vermeidung von Synchronisations-Problemen Zustandsautomat ermöglicht robusten Aufbau Erfordern kurze Rechenalgorithmen nicht blockierende Systemaufrufe genauen Timer 25

26 Übersicht Gerätevorstellung Softwareentwicklung Entwicklungsumgebung Softwarearchitektur Zeitverhalten Fazit 26

27 Zeitverhalten Anforderungen Anwendung vollständig im User-Mode Keine Echtzeiterweiterung Aufteilung in Signalverarbeitung: Takt 10 ms unbedingt einzuhalten Benutzeroberfläche: Takt 20 ms 27

28 Linux: Periodische Aktivierung Realisierung mittels Warteschleife Problem: Takte können verpasst werden 28

29 Linux: Periodische Aktivierung Realisierung mittels Echtzeituhr Spezielles Device mit eigenem Interrupt Frequenz von 2 Hz bis 8192 Hz Anzahl verpaßter Interrupts 29

30 Linux: Periodische Aktivierung Aktivierungsperiode bei zusätzlicher Belastung durch das Netzwerk keine wesentlichen Unterschiede zwischen Kernel 2.4 und

31 Übersicht Gerätevorstellung Softwareentwicklung Entwicklungsumgebung Softwarearchitektur Zeitverhalten Fazit 31

32 Fazit Schnelle und flexible Entwicklung durch Komfortable Entwicklungsumgebung vielfältige Programmierwerkzeuge umfangreiche Bibliotheken kurze Debugzyklen umfangreiche Testmöglichkeiten Verwendung einer simplen und robusten Software-Architektur Objektorientierung Zentrale Datenhaltung Vermeidung aufwändiger Nebenläufigkeiten und komplizierter Ereignissteuerungen Einbindung der Anwendungsfachleute in die Softwareentwicklung 32

33 Fazit Aber... höhere CPU-Anforderungen und höherer Speicherbedarf durch Funktionsbibliotheken Grafik Skriptsprache und einfache und robuste SW-Architektur Periodische Aktivierung, Polling 33

34 Fazit Linux ermöglicht optimale Anpassung an Projekterfordernissen Allerdings: Große Flexibilität kostet hohen Einarbeitungsaufwand Gilt auch bei Verwendung spezieller Linux-Distributionen 34

Ähnliche Dokumente

Implementierung eines M2M Back-end Servers

Implementierung eines M2M Back-end Servers Klaus-Dieter Walter SSV Embedded Systems Heisterbergallee 72 D-30453 Hannover www.ssv-embedded.de kdw@ist1.de 1 Wer ist SSV Embedded Systems? SSV Embedded Systems