DE102011087569A1

DE102011087569A1 - Verfahren zum Anpassen einer Hörvorrichtung durch eine formale Sprache

Info

Publication number: DE102011087569A1
Application number: DE102011087569A
Authority: DE
Inventors: Stefan Aschoff; Thorsten Stocksmeier
Original assignee: Siemens Medical Instruments Pte Ltd
Current assignee: Sivantos Pte Ltd
Priority date: 2011-12-01
Filing date: 2011-12-01
Publication date: 2013-06-06
Also published as: US20150245147A1; US20130251179A1; US9113279B2

Abstract

Das Verfahren zur Anpassung einer Hörvorrichtung und insbesondere eines Hörgeräts soll vereinfacht werden. Daher wird ein Verfahren vorgeschlagen, bei dem ein Modell (12) erstellt wird, das einzelne Hardwarekomponenten der Hörvorrichtung beschreibt. Außerdem wird eine formale Sprache (13) auf der Basis des Modells (12) erstellt. Mit der formalen Sprache (13) wird ein Programm (14) entwickelt. Das Programm (14) wird in einen maschinenausführbaren Code übersetzt (15). Anschließend wird der Code an die Hörvorrichtung übertragen, durch dessen Ausführung die Hörvorrichtung automatisch entsprechend dem Programm (14) eingestellt wird. Alternativ zu der Übertragung an das Hörsystem wird der Code von einem Hörgeräteanpassprogramm (21) ausgeführt und damit ein Zielparametersatz der Hörvorrichtung berechnet, den das Anpassprogramm anschließend in die Hörvorrichtung überträgt.

Description

