Design&Elektronik, Extraausgabe Okt - Silicann

PROGRAMMIERUNG
Viele Innovationen innerhalb
der nächsten
10 Jahre werden auf
dem Gebiet der »intelligenten«
und busfähigen Sensoren
zu erwarten sein. Getrieben
wird diese Entwicklung
unter anderem von den Forderungen
nach dezentraler
»Intelligenz«, nach Reduktion
der zu übertragenden
Datenmengen und nach
Verringerung des Verkabelungsaufwands.
Es geht zunehmend
darum, die elektrischen
Signale der Primärsensoren
bereits im
Sensorsystem in hoch verdichtete
Nutzinformationen
umzuwandeln und diese
über standardisierte Schnittstellen
zur Verfügung zu
stellen (Bild 1).
Dadurch wachsen die Anforderungen
an die Software-
Entwicklung. Einerseits werden
die notwendigen algorithmischen
Ansätze zur
Signalverarbeitung immer
komplexer. Andererseits stehen
statt leistungsfähiger,
zentraler Recheneinheiten für
Software-Entwicklung outsourcen
Vom Signal zur Information
Outsourcing ist in aller Munde, wenn es um
Kosteneinsparungen geht. Allerdings kann es
auch handfeste technische Vorteile haben,
Teile der Entwicklung an einen spezialisierten
Dienstleister zu vergeben. Anhand eines Beispiels
aus der Sensorik soll dieser Beitrag zeigen,
worauf man bei einer solchen Zusammenarbeit
achten sollte und welche Ergebnisse
ein konkretes Anwendungsbeispiel
gebracht hat.
Henning Fuge
ist für Controller
und Algorithmen bei Silicann
Technologies verantwortlich
20 DESIGN&ELEKTRONIK SOFTWARE-ENTWICKLUNG 2005
die Software-Implementierung
begrenzte Hardware-
Ressourcen im Sensorsystem
zur Verfügung. Sensorhersteller
und -integratoren sind
gut beraten, die Brücke zwischen
Sensorsignal und busfähiger
Nutzinformation von
spezialisierten Dienstleistern
schlagen zu lassen.
Dieser Artikel erläutert die
Projektstufen von der Ausgangssituation
über die Entwicklung
des Algorithmus
und beschreibt methodische
Ansätze der Software-Entwicklung.
Abschließend
stellt er ein konkretes Fallbeispiel
aus einer Zusammenarbeit
zwischen Sensorhersteller
und Signalverarbeitungsspezialist
vor.
Die Entwicklung der Signalverarbeitung
für einen Sensor
wird – nachdem die
Hardware ausgewählt und
aufgebaut ist – oft lediglich
als Softwareprojekt verstanden.
Damit wird das Projekt
zu früh auf die Programmierung
reduziert, getragen
von dem Gedanken: »Der
Sensor ist jetzt fertig, er
muss nur noch schnell programmiert
werden«. Damit
sind folgende Risiken verbunden:
■ Zu knappe Bemessung
dieses Projektabschnittes
■ und damit von Beginn an
falsche Erwartungshaltungen
bezüglich des Fertigstellungstermins,
nicht
selten verstärkt durch eine
späte Bereitstellung der
Hardware-Plattform.
■ Überfrachtung der Software-Entwickler
mit Fragen
der Signaltheorie und
-verarbeitung, die nicht
zu ihren Kernkompetenzen
zählen.
■ Fehlende oder mangelhafte
konzeptionelle
Überlegungen zum Signalverarbeitungsansatz
und zur grundlegenden
Signalverarbeitungstechnik.
■ Unter Zeitdruck erstellte
und von »Work-arounds«
geprägte Softwarestruktur.
■ Unzureichende Generalisierung,
Modularisierung,
Erweiterbarkeit und Wiederverwendbarkeit
der
Software.
Dies kann zu deutlichen
Nachteilen für die Verwertbarkeit
und Zukunftssicherheit
der entstehenden Lösung
führen.
Eine erfolgreiche Entwicklung
für eine Signalverarbeitung
vom Primärsignal bis
zu busfähigen Daten ist geprägt
von typischen Phasen
(Bild 2), die weit vor der eigentlichenSoftware-Entwicklung
beginnen. In der
Darstellung in Bild 2 ist der
Hardware-Zweig ausgeblendet.
Es wird davon ausgegangen,
dass die Hardware-
Entwicklung bereits erfolgt
ist und auf eine vorhandene
Hardware-Plattform zugegriffen
werden soll. Dies entspricht
oft der Realität. Meist
ist es jedoch sinnvoll, die
Signalverarbeitungshardware
nach den grundlegenden
Überlegungen zum Systemdesign
der Software zu
spezifizieren.
Dienstleister
mit einbeziehen
Wird ein Outsourcing angestrebt,
kann und sollte bereits
in der Spezifikationsphase
der Dienstleister eingebunden
werden, da
gerade hier die Erfahrung
des Spezialisten zu entscheidenden
Weichenstellungen
für das Projekt beitragen
kann. So lassen sich Doppelarbeit
und spätere Änderungen
weitgehend ausschließen.
Es ist für den Auftraggeber
ratsam, dem Auftragnehmer
auch Informationen
über die geplante
Produkt-Roadmap zu ge-

