Optimierung einer sicherheitskritischen Schrittmotorsteuerung

Transcription

Optimierung einer sicherheitskritischen
Schrittmotorsteuerung
für mobile Infusionspumpen
Uwe Fechner
4. Juni 2006
Zusammenfassung
Ausgehend von einer existierenden Schrittmotorsteuerung für mobile Infusionspumpen wurden
die Verbesserungsmöglichkeiten der existierenden Lösung analysiert und auf der Basis einer
umfassenden Recherche eine innovative neue Steuerung entwickelt.
Hierbei werden sowohl die heute verfügbaren moderneren Bauteile als auch neue Erkenntnisse
der Softwaretechnik, des Systementwurfs sicherheitskritischer Echtzeitsysteme und der Mechatronik berücksichtigt.
Durch diesen fachübergreifenden Ansatz konnten neben einer erheblichen Kostenreduktion gravierende Verbesserungen der technischen Daten sowie der Verifizierbarkeit und Verlässlichkeit
erreicht werden.
Inhaltsverzeichnis
1 Vorwort
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Abgrenzung des Themas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
6
6
2 Schrittmotorsteuerungen für Infusionspumpen
2.1 Beschreibung des hier betrachteteten Systems . . . . . . . . . . . . . . . . . . .
2.2 Optimierungsziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
8
9
3 Ausgangssituation
3.1 Leistungsaufnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Sicherheitskonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Kennzeichen sicherheitsgerichteter Echtzeitsysteme . . . . . . . . . . . .
3.2.2 Strategien für die Umsetzung der Anforderungen an sicherheitskritische
Echtzeitsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Verifizierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Verlässlichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5 Wartbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6 vorhandene Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.1 unterstützte Befehle . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.2 Eingänge des Aktorprozessors . . . . . . . . . . . . . . . . . . . . . . . .
3.6.3 Ausgänge des Aktorprozessors . . . . . . . . . . . . . . . . . . . . . . .
3.6.4 sonstiges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
10
11
11
4 Stand der Technik
4.1 auf dem Markt verfügbare Alternativen
4.1.1 andere Infusionspumpen . . . . .
4.1.2 fertige Schrittmotorsteuerungen .
4.2 Motoralternativen . . . . . . . . . . . .
4.2.1 Schrittmotoren . . . . . . . . . .
4.2.2 Gleichstrommotoren . . . . . . .
4.3 Getriebealternativen . . . . . . . . . . .
4.4 Architekturalternativen . . . . . . . . .
4.4.1 System-Architektur . . . . . . .
4.4.2 Software-Architektur . . . . . . .
4.5 Prozessoralternativen . . . . . . . . . . .
4.5.1 Auswahlkriterien . . . . . . . . .
4.5.2 Prozessorfamilien . . . . . . . . .
4.6 Auswahl eines Echtzeitkerns (RTOS1 ) .
20
20
20
21
21
21
22
23
23
23
24
26
26
28
30
1
Realtime Operating System
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
15
16
17
17
17
18
19
19
4.6.1
4.6.2
4.6.3
4.6.4
4.6.5
Auswahlkriterien .
FreeRTOSTM . . .
Salvo . . . . . . .
MicroC/OS2 . . .
selbstgeschriebener
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
Echtzeitkern
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Optimierungsansätze
5.1 verbesserte Systemarchitektur . . . . . . . . . .
5.2 verbesserte Softwarearchitektur . . . . . . . . .
5.3 Verwendung eines besser geeigneten Prozessors
5.4 verbesserte Motoransteuerung . . . . . . . . . .
5.5 Motorüberwachung . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
30
31
31
31
31
.
.
.
.
.
32
32
33
34
35
37
6 Umsetzung
6.1 Blockdiagramm . . . . . . . . .
6.2 Schaltplan . . . . . . . . . . . .
6.3 Software . . . . . . . . . . . . .
6.3.1 Formale Anforderungen
6.3.2 Zustandsdiagramme . .
6.3.3 Echtzeitkern (RTOS) . .
6.3.4 Zeitverhalten . . . . . .
6.3.5 Speicherbedarf . . . . .
6.4 Das Labormuster . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
40
41
44
44
46
47
48
50
51
7 Ergebnisse
7.1 Drehmoment . . . . . . . . .
7.1.1 Meßaufbau . . . . . .
7.1.2 Meßfehler . . . . . . .
7.1.3 Ergebnisse . . . . . . .
7.2 Leistungsaufnahme . . . . . .
7.2.1 bisheriges System . . .
7.2.2 neues System . . . . .
7.2.3 vergleichende Wertung
7.3 Platzbedarf und Kosten . . .
7.4 Verifizierbarkeit . . . . . . . .
7.5 Verlässlichkeit . . . . . . . . .
7.6 Features . . . . . . . . . . . .
7.7 Ausblick . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
52
52
52
52
54
57
57
57
58
59
61
61
62
62
.
.
.
.
.
.
.
.
.
.
.
.
.
Literaturverzeichnis
64
A Vergleich von FreeRTOS und MicroC/OS2
65
B Verwendete Softwarewerkzeuge
66
C Weitere Internetquellen
68
4
Abbildungsverzeichnis
2.1
Vereinfachtes Blockdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
Blockdiagramm . . . . . . . . . . . . . .
Schaltplan . . . . . . . . . . . . . . . . .
Motortreiber . . . . . . . . . . . . . . .
Formale Anforderungen Hauptprozessor
Formale Anforderungen Aktorprozessor
Zustandsdiagramm Ramp Controller . .
Zustände einer FreeRTOS Task . . . . .
Labormuster . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
40
41
42
44
45
46
47
51
7.1
7.2
7.3
7.4
7.5
7.6
Meßaufbau zur Messung des Drehmoments
Drehmoment und Wirkungsgrad . . . . . .
Stromaufnahme und Wirkungsgrad . . . . .
Spitzenstromaufnahme mit alter Steuerung
Spitzenstromaufnahme mit neuer Steuerung
Motorstromverlauf bei Schrittverlusten . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
53
55
56
58
59
62
5
.
.
.
.
.
.
.
.
8
1 Vorwort
1.1 Motivation
Die Motivation für die Erstellung dieser Arbeit ergab sich aus den Grenzen, auf die der Verfasser
bei seiner beruflichen Tätigkeit in der Entwicklung von Firmware für tragbare Infusionspumpen
immer wieder stieß.
Die bisherige Firmware basiert auf dem Einsatz von 8051 Prozessor Derivaten, die den Einsatz
moderner Software Konzepte sehr erschweren.
Die herkömmlichen Software Konzepte stießen an die Grenzen ihrer Leistungsfähigkeit und waren den steigenden Kundenanforderungen in Bezug auf Geschwindigkeit, Genauigkeit, geringem
Energieverbrauch sowie einer nachweislich hohen Verlässlichkeit1 nicht mehr gewachsen.
Auch im Bereich der Elektronik und der Mechanik schienen Verbesserungen möglich, bzw. es
war notwendig, überhaupt einmal Basisdaten wie Wirkungsgrad und Drehmoment zu erfassen,
um abschätzen zu können, welche Verbesserungen noch möglich sind.
1.2 Abgrenzung des Themas
Thema dieser Arbeit ist die Optimierung der Kernkomponente tragbarer Infusionspumpen2 ,
der Schrittmotorsteuerung.
Zu den Besonderheiten dieser Steuerung gehören:
• geringe Leistung (ca. 1 Watt elektrisch)
• hohe Sicherheitsanforderungen
• geringe Baugröße (ca 3 cm2 Platinenfläche3 , Motorvolumen ca. 7, 4 cm3 )
• es wird eine Drehzahlsteuerung4 mit Schrittzähler5 , nicht eine Positionssteuerung benötigt
1
2
3
4
5
hierzu gehört m.E. auch der Nachweis, daß Zeitschranken garantiert eingehalten werden. Das ist mit dem
bisherigen Design nahezu unmöglich. Siehe auch Abschnitt Zeitverhalten“ S. 15
”
ich betrachte im folgenden nur Infusionspumpen mit Peristaltik- oder Kolbenantrieb, deren Pumpköpfe von
einer rotierenden Welle angetrieben werden
multilayer Platine, einseitige Bestückung
beim Pulsbetrieb des Motors wird die mittlere Drehzahl gesteuert
wünschenswert, bisher nicht direkt implementiert
6
Die Steuerung besteht aus einem Prozessor, im folgenden Aktorprozessor genannt, der Steuerelektronik, der Meßelektronik für den Spulenstrom, einem Motor und einem Getriebe.
Sie erhält ihre Steuerbefehle über ein I2C-Bus6 Interface, über das auch ein Auslesen von
Kontrollsignalen möglich ist.
Nicht näher betrachtet wird das Benutzerinterface, die sekundären Überwachungssysteme (DMSDrucksensor, Hallsensor, Batteriespannung, Temperatur) und die Alarmsignalisierung.
Ebenfalls nicht näher betrachtet werden die Ereignisrekorder für die Überwachung des ordnungsgemäßen Betriebs und die Spannungsversorgung (gerade letztere ist sehr komplex und
auch sehr wichtig für einen verlässlichen Betrieb des Gesamtsystems.)
Soweit zu Test- und Demonstrationszwecken benötigt, verfügt der Laboraufbau, der im Rahmen
dieser Arbeit angefertigt wurde, auch über Benutzerinterface, Hauptprozessor etc. Auf die
Funktion dieser Komponenten werde ich nur insofern eingehen, als es zum Verständnis des
Gesamtsystems erforderlich ist.
6
von der Firma Philips entworfener Zweidraht-Bus zur Verbindung von MCU’s und Peripherie
7
2 Schrittmotorsteuerungen für
Infusionspumpen
2.1 Beschreibung des hier betrachteteten Systems
Die Einbettung der Schrittmotorsteuerung in die hier betrachteten Infusionspumpen sei hier
kurz erläutert:
Abbildung 2.1: Vereinfachtes Blockdiagramm
Medizinisches Personal nimmt über die Tastatur die Grundeinstellungen der Pumpe vor (Flußrate, Beutelvolumen, ggf. auch Bolusvolumen1 , Bolussperrzeiten und Dosisgrenzwerte). Der
Patient kann i.d.R. die Pumpe lediglich stoppen und starten und sich ggf. einen Bolus abrufen.
Der Hauptprozessor übernimmt die Benutzerführung, die Überwachung und Aufzeichnung aller
relevanten Daten incl. Flußrate und dem ausgangsseitigen Druck und steuert den Aktorprozes1
ein Bolus ist die Extragabe eines Medikaments auf Anforderung des Patienten
8
sor. Der Aktorprozessor erhält i.d.R. jede Minute einen neuen Förderauftrag vom Hauptprozessor und steuert den Schrittmotor.
Der Schrittmotor treibt über ein Getriebe den Pumpkopf an, der das Medikament aus dem
Vorratsbeutel über das Überleitsystem dem Patienten zuführt.
2.2 Optimierungsziele
Die hier vorliegende Arbeit hat die folgenden Ziele:
Optimierungsziele
1. ein hohes Drehmoment bei niedrigem Spitzenstrom2
2. Optimierung der Leistungsaufnahme (Batterielaufzeit)
3. Verbesserung der Softwarequalität, um die Voraussetzungen für eine Zertifizierung der
Pumpe durch die FDA3 zu verbessern
4. Erhöhung der Verläßlichkeit des Systems, dazu gehört die Genauigkeit, mit der das geförderte Volumen erfasst wird und die Zeitspanne, in der Fehler erkannt werden
5. Optimierung der Geräuschentwicklung (dies Ziel ist nachrangig, falls es durch eine einfache Änderung der Motoransteuerung erreicht werden kann, dann wäre es schön, um
dies Ziel umfassend anzugehen wäre die Entwicklung von Messmethoden nötig, die den
Rahmen dieser Arbeit sprengt)
6. Optimierung von Platzbedarf und Kosten
Dazu sind folgende vorbereitenden Maßnahmen erforderlich:
Vorbereitende Maßnahmen
1. Erfassung von Daten wie Drehmoment und Wirkungsgrad der Einzelkomponenten, um
über eine Grundlage für weitere Optimierungsmaßnahmen zu verfügen. Um diese Daten
erfassen zu können, muß eine entsprechende Messvorrichtung gebaut werden.
2. Überprüfung, ob der Motor als Sensor für a) den Ausgangsdruck und b) eine Blockade
des Antriebs geeignet ist.
2
3
ein niedriger Spitzenstrom ist wichtig, umd die Systemzuverlässigkeit und die Batterielaufzeit zu erhöhen.
Hohe Spitzenströme können bei schlechten Batterien zu einem plötzlichen Ausfall der Pumpe – ohne vorherige
Batterie schwach“ Warnung – führen
”
Federal Drug Administration, amerikanische Gesundheitsbehörde
9
3 Ausgangssituation
3.1 Leistungsaufnahme
Die Leistungsaufnahme der Pumpe setzt sich aus folgenden Anteilen zusammen:
1. mechanische Pumpleistung, abhängig vom Druck und der Flußrate
2. Pumpkopf-Verluste
3. Getriebe-Verluste
4. Motor-Verluste
5. Eigenverbrauch Aktorprozessor und Motortreiber
6. Eigenverbrauch Hauptprozessor
7. Verbrauch Display
8. Verluste der Spannungswandler
mechanische Pumpleistung Sei FR die Förderrate der Pumpe und p der ausgangsseitige
relative Druck. Dann gilt für die mechanische Pumpleistung, die unter Vernachlässigung der
Reibungsverluste aufgebracht werden muß:
Pmech = p ∗ F R
Für die maximal aufzubringende Pumpleistung errechnet sich bei F Rmax = 100 ml/h und
pmax = 1500 hP a ein Wert von Pmax = 4, 17mW .
Die max. aufgenommene elektrische Leistung1 der Pumpe beträgt bei
I = 5 mA + F R ∗ 2 mAh/ml
und einer mittleren Entladespannung (Akkubetrieb) von 2,4 Volt:
Pmaxel = 205 mA ∗ 2, 4 V = 410 mW
Daraus ergibt sich:
η = Pmech /Pel = 1, 0 %
Hier handelt es sich um den maximalen Wirkungsgrad, bei niedrigeren Flußraten und Drücken
ist der Wirkungsgrad noch viel geringer.
1
Die Formel für die Stromaufnahme habe ich dem folgenden Bericht entnommen und beruht auf Messreihen,
die 2005 durchgeführt wurden (Köl05)
10
Verluste Punkt zwei bis vier sind in der Vergangenheit noch nie bestimmt worden. Ich habe
sie (näherungsweise) messtechnisch erfasst, die Ergebnisse sind im Kapitel 7 auf Seite 52 zu
finden.
Punkt 6 bis 8 sind nicht Bestandteil dieser Arbeit.
Zu Punkt fünf ist folgendes bekannt:
Bei maximaler Förderrate liegt die Eigenstromaufnahme des Aktorprozessors bei ca. 8 mA
(bei 3,3 V), dies kann gegenüber dem Motorstrom von 100 bis 200 mA (bei 5 V) beinahe
vernachlässigt werden.
Bei niedriger Förderrate, z.B. 2 ml je Stunde sieht die Situation ganz anders aus:
Einem Motorstrom von 2-4 mA steht eine mittlere Prozessorstromaufnahme von 1-2 mA gegenüber. Hier erscheint eine Verbesserung der Laufzeit um 25-100% machbar, da:
1. die auf die Stromaufnahme bezogene Rechenleistung des bisher verwendeten Prozessors
mit 0.5 bis 0.25 MIPS/mA (bei 3.3 V) sehr gering im Vergleich zu anderen auf dem Markt
erhältlichen Prozessoren ist
2. das bisher verwendete Stromsparkonzept (Umschaltung der Taktfrequenz zur Laufzeit)
keinesfalls optimal ist
3.2 Sicherheitskonzept
3.2.1 Kennzeichen sicherheitsgerichteter Echtzeitsysteme
3.2.1.1 keine fehlerhaften Ausgaben zulässig
Anders als bei klassischer PC-Software2 , sind bei sicherheitsgerichteten Echtzeitsystemen keine
fehlerhaften Ausgaben zulässig, da Fehler zeitnah zur Gefährdung von Menschenleben und/oder der Umwelt führen, also zu Folgen, die sich nicht mehr rückgängig machen lassen.
Da es absolute Sicherheit nicht gibt, definiert DIN/VDE 31000 Teil 2 Sicherheit wie folgt:
Sicherheit ist eine Sachlage, bei der das Risiko nicht größer als das Grenzrisiko ist.
Als Grenzrisiko ist dabei das größte, noch vertretbare Risiko zu verstehen. (vgl. WHRK03, S.
7ff)
Ein System, das einen sicheren Zustand“ kennt, wird demnach genau dann als sicher bezeich”
net, wenn:
1. es im Falle eines Fehlers in den sicheren Zustand übergeht und Alarm gibt
2. der Übergang in den sicheren Zustand spätestens innerhalb der Fehlertoleranzzeit3 des
gesteuerten Prozesses erfolgt
2
3
Software, die nicht direkt an einen physikalischen, chemischen oder medizinischen Prozess gekoppelt ist
Zeitspanne, in der ein Prozeß durch fehlerhafte Steuersignale beeinträchtigt werden kann, ohne daß ein
gefährlicher Zustand eintritt
11
3. die Wahrscheinlichkeit, das dies nicht passiert, kleiner als das zuvor definierte Grenzrisiko
ist
Anders als bei klassischer PC-Software, aber auch im Unterschied zu herkömmlichen analog
oder diskret aufgebauten Steuerungen gilt für sicherheitsgerichtete Echtzeitsysteme:
1. Der Nachweis, daß das erforderliche Sicherheitsniveau erreicht wurde, kann durch Tests
nicht erbracht werden
2. Ein Fehlerausschluss4 aufgrund konstruktiver Merkmale der verwendeten Bauteile ist bei
prozessorbasierten Systemen nicht mehr möglich
3. aufgrund des unstetigen Verhaltens von Softwaresystemen (ein falsches Bit kann zu maximalem Schaden führen) sind weitgehendere Schutzmaßnahmen als bei herkömmlichen,
analogen Systemen zu treffen
3.2.1.2 Rechtzeitigkeit
Bei Echtzeitsystemen spielt die Dimension der Zeit eine große Rolle. Steuerbefehle müssen nicht
nur richtig, sonder auch rechtzeitig erteilt werden. Beispielsweise muß bei der hier betrachteten
Infusionspumpe genau angegeben werden:
1. wieviel Sekunden nach dem Auftreten eines Überdrucks eine Abschaltung erfolgen muß
(ein zu spät detektierter Überdruck führt dazu, daß das System undicht wird)
2. wieviele Millisekunden nach der Detektion einer Pumpkopfdrehung5 die Druckmessung
erfolgen muß (da der Druck während einer Umdrehung schwankt, ist anderenfalls die
Bestimmung des Maximaldrucks unmöglich)
3. wieviel Millisekunden nach der Abwicklung eines Minutenauftrags ein neuer Auftrag erteilt werden muß (eine Überschreitung dieser Zeit führt zu Fehlern in der Förderung, die
sich aufaddieren und ggf. zur Abschaltung der Pumpe wegen Unterförderung führen.)
Bei Echtzeitsystemen ist es somit von zentraler Bedeutung, alle Reaktionszeiten auf externe
Ereignisse präzise zu spezifizieren und bei der Umsetzung darauf zu achten, daß diese Zeiten
in jedem Fall eingehalten werden.
3.2.1.3 Gleichzeitigkeit
Teilweise ist es auch von Bedeutung, daß verschiedene Steuersignale gleichzeitig abgegeben werden. In dem Falle muß die maximal zulässige Abweichung der Signale voneinander spezifiziert
werden.
4
5
diese Aussage bezieht sich ausschließlich auf die prozessorbasierte elektronische Steuerung. Auf Systemebene
ist ein Fehlerausschluss sehr wohl möglich, z.B. kann die hier betrachtete Pumpe aufgrund der Leistungsfähigkeit des verwendeten Motors nie mehr als ca. 130 ml/h fördern.
Pumpkopf in Position 0◦ , maximaler Druck, eine mögliche Winkeltoleranz muß separat betrachtet werden
12
3.2.2 Strategien für die Umsetzung der Anforderungen an sicherheitskritische
Echtzeitsysteme
3.2.2.1 Fehlertoleranzmaßnahmen
Bei der bisherigen Schrittmotorsteuerung wurden eine Vielzahl von Fehlertoleranzmaßnahmen
implementiert mit dem Ziel, ein durch Software- oder Hardwarefehler bedingtes Fehlverhalten erkennen zu können, um dann entweder Fehlerkorrekturmaßnahmen einzuleiten, oder die
Infusionspumpe in einen sicheren Zustand (Pumpe ist aus) zu überführen.
Zu den Fehlertoleranzmaßnahmen gehören:
1. Maßnahmen zur Fehlererkennung
2. Redundanzmaßnahmen
3. die Verwendung einer Watchdog“
”
Maßnahmen zur Fehlererkennung Folgende Maßnahmen sind bisher realisiert:
1. Absicherung von Datenpaketen, die zwischen Prozessoren übertragen werden, per CRC16
2. Absicherung von Datenpaketen durch Übertragung der normalen und der invertierten
Daten
3. Absicherung von RAM-Daten durch Vierfachspeicherung von jeweils mit orthogonalen
Faktoren exklusiv-oder verknüpften Datenworten
4. Plausibilitätsprüfung von Förderaufträgen
5. Überwachung der Flußrate durch Zählung der Umdrehung des Pumpkopfantriebs
6. Drucküberwachung
7. Überwachung aller Betriebsspannungen sowie der Batteriespannung
8. Selbsttest mit Überprüfung der CRC des Programmcodes
Redundanzmaßnahmen Folgende Maßnahmen sind bisher realisiert:
1. zeitliche Redundanz bei der Datenübertragung
2. redundante Speicherung wichtiger Daten im RAM
3. redundante Spannungsversorgung (Batterie, Netz, Hilfsbatterie)
4. redundante Alarmgeber (rote LED, Hupe, Piepser)
5. redundante Notabschaltung
13
Watchdog-Funktionalität Bisher realisiert:
1. ein Absturz des Hauptprozessor wird vom Uhrenprozessor erkannt und führt zu einem
System-Reset mit Restart
2. ein Absturz oder eine unerlaubte Aktivität des Aktorprozessors wird ebenso erkannt und
ein Restart versucht
3. ein Absturz des Uhrenprozessors wird vom Ladeprozessor erkannt und führt zu einem
Restart
4. ein Absturz des Ladeprozessors wird von seiner Hardware-Watchdog erkannt und führt
zu einem Restart
3.2.2.2 Fehlerintoleranzmaßnahmen
systematischer Entwurf Bisher realisiert:
1. ansatzweise systematische Erfassung von Anforderungen (in Bezug auf den Aktorprozessor bisher zu vielleicht 85% vollständig)
2. UML Klassen- und Zustandsdiagramme für die Entwurfsspezifikation
3. Reviews (bisher erfolgt bezüglich der Stacknutzung und des atomaren Variablen-Zugriffs)
problemadäquate Sprache Da die Verwendung einer besser geeigneten Sprache als C aufgrund der begrenzten Ressourcen bisher nicht möglich ist, wird zumindest versucht, die Typsicherheit durch statische Codeüberprüfung mit Splint sicherzustellen.
David Evens schreibt:
Splint is a tool for statically checking C programs for security vulnerabilities and
programming mistakes. Splint does many of the traditional lint checks including
unused declarations, type inconsistencies, use before definition, unreachable code,
ignored return values, execution paths with no return, likely infinite loops, and fall
through cases. More powerful checks are made possible by additional information
given in source code annotations. Annotations are stylized comments that document
assumptions about functions, variables, parameters and types. (vergl. EL03, S. 9)
3.2.2.3 Isolation sicherheitskritischer Komponenten
Dies Prinzip wird bisher nur unvollständig umgesetzt:
Immerhin sind die Uhren- und Watchdog Funktionalität sowie die eigentliche Motoransteuerung jeweils in separaten Prozessoren implementiert. Beides ist hochgradig sicherheitskritisch
und noch so klein, daß ein gründlicher Codereview möglich wäre.
Der Ladeprozessor erfüllt sowohl sicherheitskritische (Watchdog-Funktionalität) als auch sicherheitsunkritische Aufgaben. Dies stellt eine Verletzung des Prinzips der Isolation sicherheitskritischer Komponenten dar und hat historische Ursachen (nur der Ladeprozessor verfügt
14
über einen Hardware- Watchdog, dessen Stromaufnahme so klein ist, daß er ständig in Betrieb
sein kann).
3.3 Verifizierbarkeit
Softwaredesign
3.3.0.4 Zeitverhalten
Beim Bau von Echtzeitsystemen ist es wichtig, obere Zeitschranken für die Reaktion eines
Prozessors auf externe und interne Ereignisse angeben zu können.
Bruce Powel Douglass schreibt:
In the realm of real-time systems, defining the external timing requirements is crucial to understanding of the problem. An otherwise correct result delivered past its
deadline is a system failure in a hard real-time environment. (vgl. Dou98, S. 64)
Den Nachweis zu erbringen, daß externe Zeitschranken in jedem Fall eingehalten werden, ist
jedoch beim bisherigen Softwaredesign nahezu unmöglich, da:
1. der Mainloop/ IRQ Ansatz verwendet wird
2. mit mehreren verschachtelten Interruptebenen gearbeitet wird
3. sehr große Interrupts mit Unterprogrammaufrufen verwendet werden
4. die Taktfrequenz zur Laufzeit in vielen Stufen umgeschaltet wird
Ursächlich für die Wahl dieses Softwaredesigns sind zum Teil fehlende Features in der Hardware:
1. zu wenig RAM
2. kein schneller Hardware-PWM Ausgang
Die Taktumschaltung zur Laufzeit ließe sich auch bei der gegebenen Hardware vermeiden.
3.3.0.5 direkte Umsetzung von Zustandsdiagrammen
Die Verifizierbarkeit von Software wird bei einer Softwareentwicklung in Anlehnung an den
Rational Unified Process (vgl. SW03, S. 25ff) sehr erleichtert, wenn eine direkte Zuordnung
von Zustandsmaschinen zu Klassen gegeben ist (vgl. MS02). Dies ist bisher nicht wirklich der
Falls, zum Teil aus dem Grunde, daß die Registerbank-Architektur des 8051 Prozessors eine
Verwendung von Funktionen aus verschiedenen Interrupts heraus oft nicht erlaubt.
Dadurch wird es nahezu unmöglich, automatisch aus Zustandsdiagrammen erzeugten Code zu
verwenden, der die Verfizierbarkeit stark verbessern könnte.
15
Testbarkeit
3.3.0.6 in der Entwicklung
1. da kein freier RS232 Ausgang vorhanden ist, muß das Debuggen indirekt über den I2CBus erfolgen. Das ist sehr aufwendig in der Programmierung, da jede neue Variable,
die ausgelesen werden soll, Codeänderungen an drei Prozessoren (PC, Hauptprozessor,
Aktorprozessor) erfordert.
2. es ist für den bisher verwendeten Prozessor kein on-Chip-Emulator verfügbar, der eine
Alternative zum Debuggen über den RS232 oder I2C-Port darstellen könnte
3. ein Umprogrammieren des Prozessors bei eingeschalteter Versorgungsspannung ist unmöglich. Dies erhöht die Turnaround-Zeit erheblich.
3.3.0.7 in der Produktion
Eine Verifikation des geflashten Codes ist mit dem in-Curcuit-Programmer nicht möglich. Ersatzweise wird die Korrektheit des Flashvorgangs über eine CRC geprüft, diese Prüfung erfolgt
allerdings indirekt und hat eine schlechtere Fehlererkennungsrate als ein echtes Verify.
3.4 Verlässlichkeit
Verlässlichkeit ist ein Oberbegriff für Verfügbarkeit, Zuverlässigkeit, Sicherheit, Vertraulichkeit
(der Daten), Datenintegrität und Wartbarkeit.
Eine hohe Verlässlichkeit kann mit Maßnahmen zur Fehlervermeidung, Fehlertoleranz, Fehlerbehebung und der Fehlervorhersage erreicht werden.
Eine ausführliche Beschreibung des Konzepts der Verlässlichkeit findet sich in (ALR00).
unnötig komplexes Software-Design
Die Berechnung der Pausenzeiten zwischen den Pulsgruppen ist aufgrund der Taktumschaltung
zur Laufzeit unnötig kompliziert. Die Wakeup-Logik und der Sleep-Timer wären überflüssig,
wenn der verwendete Prozessor über eine Wakeup-on-I2C-address-recognition“ Logik verfügen
”
würde.
ungenaue Steuerbarkeit
Bisher fehlt die Möglichkeit, vom Hauptprozessor aus die tatsächlich abgegebenen Motorschritte zurückzulesen. Da der Hauptprozessor die theoretischen Motorschritte nur im Sekundenraster berechnet, aber Start- und Stopvorgang asynchron zum Sekundentakt erfolgen, ergibt sich
daraus ein Volumenfehler von 1-2 Sekunden Förderung je Start/Stop- Vorgang.
Dies wirkt sich insbesondere auf die Dosiergenauigkeit kleiner Boli negativ aus.
16
keine schnelle Erkennung von Aussetzern möglich
Die Verlässlichkeit der Pumpe kann deutlich erhöht werden, wenn Aussetzer des Motors (z.B.
aufgrund von Verschmutzung des Getriebes oder aufgrund schwacher Batterie) schneller erkannt werden (also wenn der Arzt/ die Schwester noch im Zimmer ist und nicht erst 10 Minuten
später).
Dazu wäre eine Motorstromüberwachung, die Schrittverluste zuverlässig erkennt, gut geeignet.
Etwas ähnliches hat Prof. Schlienz im Artikel Der Schrittmotor, der nicht ausrastet“ beschrie”
ben (vergl. Sch02). Sein Ansatz basiert allerdings auf einer Mikroschrittansteuerung, bietet den
Vorteil der Fehlervermeidung anstelle einer Fehlererkennung aber erscheint mir doch für den
hier vorliegenden Einsatzzweck etwas zu aufwendig.
Bisher wird eine Blockade des Motors erst erkannt, wenn vier Hall-Impulse fehlen. Dies kann
bei niedrigen Förderraten lange dauern (z.B. 8 Minuten bei einer Förderrate von 2 ml/h).
3.5 Wartbarkeit
Die Wartbarkeit des Aktorprozessors ist insofern besser als früher, als eine recht vollständige
UML-Spezifikation existiert.
Die Wartbarkeit des bisherigen Systems würde ich trotzdem als schlecht einschätzen, u.a. aus
dem Grund, daß nur noch sechs Bytes von 128 Bytes an RAM (zzgl. 128 Bytes Stack) verfügbar
sind.
3.6 vorhandene Features
3.6.1 unterstützte Befehle
Es handelte sich um Befehle, die der Hauptprozessor an den Aktorprozessor über den I2C-Bus
erteilt werden und die vom Aktorprozessor verstanden werden müssen.
• AC DATA <wGroupCount> <wDelayCount> <bDelayPart>
dieser Befehl erteilt einen Förderauftrag, der aus wGroupCount Pulsgruppen besteht
(eine Pulsgruppe =
b 96 Motorschritten oder zwei Motorumdrehungen).
Für die Länge einer Pulsgruppe gilt:
tg = 181.17 ms
Die Pause zwischen den Pulsgruppen wird von den Parametern <wDelayCount> und
<bDelayPart> bestimmt.
tp = (wDelayCount + bDelayP art/256) ms
17
die Dauer eines Förderauftrags ergibt sich aus folgender Formel:
(
wGroupCount ∗ (tg + tp ) für wGroupCount > 0
tF A =
tp
für wGroupCount = 0
Dabei ist (für tF A ' 60 sec) eine Abweichung von max. ± 200 ms zulässig. Ein mit dem
Befehl AC DATA erteilter Förderauftrag beginnt zur nächsten vollen halben Sekunde
(mit der nächsten Flanke am Eingang MASTERCLOCK“ ).
”
Ein laufender Förderauftrag mit einer Restlaufzeit, die vor der nächsten vollen halben Sekunde endet wird vom Befehl AC DATA nicht abgebrochen, ein länger dauernder
Förderauftrag aber sehr wohl.
• AC ASYNC DATA <wGroupCount> <wDelayCount> <bDelayPart>
wie AS DATA, aber ein laufender Förderauftrag wird nach dem Ende der laufenden 8Halbschritt-Gruppe abgebrochen und dann sogleich der neue Auftrag begonnen (falls
der Motor stand, wird nach CRC und Plausibilitätsprüfung sofort mit der Förderung
begonnen).
• AC STOP
hält den Motor nach Ende der laufenden 8-Halbschritt-Gruppe sogleich an.
• AC GET LAST CRC liest die CRC des letzten übertragenen Datenpakets
zurück.
• AC GET LAST ERROR ermittelt den letzten aufgetretenen Fehler.
Mögliche Werte:
ERR CRC ACTOR (CRC-Fehler des Programm-Speichers)
ERR DATA (Förderauftrag länger als 75 Sekunden)
Zur Absicherung der Datenübertragung wird bei allen GET-Befehlen das Datenwort einmal
normal und zusätzlich invertiert übertragen.
3.6.2 Eingänge des Aktorprozessors
• I2C DATA (Datensignal des I2C Steuerbusses vom Hauptprozessor)
• I2C Clock (Taktsignal des I2C Steuerbusses)
• MASTERCLOCK (1 Hz Signal mit 50% Einschaltdauer)
• RESET
18
3.6.3 Ausgänge des Aktorprozessors
• OUT1a (zum Treiber für Spule1 Pin a)
• OUT1b (zum Treiber für Spule1 Pin b)
• OUT2a (zum Treiber für Spule2 Pin a)
• OUT2b (zum Treiber für Spule2 Pin b)
• WDReset (Watchdog-Reset)
• CRC READY (Dies Signal wird gesetzt, wenn die CRC eines Datenpakets berechnet und
bereitgestellt wurde, und zurückgesetzt, wenn ein Befehl empfangen wurde.)
Die Ausgänge steuern über einen Treiberbaustein direkt einen bipolaren Schrittmotor.
Die Ansteuerung erfolgt im Halbschrittbetrieb. Eine Pulsgruppe besteht aus einer Hochlaufphase von vier Motorschritten, einer Phase mit voller Drehzahl von 88 Motorschritten und
einer Bremsphase von vier Motorschritten.
Das Signal WDReset wird zumindest alle 600 ms getoggelt, solange der Aktor über einen
gültigen, nicht abgelaufenen Förderauftrag verfügt (dies kann auch ein Null-Auftrag (Null
Pulsgruppen, aber einer Pausenzeit 6= Null) sein).
3.6.4 sonstiges
Die bisherige Steuerung verfügt über weitere Befehle sowie Ein- und Ausgänge, die aber nur
zu Test- und Konfigurationszwecken bzw. dem alten (zukünftig nicht mehr notwendigen) Powermanagement dienen und hier nicht näher betrachtet werden.
19
4 Stand der Technik
4.1 auf dem Markt verfügbare Alternativen
4.1.1 andere Infusionspumpen
Die einzige mir bekannte andere tragbare Infusionspumpe, die WalkmedTM 300, verfügt über
folgende Eigenschaften:
1. Flußrate 0,1 bis 9,9 ml/h
2. Stromaufnahme1
- ca. 3.8 mA bei 5 ml/h Flußrate
- ca. 1.2 mA bei 0,5 ml/h Flußrate
Bei einer mittleren Entladespannung von 7.8 Volt bei der WalkmedTM und von 2.4 Volt für die
PEGASUS light C gilt für die Leistungsaufnahme2 :
Flußrate (ml/h)
5.0
0.5
WalkmedTM (mW)
PEGASUS light C (mW)
29,5
9,4
36.0
14.4
Tabelle 4.1: Leistungsaufnahme
Somit ist erkennbar, daß die Leistungsaufnahme der WalkmedTM zumindest laut Gebrauchsanweisung etwas niedriger ist als die Leistungsaufnahme der Infusionspumpe, deren Schrittmotorsteuerung hier optimiert werden soll.
Fairerweise muß aber beachtet werden, daß die PEGASUS Pumpe die zehnfache maximale
Förderrate und den dreifachen Abschaltdruck (1500 hPa anstatt 500 hPa) bietet.
Inwiefern die Leistungsaufnahme vom ausgangsseitigen Druck abhängt, darüber sind in den
Gebrauchsanleitungen keine Angaben zu finden.
1
2
berechnet unter der Annahme der Verwendung einer Alkali-Mangan 9V Batterie mit 625 mAh Kapazität
gemäß den Laufzeitangaben in der Gebrauchsanweisung
die Stromaufnahme der light C habe ich gemäß folgender Formel berechnet: I = 5mA + Flußrate ∗ 2mAh/ml
20
4.1.2 fertige Schrittmotorsteuerungen
Es gibt zahlreiche IC’s auf dem Markt, die über einen I2C oder SPI Bus Befehle entgegennehmen und einen (oder mehrere) Schrittmotoren ansteuern können. Als typischen Vertreter
betrachte ich hier die Eigenschaften des TMC246 der Firma TRINAMIC 3 .
1. Betriebsspannung: zumindest 7 Volt erforderlich, zur Zeit verfügbar lediglich 5 Volt
2. Kosten: Die Stückpreise liegen deutlich über 5 EUR je Stück. Eine Eigenentwicklung
ermöglicht niedrigere Stückkosten, allerdings müssen natürlich auch die Entwicklungskosten berücksichtigt werden
3. Stromaufnahme: Da alle mir bekannten Schrittmotorsteuerungen den intermittierenden
Betrieb mit Pulsgruppen-Ansteuerung nicht beherrschen, ist mit einer erheblich höheren
Stromaufnahme zu rechnen.
4. Sicherheit: Kein mir bekannter Ansteuer-IC ist für sicherheitskritische Steuerungen zugelassen. Bei dem jetzigen System-Design ist es zwingend erforderlich, daß:
- die Steuerung Förderaufträge mit mehr als 75 Sekunden Dauer nicht ausführt
- eine Watchdog Funktionalität integriert ist
- Selbsttest- Funktionalität integriert ist
Schon allein das Sicherheits-Kriterium ist ein Knock-Out Kriterium für die Verwendung von
auf dem Markt verfügbaren integrierten Schrittmotorsteuerungen.
4.2 Motoralternativen
4.2.1 Schrittmotoren
4.2.1.1 Motoren
In der Literatur sind so gut wie keine Angaben zum Wirkungsgrad von Schrittmotoren zu
finden. Die einzigen Angaben, die ich fand waren:
1. der Wirkungsgrad sei niedrig4
2. er hänge stark von der Ansteuerelektronik ab
3. das einzige Messprotokoll, was ich fand5 , ergab einen Wirkungsgrad von knapp über 50 %
Unter den Schrittmotoren haben die Scheibenmagnet-Schrittmotoren, z.B. von ESCAP6 die
besten technischen Daten. Insbesondere bieten Sie:
• geringe Eisenverluste (und somit hohen Wirkungsgrad)
3
4
5
6
siehe auch Website der Firma TRINAMIC: http://www.trinamic.com.
vergl.: http://www.energie.ch/themen/industrie/antriebe/
vergl.: http://www.roboternetz.de/phpBB2/viewtopic.php?p=12687
Homepage des Herstellers Danaher Motion: http://www.danahermotion.com/Entry_Pages/Portescap.htm
21
• bei Mikroschrittansteuerung optimale Linearität (und somit hohe Laufruhe)
Von daher könnte sich eine Prüfung des P110 series 16 mm motor“ lohnen.
”
4.2.1.2 Motoransteuerungsmethoden
elektrische Ansteuerung Hier ist zwischen der Spannungssteuerung (Betrieb mit konstanter
Spannung), der Stromsteuerung (Betrieb mit konstantem Strom) und der gemischten Steuerung (Spannungsquelle mit Vorwiderstand) zu unterscheiden. Stand der Technik ist die Stromsteuerung mit Stromabsenkung im Ruhezustand, da diese ein relativ konstantes Drehmoment
unabhängig von der Drehzahl bietet (vergl. REGT05).
Schrittsteuerung Mögliche Betriebsarten:
• Vollschrittsteuerung (einfach, unruhiger Lauf)
• Halbschrittsteuerung
• Mikroschrittsteuerung (aufwendig, sehr ruhiger Lauf)
Bei der Halbschrittsteuerung
sollte der Strom pro Spule in den Phasen, wo beide Spulen be√
stromt werden, auf 1/ 2 abgesenkt werden.
Bei der Mikroschrittsteuerung erfolgt die Ansteuerung der beiden Spulen mit einem Strom, der
proportional zum Sinus bzw. zum Kosinus des Mikroschrittwinkels ist.
4.2.2 Gleichstrommotoren
Gleichstrommotoren bieten einen höheren Wirkungsgrad (bei Motoren mit 1 W Nennleistung
bis zu 80 %), allerdings benötigen Sie zusätzlich einen (z.B. optischen) Encoder zur Drehzahlregelung. Außerdem kann die Verwendung von bürstenbehafteten Gleichstrommotoren EMVProbleme mit sich bringen, und nicht zuletzt ist ihre Lebenserwartung schlechter als die eines
Schrittmotors.
Gleichstrommotoren können außerdem nur dann verwendet werden, wenn z.B. durch Verwendung einer Peristaltik mit Schneckenantrieb sichergestellt ist, daß der Pumpkopf im stromlosen
Zustand blockiert.
Ich habe bisher keine bürstenlosen Gleichstrommotoren gefunden, die für eine so geringe Leistung und Drehzahl, wie hier benötigt, geeignet wären.
22
4.3 Getriebealternativen
Zur Zeit wird ein zweistufiges Stirnradgetriebe mit einer Untersetzung von 1:25 und einem
Modul von 2 mm verwendet. Für die Ankopplung des Antriebs an die Peristaltik werden zwei
Kegelräder mit jeweils 16 Zähnen verwendet. Als Alternative könnte ein Planetengetriebe in
Frage kommen, daß einen hohen Wirkungsgrad η ≈ 0, 85 bietet und hohe Momente übertragen
kann (vergl. BGJ02, S. 35).
Das Kegelradgetriebe ist aufgrund der kleinen Zahnräder und der Notwendigkeit der genauen
Ausrichtung der Achsen nicht unproblematisch. Eine Alternative könnte der Hypoidantrieb
darstellen.
Im Gegensatz zum normalen Kegelradantrieb sind hier die Achsen von Antriebsund Tellerrad versetzt, schneiden sich also nicht. Durch die Desaxierung wird das
Antriebsrad größer, das Tellerrad kleiner gestaltet und es befinden sich mehr Zähne
im Eingriff. Dadurch erhöhen sich die Laufruhe und die Belastbarkeit bei gleichzeitiger Platzersparnis. (aus: Wik05)
Als weitere Alternative kämen Kronräder in Frage, bei denen eine der Achsen frei verschiebbar
bleibt.
Die Wiederentdeckung der Kronräder für technische Anwendungen begann in den
1990er Jahren als Alternative zu Kegelrädern, als Fertigungs- und Berechnungsverfahren zur Verfügung standen, um Kronräder automatisiert in größeren Stückzahlen
zu fertigen. (aus: Wik06)
4.4 Architekturalternativen
4.4.1 System-Architektur
Da es für den Aufbau von Infusionspumpensteuerungen keine direkt passende DIN Norm gibt,
orientiere ich mich hier an den von DIN VDE 0801 (vergl. VDE95) für sichere, speicherprogrammierbare Steuerungen definierten Anforderungsklassen. Ich gehe davon aus, daß für den
Einsatz der Infusionspumpe mit Medikamenten, die nicht lebensnotwendig sind eine Steuerung analog der Anforderungsklasse 4 (AK4) (normale Verfügbarkeit) genügt, während bei
lebensnotwendigen Medikamenten eine Steuerung analog der Anforderungsklasse 5 (AK5) (hohe Verfügbarkeit und/oder Sicherheit) mir angemessen erscheint.
Für AK5 ist - außer Selbsttests der Zentraleinheit (ZE) und testbaren E/A- Baugruppen die redundante Auslegung der Zentraleinheit vorgeschrieben. Eine solche Systemarchitektur
erscheint mir auch für die gegebene Aufgabenstellung sehr attraktiv:
Eine redundante Auslegung der ZE ist heute mit sehr geringem Aufwand (Platz, Kosten,
Energie) machbar. Durch den Einsatz diversitärer Software auf identischer Standard-Hardware
sowie dem Vergleich von Zwischenergebnissen läßt sich eine sehr gute Fehlererkennungsrate
sowohl bei Hardware- als auch bei vielen Software Fehlern erreichen (insbesondere bei Compilerund Biblioteksfehlern).
23
Diversitäre Software läßt sich auf einfache Weise dadurch erzeugen, daß derselbe Quellcode
von verschiedenen Compilern übersetzt wird. Zusätzlich müssen alle sicherheitskritischen Algorithmen identifiziert und durch manuelle Diversität und/oder durch Zurückrechnen überprüft
werden.
Das Prinzip der Isolation sicherheitskritischer Komponenten läßt sich per Hardware oder per
Software umsetzten.
Eine Softwareimplementation könnte wie folgt aussehen:
1. Überwachungsfunktion als separate Task
2. nur in dieser Funktion wird der on Chip Hardware-Watchdog zurückgesetzt
3. wenn der Watchdog zuschlägt wird das System in den sicheren Zustand überführt und
gibt Alarm
Eine hinreichend geringe Fehlerwahrscheinlichkeit des Codes dieser Task könnte z.B. durch
einen Codereview, am besten auch auf der Ebene des Maschinencodes sichergestellt werden.
Eine Hardwareimplementierung würde ein bis zwei zusätzliche Prozessoren erfordern7 . Das
könnte zwar die Sicherheit weiter erhöhen, führt aber aufgrund der gestiegenen Systemkomplexität auch zu einer Verringerung der Verfügbarkeit.
4.4.2 Software-Architektur
Wahl der Programmiersprache Aus Kostengründen sowie aus Platz- und Energiemangel muß
die Software für den Einsatz mit sehr stark begrenzten Ressourcen optimiert werden.
In diesem Umfeld entspricht der Einsatz von C als Programmiersprache dem Stand der Technik, insbesondere wenn ein statischer Codechecker wie z.B. Splint8 zur Gewährleistung der
Typsicherheit zum Einsatz kommen (siehe auch S. 14).
Noch besser wäre eine Codierung gemäß den MISRA9 C Regeln (vergl.: Scz02).
MISRA C (2004) definiert eine Untermenge der Sprache C für den Einsatz in sicherheitskritischen Systemen. Diese Untermenge wird über 121 verpflichtende und 20 empfohlene Regeln
definiert, deren Einhaltung zu 80-90 % mit automatischen Werkzeugen10 sichergestellt werden
kann. Die Einhaltung der restlichen Regeln kann nur manuell (über Codierungsrichtlinien und
Codereviews) überprüft werden.
MISRA C stellt einen anerkannten Standard für die Codierung sicherheitskritischer Systeme in
C dar, der zwar aus der Automobilindustrie stammt, aber auch in anderen Anwendungsgebieten
wie der Medizintechnik immer mehr Verbreitung findet.
Die Verwendung von C++ würde folgende Vorteile bieten:
7
8
9
10
Prof. Halang hat ein solches System, das DIMI 40 in (WHRK03, S. 89ff) ausführlich beschrieben
Secure programming lint: Ein Open Source Werkzeug entwickelt an der Universität von Virginia. (vergl.
EL03)
Motor Industry Software Reliability Association
derartige Werkzeuge verursachen allerdings Kosten im 4-stelligen Euro Bereich. Wenn man sich damit zufrieden gibt, ca. 82% der zwingend einzuhaltenen Regeln von MISRA C (1998) automatisch überprüfen zu
können, kann man auch preiswerte Werkzeuge wie PC-lint einsetzen
24
1. Einfachere Codegenerierung aus UML-Diagrammen
2. bessere Umsetzung des Prinzips des information hiding“ durch Unterstützung von pri”
vaten und geschützten Attributen
Allerdings ist es in C++ sehr leicht, durch unbedachte Verwendung leistungsstarker Features
Code zu erzeugen, der hohe Kosten (RAM/ Laufzeit) verursacht. Bei der Verwendung von C
hat man die Kosten besser im Blick. Die Komplexität von C++ erhöht die Wahrscheinlichkeit
von Compilerfehlern und erschwert die Zertifizierung von Compilern für sicherheitskritische
Systeme.
Als eine weitere Alternative käme NesC11 in Frage, das als C-Präprozessor implementiert ist
und eine gute Unterstützung für nebenläufige Programmierung bietet.
Betriebssysteme für eingebette Systeme Stand der Technik für die Programmierung von
Echtzeitsystemen sind präemptive und kooperative Echtzeitkerne (RTOS), die sowohl in C als
auch in Assembler in großer Zahl verfügbar sind.
Diese Echtzeitkerne verfügen allerdings in der Regel nur über sehr wenige Gerätetreiber, so daß
viele Gerätetreiber (z.B. für den I2C Bus oder für einen Schrittmotor) individuell implementiert
werden müssen.
Bei der Implementierung von Gerätetreibern dürfen Interrupts nur mit großer Vorsicht verwendet werden, da es andernfalls sehr schwer wird, Zeitschranken für die Funktionen des Hauptprogramms zu berechnen. Verschachtelte Interrupts sind Tabu.
Wolfgang Halang schreibt (vgl. WHRK03, S. 140):
• Der Gebrauch von Unterbrechungen soll zugunsten zyklischer Abfragens eingeschränkt werden
• Unterbrechungen dürfen nicht geschachtelt werden
• Unterbrechungen dürfen benutzt werden, wenn sie ein System vereinfachen
Entwurfsmethoden Aus Sicherheitsgründen sollte der Top-Down Entwurf12 verwendet werden (vergl. WHRK03, S. 132), hierbei gilt UML, insbesondere UML-Zustandsdiagramme als
Mittel der Wahl für die Entwurfsspezifikation.
Für die Umsetzung von UML Zustandsdiagrammen in Klassen empfiehlt sich die Verwendung
von C+, einer einfachen Methode zur objektorientierte Programmierung in C, die lediglich ANSI C voraussetzt, wenig Overhead hat und sowohl für die manuelle als auch für die automatische
Codegenerierung gut geeignet ist. (vergl. MS02, S. 335ff)
11
12
Komponenten orientierte Sprache, Basis von TinyOS, einem Betriebssystem für drahtlose Sensornetzwerke
das bedeuted, von einer Menge schriftlich formulierter formaler Anforderungen ausgehend (die vollständig
und widerspruchsfrei sein muß) eine UML Entwurfsspezifikation zu entwickeln und darauf aufbauend erst
den Code zu schreiben, wobei die Rückverfolgbarkeit jeder Codezeile zu einer formalen Anforderung gegeben
sein muß
25
Die Verwendung von Programmiersystemen mit vollautomatische Codegenerierung wie Rhapsody wäre zwar möglich, sprengt aber etwas den Rahmen der hier gegebenen doch recht überschaubaren Aufgabenstellung.
Zusammenfassung
• C, insbesondere MISRA C entspricht durchaus dem Stand der Technik
• C++ kann für größere eingebettete Systeme eine gute Alternative darstellen
• andere Sprachen wie NesC, Pascal oder Ada haben insbesondere den Nachteil der kleineren Compiler Auswahl, was den Einsatz diversitärer Compiler nahezu unmöglich macht
• die Verwendung eines Echtzeitkerns bietet große Vorteile bei der Verifizierung des Zeitverhaltens, der Einfachheit der Programmierung und der Erweiterbarkeit der Software,
wenn seine Verlässlichkeit entweder aufgrund seiner Betriebsbewährtheit und/oder seiner Kleinheit und Lesbarkeit des Quellcodes sowie der Verfügbarkeit einer automatischen
Testsuite verifiziert werden kann
• systematische Anforderungserfassung, Top-Down Entwurf, UML als Sprache für die Entwurfsspezifikation sowie die Verwendung von in C+ implementierten Zustandsmaschinen
entsprechen dem Stand der Technik
4.5 Prozessoralternativen
4.5.1 Auswahlkriterien
Die folgenden Auswahlkriterien habe ich für den Einsatz von Prozessoren in mobilen Infusionspumpen erarbeitet. Bisher kommt in den Pumpen u.a. ein kleiner“ Aktorprozessor (8 kBytes
”
Flash) und ein großer“ Hauptprozessor (mit 128 kBytes externem Flash) zum Einsatz.
”
Wünschenswert erscheint mir:
• zukünftig nur noch Prozessoren mit internem Daten- und Programmspeicher einzusetzen,
da dadurch die Zuverlässigkeit erhöht und die Stromaufnahme erheblich gesenkt wird
• nur eine Prozessorfamilie sowohl für große als auch für kleine Aufgaben zu verwenden,
um Synergieeffekte beim Lernaufwand und bei der Anschaffung von Werkzeugen nutzen
zu können13 .
Konkret ergeben sich daraus die folgenden Auswahlkriterien:
1. Stromaufnahme
- Imax (maximale Stromaufnahme)
- IRuhe (maximale Stromaufnahme für Datenerhalt)
13
um Diversität der sich gegenseitig überwachenden Einheiten zu gewährleistet, ist die Verwendung diversitärer
Compiler wirksamer als diversitäre Hardware. Eine nähere Begründung erfolgt in 5.1
26
- MIPS14 / mA (die auf die Stromaufnahme bezogene Rechenleistung bei 3.3 V)15
2. Betriebsspannung/en
- für 3.3 V verfügbar16
- zwei Spannungen erforderlich
17
3. linearer Programmspeicher > 64 kBytes
18
4. mit internem Flash bis 256 kBytes verfügbar
19
5. interner Flash mit Bootloader Sektion (wichtig für nachträgliche Firmware Aktualisierungen)
6. mit internen RAM ≥ 4 kBytes verfügbar
7. sowohl klein (20 Pin) als auch groß (100 Pin) verfügbar
8. Peripherie
- Anzahl Timer
- Watchdog mit niedriger Stromaufnahme
- RTC mit niedriger Stromaufnahme
- I2C Ports
- SPI Ports
- PWM Ausgänge
- A/D-Wandler (Anzahl Kanäle, Auflösung, Geschwindigkeit)
- wakeup on I2C adress recognition, wakeup on pin change
9. Verfügbarkeit von Software Werkzeugen
- Compiler
Verfügbarkeit einer Kommandozeilenversion
Einbindung in die IDE Eclipse
Quelltext der Biblioteken
MISRA C Unterstützung
- Simulator
14
15
16
17
18
19
Millionen Maschinenbefehle pro Sekunde
diese Angabe ist mit Vorsicht zu betrachten. Ich verwende sie als groben Schätzwert für die Integer Rechenleistung, die Wortbreite spielt natürlich - neben vielen anderen Faktoren - auch noch eine Rolle. Beim
Vergleich von Prozessoren gleicher Wortbreite kann dieser Wert als erster Anhaltspunkt dienen.
da viele der hier verwendeten Sensoren 3.3 V benötigen macht eine andere Spannung jetzt und in den nächsten
Jahren wenig Sinn
manche Prozessoren benötigen zusätzlich zu den 3.3 V eine weitere Betriebsspannung
Banking benutzen zu müssen, weil der lineare Adressbereich nicht ausreicht, ist zeitaufwendig, fehlerträchtig
und macht ein deterministisches Zeitverhalten unmöglich
das entspricht dem doppelten des bisher maximal benötigten Programmspeichers
27
- Emulator
- RTOS
- Biblioteken
I2C Treiber
LCD Treiber
TCP Treiber
Verschlüsselungs- Module
10. on Chip debugging möglich
4.5.2 Prozessorfamilien
Ich betrachte hier die bisher verwendete Prozessorfamilie (8051 Derivate) sowie zwei mögliche
Alternativen mit besonders guten technischen Eigenschaften.
8051 Derivate
die Stromaufnahme bezieht sich auf den bisher verwendeten P89LPC922 Prozessor von Philips,
ein aktuelles Modell mit vergleichsweise guten Werten
- kein linearer Adressraum > 64 kByte
- kein Hardware-Stack > 256 Bytes möglich
- nur ca. 0.25 bis 0.5 MIPS/mA bei 8 Mhz Taktfrequenz
o als RTOS von den hier betrachteten nur Salvo verfügbar
+ große Typenvielfalt
+ viele Hersteller
Atmel AVR Familie
alle Zahlenangaben beziehen sich auf die Prozessoren ATmega168 und ATmega1281, die den
o.g. Auswahlkriterien am besten genügen
+ linearer Adressraum bis 16 MByte
+ Hardware Stack nur durch RAM Größe begrenzt
+ ca. 1 MIPS/mA bei 8 Mhz Taktfrequenz
+ schnelle PWM verfügbar20
20
für die hier betrachtete Schrittmotorsteuerung sollte die PWM Frequenz über 20 kHz liegen, damit das
Choppen unhörbar ist
28
+ phasensynchrone PWM verfügbar
+ von 8 bis 100 Pin verfügbar
+ on Chip Debugging Support
+ Ruhestromaufnahme typ. 1 µA max. 3 µA
+ FreeRTOS, MicroC/OS2 und Salvo verfügbar
o GCC bis 128 kBytes Codegröße verfügbar21
- nur ein Hersteller
ARM7 Prozessoren
Alle Zahlenangaben beziehen sich auf den AT91SAM7S128 Prozessor, einen Chip mit 32 kBytes
RAM und 128 kBytes on Chip Flash. Die SAM7 Reihe umfasst Chips von 32 kBytes bis
256 kBytes Flash Speicher.
+ linearer 32 Bit Adressraum
+ sehr schnell, ca. 45 MIPS bei 50 Mhz (bei I ' 32 mA)
+ SAM7-Reihe: viel Peripherie incl. 10 Bit A/D- Wandler on Chip
+ viele Hersteller
+ ca. 1,4 MIPS/mA bei 32 Bit Wortbreite
+ GCC verfügbar
+ FreeRTOS, MicroC/OS2 und Salvo verfügbar
- nicht mit < 48 Pins verfügbar
- Ruhestromaufnahme ca. 35 µA
- zwei Betriebsspannungen nötig
21
GCC ist ein freier C/C++ Compiler, der für viele Prozessoren Code erzeugen kann. Die Version 3.4.5 von
AVR-GCC unterstützt noch keine 24 Bit Pointer, daher die Beschränkung auf 128 kBytes Codegröße. Für die
Version 4.x von GCC sind Patches zur Unterstützung von bis zu 16 MBytes Programmspeicher verfügbar.
29
4.6 Auswahl eines Echtzeitkerns (RTOS22 )
4.6.1 Auswahlkriterien
1. RAM-Bedarf
2. ROM-Bedarf
3. Portierbarkeit
4. Betriebsart (Kooperativ/ Präemptive)
5. Verifizierbarkeit (Eignung für sicherheitskritische Systeme)
Kooperative Betriebsart Ein kooperativer Echtzeitkern zeichnet sich dadurch aus, dass eine
Task einen ausdrücklichen Yield() Aufruf absetzen muß, um einen Taskwechsel herbeizuführen.
Dies Verfahren hat den Nachteil, daß es in der Verantwortung des Anwendungsprogrammierers
liegt, maximale Taskwechselzeiten sicherzustellen aber den Vorteil, daß keine Probleme durch
nicht-atomaren Zugriff auf Mehrbyte Variable oder Datenstrukturen entstehen können.
Präemptive Betriebsart Bei einem präemptiven Echtzeitkern ist der Echtzeitkern für die
Taskumschaltung verantwortlich. Kritische Bereiche müssen vom Anwendungsprogrammierer
explizit geschützt werden. Dies bietet den Vorteil, daß sich sehr kurze Umschaltzeiten leichter
erreichen lassen und als Nachteil das Risiko nicht-atomarer Variablenzugriffe.
Verifizierbarkeit Die korrekte Funktion eines Echtzeitkerns läßt sich gut verifizieren, wenn:
1. er im Sourcecode vorliegt
2. klein ist (möglichst nicht größer als 2000 Lines of Code (LOC))
3. er weitestgehend in C und nicht in Assembler erstellt wurde
4. eine gute Dokumentation existiert
5. eine Testsuite existiert
6. seine korrekte Funktion bereits für Geräte, die für eine hohe Sicherheitsklasse zertifiziert
wurden, verifiziert worden ist
22
Realtime Operating System
30
4.6.2 FreeRTOSTM
FreeRTOSTM ist ein kleiner, portierbarer Open Source Echtzeitkern (Real Time Kernel), frei
verfügbar und ohne Lizenzgebühren auch in kommerziellen Anwendungen einsetzbar.
Es sind Portierungen für zahlreiche Mikrocontroller verfügbar, da er weitestgehend in C geschrieben ist sind Portierungen auf neue Prozessoren einfach durchzuführen.
Es ist zwar auch eine Portierung für 8051 Prozessoren verfügbar, diese hat m.E. allerdings
einen viel zu hohen Overhead, um praktikabel einsetzbar zu sein (bei einem Taskwechsel wird
der komplette Hardware Stack in den erweiterten RAM Bereich ausgelagert).
Es kann sowohl präemptiv als auch kooperativ verwendet werden, umschaltbar über eine #define Anweisung.
Im Umfang des Pakets sind zahlreiche Beispiele, Debug-Tools und eine Test-Suite enthalten(vergl. Bar03).
4.6.3 Salvo
Salvo ist ein kooperativer Echtzeitkern, der als einer der wenigen auch für 8051 Prozessoren
vernünftig geeignet, aber auch für viele andere Prozessoren verfügbar ist. Es ist ab 1-2K ROM
und 50-100 Bytes RAM verwendbar.
Er ist ausschließlich kommerziell verfügbar. Von daher sprengt sein Einsatz den Kostenrahmen
einer Bachelor-Arbeit.
4.6.4 MicroC/OS2
MicroC/OS2 ist ein portabler, präemptiver Echtzeitkern für Mikrocontroller und DSP’s. Es
hat einen kleinen Speicherbedarf (ab 2k ROM + 300 Bytes RAM + Stack) und ist vollständig
konfigurierbar, so daß nur die wirklich benötigten Funktionen wirklich im Objektcode landen.
Ein Validierungs-Suite, wie sie für sicherheitskritische Systeme benötigt wird, ist verfügbar.
Der Quellcode wird - mit ausführlichen Erläuterungen - als Buch vertrieben (vergl. Lab02).
Ein tabellarischer Vergleich von MicroC/OS2 und FreeRTOS findet sich in Anhang A.
4.6.5 selbstgeschriebener Echtzeitkern
Ein Echtzeitkern mit den hier wünschenswerten Features23 hat eine Codegröße von etwa 2000
LOC. Um so etwas in guter Qualität zu erstellen, braucht man zumindest eine Testsuite von
weiteren 4000 LOC. Das selber zu schreiben, dafür bräuchte ich (der ich wenig Erfahrung im
Betriebssystembau habe) schätzungsweise 1,5 Jahre. Das ist unwirtschaftlich und das Ergebnis
wäre sicherlich nicht besser als der Einsatz eines kommerziellen oder Open Source Kerns, der
sich schon in vielen Projekten praktisch bewährt hat.
23
Taskswitcher, absolute und relative Timer, Prioritäten, Semaphore, Message-Queue, Debug-System
31
5 Optimierungsansätze
5.1 verbesserte Systemarchitektur
Wie im Abschnitt 4.4.1 beschrieben, ist die redundante Auslegung der Zentraleinheit sehr attraktiv. Bei einer Neuentwicklung der kompletten Pumpenelektronik (und nicht nur der Schrittmotorsteuerung im auf S. 7 definierten Sinne) würde ich folgenden Aufbau vorschlagen:
1. nur noch zwei identische Prozessoren1 mit jeweils 128 bis 256 kBytes Programmspeicher
(Flash) und jeweils 64 Pins sind an der Flußsteuerung und -Überwachung beteiligt
2. alle Eingangssignale werden an beide Prozessoren geführt, alle Ausgänge können von
beiden Prozessoren gesteuert werden
3. die funktionale Aufteilung in Hauptprozessor und Aktorprozessor bleibt im Normalbetrieb erhalten, inaktive Ausgänge eines Prozessors werden in den High-Z Zustand geschaltet
4. der Hauptprozessor erfüllt folgende Aufgaben:
- Benutzerinterface
- Echtzeituhr
- Interface für externe Kommunikation, z.B. via BlueTooth
- Überwachung aller Betriebsspannungen, des Drucks und des geförderten Volumens
- Überwachung des Aktorprozessors
5. Hochauflösender A/D-Wandler mit I2C-Bus Anschluss für die Druckmessung
6. Batterieladecontroller mit I2C-Bus Anschluss
7. Verbindung beider Prozessoren untereinander und mit den o.g. E/A-Einheiten über den
I2C-Bus
8. Anschluss beider Prozessoren an einen gemeinsamen seriellen EEPROM über den SPIBus2 , um die aufgezeichneten Überwachungsdaten abzulegen3
1
2
3
wie Prof. Halang in Kap. 7 von (WHRK03) nachweist, ist ein System mit identischer Hardware und diversitärer Software einem System mit diversitärer Hardware in der Fehlererkennungsrate zumeist überlegen, da
durch einen Vergleich von Zwischenergebnissen viele Fehler erkannt werden können, deren Erkennung bei
der Verwendung diversitärer Hardware nicht möglich ist
der SPI-Bus bietet erheblich höhere Geschwindigkeiten als der I2C-Bus, außerdem ist es sinnvoll, Speicherzugriffe von der Kommunikation zwischen den Prozessoren und den E/A-Einheiten zu entkoppeln, dadurch
erreicht man ein deterministischeres Zeitverhalten
der interne EEPROM der infrage kommenden Prozessoren ist zu klein, um die geforderte Speichertiefe zu
bieten
32
9. Überwachung des Hauptprozessors durch den Aktorprozessor
10. Verwendung diversitärer Compiler für die Software auf beiden Prozessoren, z.B. GCC
und IAR-C4
11. redundante Anbindung der Alarmgeber, die auch im Falle eines Kurzschlusses eines der
beiden Alarmgeber-Ausgänge noch funktioniert und auch bei Ausfall der Hauptbatterie
12. redundante Anbindung der Notabschaltung (Spannungsversorgung der Treiberstufen)
13. beide Prozessoren verfügen über eine unabhängige interne Hardware-Watchdog
Bei einem derartigen Aufbau wäre es möglich, daß im Falle des Ausfalls eines der beiden
Prozessoren der andere seine Funktion übernimmt (Notbetrieb, dieser sollte allerdings z.B.
zeitlich begrenzt sein und dem Anwender deutlich signalisiert werden).
Außerdem würden bei diesem Aufbau auch Rechen- und RAM-Fehler sowie viele selten auftretende Softwarefehler des Hauptprozessors erkannt werden können.
interne vs. externe Watchdog Der im Rahmen dieser Arbeit gebaute Prototyp verwendet
eine prozessorinterne Watchdog, das ist einfacher als das bisherige Konzept, bei dem indirekt über mehrere Software- und Hardwarewatchdogs im Fehlerfall ein Reset ausgelöst wurde.
Einfachheit ist ein wesentlicher Aspekt sicherheitskritischer Systeme. Andererseits hätte die
Verwendung einer externen Hardware-Watchdog, wie z.B. dem MAX 823 von Maxim5 den
Vorteil der Unanfälligkeit gegenüber Software-Fehlern (sie kann nicht versehentlich abgeschaltet werden).
Auch sind Hardware-Watchdogs erhältlich, die nicht nur überwachen, ob das Rücksetzsignal
vorliegt, sondern auch eine maximale Häufigkeit garantieren, mit der es auftreten darf (Beispiel:
Der MAX 6323). So wird auch dann ein Reset ausgelöst, wenn im Fehlerfall in einem Interrupt
ständig die Watchdog betätigt wird.
Diese Vorteile einer externen Watchdog sind gegenüber den Nachteilen (Platzbedarf, Kosten,
geringere Flexibilität bei der Wahl der Zeitschranken) abzuwägen.
5.2 verbesserte Softwarearchitektur
Für eine Zweiprozessorarchitektur mit gegenseitiger Überwachung ist ein RTOS nahezu zwingend erforderlich, da jeder der Prozessoren neben seiner Hauptaufgabe auch noch die Überwachung des anderen Prozessors im Hintergrund ausführen muß.
Die Umsetzung einer Zweiprozessorarchitektur mit gegenseitiger Überwachung sprengt den
Rahmen dieser Arbeit, allerdings habe ich mich bemüht, die hier entwickelte Aktorsoftware
so zu schreiben, daß die zusätzlichen Überwachungsalgorithmen einfach hinzugefügt werden
können.
4
5
IAR ist ein Hersteller von C/C++ Compilern und Zubehör, siehe http://www.iar.com/
vergl. auch die Application Note Watchdogs Improve Reliability“
”
siehe: http://www.maxim-ic.com/appnotes.cfm/appnote_number/1926
33
Ich habe mich im Rahmen dieser Arbeit für die Verwendung von FreeRTOS (vergl. Abschnitt
4.6.2) entschieden, zum einen aufgrund seiner freien Verfügbarkeit und zum anderen aus dem
Grunde, daß ich mich mit der Funktion dieses Echtzeitkerns bereits seit längerem beschäftige
und mir die Zeit für die Einarbeitung in ein anderes RTOS momentan nicht zur Verfügung
steht (falls die hier betrachtete Infusionspumpe einer Zertifizierung durch die FDA6 unterzogen
werden soll, wäre ein Wechsel zu MikroC/OS2 zu überlegen, da hierfür alle nötigen Zertifizierungsunterlagen verfügbar sind (der Wechsel eines RTOS ist nicht so besonders aufwendig,
sofern es vom gleichen Typ (präemptiv oder kooperativ) ist).
Um eine niedrige Stromaufnahme zu erreichen, ist es üblich, daß die IDLE-Task7 des RTOS den
Prozessor in den Tiefschlaf8 versetzt, und er von einem Timer z.B. alle 2 ms wieder geweckt
wird. Dies setzt allerdings voraus, daß für den Hauptoszillator ein RC-Oszillator verwendet
wird, da nur dieser Oszillatortyp schnell genug (in max. wenigen µs) anschwingt. Die relativ
hohe Frequenztoleranz von RC-Oszillatoren (1-2 % nach Kalibrierung) muß berücksichtigt
werden.
5.3 Verwendung eines besser geeigneten Prozessors
Ich habe mich für die Verwendung von Prozessoren aus der Atmel AVR Reihe (vergl. 4.5.2)
entschieden, da sie unter Berücksichtigung der in 4.5.1 angegebenen Kriterien über die besten
Eigenschaften aller 8-Bit Prozessoren verfügen. Insbesondere:
1. ermöglichen sie die Verwendung eines RTOS, da schon der kleine ATmega168 über
1 kByte RAM und einen beliebig dimensionierbaren Stack verfügt, größere Typen über
bis zu 8 kBytes an internem RAM
2. ermöglichen sie deutliche Vereinfachungen, da sie über ein Wakeup-on-I2C-Adress-De”
tektion“ Feature verfügen
3. bieten sie eine höhere Rechenleistung, so daß der Hauptprozessor entlastet wird (schnellere Reaktion auf I2C-Bus Befehle, der Hauptprozessor muß weniger lange warten) bei
verringerter Stromaufnahme
4. sie erlauben die Verwendung des GCC, eines freien C Compilers, so daß - falls die symmetrische Zweiprozessorarchitektur mit diversitären Compilern zum Einsatz kommen soll nur ein kommerzieller Compiler gekauft werden muß
5. bieten sie einen Hardware-Watchdog mit sehr niedriger Stromaufnahme und (mehr als)
einen schnellen Hardware PWM Ausgang
6. ermöglichen sie die In-Circuit-Programmierung“ mit Verify ohne Abschaltung der Ver”
sorgungsspannung, bei Verwendung eines geeigneten Boot-Loaders ist auch eine Neuprogrammierung über den I2C Bus oder die RS232 Schnittstelle möglich
7. verfügen viele AVR-Derivate über einen On-Chip-Emulator, der ein Debuggen der Software über den Reset-Pin ermöglicht
8. sind sie im sehr kleinen MLF Gehäuse lieferbar (5*5 mm2 Baugröße beim ATmega168)
6
7
8
Federal Drug Administration, amerikanische Gesundheitsbehörde
Task, die ausgeführt wird, wenn nichts zu tun ist
oder in einen anderen Stromsparmodus, z.B. in den IDLE Zustand, wenn der PWM Ausgang aktiv bleiben
muß
34
9. bietet die Architektur einen linearen Adressraum von 24 Bit, sodaß Banking bei allen
hier infrage kommenden Programmgrößen jetzt und in den nächsten Jahren überflüssig
ist
Im Rahmen dieser Arbeit werde ich die Prozessoren vom Typ ATmega168 einsetzen, diese
können mit nur geringen Anpassungen durch die Typen ATmega1281 oder ATmega2561 ersetzt
werden, wenn eine symmetrische Zweiprozessorarchitektur implementiert werden soll. Zum
jetzigen Zeitpunkt bietet die Verwendung der kleineren ATmega168 Prozessoren den Vorteil
der besseren Vergleichbarkeit mit der bisherigen Lösung, was Platz- und Energiebedarf sowie
die Kosten betrifft, außerdem ist der Einarbeitungsaufwand bei den kleineren Prozessoren
geringer, da sie über weniger Features verfügen.
Das Problem des fehlenden Zweitherstellers relativiert sich dadurch ein wenig9 , daß zumindest
drei pinkompatible Prozessoren notfalls einsetzbar sind (ATmega128, ATmega1281, ATmega2561), so daß für den Fall, daß der gewünschte Typ nicht lieferbar ist, auf zwei andere
ausgewichen werden kann.
Die Verwendung von ARM7 Prozessoren hätte den Vorteil einer größeren Zukunftssicherheit.
Andererseits benötigen sie mehr Ruheenergie und würden eine höhere Einarbeitungszeit erfordern. Der einzige Zweck, den ich mir z.Zt. vorstellen kann, für den die Rechenleistung von
ARM7 Prozessoren in Infusionspumpen benötigt werden könnte ist die Verschlüsselung von
Daten, falls die Pumpen einmal remote über das Internet ausgelesen werden sollen. Bei der
Verwendung von BlueTooth könnte die Aufgabe der Verschlüsselung aber auch dem BlueTooth10 -Modul11 überlassen werden.
5.4 verbesserte Motoransteuerung
flexiblere Steuerung von Strom und Drehmoment
Bei der bisherigen Steuerung war es bereits möglich, entweder zu Choppen, oder auch nicht.
Gar nicht zu choppen führt zu sehr hohen Spitzenströmen am Anfang und am Ende jeder
Pulsgruppe, wenn man wie bisher implementierte Art und Weise choppt, ist das Drehmoment
unter Umständen12 zu gering.
Besser wäre es, den Grad des Choppens und somit das Drehmoment per Software einstellbar zu
machen, wobei z.B. eine Pulsweite von 80 % dem jetzigen Choppen entspräche, und bei einem
Wert von 100% bei voller Drehzahl nicht mehr gechoppt wird, sondern nur beim Anfahren
und Bremsen, um die Stromerhöhung durch die verlängerten Motorschritte auszugleichen und
somit die hohen Spitzenströme zu vermeiden, ohne das Drehmoment zu beeinträchtigen.
9
10
11
12
zumindest bei der Variante mit der symmetrischen Zweiprozessorarchitektur
BlueTooth ist eine digitale Kurzstreckenfunktechnik, die für den Einsatz in Krankenhäusern zugelassen ist
die hier infragekommenden BlueTooth Module haben auf einer Fläche von wenigen cm2 neben der Funkschnittstelle eine serielle Schnittstelle mit i.d.R. 112 kBaud. Die BlueTooth Spezifikation sieht eine Verschlüsselung der übertragenen Daten vor, von daher gibt es auch Module, die dies unterstützen.
beispielsweise unterliegen die hier verwendeten Schrittmotoren nicht unerheblichen Exemplarstreuungen
35
variable Maximaldrehzahl
Bei der jetzigen Motoransteuerung kann der Motor nur mit voller Schrittrate arbeiten. Um auch
mit niedrigeren Maximaldrehzahlen arbeiten zu können13 , muß das Choppen per HardwarePWM14 erfolgen. Dabei gibt es zwei Möglichkeiten:
a) nur einen PWM-Kanal für beide Spulen
b) getrennte PWM-Kanäle für beide Spulen
Für Halbschrittbetrieb genügt a), für Mikroschrittbetrieb ist b) erforderlich.
Für Mikroschrittbetrieb sind - insofern eine stufenlos einstellbare Schrittfrequenz gewünscht
und auf Tricks verzichtet wird - vier Timer erforderlich:
1. Timer für den RTOS-Tick
2. Mikroschritt-Timer
3. Timer für PWM-Kanal 1
4. Timer für PWM-Kanal 2
Vier Hardware-Timer sind jedoch in den ATmega168 Prozessoren nicht verfügbar, sondern nur
in deutlich größeren und teureren Prozessoren15 .
Unter Abwägung der Vor- und Nachteile habe ich mich entschieden, auf die Implementierung
einer Mikroschrittsteuerung zu verzichten:
1. ihr einziger Vorteil wäre die größere Laufruhe16 . Ich werde jedoch zunächst versuchen,
durch eine Verringerung der Maximaldrehzahl eine größere Laufruhe zu erreichen. Sollte
dies nicht zum Erfolg führen, könnte die Implementierung einer Mikroschrittsteuerung
erneut geprüft werden.
2. Nachteilig wäre der höhere Hardwareaufwand durch zweikanaliges Choppen und zweikanalige Strommessung.
3. nicht zuletzt ist mit einem höheren Strombedarf der Ansteuerschaltung zu rechnen, da
mehr Rechenleistung zur Berechnung der Mikroschritte erforderlich ist (im Vergleich zum
Halb- und Vollschrittbetrieb).
Die Implementierung der folgenden I2C-Bus befehle erscheint mir sinnvoll:
• setze die Maximaldrehzahl
13
14
15
16
dies ist nötig, um den Wirkungsgrad und die Geräuschentwicklung bei unterschiedlichen Maximaldrehzahlen
erproben zu können
bei der bisherigen Implementierung wird die Ausschaltzeit beim Choppen per Busy-Waiting realisiert, deshalb kann sie nicht zu groß gewählt werden, ohne die verfügbare Rechenleistung und den Energieverbrauch
unakzeptabel negativ zu beeinflussen. Eine kleine Einschaltzeit und somit große Ausschaltzeit ist aber für
niedrige Drehzahlen erforderlich.
der kleinste Atmel Prozessor mit vier Timern ist der ATmega162. Er hat einen um 32 mm2 höheren Platzbedarf und kostet ca. 70% mehr als der ATmega168, also etwa 0.84 EUR mehr bei Abnahme von 1000
Stck.
die höhere Positioniergenauigkeit ist bei einer Flußsteuerung irrelevant
36
• setze die Pulsweite (0..100%)
Die Pulsweite muß bei reduzierter Maximaldrehzahl auch reduziert werden. In welchem Maße,
das ist noch durch Versuche zu bestimmen.
genauere Steuerbarkeit
Das geförderte Volumen ließe sich genauer steuern, wenn nicht nur die Anzahl der Pulsgruppen
in einem Förderauftrag angegeben werden kann, sondern die genaue Anzahl der Motorschritte.
Dazu genügt ein zusätzlicher (Byte-) Parameter.
Die genauerer Steuerbarkeit bietet keinen medizinischen Vorteil, da die erzielbare Genauigkeit
auch jetzt schon vom Pumpkopf bestimmt wird, und nicht von der Ansteuerelektronik. Sie
würde aber folgende Vorteile bieten:
• auch die Verabreichung kleinster (medizinisch unsinniger) Boli würde noch eine hörbare
Reaktion der Pumpe hervorrufen. Dies kann das Vertrauen von Betatestern in die Pumpe
erhöhen, die alle einstellbaren Grenzwerte austesten.
• die Zeit, die für einen Genauigkeitstest der Förderrate erforderlich ist, könnte deutlich
reduziert werden. Bisher ist ein Jitter von +- einer Pulsgruppe pro Minute zu berücksichtigen, der sich erst nach längerer Zeit ausmittelt. Dies Problem könnte um den Faktor
96 (Anzahl der Schritte einer Pulsgruppe) reduziert werden.
5.5 Motorüberwachung
persistenter Schrittzähler
Der Hauptprozessor kann die real abgegebenen Motorschritte nicht so genau zählen, wie der
Aktorprozessor. Um diese Schrittzahl im Aktor zu zählen, ist folgendes erforderlich:
1. ein Zähler im RAM
2. ein Abspeichern des Zählerstandes im EEPROM des Aktorprozessors17 bei Auftreten des
PowerSoonDown Interrupts (von der Spannungsversorgung)
3. ein Wiederherstellen des Zählers im RAM beim Reset
4. ein I2C-Bus Befehl zum Setzen des Zählers auf einen dem Beutelvolumen entsprechenden
Zählerstand nach dem Wechsel des Beutels
5. ein I2C-Bus Befehl zum Auslesen des Zählers
17
hierbei muß die Zyklenfestigkeit des EEPROMS berücksichtigt werden. Diese beträgt beim ATmega168
100 000 Schreibzyklen. Das genügt auch ohne zusätzliche Redundanzmaßnahmen für 10 Jahre Lebensdauer
bei einem Ausschaltvorgang je Stunde.
37
Messung des Motorstroms
Wie in Abschnitt 3.4 beschrieben, dient die Messung der Motorstroms der Erhöhung der Verlässlichkeit der Pumpe.
Die Messung des Motorstroms (max. 300 mA) erfolgt über einen Messwiederstand von 0, 50 Ω
(1% Toleranz) mit einem nachgeschalteten Verstärker (10 fache Verstärkung). Somit ergibt
sich am Ausgang des Verstärkers eine maximale Meßspannung von 1,5 Volt. Diese wird mit
dem 10 Bit A/D-Wandler des ATmega168 gemessen. Es werden mehrere Messungen bei voller
Schrittfrequenz vorgenommen und gemittelt, sodaß für jede Pulsgruppe ein mittlerer Motorstrom zum Auslesen bereitsteht.
Beim Überschreiten eines Grenzwertes wird ein Schrittverlust erkannt. Darauf kann unterschiedlich reagiert werden:
1. wenn vom Motor nicht die volle Drehzahl verlangt wird wäre es sinnvoll, den Versuch zu
unternehmen, die Förderung bei reduzierter Maximaldrehzahl und mit einer gegenüber
dem Standardwert vergrößerten Pulsweite fortzusetzen18
2. wenn weiterhin Schrittverluste auftreten, sollte der Motor stoppen und eine Fehlermeldung an den Anwender erfolgen
Folgende I2C-Bus Befehle sollten implementiert werden:
1. Auslesen des mittleren Motorstroms der letzten Pulsgruppe
2. Es ist noch nicht klar, wie genau sich die Anzahl der verlorenen Schritte bei Überlast
detektieren lassen. Falls dies hinreichend genau möglich ist, sollte ihre Anzahl auslesbar
sein, andernfalls der maximale Motorstrom der letzten Pulsgruppe
18
dies entspricht der Anforderung an sicherheitskritische Echtzeitsysteme, falls irgend möglich bei Überlastung
ihre Leistung gezielt herunterzufahren, nicht aber plötzlich ganz auszusetzen
38
6 Umsetzung
Die Umsetzung erfolgte auf der Grundlage des auf der folgenden Seite abgebildeten Blockdiagramms.
Kerstück ist die ActorCPU1 . Sie steuert über den StepperDriver (Schrittmotor-Treiber) den
StepperMotor.
Die ActorCPU überwacht über den Current IN Eingang den Strom durch die Motor Spulen.
Die Keyboard-Eingänge der ActorCPU ermöglichen es ihr, die korrekte Funktion des Hauptprozessors (der MainCPU) zu überwachen (Softwaretechnisch noch nicht realisiert).
Über den TXD Ausgang können Debug-Signale ausgegeben werden.
Die MainCPU hat folgende Aufgaben:
1. Abfrage der Tastatur
2. Ansteuerung der LCD-Anzeige
3. Kommunikation mit externen Geräten, z.B. PC oder Palm
4. Überwachung der Flußrate über den Hallsensor, der die Umdrehungen des Pumpkopfes
zählt
5. Drucküberwachung
6. Ansteuerung und Überwachung der ActorCPU
7. Alarmsignalisierung im Fehlerfall
8. Blinken mit der grünen LED wenn Pumpe läuft
9. Bereitstellung einer Echtzeituhr
10. Aufzeichnung von Ereignissen im EEPROM
Zu Testzwecken kann an die serielle Schnittstelle ein Laptop/PC angeschlossen werden.
1
die korrekte deutsche Schreibweise wäre Aktor CPU. Ich benutze hier die englische Schreibweise, um die im
(englischen) Blockdiagramm verwendeten Begriffe beizubehalten.
39
6.1 Blockdiagramm
Abbildung 6.1: Blockdiagramm
40
6.2 Schaltplan
Abbildung 6.2: Schaltplan
41
Abbildung 6.3: Motortreiber
42
Schaltplan Links auf dem Schaltplan sieht man den Hauptprozessor, rechts den Aktorprozessor. Oben ist die Stiftleiste zum Messen der Signale mit einem Oszilloskop und/oder einem
Logic-Analyser zu sehen. Ganz links die Tastatur, daneben die Anschlüsse für ein einfaches
LCD Display (zwei Zeilen mit je 16 Zeichen).
Ganz rechts das Netzteil (ein fertiges Modul, daß 2005 von der Firma Pegasus GmbH unter
wesentlicher Mitwirkung des Autors entwickelt wurde).
Das Netzteil erzeugt aus einer Batteriespannung von 2-3 Volt die Betriebsspannungen von
3,3 und 5 Volt. Außerdem verfügt es über eine Notstromversorgung, die bei Entnahme der
Batterien die 3,3 Volt Spannung noch für ca. 300 ms aufrecht erhält und dies rechtzeitig über
das 1V8 IRQ Signal ankündigt.
Ganz rechts oben der Treiber (Pegelwandler) für die serielle RS232 Schittstelle, der über ein
Autoshutdown Feature verfügt (die Stromaufnahme wird bei Abziehen des Steckers automatisch auf ein Minimum reduziert).
Rechts unten die rote LED, die von beiden Prozessoren als Fehleranzeige angeschaltet werden
kann, und die grüne LED, die im Betrieb regelmäßig aufblinkt.
Folgende Komponenten fehlen im Vergleich zur realen Pumpe:
• Druckmeßwandler
• Akku-Ladeteil
• akustischer Alarm
• Echtzeituhr
• Ereignisrecorder (großer EEPROM)
• Überwachung von Temperatur und Betriebsspannungen
(All dies ist für den hier gegebenen Zweck - Messung von Wirkungsgrad, Drehmoment, Schrittgenauigkeit etc. nicht nötig.)
Motortreiber Der Motortreiber ist aus preiswerten Standardbauteilen aufgebaut. Neu ist
die Möglichkeit des Choppens über einen separaten PWM-Eingang sowie die Möglichkeit der
Strommessung.
Der Zweck von R10/ R12 liegt in einer Nullpunktverschiebung, damit auch ein negativer Offset
des (preiswerten) Operationsverstärkers gemessen und korrigiert werden kann.
Der verwendete Operationsverstärker hat folgende Merkmale:
• preiswert (< 0.50 EUR)
• niedrige Stromaufname (< 10 µA)
• Ein- und Ausgänge sind Rail-to-Rail fähig, können also (fast) über den gesamten Betriebsspannungsbereich genutzt werden.
• kleine Bauform (SC70-5 Gehäuse)
43
6.3 Software
6.3.1 Formale Anforderungen
Die formalen Anforderung an den Hauptprozessor und an den Aktorprozessor habe ich in den
folgenden beiden Diagrammen dargestellt:
Abbildung 6.4: Formale Anforderungen Hauptprozessor
44
Abbildung 6.5: Formale Anforderungen Aktorprozessor
45
6.3.2 Zustandsdiagramme
Der Kern der Steuerung wird vom Ramp Controller“ gebildet, der Klasse, die für die Erzeu”
gung der Pulsgruppen incl. der Beschleunigungs- und Bremsrampe zuständig ist. Die Funktion
dieser Klasse wird im folgenden Diagramm dargestellt:
Abbildung 6.6: Zustandsdiagramm Ramp Controller
Der Befehl run(wGroupCount, wDelayMS, wDelayPart) startet diese Zustandsmaschine, die
dann die vorgegebene Anzahl von Pulsgruppen erzeugt. Die Länge einer jeden Pulsgruppe
beträgt konstant 96 Vollschritte, das entspricht zwei Motorumdrehungen.
Der Vorteil der Pulsgruppensteuerung besteht in der verringerten Leistungsaufnahme bei niedrigen Förderraten im Vergleich zur kontinuierlichen Förderung, da in den Pausen zwischen den
Pulsgruppen der Motor ganz und die Steuerung fast ganz abgeschaltet werden können.
46
6.3.3 Echtzeitkern (RTOS)
Als Echtzeitkern verwende ich FreeRTOS.
Die Zustände, die eine Task annehmen kann, sind im folgenden Diagramm zu sehen:
Abbildung 6.7: Zustände einer FreeRTOS Task
47
6.3.4 Zeitverhalten
Alle hier angegebenen Zeiten gelten nur unter den folgenden Voraussetzungen:
1. Taktfrequenz 8 Mhz ± 2%
2. Compiler GNU C Version 3.4.5, Optimierung -s
Um ein verifizierbares Zeitverhalten zu erreichen, verwende ich folgende Interrupts und Tasks:
6.3.4.1 Interrupts
Wie auf S. 25 erläutert, sollten Interrupts sparsam verwendet werden und sich nicht gegenseitig
unterbrechen können.
Ich verwende die folgenden Interrupts:
1. Timer1 CMI (Compare Match Interrupt)
(max. alle 900 µs, Dauer der IRQ-Routine max. 150 µs)
2. RS232 Data Received Interrupt (max. alle 263 µs, Dauer max. 30 µs)
3. Clock Tick (genau alle 1/512 sec, Dauer max. 100 µs)
Der Clock Tick Interrupt ist für den Taskswitcher erforderlich. Die RS232 Interrupts sind
erforderlich, da bei 38000 Baud alle 263 µs ein neues Byte eintreffen kann, daß in einem Puffer
gesammelt werden muß, um dann vollständige Befehle von der zuständigen Task auswerten zu
lassen.
Der Timer1 CMI dient der Erzeugung der Halbschritte, die nicht nur sehr schnell generiert
werden müssen, sondern auch nur einen kleinen Jitter haben dürfen. Um dieser Anforderung
gerecht zu werden, ohne mit einem höher priorisierten Interrupt zu arbeiten, der andere IRQ
Routinen unterbrechen kann, verwende ich folgendes Konzept:
• der Timer1 CMI wird 110µs ausgelöst, BEVOR ein neuer Halbschritt ausgegeben werden
muß
• in einer Busy Waiting“ Schleife wird darauf gewartet, daß der genaue Zeitpunkt erreicht
”
ist, und dann der neue Halbschritt ausgegeben.
Rechenlast Der Timer1 CMI erzeugt eine Rechenlast von max. 15%, der RS232 Interrupt
eine Rechenlast von max. 12%, der Clock Tick eine Rechenlast von max. 5%.
Somit ergibt sich eine gesamt Interrupt-Last von max. 32%, die bei der Berechnung der Rechenzeiten der Funktionen im Hauptprogramm berücksichtigt werden muß.
48
Rechtzeitigkeit Bei der Abarbeitung des Clock-Ticks sei ein Jitter von 10%, also von 200µs
zulässig (dies ist im folgenden zu beachten). Diese Bedingung ist erfüllt, da durch Timer1 und
RS232 Interrupt eine Verzögerung von max. 150µs + 30µs = 180µs auftreten kann.
Bei der Abarbeitung des RS232 Interrupts darf eine Verzögerung von max. 263µs auftreten.
Diese Bedingung ist erfüllt, da durch den Clock Tick und den Timer1 IRQ eine max. Verzögerung von 100µs + 150µs = 250µs auftreten kann.
Bei der Abarbeitung des Timer1 CMI darf eine Verzögerung von max. 110µs auftreten, die von
der Busy Waiting Schleife kompensiert wird. Diese Bedingung ist erfüllt, da der Timer1 CMI
eine höhere Priorität als alle anderen Interrupts hat und somit durch den Clock Tick und den
RS232 Interrupt eine max. Verzögerung von
max(100µs, 30µs) = 100µs
auftreten kann.
6.3.4.2 Tasks und Koroutinen
Ich verwende die folgenden, parallel laufenden Tasks:
1. Kommando Interpreter incl. I2C Treiber
2. Förderauftrag Abwicklung
(hierzu gehört das Hochfahren der Geschwindigkeit am Anfang einer Pulsgruppe, das
langsame Abbremsen am Ende sowie die Erzeugung von n Pulsgruppen im per Parameter
definerten Zeitabstand)
3. Selbsttest (insbesondere CRC des Programmspeichers)
I2C-Treiber und Kommando Interpreter habe ich Zwecks Speicherplatz-Ersparniss in einer
Task zusammengefasst.
Außerdem verwende die folgende Koroutinen im Hintergrund (Idle-Task):
1. Erzeugung des Signals für die externe Watchdog
(wird nur generiert, wenn der ein Förderauftrag läuft)
2. Erzeugung des Signals für die interne Watchdog (wird immer generiert, wenn kein interner
Fehler detektiert wurde)
Koroutinen bieten gegenüber Tasks den Vorteil, daß sie sich einen Stack teilen und dadurch
RAM Speicher sparen. Allerdings ist mit ihnen nur kooperatives Multitasking möglich, sie
haben auch noch weitere Einschränkungen2 und sind somit nur für sehr einfache Aufgaben
verwendbar.
Die Stromüberwachung erfolgt im Timer1 Interrupt.
2
auf http://www.freertos.org/croutine.html findet sich ein ausführlicher Vergleich von Tasks und Koroutinen. Als Nachteile werden genannt: Lack of stack requires special consideration“ , Restrictions on where
”
”
API calls can be made“ und Co-operative operation only amongst co-routines themselves“ .
”
49
Risikobetrachtungen
Risiko der Überlast Eine Interrupt Überlast könnte auftreten, wenn die RS232 Schnittstelle
mit einer höheren Baudrate als 38000 Baud betrieben wird. Da die Baudrate allerdings in der
Firmware hart kodiert ist, kann dies Problem bei einer guten Dokumentation der Software nur
bei groben Programmierfehlern in ferner Zukunft auftreten3 .
Dasselbe gilt für die max. Schrittfrequenz: Auch Sie darf nicht ohne eine erneute genaue Betrachtung des Zeitverhaltens erhöht werden.
Die Frequenz des Clock Ticks darf ohne eine erneute, genaue Betrachtung des Zeitverhaltens
weder erhöht (Risiko der Überlast) noch verringert werden (Riskio des Verhungerns).
Risiko des Verhungerns Das Riskio des Verhungerns konnte in einem Codereview mit Dipl.
Ing. Pokriefke am xx.yy.2006 ausgeschlossen werden.
6.3.5 Speicherbedarf
Der Speicherbedarf hängt stark von der Anzahl der Tasks ab, diese sollte deshalb minimiert
werden.
Anzahl
Objekttyp
Einzelbedarf
4
4
2
2
2
Task
Taskstack
Priorität
Queue
QueueData
20
85
16
45
10
Gesamtbedarf (Bytes)
Summe
80
340
32
90
20
562
Tabelle 6.1: Speicherbedarf
Der tatsächlich von den einzelnen Tasks benötigte Stack sollte zur Laufzeit überwacht und dann
der höchste gemessene Wert zzgl. einem Sicherheitsaufschlag von z.B. 20% gewählt werden.
3
leider können auch Hardwarefehler, etwa ein fälschlicherweise auf 1 Mhz programmierter Taktoszillator zu
einer Überlast führen. Deshalb ist die Überwachung des Aktorprozessors durch den Hauptprozessor erforderlich, der im Störungsfall das System in den sicheren Zustand überführt
50
6.4 Das Labormuster
Das Labormuster befindet sich auf einer 150 ∗ 90 mm2 großen Platine. Auf ihr finden Platz:
1. Batteriehalterung für zwei Mignon-Zellen
2. Spannungswandler für 5V und für 3,3 Volt mit Notstromversorgung
3. RS232 Treiber mit Stecker
4. Zwei Stecker zum Programmieren der Prozessoren
5. Anschluß für Logic-Analyser zu Testzwecken
6. Fünf Tasten zur Bedienung
7. Fassung für LCD-Display
8. die Prozessoren
9. der Motortreiber incl. Stecker
Abbildung 6.8: Labormuster
Das Layout habe ich mit der CAD- Software Target 3000 erstellt (siehe Anhang Softwarewerkzeuge).
Beim Autorouten der sehr feinen SMD-Teile mußte ich sehr oft die Teile drehen und schieben,
bis der Router alle Leitungen verlegen konnte.
Für professionelles Arbeiten könnte die Verwendung des zusätlich erhältlichen Elektra-Autorouter
viel Zeit und Nerven sparen.
51
7 Ergebnisse
7.1 Drehmoment
7.1.1 Meßaufbau
Die Messung des Drehmoments der hier betrachteten Schrittmotoren erfolgt mit dem folgenden
Aufbau:
Der Motor ist mit Winkeln so auf einer Grundplatte befestigt, daß die Motorachse waagerecht
liegt. In ca. 20 cm Abstand befindet sich darüber das Drehmomentmeßgerät. Das Drehmomentmeßgerät verfügt über eine Meßscheibe mit dem Durchmesser D1 . An ihm ihr ist eine Schnur
befestigt, die über eine Schnurrolle mit dem Durchmesser D2 läuft, die auf der Motorachse
befestigt ist.
(Anstelle einer Schnurrolle kam eine Distanzhülse aus Kunststoff zum Einsatz, die einen Außendurchmesser von 4.0 mm hat. Außerdem wurde die Schnur auf einer Länge von ca. 6 cm
durch ein ZickZack Gummiband ersetzt, dadurch erreicht man einen ähnlichen Effekt wie mit
einer Elastomer Kupplung, einen ruhigeren Lauf und ein um ca. 15 % höheres Drehmoment.)
Daß Drehmomentmeßgerät ist auf einem klappbaren Brett befestigt, so daß sich der Abstand
vom Motor mit einer Flügelschraube fein einstellen läßt.
Durch Anziehen der Flügelschraube wird die Schnur gespannt und eine Bremskraft auf den
Motor ausgeübt. Diese kann dann mit dem Drehmomentmeßgerät gemessen werden.
Ich habe immer versucht, das maximale Drehmoment zu bestimmen, bei dem gerade eben
kein Schrittverlust (in einer Zeitspanne von einer Minute) auftritt, also zunächst die Schnur
gespannt, bis Schrittverlust auftritt, und dann die Schnur wieder ein wenig gelockert, und dann
das Drehmoment abgelesen.
Es gilt:
MM otor = Mgemessen ∗ D2 /D1
7.1.2 Meßfehler
Genaue Messungen durchzuführen erwies sich als schwierig. Folgende Fehlerquellen habe ich
in Betracht gezogen:
F1: die Reibung der Motorachse
F2: die Ungenauigkeit des Durchmessers der Distanzhülse
52
Abbildung 7.1: Meßaufbau zur Messung des Drehmoments
F3: die Schwierigkeit, genau den Meßpunkt zu bestimmen, wo gerade keine Schrittverluste
auftreten
F4: die Auflösung des Meßgerätes
F5: die Nullpunktdrift des Meßgerätes
F6: das Trägheitsmoment der Distanzhülle
Unter der Annahme, daß der Reibungskoeffizient des Motorlagers um den Faktor vier geringer
ist, als der Reibungskoeffizient der Schnur (Naturmaterial) auf dem Kunststoff, gilt:
F 1 ≤ 12.5%.
53
Aus D1 = 4 mm ± 0.1 mm folgt F 2 ≤ 2.5%. Aus der Wiederholgenauigkeit der Messungen
mit ansonsten gleichem Aufbau ergibt sich für F3 als Abschätzung ein Wert von 10 %.
Für MM otor > 1 mN m gilt F4 <= 6 %.
Eine Nullpunktdrift von ein bis zwei Digit ließ sich nur in der ersten Minute nach dem Einschalten beobachten. Von daher läßt sie sich vernachlässigen, wenn nach dem Einschalten des
Meßgerätes eine Aufwärmzeit von zumindest fünf Minuten abgewartet wird, und vor jeder
Meßreihe ein erneuter Nullpunktabgleich mit frei hängender Meßschnur erfolgt.
Das Trägheitsmoment der Distanzhülse tritt nur dann als Fehlerquelle in betracht, wenn der
Motor im Start- Stopp Betrieb vermessen wird. Ich vernachlässige es ebenfalls, da Durchmesser
und Masse dieser Hülse erheblich unter dem Durchmesser und der Masse des Ankers der hier
betrachteten Motoren lag.
Somit gilt für den Absolutfehler:
Fabs <= F 1 + F 2 + F 3 + F 4 <= 31%
und für den Relativfehler (beim Vergleich der alten mit der neuen Schrittmotorsteuerung unter
Verwendung desselben Motors mit derselben Distanzhülse):
Frel <= F 3 + F 4 <= 16%
Der Relativfehler läßt sich durch wiederholte Messung und Mittelwertbildung weiter reduzieren.
7.1.3 Ergebnisse
7.1.3.1 Drehmoment und Wirkungsgrad
Um einen Anstieg des Spulenstroms bei einer Verringerung der Halbschrittfrequenz zu vermeiden, ändere ich das Verhältnis, mit dem der Spulenstrom gechoppt wird gemäß der folgenden,
experimentell gefundenen Formel:
ch1 = 1 − 0.6 ∗ ((f max − f )/f max))
fmax: maximale Halbschrittfrequenz der bisherigen Schrittmotorsteuerung (1066 Hz)
ch1 : choplevel (Einschaltverhältnis), ein Wert zwischen 1 und 0
Zusätzlich wird der choplevel für die Phasen, in denen beide Spulen bestromt werden, mit dem
Faktor 0.88 multipliziert1 . Somit gilt:
ch2 = 0.88 ∗ ch1
1
√
theoretisch müßte der Strom je Spule um den Faktor 1/ 2 abgesenkt werden, um eine minimale Welligkeit
des Drehmoments zu erhalten
54
Mit dieser Ansteuerung ergibt sich die in Abb. 7.2 dargestellte Abhängigkeit von Drehmoment und Wirkungsgrad von der Halbschrittfrequenz. Gut erkennbar ist das nahezu konstante
Drehmoment im Bereich f = 250 .. 1066 Hz. Bei höheren Schrittfrequenzen fällt das Drehmoment näherungsweise linear ab, es würde bei ca. 1750 Hz die Nullachse schneiden (theoretische
Maximalfrequenz). In dieser Messung habe ich einen maximalen Wirkungsgrad von ca. 18%
ermittelt (+35-25% vom Meßwert, dieser Fehler ergibt sich aus der Summe der Fehler der
Drehmomentmessung und der Messung der Leistungsaufnahme).
Abbildung 7.2: Drehmoment und Wirkungsgrad
Aus dieser Messung ergibt sich, daß die bisherige Maximalfrequenz bereits das Optimum für
den Motorwirkungsgrad darstellt.
7.1.3.2 Stromaufnahme und Wirkungsgrad
Die Abhängigkeit der Stromaufnahme und des Wirkungsgrads vom Drehmoment bei einer konstanten Halbschrittfrequenz von 1066 Hz ist in 7.3 dargestellt. Es ergibt sich ein maximaler
Wirkungsgrad bei einem Drehmoment von 1.35 mNm von ca. 20%. Außerdem ist gut erkennbar, daß im Bereich von Null bis ca. 0.8 mNm eine nahezu lineare Abhängigkeit der mittleren
Stromaufnahme vom Drehmoment gegeben ist, allerdings mit der recht hohen Leerlaufstromaufnahme von ca. 44.2 mA.
Dieser Zusammenhang kann genutzt werden, indirekt (über die Messung der Motorstromaufnahme) das Drehmoment zu ermitteln, daß von einer eingebauten Pumpkopf/ GetriebeKombination unter realen Bedingungen benötigt wird.
Ich habe mit der Pumpkopf/ Getriebe-Kombination light 02 eine mittlere Stromaufnahme von
47 bis 55 mA gemessen. Daraus ergibt sich (aus dem Diagramm abgelesen) ein real erforder-
55
liches Drehmoment von ca. 0.2 bis 0.4 mNm sowie ein mittlerer Motorwirkungsgrad von ca.
7.5 %.
Wie in 3.1 beschrieben, ist bei einem Ausgangsdruck von 1500 hPa eine mechanische Ausgangsleistung von 4.17 mW erforderlich. Aus den Meßwerten ergibt sich eine Erhöhung der
Stromaufnahme um ca. 0.42 mA pro mW zusätzlicher Ausgangsleistung und somit eine maximale Erhöhung der Stromaufnahme um 1.77 mA bei maximalem Ausgangsdruck.
Dieser Anstieg ist so gering, daß er meines Erachtens nicht zur indirekten Bestimmung des
ausgangsseitigen Drucks verwendendet werden kann.
Abbildung 7.3: Stromaufnahme und Wirkungsgrad
7.1.3.3 Pulsgruppenbetrieb
Im Pulsgruppenbetrieb (96 Motorschritte, dann 20 ms Pause bei 100 ml/h, bei niedrigeren
Förderraten entsprechend längere Pausen) ergibt sich ein etwas geringeres maximales Drehmoment, da das Anlaufbeschleunigungsdrehmoment zusätzlich aufgebracht werden muß und
außerdem aufgrund der Trägheit des Meßaufbaus das Maximaldrehmoment nicht exakt bestimmt werden kann.
Dadurch, daß die neue Steuerung in Abhängigkeit der Schrittfrequenz choppt, konnten Messungen mit einer beliebig niedrigen Startfrequenz und einer beliebig geringen Anlaufbeschleunigung durchgeführt werden, ohne daß dadurch die Anlaufstromaufnahme unzulässig angestiegen
wäre.
56
Erstaunlicherweise ergab eine sehr geringe Anlaufbeschleunigung keine Verbesserung, sondern
eine Verschlechterung, vermutlich aufgrund von Motorresonanzen.
Mit dem gegebenen Motor ergaben folgende Werte für die Beschleunigungsrampe ein optimales
Ergebnis (minimale Spitzenstromaufnahme, maximales Drehmoment):
• fmin = 500 Hz
• fmax = 1066 Hz
• deltaV = 72 Hz (Frequenzerhöhung pro Millisekunde)
Daraus ergibt sich für die Länge der Start- und der Stoprampe eine Dauer von je 8 ms.
Die Ergebnisse sind in Tabelle 7.1 mit dargestellt.
7.2 Leistungsaufnahme
7.2.1 bisheriges System
7.2.1.1 Spitzenstromaufnahme
Ich habe eine Spitzenstromaufnahme von ca. 200 mA gemessen (Abb. 7.4).
(Meßwiderstand 1 Ohm, Kondensator 1200µF parallel zum Motortreiber, Filter 10 kOhm/
100 nF vor dem Oszilloskopeingang, Differenzspannungsmessung, AC-Kopplung).
7.2.1.2 mittlere Leistungsaufnahme
Vorbemerkung Anders als in 7.1.3.2 habe ich hier die Leistungsaufnahme am Eingang des
Spannungswandlers der Steuerung, also incl. der Leistungsaufnahme der Prozessoren und der
Verluste der Spannungswandler gemessen.
Bei einer Eingangsspannung von 2.41 V betrug die Stromaufnahme 220 bis 270 mA.
(Förderrate 100 ml/h, Aktor-Firmware 1.2, Messung am 27.05.2006, Motor/ Getriebeeinheit
light 02)
Daraus errechnet sich eine mittlere Leistungsaufnahme von 590 mW.
7.2.2 neues System
7.2.2.1 Spitzenstromaufnahme
Ich habe eine Spitzenstromaufnahme von ca. 98 mA gemssen (Abb. 7.5). Zur Minimierung der
Spitzenstromaufnahme trug der Betrieb des Chop-Timers im phasensychronen Modus bei. (Im
Fast PWM Modus lag die Spitzenstromaufnahme ca. 20 % höher.)
57
Abbildung 7.4: Spitzenstromaufnahme mit alter Steuerung
7.2.2.2 mittlere Leistungsaufnahme
Bei einer Eingangsspannung von 2.41 V betrug die Stromaufnahme 110 bis 140 mA.
(Befehl run 1000 201 , Firmware 0.4.3, Messung am 27.05.2006, Motor/ Getriebeeinheit light 02)
Daraus errechnet sich eine mittlere Leistungsaufnahme von 301 mW.
7.2.3 vergleichende Wertung
Eigenschaft
Förderrate
Drehmoment (max)
Spitzenstrom
P el (im Mittel)
P el (im Mittel)
P el (im Mittel)
100
100
100
10
2
ml/h
ml/h
ml/h
ml/h
ml/h
bisheriges
neues System
Veränderung
Verbesserung2
0.59 mNm
200 mA
590 mW
XXX mW
XXX mW
1.51 mNm
98 mA
301 mW
YYY mW
YYY mW
+156 %
-51 %
-49 %
Faktor 2.56
Faktor 2.04
Faktor 1.96
Faktor zzz
Faktor zzz
Tabelle 7.1: Vergleich von Spitzenstrom und Leistungsaufnahme
1
2
dieser Befehl bedeutet: 1000 Pulsgruppen mit je 96 Vollschritten ausgeben, zwischen zwei Pulsgruppen jeweils
20 ms warten
als Verbesserungsfaktor verstehe ich den Quotient neuer Wert/ alter Wert, wenn ein hoher Wert erstrebenswert ist, und anderenfalls der Kehrwert dieses Quotienten
58
Abbildung 7.5: Spitzenstromaufnahme mit neuer Steuerung
Die Verbesserung des Drehmoments konnte vor allem durch die optimierte Rampensteuerung
erreicht werden. Gleichzeitig war es möglich, die Leistungsaufnahme und den Spitzenstrom
erheblich zu reduzieren.
Bei niedrigen Förderraten konnte sogar eine Verringerung der Leistungsaufnahme um mehr als
70 % erreicht werden, d.h. die Batterielaufzeit konnte mehr als verdreifacht werden.
7.3 Platzbedarf und Kosten
Ich betrachte hier vereinfachend nur die aktiven Bauelemente sowie die geschätzten Entwicklungskosten. Die Bauteilekosten beruhen auf Angeboten über 1000 Stck., die ich im Dez. 2005
und Febr. 2006 eingeholt habe, sowie einem Kurs von 1 EUR = 1,20 US$. Die Entwicklungskosten sind geschätzt.
Die Größe (minimal benötigte Platinenfläche) pro Bauteil habe ich folgendermaßen berechnet:
(Länge + 2 mm) ∗ (Breite + 2 mm)
ich bin also von einem Bauteilabstand von 2 mm ausgegangen. Dies ist ein konservativer Ansatz,
ein Bauteilabstand von 1,5 mm sollte bei einer Multilayerplatine realisierbar sein.
59
bisheriges System
Ein Entwicklungsaufwand von sechs Mannmonaten à 5000 EUR, das ergibt 30000 EUR, umgelegt auf ein geschätztes Produktionsvolumen von 3000 Stck.
Anzahl
1
2
1
1
1
Größe (mm2 )
Gesamtpreis (EUR)
P89LPC922
Si9987
Si2301 EDS
BSS123
Quarz 8.388 Mhz
82.9
119.7
22.5
22.5
37.2
1.15
4.02
0.10
0.03
0.15
Zwischensumme:
Entwicklungskosten:
284.8
5.45
10.00
Gesamtsumme:
284.8
15.45
Bauteil
Tabelle 7.2: Platzbedarf und Kosten bisheriges System
neues System
Ein Entwicklungsaufwand von drei Mannmonaten à 5000 EUR, das ergibt 15000 EUR, umgelegt auf ein geschätztes Produktionsvolumen von 3000 Stck.
Anzahl
1
2
2
1
2
1
1
Bauteil
Gehäuse
Größe (mm2 )
Gesamtpreis (EUR)
ATmega168
FDG6313N
FDG6306P
74HCT00
PMEG3002TV
LPV321
Quarz 32 kHz
MLF
SC70-6
SC70-6
TSSOP
SOT666
SC70-5
49.0
32.8
32.8
58.8
35.6
17.6
28.4
1.20
0.25
0.28
0.09
0.22
0.27
0.57
Zwischensumme:
Entwicklungskosten:
255.0
2.88
5.00
Gesamtsumme:
255.0
7.88
Tabelle 7.3: Platzbedarf und Kosten neues System
Nicht berücksichtigt habe ich die Kosten für die Integration in das bestehende System sowie
die Kosten für ein neues Platinenlayout.
vergleichende Wertung
Durch die Verwendung von Standardbauteilen in Kombination mit einer leistungsfähigen MCU
anstelle von hochgradig spezialisierten Bauteilen wie dem Si9987 (einer H-Brücke) konnten bei
60
etwa demselben Platzbedarf die Bauteilkosten - trotz zusätzlicher Funktionalität - fast auf die
Hälfte reduziert werden.
Allerdings stieg die Anzahl der Bauteile deutlich an, was sich negativ auf die HardwareZuverlässigkeit auswirkt. Ich halte das für vertretbar, da hier auftretende Hardwarefehler sehr
schnell erkannt und durch Inspektionsmaßnahmen nach der Bestückung weitestgehend vermieden werden können.
Die Verwendung eines besser geeigneten Prozessors, besserer Entwurfswerkzeuge und einer
besseren Entwicklungsmethodik führten zu einem erheblich verringerten Entwicklungsaufwand,
wobei fairerweise gesagt werden muß, daß der Verfasser ein wenig auch an der Entwicklung des
bisherigen Systems beteiligt war und von daher nicht bei Null anfangen mußte.
7.4 Verifizierbarkeit
Die Verifizierbarkeit der korrekten Funktion und des korrekten Zeitverhalten der Firmware
konnte durch die Verwendung eines Echtzeitkerns (RTOS) sowie durch die Vermeidung von
verschachtelten Interrupts erheblich verbessert werden. Auch die Verfügbarkeit einer relativ
schnellen (38 kBaud) gepufferten seriellen Schnittstelle, über die Debug-Ausgaben erfolgen
können, verbessert die Verifizierbarkeit des Systems.
7.5 Verlässlichkeit
Die Verlässlichkeit des Systems konnte durch die Überwachung des Motorstrom sowie das
höhere Drehmoment erheblich gesteigert werden. (Eine Schlupfkorrektur als Fehlertoleranzmaßnahme für Schrittverluste dürfte jetzt überflüssig geworden sein.)
Ein typischer Motorstromverlauf bei Überlast ist in Abb. 7.6 dargestellt. Wenn der Motorstrom
180 mA2 überschreitet wird ein Schrittverlust detektiert. Bei jedem Schrittverlust erfolgt eine
Warnung3 , bei einem Schrittverlust in mehr als drei Pulsgruppen wird ein Fehler gemeldet und
der Motor gestoppt.
Die Fehlererkennungszeit bei einer Blockade des Motors konnte - bei einer Förderrate von
2 ml/h - von 8 Minuten auf eine Minute reduziert werden.
Leider wird die bisherige Überwachung der Pumpkopfdrehung per Hallsensor durch die neue
Motorstromüberwachung nicht überflüssig, da sich bestimmte (sehr seltene) Fehler, wie ein
ausgehaktes Zahnrad vorläufig nur mit dem Tachopulsgenerator entdecken lassen.
2
3
bei maximalem Drehmoment lag der gemessene Maximalstrom unter 160 mA, bei Schrittverlust immer über
200 mA, deshalb wurde 180 mA als Schwellwert gewählt
diese wird hier durch ein Ausgabe auf der Terminal Konsole gemeldet, in der entgültigen Pumpe wäre es
sinnvoll, diese Warnung im Service-Recorder aufzuzeichnen, nicht aber dem Anwender zu melden
61
Abbildung 7.6: Motorstromverlauf bei Schrittverlusten
7.6 Features
Die Abspeicherung des geförderten Volumens im Aktorprozessor in Kombination mit der Erkennung von Schrittverlusten ermöglicht eine sehr viel genauere Aufzeichnung des geförderten
Volumens, z.B. können nun auch sehr kleine Entlüftungsvolumen (kleiner als ein Hallsensorpuls) erstmals aufgezeichnet werden.
7.7 Ausblick
Von den sechs Optimierungszielen (siehe 2.2) konnten fünf erreicht werden. Bei einer kompletten Neuentwicklung könnte das Konzept des symmetrischen Zweiprozessorsystems umgesetzt
und damit die nächsthöhere Sicherheitsklasse4 erreicht werden. Die Grundlagen dafür sind
gelegt.
Motorvolumen und Leistungsaufnahme ließen sich durch einen anderen Motor weiter reduzieren, dies wäre allerdings mit höheren Kosten verbunden.
Die unerwartet hohe Erhöhung des Drehmoments schafft die Möglichkeit, durch eine andere
Getriebeübersetzung die maximale Förderrate zu erhöhen und die Leistungsaufnahme weiter
zu senken.
Die Geräuschoptimierung könnte in einer weiteren Arbeit genauer untersucht werden.
4
in Anlehnung an den Normentwurf nach DIN VDE 0801
62
Als eine Hauptgeräuschquelle bei niedrigen Drehzahlen konnte ich das Getriebe identifizieren.
Sein Geräusch ließe sich durch Schrägverzahnung, Präzision und Materialwahl der Zahnräder
vermutlich deutlich reduzieren, so daß eine Pumpe mit low noise“ Modus (für die Nacht) reali”
sierbar erscheint. Eine Ankopplung des Motors an das Getriebe über eine Elastomer-Kupplung
würde neben einer weiteren Geräuschreduktion auch ein noch höheres Drehmoment ermöglichen.
Auch eine Mikroschrittsteuerung konnte zur Geräuschreduzierung beitragen.
63
Literaturverzeichnis
[ALR00] Avizienis, A., J.-C. Laprie und B. Randell: Dependability of computer systems: Fundamental concepts, terminologiy, and examples. Technischer Bericht,
LAAS-CNRS, September 2000.
[Bar03] Barry, Richard: FreeRTOSTM . http://www.freertos.org, 2003.
[BGJ02] Borgolte, U., M. Gerke und A. Jochheim: Mechatronik und Robotik. Kurs
20104, Fernuniversität Hagen, 2002.
[Dou98] Douglass, Bruce Powel: Real-Time UML. Addison Wesley, 1998.
[EL03] Evans, David und David Larochelle: Splint Manual. Technischer Bericht,
University of Virginia, 2003.
[Köl05] Kölln, Harm: Die Stromaufnahme der PEGASUS Infusionspumpen. Technischer
Bericht, PEGASUS GmbH, 2005. www.pegasus-gmbh.com.
[Lab02] Labrosse, Jean J.: MicroC/OS-II. Osborne McGraw-Hill, 2002.
[MS02] Miro Samek, Ph.D.: Practical Statecharts in C/C++. CMP Books, 2002.
[REGT05] Rummich, Erich, Hermann Ebert, Ralf Gfrörer und Friedrich Traeger: Elektrische Schrittmotoren und -antriebe. expert-Verlag, 2005.
[Sch02] Schlienz, Prof. Dipl.-Ing. Ulrich: Sicherer Schrittmotorbetrieb ohne Positionssensor. Elektronik, (24), November 2002.
[Scz02] Sczepansky, Andreas: MISRA Programmierstandard. Technischer Bericht, QA
Systems, 2002.
[SW03] Six, Hans-Werner und Mario Winter: Softwaretechnik. Kurs 20100, Fernuniversität Hagen, 2003.
[VDE95] VDE0801, Normentwurf DIN: Funktionale Sicherheit - Sicherheitssysteme.
VDE-Verlag und Beuth Verlag, 1995.
[WHRK03] Wolfgang Halang, Prof. Dr. Dr. und Prof. Dr.-Ing Rundolf Konakovsky: Sicherheitsgerichtete Echtzeitsysteme. Kurs 20216, Fernuniversität Hagen, 2003.
[Wik05] Wikipedia: Artikel “Hypoidantrieb”. Stand: 18. Sep 2005 19:49. Online im Internet: http://de.wikipedia.org/wiki/Hypoidantrieb, September 2005.
[Wik06] Wikipedia: Artikel “Kronräder”. Stand: 25. Jan 2006 22:06. Online im Internet:
http://de.wikipedia.org/wiki/Kronenrad, Januar 2006.
64
A Vergleich von FreeRTOS und MicroC/OS2
Eigenschaft
kooperatives Multitasking
präemptives Multitasking
Round Robin Scheduling
Coroutinen
Semaphore
Mutexe1
Queues
Event Flags
Message Mailboxes
relatives Delay
absolutes Delay2
Interruptroutinen
Zertifizierbarkeit
Lizenz
Lizenzkosten
FreeRTOS
MicroC/OS2
JA
JA
JA
JA
JA
NEIN
JA
NEIN
NEIN
JA
JA
in C
mittelschwer3
OpenSource
keine
NEIN
JA
NEIN
NEIN
JA
JA
JA
JA
JA
JA
NEIN
nur in Assembler
leicht
Proprietär
JA (bei kommerziellem Einsatz)
Tabelle A.1: Vergleich von FreeRTOS und MicroC/OS2
wesentlicher Nachteil von FreeRTOS Da die Prioritäten zur Laufzeit nicht geändert werden
können, besteht das Problem der Prioritätsinversion4 . Dies ließe sich vermeiden:
• indem nur die Tasks mit den beiden höchsten Prioritäten auf per Semaphor geschützte
gemeinsam genutzte Resourcen zugreifen
• oder dadurch, daß Tasks mit niedriger Priorität, die auf eine ebensolche Resource zugreifen wollen, alle anderen Tasks mit vTaskSuspendAll() für die Dauer des Zugriffs
suspendieren
wesentlicher Nachteil von MicroC/OS2 Die Lizenzkosten. Für die hier betrachtete Applikation würden Lizenzkosten im unteren vierstelligen Euro-Bereich anfallen.
1
2
3
4
hier ist mit Mutex eine Semaphore gemeint, die das Problem der Prioritätsinversion5 verhindert
warten bis zum Erreichen eines angegebenen Zeitpunktes
Zertifizierungsunterlagen müssen selber erstellt werden
eine Prioritätsinversion besteht dann, wenn eine Task mit niedriger Prioriät eine Task mit höherer Priorität
daran hindert, ausgeführt zu werden. Diese kann genau dann auftreten, wenn eine Task mit hoher Priorität
auf eine Resource wartet, die von einer Task mit niedriger Priorität verwendet wird, und diese von einer
Task mittlerer Prioriät unterbrochen wird.
65
B Verwendete Softwarewerkzeuge
Sofern nichts anderes angegeben ist, handelt es sich um Open Source Programme.
Compiler
• avr-gcc Variante der GNU Compiler Collection“ mit einem Codegenerator für die AT”
MEL AVR Prozessoren. Volle Unterstützung von ANSI C (auch C99), eingeschränkte
Unterstützung von C++ und ADA.
http://winavr.sourceforge.net/ (Windows-Version)
http://www.kieltech.de/uweswiki/Compiling_5fAVR_2dGCC (Linux-Version)
IDE’s (Integrierte Entwicklungs Umgebungen)
• Eclipse universelle IDE (für viele Programmiersprachen geeignet),
geschrieben in Java
http://www.eclipse.org/
• Eclipse-cdt Plugin für C/C++ Entwicklung mit Eclipse
http://www.eclipse.org/cdt
• AVR Studio 4 Kostenlose IDE des Herstellers, mit Integration von avr-gcc, Simulator,
Debugger sowie der Ansteuerung von Programmiergeräten und Emulatoren
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2725
Ich würde Eclipse für sehr kleine Projekte NICHT empfehlen, es sei denn, man hat sowieso
schon Erfahrung im Umgang mit Eclipse. Eclipse ist ein sehr leistungsfähiges Werkzeug aber
erfordert einen hohen Einarbeitungsaufwand.
Software Dokumentation
• Doxygen Dokumentations Werkzeug for C/C++ und andere Programmiersprachen
http://www.stack.nl/~dimitri/doxygen/
• Graphviz graphisches Werkzeug, kann als Zusatz von Doxygen zur Erzeugung von
Aufruf- und Includegraphen verwendet werden
http://www.graphviz.org/
• eclox Plugin zur Vereinfachung der Benutzung von Doxygen innerhalb Eclipse
http://home.gna.org/eclox/
66
Codeanalyse
• cflow Werkzeug zu Erzeugung von Aufrufgraphen in Textdarstellung, kann zur Abschätzung der maximal benötigten Stack-Tiefe verwendet werden.
http://www.gnu.org/software/cflow/
• Splint Werkzeug zur statischen Codeanalyse, seine Verwendung erhöht die Sicherheit
von C Programmen.
http://www.splint.org/
Erstellung der Software Spezifikation
• Enterprise Architect UML Entwurfswerkzeug. Sehr leistungsfähig, kommerziell aber
preiswert, keine offizielle Unterstützung von C
http://www.sparxsystems.com.au/
Schaltplanerstellung und Platinenlayout
Für das Platinenlayout habe ich TARGET 3001! light V12 verwendet, ein preiswertes
kommerzielles Programm.
http://www.ibfriedrich.com/home.htm
67
C Weitere Internetquellen
Folgende Internetquellen sind interessant für denjenigen, der sich in die Entwicklung mit AVR
Mikrokontrollern einarbeiten will:
• Webseite des Herstellers:
http://www.atmel.com/products/AVR/
• AVR-Freaks sehr viele Infos und ein sehr gutes Diskussionsforum
http://www.avrfreaks.com/
• www.mikrocontroller.net eine deutschsprachige Website mit guten Tutorials
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial (als Beispiel)
• Archiv der avr-gcc Mailingliste Wer Webforen nicht mag, sondern eMail bevorzugt,
findet hier schnelle und sehr kompetente Antworten auf (fast) alle Fragen
http://lists.gnu.org/archive/html/avr-gcc-list/
68

Optimierung einer sicherheitskritischen Schrittmotorsteuerung

Transcription

Similar documents

Herstellung von Leiterplatten

forschungsbericht 2010

RELIGIONS- LEHRER Girls! Get$26 • week • 5 days

Jahresbericht des Schuljahres 2014/15

Thread - Universität Ulm

schmiermittel für veteranenfahrzeuge - d

Online-Version

Forschungsnewsletter Wintersemester 15/16

OmniWin® Family

Schrittmotor kurz erklärt