Die vorliegende Erfindung betrifft ein Verfahren zum Anpassen einer Hörvorrichtung. Unter einer Hörvorrichtung wird hier jedes im oder am Ohr tragbare, einen Hörreiz erzeugende Gerät, insbesondere ein Hörgerät, ein Headset, Kopfhörer und dergleichen, verstanden.
Hörgeräte sind tragbare Hörvorrichtungen, die zur Versorgung von Schwerhörenden dienen. Um den zahlreichen individuellen Bedürfnissen entgegenzukommen, werden unterschiedliche Bauformen von Hörgeräten wie Hinter-dem-Ohr-Hörgeräte (HdO), Hörgerät mit externem Hörer (RIC: receiver in the canal) und In-dem-Ohr-Hörgeräte (IdO), z.B. auch Concha-Hörgeräte oder Kanal-Hörgeräte (ITE, CIC), bereitgestellt. Die beispielhaft aufgeführten Hörgeräte werden am Außenohr oder im Gehörgang getragen. Darüber hinaus stehen auf dem Markt aber auch Knochenleitungshörhilfen, implantierbare oder vibrotaktile Hörhilfen zur Verfügung. Dabei erfolgt die Stimulation des geschädigten Gehörs entweder mechanisch oder elektrisch.
Hörgeräte besitzen prinzipiell als wesentliche Komponenten einen Eingangswandler, einen Verstärker und einen Ausgangswandler. Der Eingangswandler ist in der Regel ein Schallempfänger, z. B. ein Mikrofon, und/oder ein elektromagnetischer Empfänger, z. B. eine Induktionsspule. Der Ausgangswandler ist meist als elektroakustischer Wandler, z. B. Miniaturlautsprecher, oder als elektromechanischer Wandler, z. B. Knochenleitungshörer, realisiert. Der Verstärker ist üblicherweise in eine Signalverarbeitungseinheit integriert. Dieser prinzipielle Aufbau ist in 1 am Beispiel eines Hinterdem-Ohr-Hörgeräts dargestellt. In ein Hörgerätegehäuse 1 zum Tragen hinter dem Ohr sind ein oder mehrere Mikrofone 2 zur Aufnahme des Schalls aus der Umgebung eingebaut. Eine Signalverarbeitungseinheit 3, die ebenfalls in das Hörgerätegehäuse 1 integriert ist, verarbeitet die Mikrofonsignale und verstärkt sie. Das Ausgangssignal der Signalverarbeitungseinheit 3 wird an einen Lautsprecher bzw. Hörer 4 übertragen, der ein akustisches Signal ausgibt. Der Schall wird gegebenenfalls über einen Schallschlauch, der mit einer Otoplastik im Gehörgang fixiert ist, zum Trommelfell des Geräteträgers übertragen. Die Energieversorgung des Hörgeräts und insbesondere die der Signalverarbeitungseinheit 3 erfolgt durch eine ebenfalls ins Hörgerätegehäuse 1 integrierte Batterie 5.
Die Entwicklung von Hörgerätanpasssystemen ist bei der hohen Komplexität aktueller Hörgeräteplattformen eine umfangreiche Aufgabe, für die Methoden des Software-Engineerings eingesetzt werden.
Die Definition von Features, d. h. Eigenschaften eines Hörsystems (Synonym für Hörvorrichtung), wird zu wesentlichen Teilen von Fachleuten auf dem Gebiet der Audiologie/Hörsystemanpassung vorgenommen. Auch für diese Umsetzung wird dann ein umfangreicher Software-Engineering Prozess in Gang gesetzt:
Der deutsche Betriff für Software-Engineering ist „Software-Technik“, die lt. Wikipedia folgendermaßen definiert wird,
Zitat:
Eine Definition von Helmut Balzert beschreibt das Gebiet als „Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen“ (Lit. Balzert, S. 36)
Wikipedia wie auch der Standardliteratur ist zu entnehmen, dass zu den typischen Phasen eines Softwareprojektes in einem frühen Stadium die Anforderungsdefinition (Requirements Engineering) und dann später Phasen wie Softwarearchitektur, Programmierung/Implementierung folgen. Das Software Engineering ist typischerweise eine Teamarbeit, bei der Mitarbeiter unterschiedlicher Qualifikationen und Rollen in den einzelnen Phasen eines Softwareprojekts aktiv werden: Der Requirements-Engineer, der Architekt, der Softwareentwickler, der sich ggf. auf ein Teilgebiet der Software spezialisiert hat, der Softwaretester.
Weiterhin bekannt sind sogenannte „Formale Sprachen“. Vergleiche dazu „Enzyklopädie der Wirtschaftsinformatik, Online-Lexikon“ (http://www.enzyklopaedie-derwirtschaftsinformatik.de/wienzyklopaedie/lexikon/technologien-methoden/Sprache/Formale-Sprache),
Zitat:
Eine formale Sprache stellt eine zumeist mit Hilfe der natürlichen Sprache festgelegte künstliche Sprache dar. Anstoß zur Entwicklung und für den Einsatz formaler Sprachen gaben Forschungen aus dem Bereich der Programmiersprachen (Informatik) sowie der Modellierungssprachen zur Darstellung (Repräsentation) von unternehmensrelevanter Information... Die Folgen waren zum einen höhere (abstraktere) Programmiersprachen und zum anderen semantische Modelle. Mit ihrer Hilfe sollen komplexe Systeme wie Anwendungsprogramme oder Unternehmensnetze effektiver und effizienter entwickelt werden können.
Die Aufgabe der vorliegenden Erfindung besteht somit darin, ein Verfahren bereitzustellen, mit dem eine Hörvorrichtung bzw. ein Hörsystem einfacher angepasst werden kann.
Erfindungsgemäß wird diese Aufgabe gelöst durch ein Verfahren zum Anpassen einer Hörvorrichtung durch

– Erstellen eines formalen Modells, das Parameter einzelner Hardwarekomponenten der Hörvorrichtung beschreibt und diese Parameter gegebenenfalls um Aspekte einer für das Anwendungsgebiet spezifischen Beschreibung ergänzt,
– Erstellen einer formalen Sprache auf der Basis des Modells,
– Erstellen eines Programms mit Hilfe der formalen Sprache,
– Übersetzen des Programms in einen maschinenausführbaren Code und
– Übertragen des maschinenausführbaren Codes an die Hörvorrichtung, durch dessen Ausführung die Hörvorrichtung automatisch entsprechend dem Programm eingestellt wird.

Mit „Hörsystem“ bzw. „Hörvorrichtung“ wird ein System aus Hardware und Software bezeichnet, wobei es sich bei der Hardware um das oder die beiden Hörgeräte eines Minderhörenden handelt und bei der Software um Software, die ganz im Hörgerät („Firmware“) oder zum Teil im Hörgerät und zum Teil in einem Gerät implementiert ist, welches mit dem/den Hörgerät(en) in Verbindung steht (z. B. Smartphone, Fernbedienung).
In vorteilhafter Weise wird also basierend auf einer konkreten Hardwarestruktur einer Hörvorrichtung eine spezifische formale Sprache entwickelt, mit der sich dann die Hörvorrichtung einstellen lässt. Damit kann das Verhalten von Hörsystemen von Anwendungsexperten der Hörgeräteakustik (z. B. Hörgeräteakustiker oder Audiologe) unter Einsatz einer formalen Sprache („Domain-Specific Language“) in Form von menschenlesbaren Programmen niedergeschrieben und anhand des Modells automatisch in maschinen-ausführbare Programme übersetzt werden. Dieser Entwicklungsvorgang kann vom Anwendungsexperten autonom, d. h. ohne weitere Hilfe von Experten der Softwareentwicklung vorgenommen werden. Die automatische Übersetzung geschieht beispielsweise dadurch, dass ein Programm erzeugt wird, das von der Anpass- bzw. Fitting-Software ausgeführt wird. Alternativ wird dem Anwendungsexperten angeboten, automatische Programme für andere Zielsysteme: Accessoires wie Smartphones, Fernsteuerungen oder aber direkt für das Hörgerät zu erstellen.
Das Verfahren ermöglicht eine Aufteilung der einzelnen Verfahrensschritte auf verschiedene Experten, die das Hörsystem entwickeln:
Von dem Hersteller der Hörsysteme wird für das Hörsystem einmalig

– das formale Modell
– die formale Sprache
– ein automatischer Übersetzungsmechanismus zur Übersetzung von Programmen, die in der formalen Sprache geschrieben sind
– eine automatisierte Übertragung des maschinenausführbaren Codes an die Hörvorrichtung bereitgestellt.

Danach können mehrere Anwendungsexperten der Hörakustik (vorzugsweise auch Experten von OEM-Nehmern des Hörsystemherstellers oder anderen Partnern) die folgenden Schritte vornehmen:

– Erstellen eines Programms unter Einsatz der formalen Sprache
– jeweils (für jedes Programm) ein Übersetzungsvorgang durch Aktivierung des automatischen Übersetzungsmechanismus. Dieser Übersetzungsvorgang produziert einen maschinen-ausführbaren Code.
– jeweils die Übertragung des maschinen-ausführbaren Codes durch Aktivierung der automatisierten Übertragung. Dadurch gelangt der maschinen-ausführbare Code in das Hörsystem.

Die durch den Hersteller des Hörsystems einmalig (pro Hardware) ausgeführten Verfahrensschritte definieren, also das Hörsystem als Plattform, auf der die Anwendungsexperten produktspezifisches Verhalten des Hörsystems implementieren.
Für den Hersteller ergeben sich damit die Vorteile einer systematischen Trennung von Plattform- und Produktentwicklung sowie der Reduktion von Entwicklungsaufwand, Entwicklungszeit und Fehleranfälligkeit in der Produktentwicklung von Hörsystemen. Darüber hinaus bietet der Hersteller den Anwendungsexperten die Möglichkeit zügig umsetzbare Prototypen von audiologischen Leistungsmerkmalen zu erstellen und dieses ggf. wiederholen und verfeinern zu können. (Anm: im Englischen wird dieses „rapid prototyping“ genannt). Dieses reduziert die Aufwände der an dem gesamten Entwicklungsprozess beteiligten Anwendungsexperten, wodurch entsprechend die Aufwände bei dem Hersteller des Hörsystems oder aber beim OEM-Nehmer/Partner reduziert werden.
Außerdem besteht die Möglichkeit, audiologische Leistungsmerkmale automatisch auf verschiedene Zielsysteme umzusetzen (Beispiele: Ablauf in einer Anpass-Applikation, Smartphone, herstellereigene Fernsteuerung und im Hörgerät).
Der Akustiker hat in vorteilhafter Weise somit die Möglichkeit, aufgrund eigener audiologischer Fachkenntnisse die Feinanpassung von Hörsystemen zu definieren, auszuführen und am und mit dem Patienten zu testen. Darüber hinaus besteht mit dem erfindungsgemäßen Verfahren die Möglichkeit, mit Patienten sehr individuelle Hörsystemanpassungen vorzunehmen.
Bei einer speziellen Ausgestaltung des erfindungsgemäßen Verfahrens ist zumindest eine der Hardwarekomponenten der Hörvorrichtung eine Filterbank oder ein Verstärker, deren Parameter mit dem Programm eingestellt werden.
Gemäß einer weiteren Ausführungsform kann von einem Nutzer der Hörvorrichtung ein Hörverlust gemessen werden und das Programm in Abhängigkeit von dem gemessenen Hörverlust agieren oder verzweigen. Insbesondere ist die formale Sprache so ausgeführt, dass der gemessene Hörverlust eines Patienten oder auch andere Eigenschaften des Patienten (z.B. Alter, Geschlecht) abgefragt werden können und es dem Anwendungsexperten dann ermöglichen, die weitere Ausführung seiner Programme davon abhängig zu stellen. Dies kann beispielsweise dadurch geschehen, dass abhängig vom Hörverlust selektiv nur einzelne Programmteile ablaufen. Mit diesem Vorgehen lässt sich die Erstanpassung eines Hörsystems definieren, so dass sie am Patienten durchgeführt werden kann.
Bei dem Erstellen des Programms kann ein Hörprogramm für eine vorgegebene Umgebungssituation geschaffen werden. Damit kann sehr flexibel auf sehr individuelle Umgebungssituationen eingegangen werden. Ebenso kann das in der formalen Sprache erstellte Programm auch auf einer niedrigeren Ebene zur Anpassung an die vorgegebene Umgebungssituation verwendet werden, ohne ein gesamtes Hörprogramm bereitstellen zu müssen. Dabei kann eine Umgebungssituation insbesondere durch einen oder mehrere unabhängige Parameter definiert sein.
Das in der formalen Sprache erstellte Programm kann so gestaltet werden, dass es automatisch bei Vorliegen der bestimmten Umgebungssituation oder bei einem vorgegebenen Zustandsübergang der Hörvorrichtung aktiviert wird. Der Anwender hat also selbst die Möglichkeit, die Aktivierung von Programmen individuell zu steuern.
Gemäß einer Weiterentwicklung beinhaltet das Übersetzen des Programms, dass das Programm zunächst in ein Softwareprogramm, das von einem Hörgeräteanpassprogramm ausführbar ist, übersetzt wird, und anschließend das Softwareprogramm von dem Hörgeräteanpassprogramm in den maschinenausführbaren Code transformiert wird. Alternativ kann das Hörgeräteanpassprogramm die Ausführung des Programms nutzen, um einen Zielparametersatz des Hörgerätes zu berechnen, um diesen dann in das Hörgerät zu programmieren. Auf diese Weise kann ein bereits vorhandenes Hörgeräteanpassprogramm weiter genutzt werden, sodass der Compiler für das Programm in der formalen Sprache auf einer höheren Ebene arbeiten kann und nicht die Umsetzung in maschinenausführbaren Code durchführen muss.
Vorzugsweise wird das Programm mit einem Editor erstellt, der einen Programmierfehler während der Eingabe kenntlich macht. Auf diese Weise lässt sich das Programm in der formalen Sprache auch für weniger versierte Anwendungsexperten rascher erstellen.
In einer speziellen Ausführungsform erfolgt das Übersetzen des Programms in einem ersten Schritt durch Transformieren des Programms in einen Syntaxbaum und in einem zweiten Schritt durch Übersetzen des Syntaxbaums in ein für die Hörvorrichtung ausführbares Programm. Auf diese Weise lässt sich auch ein sehr komplexes Programm in einen maschinenausführbaren Code übersetzen.
Die vorliegende Erfindung wird anhand der beigefügten Zeichnungen näher erläutert, in denen zeigen:
1 den prinzipiellen Aufbau eines Hörgeräts gemäß dem Stand der Technik;
2 ein schematisches Blockdiagramm eines erfindungsgemäßen Anpassverfahrens;
3 einen Überblick über plattform-spezifische und produkt-spezifische Verfahrensschritte sowie
4 ein ausführliches Schema zur Erstellung von maschinenausführbaren Code für Hörvorrichtungen.
Die nachfolgend näher geschilderten Ausführungsbeispiele stellen bevorzugte Ausführungsformen der vorliegenden Erfindung dar.
Das erfindungsgemäße Verfahren dient zur patientenspezifischen Anpassung von Hörsystemen. Es kommt dabei eine formale Sprache sowie eine Software zur automatischen Umsetzung zu Einsatz.
Die Erfindung sieht vor, dass das Verhalten eines Hörsystems durch einen Fachmann der Audiologie definierbar und mittels eines Softwaresystems umsetzbar ist, ohne dass zum Zweck der Umsetzung ein aufwändiger Softwareentwicklungsprozess in Gang gesetzt werden muss.
Wesentlich für die Erfindung ist, dass das Verhalten eines Hörsystems von einem Fachmann des Anwendungsgebietes festgelegt werden kann, ohne Fachkräfte der Entwicklung des Hörsystems hinzuziehen zu müssen (Systementwickler, Softwareentwickler etc.). Dabei kann es sich bei dem Fachmann um einen bei einem Hörgerätehersteller (Hersteller oder OEM-Nehmer) angestellten Fachmann, einen Akustiker (der Hörgeräte auf die Bedürfnisse und Präferenzen eines Minderhörenden anpasst) oder auch einen versierten Minderhörenden handeln.
Die Erfindung beschreibt ein Verfahren, eine Anpassung eines Hörsystems für einen vorab durch den Hersteller des Hörsystems definierbaren Satz von Anwendungsfällen vorzunehmen:

– Ausführung des First Fit (Erstanpassung aufgrund des gemessenen Hörverlustes)
– Aktivierung eines Hörprogramms, das auf eine bestimmte Umgebungssituation (z. B. Telefon, Musik, TV) hin optimiert ist.

Eine weitere Ausbaustufe der Erfindung ermöglicht die Anpassung für Anwendungsfälle (oder Spezialisierungen von Anwendungsfällen), die zu einem beliebigen Zeitpunkt definierbar sind:

– Optimierungen von Hörprogrammen auf Umgebungssituationen, die nicht vom Hersteller vorgegeben sind,
– einzelne, für den Minderhörenden klar erkennbare Umgebungssituationen, z. B. ist das Hörgerät im Wesentlichen gut, nur das Geschirrklappern ist zu schrill.
– Spezialeinstellungen, die durch das Eintreten bestimmter Zustände eintreten, z. B. immer, wenn der Klassifikator des Hörsystems zwischen 8:00 Uhr und 9:00 Uhr den Umgebungszustand „Ruhe“ detektiert hat, dann... (z. B. liest der Minderhörende seine Morgenzeitung und möchte, dass sich das Blättern in der Zeitung nicht wie ein Gewitter anhört).

Speziell diese Ausbaustufe der Erfindung lässt die Anwendung für Fachleute, die nicht bei einem Hersteller von Hörsystemen arbeiten, also niedergelassene Akustiker oder versierte Minderhörende interessant erscheinen.
Das erfindungsgemäße Verfahren bzw. ein entsprechendes System erlaubt es also, einem Fachmann/Anwendungsexperten (einer im Fachgebiet der Audiologie versierten Person), Anforderungen an das Verhalten eines Hörsystems zu erstellen und diese Anforderungen automatisch in ein durch das Hörsystem (Zielsystem) ausführbares Programm zu übersetzen.
Damit die Anforderungen automatisch in ein Programm für das Zielsystem übersetzt werden können, müssen sie formalisiert (also formal, nicht informell) vorliegen.
Die Erfindung sieht daher vor, eine formale Sprache zu definieren in der der Fachmann seine Anforderungen als eine aus endlich vielen Schritten bestehende Handlungsvorschrift (Algorithmus) an das Hörsystem für einen Satz von Anwendungsfällen niederschreiben kann.
Ein zentraler Aspekt der Erfindung ist der, dass auf der Eingabeseite des Verfahrens/Systems der Anwendungsexperte das Verhalten eines Hörsystems menschenlesbar bzw. genauer: Anwendungsexperten-lesbar – als formale Algorithmen definieren kann und diese automatisch auf das Hörsystem in maschinenausführbare Programme übersetzen kann.
Damit diese formale Sprache für den Fachmann einsetzbar ist, enthält sie einen Wortschatz von Bezeichnern, d.h. Wörtern, die aus dem Anwendungsgebiet der Hörsystemanpassung entnommen sind und deren Bedeutung sich daher für einen Fachmann erschließt (Beispiele: Verstärkung, Kompression, Frequenz, Kurve). Zudem sind unter diesen Bezeichnern keine Worte enthalten, die keine Entsprechung im Anwendungsgebiet haben. Dazu gehören vor allem Begriffe mit einer primär technischen Bedeutung (Beispiele: Hardware-Registeradressen, Kommandos für Registeroperationen, Hardwarekoeffizienten).
Außerdem wird für die formale Sprache eine Syntaxdefinition (d.h. Regeln zur Aneinanderreihung der Bestandteile der formalen Sprache: Symbole (Buchstaben), Bezeichner, Schlüsselworte) verwendet, die auf eine gute Lesbarkeit und Verständlichkeit durch den Anwendungsexperten hin optimiert ist. Erst der erfindungsgemäß anschließende Übersetzungsvorgang produziert ein maschinenausführbares Programm, das einer maschinengerechten Syntax genügt.
Im Folgenden wird für die formale Sprache auch der englischsprachige Fachausdruck „Domain Specific Language" (DSL) verwendet. Die Erfindung sieht also den Einsatz einer DSL vor, die auf die Domäne der der Hörsystemanpassung spezialisiert ist.
Außerdem sieht die Erfindung einen automatischen Übersetzungsvorgang vor, mit dem die vom Fachmann erstellten Anforderungen jeweils in ein Softwareprogramm übersetzt werden können, das von dem Hörsystem ausführbar ist.
Alternativ können die Anforderungen auch in ein Softwareprogramm übersetzt werden, das durch das Hörgeräteanpassprogramm ausführbar ist. In diesem Fall wird nach der Ausführung in dem Hörgeräteanpassprogramm das Hörsystem entsprechend modifiziert.
In einer besonders bevorzugten Ausführungsform wird das Hörsystem vom Hersteller so gestaltet, dass anlässlich von Zustandsübergängen im Hörsystem maschinenausführbarer Code aktiviert wird, der erfindungsgemäß vom Fachmann erstellt wurde (eingegeben, mit dem automatischen Übersetzungsvorgang erstellt und mit der automatisierten Übertragung an das Hörsystem übertragen). Diese Zustandsübergänge können vielfach solche sein, die unmittelbar durch den Gebrauch des Hörsystems durch den Minderhörenden induziert sind: Betätigungen von Bedienelementen durch den Minderhörenden, Über- oder Unterschreitungen bestimmter Schall-Eingangspegel, das Eintreten eines bestimmten Klassifikationsergebnisses der kontinuierlichen Umgebungsanalyse („Klassifikator") und andere.
Es kommen aber auch Zustandsübergänge in Betracht, die aus der Interaktion des Minderhörenden mit einem Akustiker oder Hersteller herrühren, z.B. der Ablauf einer Probefrist für ein bestimmtes Feature oder der Kundenerwerb eines Lizenzschlüssels für ein Feature.
Dadurch kann das Verhalten des Hörsystems sehr spezifisch auf die Umgebung und auf persönliche Präferenzen eines einzelnen Minderhörenden eingestellt werden.
2 zeigt schematisch das Anpassen eines oder mehrerer Hörsysteme 10, 11 (HS1, HS2). Zunächst wird jedoch die Anpassung des einzelnen Hörsystems 10 beschrieben.
Das Hörsystem 10 besitzt eine spezifische Hardwarestruktur. Insbesondere besitzt das Hörsystem 10 (z.B. ein Hörgerät) beispielsweise einen Verstärker und eine Filterbank, die jeweils als Hardwarekomponenten anzusehen sind, auch wenn sie beispielsweise zusammen als integrierter Schaltkreis einteilig realisiert sind. Unter einer Hardwarekomponente wird hier auch beispielsweise eine Rückkopplungsunterdrückungseinrichtung, eine Windgeräuschunterdrückungseinrichtung, ein Richtmikrofon und dergleichen verstanden. Auch wenn derartige Komponenten auch als Software realisiert werden können, werden sie auf einer Hardware implementiert und daher hier als Hardwarekomponenten bezeichnet. Die Hardwarekomponenten sind individuell einstellbar. Jede Hardwarekomponente kann einen oder mehrere Einstellparameter besitzen. So kann beispielsweise ein Verstärker nicht nur lauter und leiser gestellt werden, sondern es kann auch seine Kompressionskennlinie verändert werden. All diese Hardwarekomponenten mit ihren Einstellmöglichkeiten lassen sich in einem Hardwaremodell 12 (HW1) beschreiben. Ein Hörgerät mit seinen spezifischen Hardwarekomponenten besitzt also ein spezifisches Hardwaremodell 12.
Die im Hardwaremodell beschriebenen Einstellparameter werden mit domänenspezifischen Bezeichnungen versehen. Neben diesen für den Anwendungsexperten verständlichen Bezeichnern werden, wo erforderlich, spezielle Transformationsvorschriften im Modell abgelegt.
Mit denen können logische Datenwerte (d.h. in einer für den Anwendungsexperten verständlichen Notation, z.B. „–3 dB“) in technische Datenwerte (die auf die Hardware applizierbar sind, z.B. Bitmuster) umgewandelt werden. Diese Umwandlung ist ebenfalls in der umgekehrten Richtung möglich.
Alternativ zu einer Transformationsvorschrift kann der Transformationsvorgang von logischen Parameterwerten in physikalische dadurch ermöglicht werden, dass für betreffende Parameter Übersetzungstabellen im Modell enthalten sind. Diese Übersetzungstabellen stellen jeder möglichen logischen (domänenspezifischen) Notation eines Wertes die technische (hardwarespezifische) Angabe des Wertes gegenüber.
Dadurch ist in dem Modell eine Hardwareabstraktion enthalten: Die Werte der Parameter sind sowohl in domänenspezifischer als auch in hardwarespezifischer Form definiert und übersetzbar.
Zu diesem Modell wird eine formale Sprache entwickelt. Die Syntax dieser Sprache ist zum einen auf eine gute Verständlichkeit für den Anwendungsexperten hin optimiert. Zum anderen enthält diese Sprachdefinition auch die domänenspezifischen Bezeichner, die im Modell hinterlegt sind.
Das spezifische Hardwaremodell ist also Basis für die formale Sprache 13 (FS). Die Syntax der Sprache ist so gestaltet, dass sie für den Anwendungsexperten verständlich ist. Dies wird dadurch erreicht, dass die Syntax die Bezeichner verwendet, die als domänenspezifische Bezeichner im Hardwaremodell enthalten sind und dort die genannten Einstellparameter beschreiben. Dadurch ist die Sprache auf Hardwaremodell 12 abgestimmt. Ein Anwender nutzt nun die formale Sprache 13, um damit ein Programm 14 zu erstellen, nämlich ein Anpassprogramm für das Hörsystem 10. Das Anpassprogramm 14 wird mit Hilfe eines Compilers 15 (COMP) in einen maschinenausführbaren Code übersetzt. Dazu sind auch Informationen von oder über das Hardwaremodell 12 notwendig. Der maschinenausführbare Code wird schließlich auf das Hörsystem 10 übertragen, wodurch dieses in gewünschter Weise angepasst ist.
Die formale Sprache 13 kann so abstrahiert sein, dass sie auch zur Anpassung des zweiten Hörsystems 11 (HS2) verwendet werden kann. Dieses zweite Hörsystem 11 ist von einem anderen Typ als das erste Hörsystem 10. Es besitzt eine ebenfalls spezifische Hardwarestruktur, die durch ein zweites Hardwaremodell 16 (HW2) beschrieben werden kann. Die Formalsprache 13 ist in diesem Fall auf der Basis der beiden Hardwaremodelle 12 und 16 entwickelt. Ein mit der formalen Sprache erstelltes Programm ist somit portierbar (von einem System zum anderen). Beispielsweise hat eine Hardwarekomponente des ersten Hörsystems 10 für einen Windgeräuschunterdrückungsalgorithmus drei Einstellstufen, während eine korrespondierende Hardwarekomponente des zweiten Hörsystems 11 fünf Einstellmöglichkeiten besitzt. Diese typabhängigen Einstellmöglichkeiten müssen dann in der formalen Sprache berücksichtigt sein. Bei ein und dem selben Programm 14 für beide Hörsysteme 10, 11 wird dann für das zweite Hörsystem 11 ein anderer Maschinencode erzeugt als für das erste Hörsystem 10, da ja das zweite Hörsystem andere Einstellmöglichkeiten besitzt. D. h. das Programm 14 bzw. die zugrunde liegende formale Sprache sind von der Hardware zu einem gewissen Teil abstrahiert. Der Programmierer muss für die Anpassung die jeweilige Hardware nicht kennen.
Der nachfolgende Ausdruck zeigt ein Beispiel, wie das Modell (Hardwaremodell) in Form einer Datei, speziell in der bevorzugten Form einer Datei im .xml-Format, ausgeführt sein kann.
Für alle Parameter mit dem Namen „Gain“ (davon gibt es im Modell vier, je einen Gain-Parameter für einen Kanal) sind die möglichen Parameterwerte unter
<ParValues name=“Gain“
definiert, wobei eine Formel, also eine Transformationsvorschrift zum Einsatz kommt, was in derselben Zeile durch
translation=“formula“
gekennzeichnet ist.
Das Modell definiert, dass hier die domainenspezifische Darstellung mit einem zweistelligen Zahlenwert (magnitude type=“decimalNumber“ intDigits=“2“) und der physikalischen Einheit „dB“ (<physicalUnit id=“dB“>) im Gültigkeitsbereich von 0 (<minValue>0</minValue>) bis 80 vorgenommen wird (<maxValue>0</maxValue>).
Außerdem definiert das Modell, dass die Transformation des logischen (d.h. domänenspezifischen) Wertes in den physikalischen (technischen, hardwarespezifischen) Wert erfolgt, indem der Wert durch zwei zu teilen ist.
(<domainToHardware> x / 2 </domainToHardware>).
Die Werte der Ansprechempfindlichkeit der Feedback-Detektierung („Feedback Detection Sensivity“) werden mit Hilfe einer Tabelle (translation=“tableLookup“) von der logischen, domänenspezifischen Darstellung in den entsprechenden physikalischen Wert übersetzt. So entspricht z. B. die Einstellung auf „strong“ dem physikalischen bitmuster-Wert „0010“ (<value domainLabel=“strong“ hardwareBitPattern=“0010“>).
Eine Zusammenstellung von plattform-spezifischen Verfahrensschritten und produkt-spezifischen Verfahrensschritten ist in 3 wiedergegeben. Plattform-spezifische Verfahrensschritte 44 sind einmalig je Plattform auszuführen und von dem Hersteller des Hörsystems vorzunehmen. Darunter fällt das Schaffen eines Hardwaremodells 12, einer formalen Sprache 13, aber auch eines automatischen Übersetzungsmechanismus 40 (ÜM) sowie eines automatischen Übertragungsmechanismus 41 (ÜT). Der automatische Übersetzungsmechanismus 40 übersetzt Programme, die in der formalen Sprache 13 geschrieben sind, in maschinen-lesbaren Code. Der automatische Übertragungsmechanismus 41 überträgt dann die maschinen-ausführbaren Programme in das Hörsystem 10. Durch die Softwareentwicklung wird somit eine entsprechende Infrastruktur geschaffen.
Diese Infrastruktur wird durch Anwendungsexperten genutzt, die somit die produkt-spezifischen Verfahrensschritte 45 mindestens einmalig, optional mehrfach ausführen können. Die Anwendungsexperten können vom Hörsystemhersteller oder beispielsweise von OEM-Partnern stammen. Bei diesen produktspezifischen Verfahrensschritten 45 handelt es sich um das Programm 14, das von einem Anwendungsexperten in der formalen Sprache geschrieben wird. Der Anwendungsexperte muss den automatischen Übersetzungsmechanismus für das Programm 14 aktivieren (Schritt 42), um den maschinenausführbaren Code herzustellen. Schließlich muss der Anwendungsexperte den automatischen Übertragungsmechanismus aktivieren (Schritt 43), um den maschinenausführbaren Code auf das Hörsystem 10 (HS) zu übertragen.
4 zeigt den Gesamtablauf einer Anpassung eines Hörgeräts, bei der die Programmierung anhand einer formalen Sprache erfolgt. Ein Hörgerätehersteller entwickelt Hörgeräte 20, eine Anpasssoftware 21, die von einem Fachmann 22 und einem Akustiker 23 genutzt wird, und eine integrierte Entwicklungsumgebung 24 (IDE), die ebenfalls von dem Fachmann 22 genutzt wird.
Vorzugsweise schaffen die Softwareentwickler 25 eine automatisiert herstellbare Entwicklungsumgebung 24 und eine automatisiert herstellbare Software 21. Dabei dient eine Definition vordefinierter Bezeichner 26 (Identifyer) als Basis für den Herstellprozess der Anpasssoftware 21. Darüber hinaus dient eine Definition der vordefinierten Bezeichner 26 und eine Definition der konkreten Syntax 27 als Basis für die Erstellung der Entwicklungsumgebung 24.
Der Fachmann 22 (Fachmann bei einem Hörgerätehersteller oder einem OEM-Partner oder ein unabhängiger Akustiker) nutzt die Entwicklungsumgebung 24, um ein Programm 28 zu schreiben. Das Programm 28 ist in einer menschenlesbaren Sprache (Domain-Specific Language = DSL) geschrieben und definiert das Verhalten eines Hörsystems.
Mit Hilfe der Entwicklungsumgebung 24 lässt sich für den Fachmann 22 ein maschinenausführbarer Programmcode automatisch erzeugen (vergleiche Pfeile 29). Dieser Code 30 kann von der Anpasssoftware 21, von einem Smartphone, PDA, einer Fernsteuerung oder einem anderen Zubehör 31 oder von dem Hörgerät 20 selbst ausführbar sein. Für den Fall, dass der Code für die Anpasssoftware 21 oder das Zubehör 31 erstellt wurde, ändert der Code die Parameter des Hörgeräts, welche die Anpasssoftware bzw. das Zubehör an das Hörgerät 20 überträgt.
In vorteilhafter Weise wird die Definition der audiologischen Features vom Fachmann also in einer formalen Sprache (DSL) erstellt. Dadurch kann bereits während der Erstellung eine Prüfung vorgenommen werden, ob die Anforderungen formal korrekt sind. Der Fachmann kann beispielsweise bei Gebrauch eines entsprechenden Toolings/Editors während der Eingabe durch farbige Markierungen auf Fehler hingewiesen werden. Dadurch werden Fehler, die in der Phase der Anforderungserstellung entstehen können, vermieden.
Im Folgenden wird für ein solches Tooling der englischsprachige Fachausdruck „Integrated Development Environment" (IDE) verwendet. Dies ist ein geläufiger Ausdruck für Entwicklungsumgebungen, die für sogenannte „general purpose languages", also Programmiersprachen wie C, C++, C#, Java o.ä. eingesetzt werden.
Die Definition und Umsetzung von audiologischen Features kann allein von einem Fachmann vorgenommen werden. Der Fachmann benötigt kein Entwicklungsteam. Dadurch entfallen etliche Kommunikationswege von Mensch zu Mensch, z.B. unter Einsatz von in Prosa geschriebenen Dokumenten, auf denen typischerweise Fehler entstehen.
Die Umsetzung von audiologischen Features erfordert nicht den Einsatz eines länger andauernden kompletten Software-Engineering-Prozesses, sondern kann automatisiert binnen einer oder weniger Minuten vorgenommen werden. Dadurch entstehen die folgenden Vorteile:

– Bei dem Einsatz bei einem Hörgerätehersteller (Hersteller oder OEM-Nehmer) wird Zeit in der Entwicklung von Hörgerätesystemen eingespart.
– Die Produktentwicklung (von Hörgeräten oder Hörsystemen) kann sich der Technik eines „Rapid Prototypings" bedienen, bei der versuchsweise wiederholt Features entworfen, getestet und modifiziert werden.

Sofern die formale Sprache eine Aufteilung von Features in einzelne, identifizierbare Einheiten vorsieht (vorzugsweise: Funktionen) – schafft dies die Möglichkeit, dass der Fachmann solche Einheiten wiederverwendet (code re-use). Eine konsequente und strukturierte Wiederverwendung von Code spart in der Summe Aufwand, reduziert Fehleranfälligkeit und Wartungsarbeiten und schafft bessere Voraussetzungen für spätere Erweiterungen.
In einer bevorzugten Ausführungsform der Erfindung bedient sich die Anpasssoftware, die beim Audiologen zum Einsatz kommt, erfindungsgemäß erstellter maschinen-ausführbarer Programme, die auf das Zielsystem der Anpass-Software erstellt wurden. Ein solches Vorgehen hat für den Hersteller organisatorische Vorteile:

– Die Entwicklung einer Anpass-Software wird auf ein Team von Software-Entwicklern und ein Team von Mitarbeitern einer Audiologie-Abteilung verteilt.
– Es besteht eine klare Trennung in Plattform- und Produktentwicklung. Die Anpasssoftware ist in der Lage, eine Hörgeräte-Plattform universell anzusteuern.

Da die Erfindung vorsieht, dass der Anwendungsexperte seine Programmteile für einen spezifischen, vordefinierten Satz von Anwendungsfällen erstellt, ist das Interface (die Interaktionsszenarien) zwischen der Anpasssoftware und den vom Anwendungsexperten erstellten Teilen einmalig definiert, so dass von mehreren Anwendungsexperten produktspezifische (einzelne Hörgeräte oder Hörgerätefamilien) Programme auch nach der Fertigstellung der Anpasssoftware erstellt und ausgeliefert werden können.
Durch die weitgehende Automatisierung wird zudem die Definition und Entwicklung von Features durch Fachleute, die nicht bei einem Hörgerätehersteller arbeiten, denkbar. Hier kann es sich um Audiologen (selbständig, mit eigenem Geschäft) oder sogar um versierte Minderhörende handeln.
Insbesondere Audiologen, die das Gebiet der Hörgeräteakustik erlernt oder studiert haben, und damit mit den in der formalen Sprache definierten Bezeichnern umgehen können, sollten auch als Anwendungsexperten in das erfindungsgemäße System einbezogen werden können. Wie beschrieben, sieht eine bevorzugte Ausführungsform der Erfindung vor, dass das Hörsystem erfindungsgemäß angefertigte Programme aktiviert. Dadurch kann das Verhalten des Hörsystems sehr individuell auf die Präferenzen des Minderhörenden eingestellt werden, was den Einsatz des Systems für niedergelassene Akustiker wiederum interessanter erscheinen lässt.
Die vom Anwendungsexperten geschriebenen Programme lassen sich als logische, identifizierbare Einheiten aufteilen. Nun können solche Einheiten ohne weiteres jeweils einer User-Interface-Einheit hinterlegt werden, deren Oberfläche symbolhaft oder bildhaft den Effekt des Programms darstellt. Auf diese Weise lässt sich z.B. beim Hersteller von Hörsystemen (oder OEM-Partner) ein optisches „Baukastensystem" erstellen, dessen sich der externe Anwendungsexperte bedient. Bei diesem Ansatz kommen als externe Anwendungsexperten sowohl niedergelassene Akustiker wie auch versierte Minderhörende in Betracht.
Die Beteiligung von niedergelassenen Akustikern als externen Anwendungsexperten macht auch eine weitere Anwendung möglich:
Gruppen von Akustikern können sich per Internet darüber austauschen, welche Lösungen sie mit welchem Erfolg für bestimmte Anwendungsfälle eingesetzt haben. Stellt sich z.B. ein schrilles Geschirrklappern als ein typischer Fall heraus, für den die Hilfe von Akustikern nachgefragt wird, so können sich Akustiker darüber austauschen, ob sie eine Absenkung der Verstärkung bei hohen Frequenzen oder eine Erhöhung der Kompression einsetzen. Die Voraussetzungen für ein solches Szenario sind geschaffen, da heutzutage soziale Netzwerke per Internet möglich sind und erfindungsgemäß geschriebene Programme von Anwendungsexperten lesbar sind.
Das erfindungsgemäße Verfahren bzw. ein entsprechendes Softwaresystem kann wie folgt hierarchisch verfeinert werden (A bis H):

A) Softwaresystem/Verfahren, das einen Anwendungsexperten der Audiologie befähigt, Programme für die Abfrage und Modifikation eines Hörsystems in einer auf das Fachgebiet der Hörsysteme und Hörsystemanpassung spezialisierten formalen Sprache, einer DSL (Domain Specific Language) zu schreiben und in ein von dem Hörsystem ausführbares Programm zu übersetzen.
B) Softwaresystem wie in A), bei dem der Übersetzungsvorgang in zwei aufeinanderfolgenden Schritten vorgenommen wird. Dabei wird in dem ersten Schritt das vom Anwendungsexperten geschriebene Programm in einen abstrakten Syntaxbaum übersetzt. Ein jeder solcher Syntaxbaum genügt der abstrakten Syntax, d.h. einem Satz von Regeln, die beschreiben, welche Struktur für Syntaxbäume zulässig sind. In dem zweiten Schritt wird der abstrakte Syntaxbaum ein maschinenausführbares Programm für das Zielsystem übersetzt.
C) Softwaresystem wie in B), bei dem für den zweiten Schritt verschiedene Übersetzungen für jeweils verschiedene Zielsysteme (z. B. Fernsteuerung, PDA, Smartphone) zur Verfügung stehen.
D) Softwaresystem wie in A), bei dem der Satz von Regeln, also die abstrakte Syntax in vier Ebenen beschrieben wird: a. Beschreibung des Alphabets: Angabe der Menge an Symbolen, die in der Sprache verwendet werden können (Buchstaben, Ziffern, Sonderzeichen) b. Beschreibung der Wörter. Es werden zulässige Kombinationen der Symbole zu Wörtern angegeben. Bei den Wörtern wird zwischen Schlüsselwörtern und Bezeichnern unterschieden. i. Schlüsselwörter sind festgelegte Symbolkombinationen, die eine spezielle Bedeutung innerhalb der Sprache haben; ii. Bezeichner sind Namen, die 1. vom Anwendungsexperten für bestimmte Elemente vergeben werden können (freie Bezeichner) 2. zusammen mit der DSL festgelegt werden und bestimmten Begriffe aus dem Anwendungsgebiet des Anwendungsexperten entsprechen. (vorgegebene Bezeichner, z. B. Verstärkungssteller, Kompressionssteller, Frequenz) c. Beschreibung der Sätze: Es werden zulässige Kombinationen von Schlüsselwörtern, Bezeichnern und Symbolen zu Sätzen angegeben. Vorzugsweise wird der Aufbau der Sätze mit Hilfe der kontextfreien Backus-Naur-Form (BNF) beschrieben. d. Einschränkung der Sätze durch Kontextbedingungen: Durch Regeln (die auch als „statische Semantik" bezeichnet werden) werden Sätze ausgeschlossen, die zu einem semantisch (inhaltlich) falschen Programm führen.
E) Softwaresystem wie in D), – bei der die formalen Syntaxdefinitionen wie unter (D.a); (D.b.i); (D.b.ii.1); (D.c) und (D.d) beschrieben in Dateien gehalten werden, und – bei der die in der formalen Syntaxdefinition vorgegebenen Bezeichner (D.b.ii.2) in Dateien gehalten werden.
F) Softwaresystem wie in D), bei dem der Übersetzungsvorgang in den maschinen-lesbaren Code ein formales Modell verwendet, das die unter (D.b.ii.2) genannten vorgegebenen Bezeichner auf Hardwareparameter abbildet.
G) Softwaresystem wie in D), das den audiologisch versierten Anwender unterstützt, in dem es ihm ein auf die DSL/formale Sprache spezialisierte Entwicklungsumgebung (IDE: Integrated Development Environment) zur Verfügung stellt. Diese ist vorzugsweise durch ein oder mehrere der folgenden Eigenschaften charakterisiert: a. Überprüfung der Eingaben des Anwendungsexperten auf formale Korrektheit entsprechend der unter (D) genannten Syntaxregeln. Markierung von festgestellten Fehlern im user-interface der Entwicklungsumgebung b. Überprüfung der Eingaben des Anwendungsexperten darauf, ob eingegebene Schlüsselworte zulässig sind, d.h. in der DSL vorkommen dürfen. c. Farbliche Hervorhebung von eingegebenen Schlüsselworten. (Anm. ein solches Feature wird im Englischen auch „syntax coloring" genannt) d. Überprüfung der Eingaben des Anwendungsexperten darauf, ob eingegebene Bezeichner als freie Bezeichner eingesetzt werden können oder anderenfalls einem vorgegebenen Bezeichner entsprechen und damit in dem Programm vorkommen dürfen. e. Auswahllisten von vorgegebenen Bezeichnern: Der Anwendungsexperte erhält auf Tastendruck („Hotkey") eine Auswahlliste aller vorgegebenen Bezeichner, die an der aktuellen Stelle (Cursorposition in der Entwicklungsumgebung) zulässig sind. Er kann per Tasten oder Maus einen dieser Bezeichner auswählen und erspart sich dadurch die buchstabenweise Eingabe des vorgegebenen Bezeichners. Sofern der Anwendungsexperte bereits einige Buchstaben eines vorgegebenen Bezeichners eingegeben hat, erhält er auf Tastendruck („Hotkey") eine Auswahlliste aller vorgegebenen Bezeichner, die an der aktuellen Stelle zulässig sind und zudem auf die vorgegebenen Bezeichner eingeschränkt ist, die mit der eingegebenen Buchstabenfolge beginnen. (Anm.: ein solches Feature wird im englischen auch „code completion" genannt) f. Aktivierungsmöglichkeit der automatischen Übersetzungen: Im user interface der IDE kann der Anwendungsexperte die unter A), B) oder C) genannten automatischen Übersetzungsvorgänge aktivieren. Dadurch erhält er die auf dem Zielsystem ausführbaren Programme. Da der Anwendungsexperte standardmäßig auch mit dem Zielsystem ausgestattet sein wird, kann er die ausführbaren Programme gleich auf dem Zielsystem / den Zielsystemen testen.
H) Softwaresystem, bei der die unter G) genannte Entwicklungsumgebung (IDE) mittels eines Software-Toolkits erstellt ist, welches a. Dateien, welche vorgegebene Bezeichner der DSL enthalten (unter E) aufgeführt) b. Dateien, zulässige Satzdefinitionen der formalen Sprache enthalten (unter F) aufgeführt), als Eingabe aufnimmt und aus dieser Eingabe automatisiert die Entwicklungsumgebung (IDE) für den Fachmann erstellt.

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