en, damit zukünftige Funktionsumfänge
in der Softwarekonzeptionberücksichtigt
werden können.
Den Dienstleister mit der Erstellung
der Spezifikation zu
beauftragen, kann gerade in
einer erstmaligen Zusammenarbeit
als Einstieg dienen,
um das Zusammenspiel
zwischen Auftraggeber und
Auftragnehmer zu testen.
Verläuft diese Phase reibungslos,
ist dies in der Regel
ein guter Indikator für
die weitere Zusammenarbeit.
Zudem ist die externe
Sicht des Spezialisten auf
das Projekt meist unbefangener,
sodass Klärungsbedarf
für die Spezifikation
schneller erkannt wird.
Eine wichtige Funktion
kommt der genauen Analyse
des zu verarbeitenden Signals
zu. In dieser Phase werden
die Grundlagen für die
spätere effiziente Verarbeitung
definiert. Vor allem ist
zu untersuchen, welche redundanzfreieNutzinformation
das Signal enthält, die
für eine spätere Auswertung
benötigt wird. Gelingt es,
diese Nutzinformation zu
extrahieren und damit die
Datenmenge zu reduzieren,
vereinfacht sich die nachfolgende
Auswertung in vielen
Fällen drastisch. Die Art der
Analyse hängt von den Eigenschaften
des Signals ab.
Sie unterscheidet sich unter
anderem je nach dem, ob es
sich um ein zeitdiskretes
oder zeitkontinuierliches,
ein- oder mehrdimensionales,
quasi-lineares oder stark
nicht lineares, ungestörtes
oder stark gestörtes Signal
handelt.
Ausgehend von den Ergebnissen
der Signalanalyse ist
ein geeigneter technischer
Ansatz für die Signalverarbeitung
zu wählen. Hier sind gegebenenfalls
Fragen wie die
folgenden zu beantworten:
■ Wie ist das Signal zu transformieren,
um Korrelationen,
Redundanzen und
Störungen zu beseitigen?
■ Wie lässt sich die Datenmenge
geeignet auf
die Nutzinformation reduzieren?
■ Mit welchen Methoden
sind welche Merkmale zu
extrahieren?
■ Wie werden diese Merkmale
abgebildet und ausgewertet?
Die richtige Wahl des technischen
Ansatzes entscheidet
maßgeblich über das
Aufwand/Nutzen-Verhältnis
der nachfolgenden Schritte.
Zuweilen entscheidet sich
mit der Wahl des technischen
Ansatzes, ob die Lösung
insgesamt realisiert
werden kann.
Anstatt »drauflos« zu programmieren,
muss nun
zunächst auf höherer Abstraktionsebene
überlegt werden,
wie sich der grundsätzliche
technische Ansatz in geeignete
Algorithmen überführen
lässt und wie diese sich optimieren
lassen. Auch in diesem
Schritt steckt – abhängig
von der Anwendung – oft gewaltigesOptimierungspotenzial.
Nachdem Klarheit über den
geeigneten technischen Ansatz
und dessen Überleitung
in Algorithmen herrscht,
kann man das komplette
Systemdesign für die Soft-
DESIGN&ELEKTRONIK SOFTWARE-ENTWICKLUNG 2005
21
ware erstellen. Hierbei wird
festgelegt, welche Verarbeitungsschritte
vorzusehen
sind, in welche Module die
Software zu gliedern ist, wie
die Schnittstellen zwischen
den Modulen gestaltet werden
sollen, welche Datenformate
bedarfsgerecht sind,
wie das Datenmanagement
und die Datenhaltung erfolgen
sollen, etc.
Auswahl der Tools
Tendenziell werden Tools für
die Erstellung der Software
zu früh und anhand der Kriterien
»Was ist vorhanden«
oder »Was ist bekannt« festgelegt.
Die Tools werden regelmäßig
durch die verwendete
Hardware-Plattform
vorgegeben. Dies ist ein weiterer
Grund, die Hardware
erst nach den technischen
Überlegungen zu spezifizieren.
Diese Auswahl sollte –
wenn möglich – erst unmittelbar
vor der eigentlichen
Software-Entwicklung und
unbefangen getroffen werden,
damit die verwendeten
Tools für die Aufgabenstellung
optimal geeignet sind.
Dies setzt natürlich voraus,
dass eine Auswahl unter verschiedenen
Alternativen
möglich ist. Der Spezialist ist
dazu eher in der Lage.
An diesem Punkt erst beginnt
die eigentliche Software-Entwicklung.
Ist die
Vorarbeit gut geleistet, sollte
die Software-Entwicklung
nun keine unliebsamen
Überraschungen mehr bieten
und »straight forward«
in kurzer Zeit zu realisieren
sein. Schließlich ist die meist
auf einem Funktionsmuster
oder Prototypen entwickelte
Software auf die serienreife
Zielhardware zu übertragen.
Als nächstes kommt die Verifikation.
Dabei wird überprüft,
ob die entwickelte Software
der Spezifikation entspricht.
Eine professionell erstellte
Spezifikation vereinfacht diesen
Schritt deutlich. Innerhalb
der Software-Entwicklung
sind natürlich mehrere
Verifikationsstufen ratsam. So
lassen sich bei sinnvoller Software-Konzeption
zunächst
Module einzeln verifizieren.
Ist die Verifikation erfolgreich
abgeschlossen, erfolgt
üblicherweise die Lieferung
der Lösung, sofern die Entwicklung
nicht bereits beim
Auftraggeber durchgeführt
wurde. Eine bedarfsgerechte
Dokumentation, die dem
Auftraggeber nicht nur das
Verständnis der Software
sondern auch der technischen
Überlegungen ermöglicht,
sollte bereits jetzt
für den folgenden Schritt
vorhanden sein.
Bei der Validierung wird
überprüft, ob die entwickelte
Software unter den Einsatzbedingungen
beim Kunden

PROGRAMMIERUNG
den Anforderungen genügt.
Es ist regelmäßig davon auszugehen,
dass sich diese Einsatzbedingungen
deutlich
von den Laborbedingungen
während der Entwicklung
unterscheiden. Nicht selten
treten dabei noch unerwünschte
Effekte auf, die geeignet
zu behandeln sind. Es
gibt Fälle, in denen der Auftraggeber
die Spezifikation
unter Zeitdruck und ohne
hinreichende Erfahrung erstellt
hat. Dann ist nicht ausgeschlossen,
dass Lücken in
der Spezifikation, die berücksichtigt
und nachgearbeitet
werden müssen, erst
während der Validierung zutage
treten. Dies plant ein erfahrener
Dienstleister im
Sinne der Kundenzufriedenheit
rechtzeitig ein.
Sind die während der Validierung
eventuell aufgetretenen
Effekte behoben und
die Nacharbeiten abgeschlossen,
steht einer abschließenden
Übergabe
nichts im Wege. Zu einer
professionellen Übergabe
gehört neben der erstklassigen
Dokumentation auch
eine Präsentation beim Auftraggeber
für einen reibungsfreien
Wissenstransfer.
Der Auftraggeber (Sensorhersteller
oder -integrator)
ist nun im Besitz einer auf
seine Bedürfnisse optimierten
Softwarelösung. Hat der
Signalverarbeitungsspezialist
gute Arbeit geleistet,
werden spätere Anpassungen
und Funktionserweiterungen
am Sensor nur geringen
Aufwand erzeugen.
Der Sensorhersteller oder -integrator
kann sich so auf sein
Kern-Know-how konzentrieren
und vermeidet es, »das
Fahrrad neu zu erfinden«.
Praktisches Beispiel
Ein Beispiel einer erfolgreichen
Zusammenarbeit zwischen
Sensorhersteller und
Signalverarbeitungsspezialist
ist die Entwicklung eines
Software-Paketes für das
22 DESIGN&ELEKTRONIK SOFTWARE-ENTWICKLUNG 2005
Bild 1: Wertschöpfungskette bei »intelligenten« Sensoren
»Optical Multi-Input Device«
(OMID) der Firma Mechaless
Systems. Ausgeführt
wurde die Software-Entwicklung
von der Firma Silicann
Technologies.
Das OMID ermöglicht es,
verschiedene Handgesten
oder Fingerbewegungen zu
unterscheiden. Hierfür detektiert
ein auf der »Halios«-
Technik basierender Infrarotsensor
die ausgesendete
und von der Hand oder dem
Finger zurückgestreute
Strahlung, anschließend
wertet der Sensor die Daten
mithilfe eines Signalverarbeitungsalgorithmus
aus. Je
nach Aufbereitung der Sensorsignale
kann das OMID –
ohne Veränderung der
Hardware – als optischer
Schalter, Taster, Maus,
Trackball oder Slider (X, Y,
Z) eingesetzt werden. So
kann mit dem Halios-Prinzip
die gewünschte Bedienfunktion
elegant und flexibel in
Armaturen, Chassis und Bedienfelder
integriert werden.
Der mechanikfreie Aufbau
ist dabei verschleißfrei
und alterungsbeständig.
Die Vorverarbeitung der
Messwerte erfolgt mit einem
Mikrocontroller der Firma Elmos,
wobei ein von Mechaless
entwickelter Algorithmus
zum Einsatz kommt. Es
galt jetzt, einen neuen Signalverarbeitungsalgorith
Bild 2: Phasen der Software-Entwicklung zur Sensorsignalverarbeitung
mus zu entwickeln, der die
flexible und robuste Erkennung
und Unterscheidung
der Gesten ermöglicht. Damit
waren auch die Vorteile
adaptiver Ansätze für die
Gestikerkennung mit Halios
herauszustellen.
Nach Unterzeichnung einer
Verschwiegenheitsvereinbarung
fand die erste Vorbesprechung
beim Auftraggeber
statt, bei dem alle auf
der Auftraggeberseite in das
Projekt involvierten Entwickler
teilnahmen. So konnten
zahlreiche Hinweise zum
bisherigen Vorgehen und zu
den aktuellen Ergebnissen
aufgenommen werden. Die
Zielstellung und die Rahmenbedingungen
für das
Projekt ließen sich dadurch
schnell festlegen. Die Spezifikation
im Sinne eines
Pflichtenheftes wurde anhand
der Erkenntnisse aus
dem Projektmeeting erstellt.
Nach der Festlegung der
Spezifikation wurde auf dieser
Basis das Angebot unterbreitet
und der Auftrag erteilt.
Die offene Kommunikationskultur
beider Seiten
unterstützte eine reibungsfreie
Abstimmung. Die Vorbereitungsphase
von der
Vorbesprechung bis zum
Auftrag benötigte so nur
wenige Manntage.
Die Hardware-Plattform für
die Entwicklung der Signalverarbeitungssoftware
hatte
der Auftraggeber vor Beginn
der Zusammenarbeit fertig
gestellt, sodass der Mikrocontroller,
die Entwicklungstools
für die Software