http://www.enzyklopaedie-derwirtschaftsinformatik.de/wienzyklopaedie/lexikon/technologien-methoden/Sprache/Formale-Sprache [0008]

Claims

Verfahren zum Anpassen einer Hörvorrichtung (20) gekennzeichnet durch – Erstellen eines formalen Modells (12), das einzelne Parameter von Hardwarekomponenten der Hörvorrichtung beschreibt, – Erstellen einer formalen Sprache (13) auf der Basis des Modells (12), – Erstellen eines Programms (14) mit Hilfe der formalen Sprache (13), – Übersetzen des Programms (14) in einen maschinenausführbaren Code und entweder – Übertragen des maschinenausführbaren Codes (30) an die Hörvorrichtung (20), durch dessen Ausführung die Hörvorrichtung automatisch entsprechend dem Programm (14) eingestellt wird, oder – Ausführen des maschinenausführbaren Codes von einem Hörgeräteanpassprogramm (21) dessen Ausführung in einem Parametersatz resultiert, der von dem Hörgeräteanpassprogramm in das Hörgerät übertragen wird.
Verfahren nach Anspruch 1, bei dem das Übersetzen des Programmes (14) in den maschinenausführbaren Code in zwei aufeinander folgenden Schritten vorgenommen wird: a) Erstellen eines automatischen Übersetzungsmechanismus zur Übersetzung von Programmen (40), die in der formalen Sprache geschrieben sind, in einen maschinenausführbaren Code, und b) Aktivierung dieses automatischen Übersetzungsmechanismus für eines oder mehrerer dieser Programme einfach oder mehrfach.
Verfahren nach Anspruch 1, bei dem das Übertragen des maschinenausführbaren Codes (30) an die Hörvorrichtung (20) in zwei aufeinander folgenden Schritten vorgenommen wird: a) Erstellen eines automatisierten Übertragungsvorganges (41), zur Übertragung des maschinenausführbaren Codes (30) an die Hörvorrichtung, und b) Aktivierung dieses automatisierten Übertragungsvorgangs einfach oder mehrfach.
Verfahren nach Anspruch 2 oder 3 wobei mehrere automatische Übersetzungsmechanismen erstellt werden, die in der formalen Sprache geschriebene Programme jeweils in maschinenausführbaren Code einer eigenen Zielplattform übersetzen und zudem entsprechend mehrere automatisierte Übertragungsmechanismen erstellt werden, die die maschinenausführbaren Programme auf die jeweilige Zielplattform übertragen.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Hörvorrichtung mindestens eine Filterbank oder einen Verstärker enthält, deren Parameter mit dem Programm (14) eingestellt werden.
Verfahren nach einem der vorhergehenden Ansprüche, wobei von einem Nutzer der Hörvorrichtung ein Hörverlust gemessen und das Programm in Abhängigkeit von dem gemessenen Hörverlust agiert oder verzweigt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei bei dem Erstellen des Programms (14) ein Hörprogramm für eine vorgegebene Hörsituation geschaffen wird.
Verfahren nach Anspruch 7, wobei das Programm (14) zum Anpassen an die vorgegebene Umgebungssituation dient.
Verfahren nach Anspruch 8, wobei die Umgebungssituation durch einen oder mehrere unabhängige Parameter definiert ist.
Verfahren nach einem der Ansprüche 7 bis 9, wobei das Programm so erstellt wird, dass das maschinenausführbare Programm automatisch bei Vorliegen der vorgegebenen Umgebungssituation oder bei einem vorgegebenen Zustandsübergang der Hörvorrichtung aktiviert wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Übersetzen des Programms (14) beinhaltet, dass das Programm zunächst in ein Softwareprogramm, das von einem Hörgeräteanpassprogramm (21) ausführbar ist, übersetzt wird, und anschließend das Softwareprogramm von dem Hörgeräteanpassprogramm in den maschinenausführbaren Code (30) transformiert wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Erstellen des Programms (14) mit einem Editor erfolgt, der – einen Programmierfehler während der Eingabe sichtbar macht, – oder Schlüsselworte der formalen Sprache mit einer speziellen Farbe kennzeichnet, – oder dem Anwender auf Tastendruck alle für die aktuelle Stelle/Cursorposition zulässigen Bezeichner in einer Liste zur Auswahl zur Verfügung stellt, – oder dem Anwender die Aktivierung des automatisierten Übersetzungsvorganges und Übertragungsvorganges anbietet, mit dem zuerst das eingegebene Programm in maschinenausführbaren Code übersetzt wird und anschließend in das Hörsystem übertragen wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Übersetzen des Programms in einem ersten Schritt durch Transformieren des Programms in einen Syntaxbaum und in einem zweiten Schritt durch Übersetzen des Syntaxbaums in ein für die Hörvorrichtung (20) ausführbares Programm erfolgt.