und die sonstigen Hardware-Ressourcen
bereits
festgelegt und zu verwenden
waren.
Dem Auftragnehmer standen
für die Entwicklung ein
Prototyp des Sensors und
grundlegende Teile der
Firmware zur Verfügung.
Die notwendigen Entwicklungswerkzeuge
für den
Controller und mehrere
Hilfs- und Demonstrationsprogramme
waren ebenfalls
vorhanden.
Das OMID zeigt – je nach
Bedienverhalten – charakteristische
Signalverläufe. In
Bild 3 sind Beispiele für einen
konkreten Bedienvorgang
(»Touch«) dargestellt,
basierend auf einem der vorhandenen
Sensorsignale.
Dabei korreliert der Signalhub
mit der Entfernung der
Hand vom Sensor. So kann
diese typische Hand- oder
Fingerbewegungen erkannt
und die entsprechende applikationsspezifischeFunktion
ausgelöst werden.
Durch die Auswertung weiterer
vorhandener Signale
lassen sich auch XYZ-Bewegungen
und damit andere
typische Gesten oder Bewegungen
auswerten (z.B.
»3D-Maus«). Der technische
und algorithmische Ansatz
muss die Menge der bekanntenAnwendungsmöglichkeiten
und Bedienvorgänge
abdecken und für
zukünftige Anwendungen
ohne Konzeptbrüche erweiterbar
sein.
Die Signalanalyse lieferte
wichtige Hinweise zur Datenreduktion
und zur Extraktion
charakteristischer Merkmale
für die Unterscheidung
der verschiedenen Bedienvorgänge.
Aufgrund der offenen
Menge zukünftiger
Anwendungen wurde ein
möglichst universeller technischer
Ansatz auf Basis eines
erweiterbaren Merkmalsraums
gewählt. Dadurch
kann die Signalauswertung
mit einfachen Vektor-Operationen
erfolgen. Das verrin-
Parameter Ausgangssituation Erwartungshaltung Ergebnis
Programmspeicher 4 KByte max. ggf. Erweiterung auf 8 KByte 2,5 KByte
Datenspeicher 192 Byte keine Angabe 70 Byte bis 192 Byte
Reaktionszeit