DE102014204139A1

DE102014204139A1 - Näherungsschnittstellen-Entwicklungssystem mit Analysator und Verfahren

Info

Publication number: DE102014204139A1
Application number: DE201410204139
Authority: DE
Inventors: Pietro Buttolo; Stuart C. Salter; Matthew Majkowski; James J. Surman; James Stewart Rankin
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2013-03-13
Filing date: 2014-03-06
Publication date: 2014-09-18
Also published as: US20140278194A1

Abstract

Es werden ein Entwicklungssystem und ein Verfahren zum Prüfen von Näherungssensorschnittstellen, wie etwa einer kapazitiven Schalterbaugruppe, die in einem Kraftfahrzeug verwendet werden kann, bereitgestellt. Das System umfasst in Speicher gespeicherte Softwareroutinen zum Betreiben einer Näherungssensorschnittstelle, die mehrere Sensoren aufweist, und ein Datenlog mit Benutzerausgaben der Näherungssensoren. Das Entwicklungssystem umfasst einen Replikator zum Replizieren der Näherungssensorschnittstelle auf der Basis der Softwareroutinen und des Datenlogs und zum Erzeugen von Ausgaben der Näherungssensorschnittstelle zur Bestimmung von Leistungsfähigkeit. Das System umfasst ferner einen Analysator zum Verarbeiten der Prüfdaten zur ordnungsgemäßen Aktivierung der Näherungssensorschnittstelle und Erzeugen einer Ausgabe, die die Prüfergebnisse angibt.

Description

Die vorliegende Erfindung betrifft allgemein Benutzeroberflächen und insbesondere ein Entwicklungswerkzeug zur Prüfung und Entwicklung von Näherungsschnittstellen wie etwa in Fahrzeugen verwendete Näherungsschalter.
Kapazitive Sensorschnittstellen werden zunehmend in verschiedenen elektronischen Einrichtungen verwendet, darunter Smartphones, Geräte und Fahrzeuginstrumententafeln, um traditionelle mechanische Schalter zu ersetzen. Bei Kraftfahrzeuganwendungen können kapazitive Sensorschnittstellen verwendet werden, um Einrichtungen zu betätigen, wie etwa elektrische Fenster, Scheinwerfer, Scheibenwischer, Glasdächer oder Schiebedächer, Innenbeleuchtung, Radioinformationen, Infotainment-Einrichtungen und verschiedene andere Einrichtungen. Näherungsschalter, wie etwa kapazitive Schalter, verwenden einen oder mehrere Näherungssensoren, um ein Erfassungsaktivierungsfeld zu erzeugen, und erfassen Änderungen des Aktivierungsfelds, die Benutzerbetätigung des Schalters anzeigen, die typischerweise durch den Finger eines Benutzers in dichter Nähe oder in Kontakt zu dem Sensor verursacht werden. Kapazitive Schalter sind typischerweise dafür ausgelegt, Benutzerbetätigung des Schalters auf der Basis eines Vergleichs des Erfassungsaktivierungsfelds mit einer Schwelle zu detektieren.
Ein kapazitiver Schalter stellt typischerweise keine digitale Ein/Aus-Eingabe bereit, sondern stellt stattdessen einen Sensorwert abhängig von verschiedenen Eigenschaften, darunter Fingergröße, Haltung und Abstand des Bedieners, bereit. Dementsprechend ist die Logik zum Interpretieren der Bedienerabsicht zur Betätigung eines oder mehrerer Schalter im Allgemeinen komplexer als ein traditioneller mechanischer Schalter. Aufgrund der verschiedenen Bediener und Verwendungszwecke kann es schwierig sein, effizient eine kapazitive Sensorschnittstelle zu entwickeln, die sich für die Verwendung durch verschiedene Bediener gut eignet. Bei der Kraftfahrzeuganwendung umfasst die Entwicklung dieser Arten von Näherungssensorschnittstellen typischerweise Umgebungsprüfung der Schnittstellen durch einen großen Pool von Benutzern in einer Kundenklinik, wobei im Allgemeinen ein kostspieliger und zeitaufwendiger Prozess beteiligt ist. Wenn Änderungen wie etwa Änderung von Abstimmparametern in Software an den Sensorschnittstellen vorgenommen werden müssen, muss die Prüfung möglicherweise wiederholt werden. Es wäre wünschenswert, ein Entwicklungssystem bereitzustellen, das Zeit und Kosten zum Prüfen und Entwickeln von kapazitiven Sensorschnittstellen insbesondere für die Verwendung in der Kraftfahrzeugumgebung verringert.
Gemäß einem Aspekt der vorliegenden Erfindung wird ein Näherungsschnittstellen-Entwicklungssystem bereitgestellt. Das Näherungsschnittstellen-Entwicklungssystem umfasst Softwareroutinen, die dafür entwickelt sind, eine Näherungssensorschnittstelle zu bedienen, die mehrere Näherungssensoren aufweist. Das System umfasst außerdem aus Prüfung der Softwareroutinen beschaffte Prüfdaten und einen Analysator zum Verarbeiten der Prüfdaten, um Leistungsfähigkeit der Näherungssensorschnittstelle zu bestimmen, und zum Erzeugen einer Ausgabe, die Prüfergebnisse angibt.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird ein Verfahren zum Entwickeln einer Näherungssensorschnittstelle bereitgestellt. Das Verfahren umfasst die Schritte des Bereitstellens von Softwareroutinen, die dafür entwickelt sind, eine Näherungssensorschnittstelle zu bedienen, die mehrere Sensoren aufweist, und das Prüfen der Softwareroutinen, um Testdaten zu erzeugen. Das Verfahren umfasst ferner die Schritte des Verarbeitens der Testdaten, um die Leistungsfähigkeit der Softwareroutinen zu bestimmen und Erzeugen einer Ausgabe, die die Prüfergebnisse augibt.
Diese und andere Aspekte, Aufgaben und Merkmale der vorliegenden Erfindung werden von Fachleuten bei Durchsicht der folgenden Beschreibung, Ansprüche und angefügten Zeichnungen verständlich und ersichtlich.
Es zeigen:
1 eine perspektivische Ansicht eines Fahrgastraums eines Kraftfahrzeugs mit einer Overheadkonsole, die eine Näherungsschalterbaugruppe gemäß einer Ausführungsform verwendet;
2 eine vergrößerte Ansicht der in 1 gezeigten Overheadkonsole und Näherungsschalterbaugruppe, ferner mit einem Datenlogger zur Benutzerprüfung gekoppelt;
3 eine durch die Linie III-III in 2 genommene vergrößerte Querschnittsansicht eines Arrays von Näherungsschaltern in Bezug auf den Finger eines Benutzers;
4 ein Schaltbild eines in jedem der in 3 gezeigten kapazitiven Schalter verwendeten kapazitiven Sensors;
5 ist ein Blockschaltbild der Näherungsschalterbaugruppe gemäß einer Ausführungsform;
6 ist ein Blockschaltbild eines Entwicklungssystems, das einen Replikator und Analysator als Werkzeug zum Entwickeln der Näherungsschalter verwendet, gemäß einer Ausführungsform;
7 ein Flussdiagramm einer Steuerroutine mit Wrapper, die durch das Entwicklungssystem betrieben wird, gemäß einer Ausführungsform;
8 ein Flussdiagramm der Subroutine zum Extrahieren typischer Parameter von 7;
9 ein Flussdiagramm der Ereignisaktualisierungssubroutine von 8;
10 ein Flussdiagramm der Ereignisinitialisierungssubroutine von 8;
11 ein Flussdiagramm der Subroutine zum Finden des zweitgrößten Signals von 9;
12 ein Flussdiagramm der Subroutine zum Verarbeiten des neuen Max-Kanals von 8;
13 ein Flussdiagramm der Replikatorroutine gemäß einer Ausführungsform;
14 ein Flussdiagramm der Subroutine zum Parsen der Parameterkonfiguration von 13;
15 ein Flussdiagramm der Subroutine zum Beschaffen der Liste der zu verarbeitenden Datenlogs von 13;
16 ein Flussdiagramm der Subroutine zum Parsen des Sensorwerts aus Datenlog von 13;
17 ein Flussdiagramm der Analysatorroutine gemäß einer Ausführungsform;
18 ein Flussdiagramm der Subroutine des Parsens der DOE-Datei von 17;
19 ein Flussdiagramm der Analysator-Ereignislog-Subroutine von 17 gemäß einer Ausführungsform;
20 ein Flussdiagramm der Analysator-Ereignislog-Subroutine von 17 gemäß einer anderen Ausführungsform;
21 eine Tabelle der Abtastung von durch das Entwicklungssystem beschafften und verarbeiteten Näherungsschalter-Aktivierungsereignissen gemäß einem Beispiel;
22 eine Tabelle von Ereignis-DOE-Log-Daten, die die Ausgabe mehrerer Tests, die durch den Analysator zu einem Zusammenfassungsdiagramm kombiniert werden, zeigt, gemäß einem Beispiel;
23 eine Tabelle eines vereinfachten Ausgabeberichts, der Testergebnisse präsentiert, die Aktivierungstyp und -dauer zeigen, gemäß einem Beispiel;
24 einen Graph des Prozentsatzes der Aktivierungsfehler als Funktion minimaler Zählratenzunahme über 80 Millisekunden zur Aktivierung ohne Handschuhe gemäß einem Beispiel;
25 einen Graph des mittleren Prozentsatzes der Aktivierung als Funktion der kapazitiven Pegelaktivierungsschwelle ohne Handschuhe gemäß einem Beispiel;
26 einen Graph eines mittleren Prozentsatzes von Aktivierungsfehlern als Funktion der kapazitiven Pegelaktivierungsschwelle für Interaktion mit behandschuhter Hand gemäß einem Beispiel;
27 einen Graph des mittleren Prozentsatzes von Aktivierungsfehlern für Schalter als Funktion verminderter/vergrößerter Empfindlichkeit ohne Handschuhe gemäß einem Beispiel;
28 einen Graph des mittleren Prozentsatzes von Aktivierungsfehlern für Schalter als Funktion verminderter/vergrößerter Empfindlichkeit für Interaktion mit behandschuhter Hand gemäß einem Beispiel; und
29 einen Graph, der vier Versionen von Software vergleicht, die unter Verwendung des Entwicklungswerkzeugs geprüft wurden, gemäß einem Beispiel.
Wie gefordert werden hier ausführliche Ausführungsformen der vorliegenden Erfindung offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich beispielhaft für die Erfindung sind, die in verschiedenen und alternativen Formen realisiert werden kann. Die Figuren sind nicht unbedingt gemäß einem ausführlichen Entwurf; bestimmte Diagramme können übertrieben oder minimiert sein, um Funktionsübersicht zu zeigen. Hier offenbarte spezifische strukturelle und Funktionsdetails sind deshalb nicht als beschränkend aufzufassen, sondern lediglich als repräsentative Grundlage, um es Fachleuten zu lehren, die vorliegende Erfindung verschiedenartig einzusetzen.
Mit Bezug auf 1 und 2 ist das Innere eines Kraftfahrzeugs 10 im Allgemeinen mit einer Näherungssensorschnittstelle im Fahrgastraum, bezeichnet als Näherungsschalterbaugruppe 20 mit mehreren Näherungsschaltern 22 mit Schalteraktivierungsüberwachung und -bestimmung gemäß einer Ausführungsform dargestellt. Das Fahrzeug 10 umfasst im Allgemeinen eine am Dachhimmel auf der Unterseite des Dachs oder der Decke an der Oberseite des Fahrgastraums im Allgemeinen über dem vorderen Fahrgastsitzbereich montierte Overheadkonsole 12. Die Schalterbaugruppe 20 besitzt mehrere Näherungsschalter 22, die gemäß einer Ausführungsform nahe beinander in der Overheadkonsole 12 angeordnet sind. Die verschiedenen Näherungsschalter 22 können eine beliebige Anzahl von Fahrzeugvorrichtungen und -funktionen steuern, wie etwa Steuerung von Bewegung eines Schiebedachs oder Glasdachs 16, Steuern der Bewegung einer Glasdachblende 18, Steuern der Aktivierung einer oder mehrerer Beleuchtungsvorrichtungen, wie etwa innerer Karten-/Lese- und Domlampen 30 und verschiedener anderer Vorrichtungen und Funktionen. Es versteht sich jedoch, dass sich die Näherungsschalter 22 an einem anderen Ort in dem Fahrzeug 10 befinden können, wie etwa im Armaturenbrett, an anderen Konsolen, wie etwa der Mittelkonsole, in ein Berührungsschirmdisplay 14 für ein Radio- oder Infotainmentsystem, wie etwa ein Navigations- und/oder Audiodisplay integriert oder an einem anderen Ort an Bord des Fahrzeugs 10 angeordnet, um Benutzerschnittstellen gemäß verschiedenen Fahrzeuganwendungen zu ermöglichen.
Die Näherungsschalter 22 werden hier gemäß einer Ausführungsform als kapazitive Schalter gezeigt und beschrieben. Jeder Näherungsschalter 22 umfasst mindestens einen Näherungssensor, der ein Erfassungsaktivierungsfeld zum Erfassen von Kontakt oder dichter Nähe (z.B. bis auf einen Millimeter) eines Benutzers in Bezug auf einen oder mehrere Näherungssensoren, wie etwa Wischbewegung durch den Finger eines Benutzers, bereitstellen. Somit ist das Erfassungsaktivierungsfeld jedes Näherungsschalters 22 bei der beispielhaften Ausführungsform ein kapazitives Feld, und der Finger des Benutzers besitzt elektrische Leitfähigkeit und dielektrische Eigenschaften, die eine Änderung oder Störung des Erfassungsaktivierungsfelds verursachen können, wie für Fachleute offensichtlich sein sollte. Es versteht sich jedoch für Fachleute auch, dass zusätzliche oder alternative Arten von Näherungssensoren verwendet werden können, wie etwa, aber ohne Beschränkung darauf, induktive Sensoren, optische Sensoren, Temperatursensoren, Widerstandssensoren, dergleichen oder eine Kombination davon. Beispielhafte Näherungssensoren werden im ATMEL® Touch Sensors Design Guide, 10620 D-AT42-04/09, vom 9.4.2009 beschrieben, deren Inhalt hiermit durch Bezugnahme vollständig aufgenommen wird.
Die in 1 und 2 gezeigten Näherungsschalter 22 stellen jeweils Steuerung einer Fahrzeugkomponente oder -vorrichtung bereit oder stellen eine eigene Steuerfunktion bereit. Ein oder mehrere der Näherungsschalter 22 können eigens für die Steuerung von Bewegung eines Schiebedachs oder Glasdachs 16 gewidmet sein, um zu bewirken, dass sich das Glasdach 16 in eine offene oder geschlossene Richtung bewegt, das Glasdach zu neigen oder Bewegung des Glasdachs auf der Basis eines Steueralgorithmus zu stoppen. Ein oder mehrere andere Näherungsschalter 22 können eigens der Steuerung von Bewegung einer Glasdachblende 18 zwischen offener und geschlossener Stellung gewidmet sein. Das Glasdach 16 und die Blende 18 können jeweils als Reaktion auf Betätigung des entsprechenden Näherungsschalters 22 durch einen Elektromotor betätigt werden. Andere Näherungsschalter 22 können der Steuerung anderer Vorrichtungen gewidmet sein, wie etwa Einschalten einer inneren Karten-Leselampe 30, Ausschalten einer inneren Karten-/Leselampe 30, Ein- oder Ausschalten einer Fahrgastraumleuchte, Entriegeln eines Kofferraums, Öffnen einer Heckklappe oder Deaktivieren eines Türlampenschalters. Zusätzliche Steuerungen über die Näherungsschalter 22 wären Betätigung von elektrischen Türfenstern nach oben und unten. Verschiedene andere Fahrzeugsteuerungen können mittels der hier beschriebenen Näherungsschalter 22 gesteuert werden.
Mit Bezug auf 3 ist ein Teil der Näherungsschalterbaugruppe 20 mit einem Array aus drei seriell angeordneten Näherungsschaltern 22 in dichter Beziehung zueinander in Bezug auf den Finger 34 eines Benutzers während der Benutzung der Schalterbaugruppe 20 dargestellt. Jeder Näherungsschalter 22 umfasst einen oder mehrere Näherungssensoren 24 zum Erzeugen eines Erfassungsaktivierungsfelds. Gemäß einer Ausführungsform kann jeder der Näherungssensoren 24 durch Drucken von leitfähigem Farbstoff auf die obere Oberfläche der Polymer-Overheadkonsole 12 gebildet werden. Ein Beispiel für einen Farbstoffdruck-Näherungssensor 24 ist in 4 im Allgemeinen mit einer Ansteuerelektrode 26 und einer Empfangselektrode 28 jeweils mit verschränkten Fingern zum Erzeugen eines kapazitiven Felds 32 gezeigt. Es versteht sich, dass jeder der Näherungssensoren 24 anderweitig gebildet werden kann, wie etwa durch Zusammenbauen einer vorgeformten leitfähigen Leiterbahn auf einem Substrat gemäß anderen Ausführungsformen. Die Ansteuerelektrode 26 empfängt Rechteckansteuerimpulse, die mit einer Spannung V_I angelegt werden. Die Empfangselektrode 28 besitzt einen Ausgang zum Erzeugen einer Ausgangsspannung V_O. Es versteht sich, dass die Elektroden 26 und 28 in verschiedenen anderen Konfigurationen angeordnet werden können, um das kapazitive Feld als das Aktivierungsfeld 32 zu erzeugen.
Bei der hier gezeigten und beschriebenen Ausführungsform wird die Ansteuerelektrode 26 jedes Näherungssensors 24 mit Spannungseingabe V_I als Rechteckimpulse angelegt, die einen Ladeimpulszyklus aufweisen, der ausreicht, um die Empfangselektrode 28 auf eine gewünschte Spannung aufzuladen. Die Empfangselektrode 28 dient dadurch als Messelektrode. Bei der gezeigten Ausführungsform überlappen sich durch angrenzende Näherungsschalter 22 erzeugte angrenzende Erfassungsaktivierungsfelder 32 etwas, gemäß anderen Ausführungsformen kann jedoch keine Überlappung bestehen. Wenn ein Benutzer oder Bediener, wie etwa der Finger 34 des Benutzers, in das Aktivierungsfeld 32 eintritt, detektiert die Näherungsschalterbaugruppe 20 die durch den Finger 34 an dem Aktivierungsfeld 32 verursachte Störung und bestimmt, ob die Störung ausreicht, um den entsprechenden Näherungsschalter 22 zu aktivieren. Die Störung des Aktivierungsfelds 32 wird durch Verarbeiten des dem entsprechenden Signalkanal zugeordneten Ladeimpulssignals detektiert. Die Bestimmung, ob die Störung ausreicht, um einen Schalter zu aktivieren, kann das Vergleichen eines als Reaktion auf das Aktivierungsfeld erzeugten erfassten Signals mit einem oder mehreren Schwellenwerten, Schwellenraten oder andere bekannte Schalteraktivierungs-Detektionstechniken umfassen. Zusätzlich kann die Störung an dem Aktivierungsfeld verarbeitet werden, um zu bestimmen, ob ein Benutzer die Schalter durchläuft oder erkundet oder eine Wisch- oder andere Geste als Eingabe ausführt. Wenn der Finger 34 des Benutzers zwei Aktivierungsfelder 32 kontaktiert, detektiert die Näherungsschalterbaugruppe 20 die Störung beider kontaktierter Aktivierungsfelder 32 über getrennte Signalkanäle. Jeder Näherungsschalter 22 besitzt seinen eigenen dedizierten Signalkanal, der Ladeimpulszählungen erzeugt, die verarbeitet werden.
Mit Bezug auf 5 ist die Näherungsschalterbaugruppe 20 gemäß einer Ausführungsform dargestellt. Es sind mehrere Näherungssensoren 24 gezeigt, die Eingaben für eine Steuerung 40, wie etwa einen Mikrokontroller, bereitstellen. Die Steuerung 40 kann Steuerschaltkreise umfassen, wie etwa einen Mikroprozessor 42 und Speicher 48. Die Steuerschaltkreise können Erfassungssteuerschaltkreise umfassen, die das Aktivierungsfeld jedes Sensors 22 verarbeiten, um Benutzeraktivierung des entsprechenden Schalters zu erfassen, indem das aktivierungsfelderzeugte Signal gemäß einer oder mehreren Steuerroutinen mit einer oder mehreren Schwellen und/oder Ratenwerten verglichen wird. Es versteht sich, dass andere analoge und/oder digitale Steuerschaltkreise verwendet werden können, um jedes Aktivierungsfeld zu verarbeiten, Benutzeraktivierung zu bestimmen und eine Aktion einzuleiten. Die Steuerung 40 kann gemäß einer Ausführungsform ein von ATMEL^® verfügbares QMatrix-Beschaffungsverfahren verwenden. Das ATMEL-Beschaffungsverfahren verwendet einen WINDOWS^®-Host-C/C++-Compiler und -Debugger WinAVR zur Vereinfachung von Entwicklung und Prüfung des Hilfsprogramms Hawkeye, das Überwachung des internen Zustands kritischer Variablen in der Software in Echtzeit sowie Sammeln von Logs von Daten zur Nachverarbeitung erlaubt.
Die Steuerung 40 liefert ein Ausgangssignal an eine oder mehrere Vorrichtungen, die dafür ausgelegt sind, als Reaktion auf korrekte Aktivierung eines Näherungsschalters dedizierte Aktionen durchzuführen. Zum Beispiel können die eine oder mehreren Vorrichtungen ein Glasdach 16 mit einem Motor zum Bewegen des Glasdachpanels zwischen offener und geschlossener und geneigter Stellung, eine Glasdachblende 18, die sich zwischen offener und geschlossener Stellung bewegt, und Beleuchtungsvorrichtungen 30, die ein- und ausgeschaltet werden können, umfassen. Es können andere Vorrichtungen gesteuert werden, wie etwa ein Radio, um Ein- und Ausfunktionen, Lautstärkeregelung, Suchlauf durchzuführen, und andere Arten von Vorrichtungen zum Ausführen anderer dedizierter Funktionen. Einer der Näherungsschalter 22 kann der Betätigung des Glasdachs geschlossen gewidmet sein, ein anderer Näherungsschalter 22 kann der Betätigung des Glasdachs offen gewidmet sein, und ein weiterer Schalter 22 kann der Betätigung des Glasdachs in eine Neigungsstellung gewidmet sein, wobei alles bewirken würde, dass ein Motor das Glasdach zu einer gewünschten Stellung bewegt. Die Glasdachblende 18 kann als Reaktion auf einen Näherungsschalter 22 geöffnet werden und kann als Reaktion auf einen anderen Näherungsschalter 22 geschlossen werden.
Die Steuerung 40 ist ferner mit einem mit dem Mikroprozessor 42 gekoppelten Analog-Digital- bzw. A/D-Komparator 44 gezeigt. Der A/D-Komparator 44 empfängt die Spannungsausgabe V_O von jedem der Näherungsschalter 22, setzt das Analogsignal in ein Digitalsignal um und liefert das Digitalsignal an den Mikroprozessor 42. Zusätzlich umfasst die Steuerung 40 einen Impulszähler 46, der mit dem Mikroprozessor 42 gekoppelt ist. Der Impulszähler 46 zählt die Ladesignalimpulse, die an jede Ansteuerelektrode jedes Näherungssensors angelegt werden, führt eine Zählung der zum Laden des Kondensators, bis die Spannungsausgabe V_O eine vorbestimmte Spannung erreicht, notwendigen Impulse durch und liefert den Zählwert an den Mikroprozessor 42. Der Impulszählwert gibt die Kapazitätsänderung des entsprechenden kapazitiven Sensors an. Die Steuerung 40 ist ferner mit einem impulsbreitenmodulierten Ansteuerpuffer 15 kommunizierend gezeigt. Die Steuerung 40 liefert ein impulsbreitenmoduliertes Signal an den impulsbreitenmodulierten Ansteuerpuffer 15, um eine Rechteck-Impulsfolge V_I zu erzeugen, die an jede Ansteuerelektrode jedes Näherungssensors/-schalters 22 angelegt wird. Die Steuerung 40 verarbeitet eine oder mehrere im Speicher gespeicherte Steuerroutinen 100, um die Näherungsschalter zu überwachen und eine Bestimmung bezüglich Aktivierung eines dieser durchzuführen. Die Steuerroutinen 100 können eine Routine zum Ausführen eines Verfahrens zum Aktivieren der Näherungsschalter unter Verwendung bekannter Detektionstechniken, wie etwa Vergleichen der erzeugten Signale mit einem oder mehreren Schwellenwerten und/oder Schwellenraten, umfassen.
Die Näherungsschalterbaugruppe 20 kann eine Änderung von Sensor-Ladungsimpulszählwerten, die auch als Δ-Sensorzählwerte bezeichnet wird, für mehrere Signalkanäle erzeugen, die mehreren Näherungsschaltern zugeordnet sind. Die Änderung des Sensor-Ladungsimpulszählwerts ist die Differenz zwischen einem initialisierten Referenzzählwert ohne im Aktivierungsfeld vorhandenen Finger oder vorhandenes anderes Objekt und dem entsprechenden Sensorstand. Wenn sich der Finger eines Benutzers mit einem Sensor 24 in Kontakt oder in dichter Nähe zu diesem befindet, ändert der Finger die an dem entsprechenden Sensor 24 gemessene Kapazität. Die Kapazität ist zu der parasitären Kapazität des unberührten Sensorpad parallel, und dementsprechend als ein Offset zu messen. Die vom Benutzer oder Bediener verursachte Kapazität ist proportional zu der Dielektrizitätskonstante des Fingers oder anderen Körperteils des Benutzers, der dem kapazitiven Pad ausgesetzten Oberfläche und umgekehrt proportional zur Distanz der Extremität des Benutzers zur Schalttaste. Gemäß einer Ausführungsform wird jeder Sensor über Impulsbreitenmodulations- bzw. PWM-Elektronik mit einer Folge von Spannungsimpulsen erregt, bis der Sensor bis auf ein festgesetztes Spannungspotential aufgeladen ist. Ein solches Beschaffungsverfahren lädt die Empfangselektrode 28 auf ein bekanntes Spannungspotential auf. Der Zyklus wird wiederholt, bis die Spannung am Messkondensator eine vorbestimmte Spannung erreicht. Das Bringen des Fingers eines Benutzers auf die Berührungsoberfläche des Schalters 24 führt externe Kapazität ein, die die in jedem Zyklus übertragene Ladungsmenge vergrößert, um dadurch die Gesamtzahl der Zyklen zu verringern, die erforderlich ist, damit die Messkapazität die vorbestimmte Spannung erreicht. Der Finger des Benutzers bewirkt die Änderung des Sensorladungsimpulszählwerts als Zunahme, da dieser Wert auf dem initialisierten Referenzzählwert minus dem Sensorstand basiert. Es versteht sich, dass in anderen Näherungssensorschnittstellen andere Sensorbeschaffungs- und -detektionstechniken verwendet werden können.
Die Näherungssensorschnittstelle kann eine beliebige einer Anzahl bekannter Techniken zum Überwachen eines erfassten Signals als Reaktion auf einen oder mehrere Näherungssensoren und Detektieren von Aktivierung eines Schalters verwenden. Ein Beispiel für eine Näherungsüberwachungs- und -bestimmungstechnik wird in der US-Patentanmeldung Nr. 13/721,886, eingereicht am 20.12.2012 mit dem Titel „PROXIMITY SWITCH ASSEMBLY AND ACTIVATION METHOD USING RATE MONITORING“ offenbart, die die Verwendung von Schwellen und einer Ratenüberwachungsroutine zur Bestimmung von gültigen Schalteraktivierungen offenbart. Die oben erwähnte Patentanmeldung wird hiermit durch Bezugnahme aufgenommen. Es versteht sich, dass andere Sensorüberwachungs- und -aktivierungsbestimmungstechniken in der Näherungssensorschnittstelle verwendet werden können, die durch das hier offenbarte Entwicklungssystem zur Prüfung simuliert und analysiert wird.
Ein Näherungssensorschnittstellen-Entwicklungssystem wird verwendet, um Näherungsschnittstellensensoren, wie etwa die Näherungsschalterbaugruppe 20 und andere Näherungssensorschnittstellen, die Näherungs- und/oder Gestenerkennungsschnittstellen umfassen, zu prüfen und bei deren Entwicklung zu helfen. Während der Entwicklung solcher Sensorschnittstellen ist es oft notwendig, neue Softwareanwendungen zu modifizieren oder zu schreiben, um potentielle Fehlschläge und andere Beschränkungen zu beseitigen oder zu kompensieren. Zum Beispiel würden an der Software vorgenommene Änderungen, wie etwa Ändern eines Abstimmparameters wie des zum Bestimmen von Schalteraktivierung verwendeten Schwellenwerts oder wie etwa Änderung der Empfindlichkeit eines oder mehrerer Sensoren oder wie etwa Hinzufügen neuer Module wie einer Routine zum Kompensieren von Kondensation, typischerweise auch die Durchführung einer vollen Menge von Umgebungsprüfungen sowie einer ausführlichen Kundenklinik zur ordnungsgemäßen Prüfung der neu programmierten Baugruppe erfordern. Das vorliegende Näherungssensorschnittstellenentwicklungssystem ermöglicht vorteilhafterweise das Prüfen und die unterstützte Entwicklung von Näherungssensorschnittstellen mit neuer Software oder Änderungen an Software auf eine Weise, die die Kosten und Zeit zum Bestätigen eines ordnungsgemäßen Betriebs und optimale Leistungsfähigkeit signifikant verringert, ohne zeitaufwendige wiederholte Umgebungsprüfung und Kundenkliniken zu erfordern.
Das Näherungsschnittstellen-Entwicklungssystem sammelt oder empfängt ein Datenlog, das aus einer vollen Menge von Umgebungsprüfungen und/oder einer Kundenklinik beschafft werden kann, wobei typischerweise viele potentielle Bediener verwendet werden, die die verschiedenen Näherungsschalter durch Drücken der Schalter, Ausführen bestimmter Gesten und Ausführen verschiedener anderer Benutzereingabe-Näherungssensorschnittstellenaktionen aktivieren können. Diese Datenlogs können gemäß einem Beispiel durch Verwendung der in 1–5 gezeigten Näherungsschalterbaugruppe 20 beschafft werden. Hierbei kann die Näherungsschalterbaugruppe 20 in einem Fahrzeug wie etwa in 1 gezeigt installiert sein oder kann in einer Umgebungsprüfkammer installiert sein, in der Umgebungsbedingungen wie Temperatur, Feuchtigkeit und andere Faktoren kontrolliert und variiert werden können. Ein Datenlogger 50 kann wie in 2 und 5 während der Kundenklinik mit der Näherungsschalterbaugruppe 20 gekoppelt sein, um die zum Erzeugen des Datenlog verwendeten Daten aufzuzeichnen. Das in dem Datenlogger 50 gespeicherte Datenlog kann typische Aktivierungsdaten umfassen, sowie sie von den verschiedenen Sensoren der Baugruppe 20 erfasst werden, während verschiedene Bediener mit der Näherungsschalterbaugruppe 20 in Aktion treten. Die gesammelten Daten können unverarbeitete Hardwaresensorausgaben und den Zeitstempel umfassen. Während der Prüfung werden bestimmte Softwareroutinen von den Näherungsschaltern ausgeführt. Das Datenlog zeichnet die verschiedenen Sensoreingaben auf und verwendet die Daten zur Verwendung beim Prüfen von Änderungen an der Software oder alternativer Software dergestalt, dass nicht jedes Mal, wenn eine Softwareänderung an der Näherungsschalterbaugruppe vorgenommen wird, die ausführliche Kundenklinik wiederholt werden muss.
Mit Bezug auf 6 ist das Näherungsschnittstellen-Entwicklungssystem 60 gemäß einer Ausführungsform dargestellt. Das Näherungsschnittstellen-Entwicklungssystem 60 umfasst ein Entwicklungswerkzeug 62 mit einem Mikroprozessor 64 und Speicher 66. Das Entwicklungswerkzeug 62 kann eine dedizierte Verarbeitungsmaschine umfassen, die in der Lage ist, Näherungssensorschnittstellen-Softwareroutinen und das Datenlog zu verarbeiten, um den Betrieb der Software auf einer Näherungssensorschnittstelle zu replizieren und um die während der Replikation erzeugten Daten zu analysieren, um Leistungsfähigkeitsausgaben bereitzustellen. Das Entwicklungswerkzeug 62 kann gemäß einer Ausführungsform einen Computer umfassen, der dafür programmiert ist, die hier beschriebene Funktionalität auszuführen.
Das Näherungsschnittstellen-Entwicklungssystem 60 empfängt ein oder mehrere Datenlogs von dem Eingang 74 und speichert das Datenlog in der Datenlogspeicherung 68 des Speichers 66. Zusätzlich können mehrere Steuerroutinen 72A–72I in dem Speicher 66 gespeichert werden. Die Steuerroutinen 72A–72I sind Softwareroutinen, die dafür ausgelegt sind, eine Näherungssensorschnittstelle, wie etwa eine Näherungsschalterbaugruppe, zu betreiben, umfassen aber einen Wrapper zum Verarbeiten von Daten ohne die Näherungsschalterhardware. Die Softwareroutinen 72A–72I können dieselbe Software sein, die dafür ausgelegt ist, auf einer Näherungsschalterbaugruppe betrieben zu werden, und können zusätzlichen Code umfassen, um Ausführung ohne die Hardware zu ermöglichen. Varianten der Software der Steuerroutinen 72A–72I können Änderungen an der Software oder alternative Software umfassen, die in dem Speicher 66 gespeichert und durch das Entwicklungswerkzeug 62 verarbeitet werden können. Das Entwicklungswerkzeug 62 empfängt verschiedene andere Eingaben 76, darunter alternative Steuerroutinen 82, die Änderungen an den Softwareprogrammen umfassen, die durch das Näherungsschnittstellen-Entwicklungssystem 60 geprüft werden sollen. Zu anderen Eingaben gehören Parameterkonfigurationen zur Prüfung 84 wie etwa Schwellenwerte, Kalibrationsratenwerte, Ratenüberwachungsschwelle, Signaturverhältnisse, Anzahl aktiver Kanäle, für ein stabiles Signal erforderlicher Zeitraum, Bereiche für ein stabiles Signal und andere Parameter. Zu weiteren Eingaben gehören Sensorwert-Skalierungsmatrizen 86, die Multiplikationsfaktoren zum Abstimmen oder Justieren von Empfindlichkeiten von Sensoren umfassen können. Das Entwicklungswerkzeug 62 erzeugt Ausgaben 78, die Konfigurations-/Leistungsfähigkeitsdiagramme umfassen, wie etwa den Prozentsatz erfolgreich erkannter beabsichtigter Aktivierungen, Prozentsatz getriggerter unbeabsichtigter Aktivierungen, Art von Aktivierungen, Art von nichterkannten Aktivierungen, Bewertungseinstufungsdaten und anderen Leistungsfähigkeitsdaten.
Das Näherungsschnittstellen-Entwicklungssystem 60 umfasst einen Replikator 70, der in dem Speicher 66 gespeichert und durch den Mikroprozessor 64 ausgeführt gezeigt ist. Der Replikator 70 repliziert oder simuliert die Näherungssensorschnittstelle auf der Basis der Steuerroutinen, einschließlich Softwareänderungen und alternativer Steuerroutinen, und bestimmt Ausgaben der Näherungssensorschnittstelle, die analysiert werden, um ordnungsgemäßen oder optimalen Betrieb der Software zu bestimmen, so wie er erwartungsgemäß auf der Näherungssensorschnittstelle operieren wird. Der Replikator 70 verarbeitet das während der Umgebungsprüfung erzeugte Datenlog, wie etwa bei einer Kundenklinik erfasste Daten, durch den in der Produktionseinheit der Näherungssensorschnittstelle verwendeten tatsächlichen Quellcode ohne Notwendigkeit von der Schnittstelle zugeordneter physischer Hardware. Der Replikator 70 verarbeitet Eingaben, zu denen die Ablesungen kapazitiver Sensoren aus dem Datenlog gehören, und erzeugt Ausgaben, zu denen Auslöseentscheidungen gehören, wie etwa, ob ein Benutzer beabsichtigt, einen Schalter zu aktivieren oder nicht. Die in dem Replikator 70 verwendete Software kann mit dem in der Näherungssensorschnittstelle verwendeten Produktionscode identisch sein, so dass die Ausgabe des Replikators 70 mit den Daten übereinstimmen würde, die in dem Datenlog für die identische Softwaresteuerroutine vorgelegt werden. Wenn eine Änderung an dem Softwarecode vorgenommen wird, wie etwa Zusatz eines neuen Moduls oder Abstimmung eines Parameters, sagt die durch das Näherungsschnittstellen-Entwicklungssystem erzeugte Replikatorausgabe mit Gewissheit voraus, was unter Verwendung des neuen Softwarecodes in dem tatsächlichen Produktionsteil auftreten würde, als wäre die Prüfung unter Verwendung der tatsächlichen Hardware in einer Umgebungskammer und/oder unter Verwendung von Kundenkliniken durchgeführt. Durch Verwendung des Replikators 70 kann die Auswirkung jeglicher Softwarecodeänderungen an einem zuvor gesammelten Datenlog in praktisch keiner Zeit geprüft werden.
Das Näherungsschnittstellen-Entwicklungssystem 60 umfasst ferner einen Analysator 80, der im Speicher 66 gespeichert und durch den Mikroprozessor 64 ausführbar gezeigt ist. Der Analysator 80 verarbeitet die durch den Replikator 70 erzeugten Daten nach, um zu bestimmen, ob beabsichtigte Aktivierungen der Näherungsschalter verpasst wurden (z.B. der Bediener versucht hat, einen Schalter zum Öffnen des Dachs zu aktivieren, aber nichts geschehen ist), oder unerwünschte Aktivierungen ausgelöst wurden (z.B. bewegte der Bediener die Hand beim Reichen nach dem Overhead-Brillenfach in der Nähe der Schnittstelle, und es wurde aus Versehen ein Schalter ausgelöst). Wenn eine große Anzahl von Kundendatenstichproben gesammelt wird, ist die Handverarbeitung der Daten zeitaufwendig und fehleranfällig. Der Analysator 80 verarbeitet die von dem Replikator 70 ausgegebenen Daten auf eine Weise, die präzise und viel weniger zeitaufwendig ist.
Mit Bezug auf 7–12 ist eine von dem Replikator 70 verwendete Steuerroutine 100 mit Wrapper gemäß einer Ausführungsform dargestellt. Die Routine 100 beginnt im Schritt 102 und schreitet zum Schritt 104 voran, um Hardware-Zustandsvariablen zu initialisieren, um Hardware zu kompensieren, die der Näherungssensor-Schnittstelle zugeordnet, aber während des Prüfens des Entwicklungssystems nicht implementiert wird. Die Steuerroutine 100 ist Softwarecode, der ein exaktes Duplikat der auf den tatsächlichen Produktionshardwarekomponenten laufenden Software umfassen kann, mit eingebettetem Zusatzcode in Form des Softwareanalysators, um zusätzliche Informationen über das Systemverhalten bereitzustellen. Die Steuerroutine 100 wird mit verschiedenen Eingaben verarbeitet, wie etwa Sensorwerten, darunter unverarbeitete Kanalsignale aus dem Datenlog, zu prüfende Parameterwerte einschließlich Schwellen und Ratenwerte und Skalierungsmatrizen. Die Software der Steuerroutine 100 erzeugt Ausgaben auf der Basis des Datenlogs so, als wäre es erzeugt worden, wenn eine Prüfung an dem Produktionsteil laufen gelassen würde, und erzeugt zusätzlich typische Parameter und Ereignislogs.
Die Routine 100 umfasst den Schritt 106, der die Steuerroutinenparameterwerte wie erforderlich setzt, wie zum Beispiel eine Schwelle gleich Schwelle i setzt. Dies setzt die neuen Werte der Steuerroutinenparameter, die auf Leistungsfähigkeit geprüft werden, wie zum Beispiel, was geschehen könnte, wenn eine Schwelle herabgesetzt wird oder wenn eine Kalibrationsrate vergrößert wird. Als Nächstes bestimmt die Routine 100 im Entscheidungsschritt 108, ob mehr als ein unverarbeiteter Kanal gleich null gesetzt ist. Wenn mehr als ein unverarbeiteter Sensorwert in dem Datenlog gleich null gesetzt ist, bedeutet dies, dass ein Rücksetzen in der Hardware aufgetreten ist, als das Datenlog gesammelt wurde. Wenn dies geschieht, werden die Hardware-Zustandsvariablen neu initialisiert. Als Nächstes skaliert die Routine 100 im Schritt 112 die unverarbeiteten Werte, um die vergrößerte/verkleinerte Empfindlichkeit zu simulieren, indem das unverarbeitete Kanalsignal mit der Skalierungsmatrix S [] multipliziert wird. Bei einer Ausführungsform kann die Skalierungsmatrix linear sein. Es versteht sich jedoch, dass die Skalierungsmatrix eine negative Exponentialfunktion oder ein logarithmischer Wert sein kann, oder anderweitig durch eine andere Funktion oder Gleichung definiert werden kann. Durch Justieren der Skalierungsmatrix kann ein Multiplikator verwendet werden, um eine Softwareänderung zu simulieren, wie etwa eine Änderung der Sensorempfindlichkeit, und die Auswirkung davon auf die Näherungssensorschnittstelle kann durch das Entwicklungssystem geprüft werden.
Zu Schritt 114 voranschreitend lässt die Routine 100 den Code der Steuerroutine i laufen, der eine Kopie des tatsächlichen Codes ist, der auf der Produktions-Sensorschnittstellenbaugruppe laufen gelassen wird. Die Steuerroutine wird mit Eingaben ausgeführt, zu denen ein Sensorwert, wie etwa ein unverarbeiteter skalierter Kanalwert, und Ausgaben, wie etwa der Schalter-aktiv-Zustand gehören. Dementsprechend kann der Softwarecode ohne Hardware ausgeführt und geprüft werden, während dieselben Ausgaben bereitgestellt werden, als wäre der Code auf der tatsächlichen Produktionsbaugruppe laufen gelassen worden. Die Routine 100 schreitet dann zum Schritt 116 voran, um typische Parameter zu extrahieren, wie etwa maximale Signalkanäle, Rausch- und Signalbereich, Maximalrate, zweiter Maximalkanal, Anzahl aktiver Kanäle über einer aktiven Schwelle, Verhältnis (max/Summe) Maximalverhältnis, Maximalspitze anderer Parameter. Somit werden Schlüsselereignisse und -parameter extrahiert, die als Eingaben für den Analysator verwendet werden können. Als Nächstes gibt im Schritt 118 der auf dem Replikator laufende Code die verarbeiteten Informationen auf dem verarbeiteten Datenlog auf einer dedizierten Schnittstelle aus. Dieses Modul sendet das Log direkt zu einer Datei, die als Eingabe für den Analysator verwendet wird. Im Schritt 120 gibt die Routine 100 die typischen Parameter/das Ereignislog aus, worin die verarbeiteten Informationen hinsichtlich des Signals, wie etwa das maximale Signal während eines Ereignisses, Signalbereich usw., enthalten sind. Als Nächstes bestimmt die Routine 100 im Entscheidungsschritt 122, ob die Eingabe aus dem Datenlog vollständig verarbeitet (fertig) ist und endet, wenn dem so ist, im Schritt 124. Andernfalls kehrt die Routine 100 zum Schritt 108 zurück.
Unter Bezugnahme auf 8 ist die Subroutine zum Extrahieren typischer Merkmale vom Schritt 116 beginnend mit Schritt 130 und voranschreitend, um eine Ereignisaktualisierung im Schritt 132 durchzuführen, weiter dargestellt. Der Ereignisaktualisierungsschritt 132 wird in Verbindung mit einer in 9 gezeigten Subroutine gezeigt und beschrieben. Nach der Ereignisaktualisierung schreitet die Routine 116 zum Entscheidungsschritt 134 voran, um zu bestimmen, ob ein Signalkanal zuvor aktiv war, und schreitet, wenn dem nicht so ist, zum Entscheidungsschritt 136 voran. Im Entscheidungsschritt 136 bestimmt die Routine 116, ob ein neuer maximaler Kanal vorliegt, und verarbeitet, wenn dem so ist, den neuen maximalen Kanal im Schritt 130, bevor sie im Schritt 140 endet. Wenn es keinen neuen maximalen Kanal gibt, schreitet die Routine 116 zum Entscheidungsschritt 142 voran, um zu bestimmen, ob der maximale Kanal aktiviert wurde, und tritt, wenn dem so ist, in das Ereignis für den aktivierten maximalen Kanal (Schritt 144) ein, bevor sie im Schritt 140 endet. Wenn im Schritt 134 bestimmt wurde, dass zuvor ein Kanal aktiv war, schreitet die Routine 116 zum Entscheidungsschritt 146 voran, um zu bestimmen, ob der Kanal freigegeben wurde, und endet, wenn dem nicht so ist, im Schritt 140. Wenn der Kanal freigegeben wurde, tritt die Routine 116 in das Ereignis für die aktuelle Kanalfreigabe ein (Schritt 148) und schreitet dann zum Schritt 150 voran, um die nächste Ereignisinitialisierung zu setzen, bevor sie im Schritt 140 endet.
Die Ereignisaktualisierungssubroutine 132 ist in 9 dargestellt, beginnend im Schritt 154 und voranschreitend zu Schritt 156, um das größte Signal (max_channel) zu finden, und dann zum Schritt 158, um das zweitgrößte Signal (second_max_channel) zu finden. Als Nächstes schreitet die Routine 132 zum Entscheidungsschritt 160 voran, um zu bestimmen, ob der maximale Kanal größer als ein Schwellenrauschen ist, und setzt, wenn dem so ist, ein Verhältnis gleich dem maximalen Kanal, dividiert durch den Summenkanal (Schritt 162). Der Summenkanal ist eine Summierung aller Signalkanäle, die der Näherungssensorschnittstelle zugeordnet sind. Danach schreitet die Routine 132 zum Schritt 164 voran, um das maximale beobachtete Verhältnis mit dem aktuellen Verhältniswert zu aktualisieren, wenn dieser größer als das aktuelle maximale beobachtete Verhältnis ist. Als Nächstes wird im Schritt 166 der maximale beobachtete max_ch mit dem aktuellen max_ch aktualisiert, wenn dieser größer ist. Danach wird im Schritt 168 der maximale beobachtete zweitgrößte Kanal mit dem aktuellen zweitgrößten Kanal aktualisiert, wenn dieser größer ist. Die Routine 132 schreitet dann zum Entscheidungsschritt 170 voran, um zu bestimmen, ob der Spitzen-Maximalkanal größer als der Maximalspitzen-Maximalkanal ist, und schreitet, wenn dem so ist, zum Schritt 172 voran, um den Maximalspitzen-Maximalkanal gleich dem Spitzen-Maximalkanal zu setzen und den Maximalspitzen-Summenkanal gleich dem Spitzen-Summenkanal zu setzen. Im Anschluss an Schritt 172 oder die negative Entscheidung von Schritt 170 schreitet die Routine 132 zum Schritt 174 voran, um die Maximalzahl (N) aktiver Kanäle gleich der maximalen max_number aktiver Kanäle (N_active_ch) zu setzen. Danach wird im Schritt 176 die maximale beobachtete Rate gleich der aktuellen Rate gesetzt, wenn diese größer ist. Dann wird das maximale beobachtete Rauschen mit dem aktuellen Rauschen verglichen, und das maximale Rauschen wird gleich dem aktuellen Rauschen gesetzt, wenn dieses größer ist (Schritt 178), bevor im Schritt 180 geendet wird. Wenn der maximale Kanal im Entscheidungsschritt 160 nicht größer als die Rauschschwelle ist, schreitet die Routine 130 direkt zum Schritt 178 voran, um das maximale beobachtete Rauschen zu aktualisieren, bevor sie im Schritt 180 endet.
Die Ereignisinitialisierungssubroutine 150 ist in 10 dargestellt. Die Routine 150 beginnt im Schritt 184 und schreitet zum Schritt 186 voran, um den maximalen zweiten Maximalkanal gleich der kleinsten für diese Variable verfügbaren ganzen Zahl zu setzen, um das Maximalverhältnis gleich der kleinsten für diese Variable verfügbaren ganzen Zahl zu setzen, um den Maximalspitzen-Maximalkanal gleich der kleinsten für diese Variable verfügbaren ganzen Zahl zu setzen und um den Maximalspitzen-Summenkanal gleich der kleinsten ganzen Zahl zu setzen. Das detektierte Ereignis wird dann im Schritt 188 gleich keines gesetzt. Als Nächstes schreitet die Routine 150 zum Schritt 190 voran, um alle Timer rückzusetzen und alle Flags rückzusetzen, bevor sie im Schritt 192 endet.
Die Subroutine 156, die das zweitgrößte Signal (zweiter Max-Kanal) definiert, ist in 11 dargestellt, beginnend im Schritt 200 und voranschreitend zum Schritt 202, um den zweiten Maximalkanal gleich der kleinsten ganzen Zahl zu setzen. Als Nächstes schreitet die Routine 156 zum Entscheidungsschritt 204 voran, um zu bestimmen, ob der Kanal der Max-Kanal ist, und schreitet, wenn dem so ist, zum Entscheidungsschritt 210 voran, um zu bestimmen, ob alle Kanäle gescannt sind, und speichert, wenn dem so ist, die Informationen im Schritt 212 im Ereignislog, bevor sie im Schritt 214 endet. Wenn wie durch den Entscheidungsschritt 210 bestimmt nicht alle Kanäle gescannt sind, kehrt die Routine 156 zum Schritt 204 zurück. Wenn im Schritt 204 der aktuelle Kanal nicht der Max-Kanal ist, schreitet die Routine 156 zum Entscheidungsblock 206 voran, um zu bestimmen, ob der Kanal größer als der zweite Maximalkanal ist, und setzt, wenn dem so ist, den zweiten Maximalkanal im Schritt 208 gleich dem aktuellen Kanal, bevor sie zum Entscheidungsschritt 210 voranschreitet. Wenn der aktuelle Kanal im Entscheidungsschritt 206 nicht größer als der nächste Kanal ist, springt die Routine 156 nach vorne zum Entscheidungsschritt 210.
Die Subroutine 138 des Verarbeitens des neuen Max-Kanals ist in 12 beginnend im Schritt 220 und voranschreitend zum Entscheidungsschritt 222 gezeigt, um zu bestimmen, ob der vorherige Kanal größer als die Rauschschwelle war, und endet, wenn dem nicht so ist, im Schritt 232. Wenn der vorherige Kanal größer als die Rauschschwelle war, schreitet die Routine 138 zum Entscheidungsschritt 224 voran, um zu bestimmen, ob der neue Kanal aktiv ist, was dadurch bestimmt werden kann, dass ein neuer Kanal größer als ein Schwellen-Aktivwert ist. Wenn der neue Kanal nicht aktiv ist, schreitet die Routine 138 dazu voran, das Ereignis gleich Aktivierung abgebrochen zu setzen (Schritt 228) und die nächste Ereignisinitialisierung zu setzen (Schritt 230), bevor sie im Schritt 232 endet. Wenn im Schritt 224 bestimmt wurde, dass der neue Kanal aktiv war, setzt die Routine 138 das Ereignis im Schritt 226 auf Ereignisnachlauf, bevor sie zu Schritt 230 voranschreitet.
Der Softwarereplikator kann als ein Aktivierungsdetektionsmodul als exaktes Duplikat der auf der tatsächlichen Produktionshardwarekomponente laufenden Software implementiert werden. Der Replikator kann mit zusätzlichem Softwarecode, der als der Softwareanalysator bezeichnet wird, eingebettet werden, um einem Entwickler Informationen über das Systemverhalten bereitzustellen. Während an einer Hardwareimplementierung eine umfassende Kundenklinik laufen gelassen wird, wird das volle Sensorsignallog gesammelt, und das Datenlog kann als Eingabe für den Softwarereplikator, implementiert unter Verwendung desselben Quellcodes, der auf dem tatsächlichen Hardwaresensor-Schnittstellenmodul läuft, verwendet werden. Parameter in der Software können wie benötigt und im Replikator geprüft schnell geändert werden. Unter Verwendung der Differenz (Δ) zwischen gewünschten und tatsächlichen Aktivierungen zusätzlich zu der Anzahl unbeabsichtigter Aktivierungen als zwei Qualitätsmetriken wird das Aktivierungslog gesammelt und mit dem gewünschten Ergebnis verglichen. Zusätzlich kann das Sensordatenlog durch einen Signalverstärker vorverarbeitet werden, um Platinen mit höherer oder niedriger Empfindlichkeit, Sensorplatinen mit mehr oder weniger Übersprechen zwischen Kanälen oder Sensorplatinen mit demselben Layout, aber mit umentworfenen einzelnen Schaltern, die entweder andere Padgrößen oder Vorlagen aufweisen, zu simulieren. Die Aktivierungsdetektion in dem Softwarereplikator verarbeitet das modifizierte Datenlog, um vorherzusagen, welche Auswirkung diese Änderungen auf die physische Hardware hätten, so dass so viel Daten wie von einer vollen Klinik schnell verarbeitet werden können. Es kann schnell ein richtiger Sensorpadentwurf ausgewählt werden, die Softwareparameter können optimal abgestimmt werden und die Robustheit der Näherungssensorschnittstelle gegenüber Herstellungsvariabilität schnell bewertet werden.
Anstelle der Verwendung von gesammelten Sensorlogdaten können gemäß einer anderen Ausführungsform die tatsächlichen Bedienerhandhaltungs-Logdaten einem Softwaremodell des tatsächlichen Hardwaremoduls zugeführt werden, um das Datenlog zu erzeugen. Somit kann das Softwaremodell vorhersagen, was die Sensorantwort wäre. Das Handbewegungslog kann aus einer tatsächlichen Klinik gesammelt oder unter Verwendung eines der verfügbaren Mensch-Modellierungspakete erzeugt werden.
Die Replikatorroutine 300 ist in 13–16 gemäß einer Ausführungsform dargestellt. Mit Bezug auf 13 beginnt die Replikatorroutine 300 im Schritt 302 und schreitet zum Schritt 304 voran, um die Konfigurationsdatei zu analysieren. Als Nächstes beschafft die Routine 300 im Schritt 306 die Signalskalierungsmatrix S [] und schreitet zum Schritt 308 voran, um eine Liste von zu verarbeitenden Datenlogs, wie etwa Datenlog 0, Datenlog 1, Datenlog i, zu beschaffen. Die Eingaben für den Replikator können als eine Vorlagentextdatei, wie etwa eine Menge von Anweisungen, gesendet werden, und die Schritte 304, 306 und 308 werden benutzt, um diese Dateien zu durchparsen. Es versteht sich, dass dem Replikator verschiedene Eingaben zugeführt werden, darunter eine Konfiguration zum Analysieren der Datenlogs. Die Konfiguration zum Analysieren kann zu prüfende Steuerroutinen, zu prüfende Parameterkonfigurationen, wie zum Beispiel Schwellen und Kalibrationsraten, und Sensorwert-Skalierungsmatrizen, wie etwa eine Skalierungsmatrix zum Multiplizieren von unverarbeiteten Sensorwerten aus dem Datenlog, umfassen.
Die Replikatorsubroutine 300 parst im Schritt 310 die Sensorwerte. Das Datenlog kann Informationen enthalten, die für den Replikator nicht relevant sind, und dementsprechend kann diese Routine identifizieren, welche Daten die unverarbeiteten Sensorwertdaten sind, die als Eingabe für den Replikator zu verwenden sind. Als Nächstes führt die Routine 300 im Schritt 312 die Wrapper-Steuerroutine aus. Hierbei werden die unverarbeiteten Sensorwerte aus dem Datenlog zu der Steuerroutine gesendet. Die Routine besitzt einen Wrapper, der Aufgaben ausführt, die andernfalls durch Hardwaremodule in der Produktionsbaugruppe durchgeführt würden. Somit dient der Wrapper als Schnittstelle zum Ersetzen von Codezeilen, die hardwareabhängig sind, mit Code, der hardwareunabhängig ist. Als Nächstes schreitet die Routine 300 dazu voran, die Ausgangslogs aus der Steuerroutine im Schritt 314 abzuspeichern. Es können zwei Ausgangslogs im Speicher abgespeichert werden, darunter ein verarbeitetes Datenlog, das das Datenlog ist, so wie es erzeugt werden würde, wenn eine Prüfung an einer Produktions-Sensorschnittstellenbaugruppe laufen gelassen würde, und ein Log von typischen Parametern/Ereignissen. Danach schreitet die Routine 300 zum Entscheidungsschritt 316 voran, um zu bestimmen, ob irgendwelche Datenlogs übrig sind, und kehrt, wenn dem so ist, zum Schritt 310 zurück. Andernfalls endet die Routine 300 im Schritt 318.
Die Subroutine 304 zum Parsen der Parameterkonfigurationsdatei ist in 14 dargestellt. Die Parameterkonfigurationsdatei zum Initialisieren des Replikators kann als Textdatei gesendet werden, wodurch sichergestellt wird, dass der Replikator als getrenntes Werkzeug verwendet werden kann. Die Textdatei kann geparst werden, um die Liste von Parametern und ihre jeweiligen Werte zu beschaffen. Beginnend im Schritt 320 schreitet die Routine 304 zum Schritt 322 voran, um ein Tag zu beschaffen, und dann zum Schritt 324, um das Tag mit einer Datenbank abstimmbarer Parameter zu vergleichen. Ein Tag ist eine spezifische Parameterkennung, die einer Liste von Parameterwerten zugeordnet ist. Die Routine 304 bestimmt im Entscheidungsschritt 326, ob eine Übereinstimmung erfolgreich war, und schreitet, wenn dem so ist, zum Schritt 328 voran, um einen Abstimmwert zu beschaffen. Als Nächstes bestimmt die Routine 304 im Entscheidungsschritt 330, ob der Abstimmwert in einem gültigen Bereich liegt, und fügt, wenn dem so ist, den verglichenen Parameter im Schritt 322 zu einer Liste abzustimmender Parameter hinzu. Wenn der Vergleich nicht erfolgreich war oder wenn der Abstimmwert nicht in dem gültigen Bereich liegt, schreitet die Routine 304 direkt zum Entscheidungsschritt 334 voran. Im Entscheidungsschritt 334 bestimmt die Routine 304, ob weitere Tags zu verarbeiten sind, und kehrt, wenn dem so ist, zum Schritt 322 zurück. Andernfalls endet die Routine 304 im Schritt 336.
Die Subroutine 308 zum Beschaffen der Liste zu verarbeitender Datenlogs ist in 15 dargestellt. Die Liste von durch den Replikator zu verarbeitenden Datenlogs kann als Textdatei gesendet werden, wodurch auch sichergestellt wird, dass der Replikator als getrenntes Werkzeug verwendet werden kann, und die Textdatei kann geparst werden, um die Liste zu beschaffen. Die Routine 308 beginnt im Schritt 340 und schreitet zum Schritt 342 voran, um die Datenloglistenkonfigurationsdatei zu parsen, und dann zum Schritt 344, um ein Tag zu beschaffen. Im Entscheidungsschritt 346 bestimmt die Routine 308, ob das Tag enthalten ist und beschafft, wenn dem so ist, eine Vorlage und fügt die Vorlage hinzu, um eine Vorlagenliste aufzunehmen (Schritt 352). Wenn das Tag nicht enthalten ist, schreitet die Routine 308 zum Entscheidungsschritt 348 voran, um zu bestimmen, ob das Tag ausgeschlossen ist, und beschafft, wenn dem so ist, eine Vorlage und fügt eine Vorlage hinzu, um die Vorlagenliste auszuschließen (Schritt 350). Auf jeden Fall schreitet die Routine 308 zum Entscheidungsschritt 354 voran, um zu bestimmen, ob es weitere zu verarbeitende Tags gibt, und kehrt, wenn dem so ist, zum Schritt 342 zurück. Wenn keine weiteren Tags zu verarbeiten sind, schreitet die Routine 308 zum Schritt 356 voran, um das Datenlogverzeichnis zu scannen, und dann zum Entscheidungsschritt 358, um zu bestimmen, ob der Dateiname i mit irgendeiner Aufnahmevorlage übereinstimmt, und schreitet, wenn dem so ist, zum Entscheidungsschritt 360 voran. Im Entscheidungsschritt 360 bestimmt die Routine 308, ob der Dateiname i mit irgendeiner Ausschlussvorlage übereinstimmt, und beschafft, wenn dem nicht so ist, eine Vorlage, um die Vorlage zu der Vorlagenaufnahmeliste hinzuzufügen (Schritt 336). Auf jeden Fall schreitet die Routine 308 zum Entscheidungsschritt 364 voran, um zu bestimmen, ob es weitere Dateien in dem Verzeichnis gibt, und kehrt, wenn dem so ist, zum Schritt 358 zurück. Andernfalls endet Schritt 308 im Schritt 366.
Die Subroutine 310 zum Parsen des Sensorwerts aus dem Datenlog ist in 16 dargestellt. Das Datenlog kann für den Replikator nicht relevante Informationen enthalten, und dementsprechend identifiziert die Routine 310, welche Daten die als Eingabe für den Replikator zu verwendenden unverarbeiteten Sensorwertdaten sind. Die Routine 310 beginnt im Schritt 370 und schreitet zum Schritt 372 voran, um, wenn dies das erste Mal ist, Datenlog-Parameterliste, Zeitstempel, Delta_0, Delta_N, Raw_N aus dem Datenlog-Header aufzubauen. Als Nächstes schreitet die Routine 310 im Entscheidungsschritt 374 dazu, zu bestimmen, ob die Parameterliste (i) gleich Raw_N gesetzt ist, und setzt, wenn dem so ist, den unverarbeiteten Kanal i gleich dem Datenlog i (Schritt 376). Wenn die Parameterliste i nicht gleich Raw_N ist, schreitet die Routine 310 zum Entscheidungsschritt 378 voran. Im Entscheidungsschritt 378 bestimmt die Routine 310, ob das Parsen der Parameterliste abgeschlossen ist, und kehrt, wenn dem nicht so ist, zum Schritt 374 zurück. Andernfalls endet die Routine 310 im Schritt 380.
Mit Bezug auf 17–20 ist die Analysatorroutine 400 gemäß einer Ausführungsform dargestellt. Der Analysator 400 empfängt Eingaben, einschließlich des Entwurfs des Experiments (DOE). Der DOE ist der Entwurf jeder Informationssammelübung, die in einer zu analysierenden kontrollierten Experimentkonfiguration durchzuführen ist, und liefert Ausgaben, einschließlich der Konfigurations-/Leistungsfähigkeitsdiagramme. Die Eingaben können alternative Steuerroutinen, die zu prüfende Parameterkonfiguration, wie etwa Schwellen und Kalibrationsraten, und die Sensorwert-Skalierungsmatrix S [] als Skalierungsmatrix zum Multiplizieren von unverarbeiteten Sensorwerten aus dem Datenlog umfassen und können andere Parameter umfassen. Die Ausgaben können den Prozentsatz erfolgreich erkannter beabsichtigter Aktivierungen, den Prozentsatz ausgelöster unbeabsichtigter Aktivierungen und andere verschiedene mögliche Ausgaben umfassen. Die Analysatorroutine 400 beginnt im Schritt 402 und schreitet zum Schritt 404 voran, um die DOE-Datei zu parsen, und dann zum Schritt 406, um die erste Auswahl in der DOE-Tabelle zu nehmen. Im Schritt 408 setzt die Analysatorroutine 400 die Replikatorkonfigurationsdatei und schreitet dann dazu, den Replikator laufen zu lassen (Schritt 410). Nach dem Betrieb des Replikators schreitet die Analysatorroutine 400 dazu, die Replikatorlogs zu analysieren (Schritt 412). Die Ausgangslogs jedes Replikatorbetriebs können analysiert werden, um Benchmarking-Informationen zur Verwendung beim Prüfen und Entwickeln der Näherungssensorschnittstelle zu extrahieren.
Im Anschluss an die Analyse der Replikatorlogs schreitet die Analysatorroutine 400 zum Entscheidungsschritt 414 voran, um zu bestimmen, ob weitere Auswahlen in der DOE-Tabelle übrig sind, und nimmt, wenn dem so ist, die nächste Auswahl in der DOE-Tabelle und kehrt zum Schritt 408 zurück. Wenn keine weiteren Auswahlen in der DOE-Tabelle übrig sind, schreitet die Analysatorroutine 400 dazu, im Schritt 418 die Ausgabe zusammenzustellen, bevor sie im Schritt 420 endet. Die analysierten Daten aller Softwarekonfigurationen können zu einem oder mehreren Konfigurations-/Leistungsfähigkeitsdiagrammen aggregiert werden. Die Diagramme können zusammengestellte und kategorisierte Leistungsfähigkeitsdaten umfassen.
Die Subroutine 404 zum Parsen der DOE-Datei ist in 18 dargestellt, beginnt im Schritt 422 und schreitet bei 424 dazu, die Tag-Daten zu beschaffen und das Tag mit der Datenbank abstimmbarer Parameter zu vergleichen (Schritt 426). Als Nächstes schreitet die Routine 404 zum Entscheidungsschritt 428 voran, um zu sehen, ob der Vergleich erfolgreich war, und beschafft, wenn dem so ist, im Schritt 430 Abstimmwerte und fügt im Schritt 432 Parameter und Werte zu der Analysator-DOE-Tabelle hinzu und schreitet zum Schritt 434 voran. Wenn der Vergleich nicht erfolgreich war, schreitet die Routine 404 zum Schritt 434 voran. Im Schritt 434 bestimmt die Routine 404, ob weitere Tags zu verarbeiten sind, und kehrt, wenn dem so ist, zum Schritt 424 zurück. Andernfalls endet die Routine 404 im Schritt 436.
Die Ereignisanalysierroutine 440 ist in 19 gemäß einer Ausführungsform dargestellt. Die Ereignisanalysierroutine 440 kann als ein Modul implementiert werden, das die Replikatorausgangslogs zu einem Leistungsfähigkeitsdiagramm zusammenstellt. Hierbei beginnt die Routine 440 im Schritt 442 und schreitet zum Entscheidungsschritt 444 voran, um zu bestimmen, ob das Ereignis ein Aktivierung-Abgebrochen-Ereignis ist, und vergrößert, wenn dem so ist, den Aktivierung-Abgebrochen-Zähler und verkleinert den Kanalaktivierung-Abgebrochen-Zähler (Schritt 446), bevor sie zum Schritt 458 voranschreitet. Wenn das Ereignis kein Aktivierung-Abgebrochen-Ereignis ist, schreitet die Routine 440 zum Entscheidungsschritt 448 voran, um zu bestimmen, ob das Ereignis ein Durchlaufereignis ist, und vergrößert, wenn dem so ist, den Durchlaufereigniszähler und vergrößert den Kanaldurchlaufereigniszähler (Schritt 450), bevor sie zum Schritt 458 voranschreitet. Wenn das Ereignis kein Durchlaufereignis ist, schreitet die Routine 440 zum Entscheidungsschritt 452 voran, um zu bestimmen, ob das Ereignis ein Aktivierungsereignis ist, und vergrößert, wenn dem so ist, den Aktivierungszähler und vergrößert den Kanalaktivierungszähler (Schritt 454). Danach berechnet die Routine 440 jeweils Folgendes: die Aktivierungsdetektionszeit, Ereignisdauer, Aktualisierungsbereiche und Histogramme für Aktivierungsdetektionszeit und Ereignisdauer (Schritt 456), bevor sie zum Schritt 458 voranschreitet. Wenn das Ereignis kein Aktivierungsereignis ist, schreitet die Routine 440 zum Entscheidungsschritt 460 voran. Im Schritt 458 setzt die Routine 440 die Aktualisierungsbereiche und die Histogramme jeweils für Folgendes: den zweiten Maximal- bzw. Max-Kanal, das Max-Verhältnis, max_peak_max_ch, max_peak_sum_ch, max_rate und max_noise. Danach schreitet die Routine 440 zum Entscheidungsschritt 460 voran, um zu bestimmen, ob weitere Ereignisse übrig sind, und kehrt, wenn dem so ist, zum Schritt 444 zurück. Andernfalls endet die Routine 440 im Schritt 462.
Eine Ereignisanalysier-Logroutine 500 für eine spezifische Näherungsschalterbaugruppe ist gemäß einer anderen Ausführungsform dargestellt. Bei dieser Ausführungsform sind zusätzliche Informationen bezüglich der Steuerroutine verfügbar, die aus dem Log extrahiert werden können. Dieses Modul kann mit einer spezifischen Näherungssensorschnittstelle implementiert werden, die spezifischere Schritte als die vorherige Ausführungsform aufweist. Bei dieser Ausführungsform beginnt die Routine 500 im Schritt 502 und schreitet zum Entscheidungsschritt 504 voran, um zu bestimmen, ob das Ereignis ein Aktivierung-Abgebrochen-Ereignis ist, und schreitet, wenn dem so ist, dazu, den Aktivierung-Abgebrochen-Zähler zu vergrößern und den Kanalaktivierung-Abgebrochen-Zähler zu vergrößern (Schritt 506). Danach aktualisiert die Routine 500 im Schritt 508 die Bereiche und Histogramme jeweils für Folgendes: max_second_max_channel, max_ratio, max_peak_max_channel, max_peak_sum_channel, max_rate und max_noise. Im Entscheidungsschritt 510 bestimmt die Routine 500 danach, ob die Max-Rate kleiner als eine Ratenschwelle ist, und vergrößert, wenn dem so ist, den Zähler Aktivierung abgebrochen aufgrund unzureichender Rate (Schritt 518). Wenn die Max-Rate nicht kleiner als die Ratenschwelle ist, schreitet die Routine 500 zum Entscheidungsschritt 512 voran, um zu bestimmen, ob das Max-Verhältnis größer als eine Signaturschwelle ist, oder ob max_second_max_channel dividiert durch max_peak_max_channel kleiner als eine Dual-Kanal-Schwelle ist, und vergrößert, wenn dem so ist, den Zähler Aktivierung abgebrochen aufgrund unzureichender Signatur (Schritt 520). Wenn die Ausgabe des Entscheidungsblocks 512 nein ist, schreitet die Routine 500 zum Entscheidungsschritt 514 voran, um zu bestimmen, ob max_noise kleiner als die Rauschschwelle ist, und vergrößert, wenn dem so ist, den Zähler Aktivierung abgebrochen aufgrund von hohem Rauschen (Schritt 522). Andernfalls schreitet die Routine 500 dazu, den Zähler Aktivierung abgebrochen aufgrund von nichtstabilem Signal, bevor sie zum Schritt 538 voranschreitet.
Wenn das Ereignis kein Aktivierung-Abgebrochen-Ereignis ist, schreitet die Routine 500 zum Entscheidungsschritt 524 voran, um zu bestimmen, ob das Ereignis ein Durchlaufereignis ist, und schreitet, wenn dem so ist, zum Schritt 526 voran, um den Durchlaufereigniszähler zu vergrößern und um den Kanal-Durchlaufereigniszähler zu vergrößern, und dann zum Schritt 528, um die Bereiche und Histogramme jeweils für Folgendes zu aktualisieren: max_second_max_channel, max_ratio, max_peak_max_channel, max_peak_sum_channel, max_rate und max_noise, bevor sie zum Schritt 538 voranschreitet.
Wenn das Ereignis kein Durchlaufereignis ist, schreitet die Routine 500 zum Entscheidungsschritt 530 voran, um zu bestimmen, ob das Ereignis ein Aktivierungsereignis ist, und vergrößert, wenn dem so ist, den Aktivierungszähler und vergrößert den Kanalaktivierungszähler (Schritt 532) und schreitet dann zum Schritt 534 voran, um die Aktivierungsdetektionszeit und Ereignisdauer zu berechnen. Als Nächstes schreitet die Routine 500 zum Schritt 536 voran, um die Bereiche und Histogramme jeweils für Folgendes zu aktualisieren: max_second_max_channel, max_ratio, max_peak_max_channel, max_peak_sum_channel, max_rate und max_noise-Aktivierungszeit und Ereignisdauer. Danach schreitet das Verfahren 500 zum Entscheidungsblock 538 voran, um zu sehen, ob weitere Ereignisse übrig sind, und kehrt, wenn dem so ist, zum Schritt 504 zurück. Andernfalls endet die Routine 500 im Schritt 540.
Um das Ansprechen einer Näherungssensorschnittstelle zu verbessern und um unbeabsichtigte Betätigungen zu verringern, ist es vorteilhaft, zu wissen, ob die aktuelle Abstimmung und Einrichtung der Software, die zu prüfen ist, dazu führen würden, dass ein Bewegungsereignis ein Schalteraktivierungsereignis auslöst oder nicht, und ferner ihre Klassifikation zu bestimmen, wie etwa als ein Tip- oder stabiles Drückereignis, ein Bloßhand- oder behandschuhte-Hand-Ereignis. Wenn kein Ereignis stattfindet, ist es ferner wünschenswert, zu wissen, ob der Grund darin bestand, dass der Bediener die Schalter erkundet hat oder ob die Aktivierung aufgrund einer Sicherheitsverriegelung abgebrochen wurde oder weil eine Auslösebewegung als zu langsam angesehen wird oder weil der Kanal niemals aufgrund der Anwesenheit von Rauschen auf dem Signal einen stabilen Zustand erreicht hat oder weil das Signaturverhältnis nicht ausreichend war. Der Softwarereplikator erzeugt gemäß bestimmten Beispielen Informationen, um dabei zu helfen, zu verstehen, ob ein beabsichtigtes Ereignis, wie etwa ein Glasdachschließereignis, erkannt wurde, aber aufgrund suboptimaler Abstimmung der Schnittstelle nicht ausgelöst wurde, oder ob der Bediener unabsichtlich den Verriegelungsschalter ausgelöst hat oder ob zu viele beabsichtigte Fahrgastrauminnenleuchtenaktivierungen zurückgewiesen wurden, weil ein Feuchtigkeitskompensationsmechanismus zu aggressiv abgestimmt war.
Der Softwarereplikator kann verschiedene Parameter aufzeichnen, die Metriken für das Entwicklungssystem zum Prüfen und Bestimmen von Ansprechen und Robustheit der Näherungssensorschnittstelle bereitstellen. Zu aufgezeichneten Parametern können die Signalspitze während der Aktivierungsbewegung und ihre Signatur, die Anzahl der während der Bewegung aktiven Kanäle, der zweitgrößte Signalpegel, während das Ereignis die Spitze erreichte, die schnellste Rate des größten Kanals und die Dauer des Bewegungsereignisses vom Anfang der Detektion und vom Anfang bis Ende gehören. Es versteht sich, dass der Replikator verschiedene andere Parameter und Kombinationen von Parametern aufzeichnen kann.
Mit Bezug auf 21 ist eine beispielhafte Ausgabe des Softwareanalysators dargestellt, bei der fünf Drückereignisse durch den Softwarereplikator und Analysator verarbeitet werden. Alle Schalterdruckereignisse wurden in diesem Beispiel als stabile Druckereignisse interpretiert. Jeder Signalkanal erreichte einen Spitzen-Kapazitiv-Zählwert im Bereich von 191 bis 324, mit einer maximalen Rate im Bereich von 195 bis 325. Die dargestellten Daten sind Daten, die aus einer Prüfung durch einen einzigen Benutzer beschafft wurden. Es versteht sich, dass der Benutzer einen oder mehrere Schalter in vielfältigen Aktivierungstechniken aktivieren kann und dass mehrere Benutzer die Näherungssensorschnittstelle während des Datenloggens zur Beschaffung und Analyse der Daten betätigen können. Die für die Kanäle 0–4 während eines aktiven stabilen Ereignisses beschafften Daten umfassen das Handschuhwarten, Warten, max_channel, sum_channel, Verhältnis von sum_channel zu max_channel, peak_max, peak_sum, max_ratio, Anzahl der Kanäle über der Aktivierungsschwelle (N_act_channel), zweiter max_channel, max_channel-Stabilzustand, Ratensperrung und Raten-Max. Es versteht sich, dass das Entwicklungssystem verschiedene andere Parameter beschaffen, aufzeichnen und analysieren kann.
Mit Bezug auf 22 sind die Ausgangsparameter von mehreren Prüfungen in einem verbundenen Zusammenfassungsdiagramm für mehrere Subjekte, mehrere Prüfläufe und Prüfungen, die automatisch durch den Analysator zusammengestellt werden, gezeigt. Der Analysator verarbeitet die durch den Replikator erzeugten Ausgaben und produziert ein oder mehrere Leistungsfähigkeitsdiagramme, die die Leistungsfähigkeit der geprüften Näherungssensorschnittstelle angeben. Das verbundene Zusammenfassungs-Leistungsfähigkeitsdiagramm in 22 zeigt zusammengestellte Daten für jeden bestimmter Parameter und Ergebnisse für die Kanäle ch0–ch7 und vergibt für jeden Kanal eine Pass- und eine Fail-Zahl und eine Bewertung, die das Verhältnis von Pass zu Fail angibt. In dem gezeigten beispielhaften Diagramm trat für die Signalkanäle ch0 und ch1 eine hohe Fehlschlagrate auf, die in einem spezifischen Beispiel auf einen aggressiven Ratenüberwachungsalgorithmus zum Kompensieren von Hardwarekondensationsereignissen zurückzuführen war. Die geprüfte Software umfasst in diesem Beispiel eine aggressive Kalibrationseinstellung, die zu dem Ausfall bestimmter Kanäle wie durch das Entwicklungssystem bestimmt führt, ohne dass es notwendig ist, Umgebungsprüfung mit einer großen Benutzerklinik zu wiederholen. Somit kann Software effizient und effektiv modifiziert und geprüft werden.
Mit Bezug auf 23 ist ein anderer vereinfachter Bericht, der durch den Analysator erzeugt wird, für DV-Prüfung (Entwurfsverifikation) und PV-Prüfung (Produktverifikation) gezeigt, der nur die Reihenfolge aufzeichnet, in der Kanäle aktiviert wurden, ob die Aktivierung mit einem langen Drücken oder einem Tippen erfolgte, und die Dauer des Drücken. Dieser vereinfachte Bericht kann verwendet werden, um die Aktivierungssequenzausgabe mit dem gewünschten Ziel, der Reihenfolge, in der die mechanischen Finger die Schalter in der thermischen Umgebungskammer aktivieren, abzustimmen und zu bestimmen, ob alle Druckbetätigungen Aktivierung ausgelöst haben oder um auf die Anwesenheit zusätzlicher unbeabsichtigter Aktivierungen, die durch thermisch-klimatische Ereignisse ausgelöst werden, zu prüfen.
24–29 zeigen verschiedene Diagramme, die während des Prüfens einer Overheadkonsole mit einer kapazitiven Schalterbaugruppe erzeugt wurden. Um die Software der kapazitiven Schalterbaugruppe abzustimmen, wurde der Simulator mit verschiedenen Schwellenwerten für einen Ratenüberwachungsalgorithmus betrieben, im Bereich von keiner Ratenüberwachung bis zu sehr aggressiver Ratenüberwachung (Ratenschwelle von 0 Zählungen/80 Millisekunden bzw. 70 Zählungen/80 Millisekunden). Es wurden mehr als 100 Stichproben in Umgebungskammern gesammelt, die eine maximale aufgezeichnete feuchtigkeitsausgelöste Ereignisrate von etwa 25 Zählungen/80 Millisekunden aufwies.
Zeile 630 in dem in 24 gezeigten Diagramm zeigt den prozentualen Aktivierungsfehler als Funktion der Ratenüberwachungsschwelle für eine Bloße-Hand-Aktivierung ohne Handschuhe. In einem Bereich von 30 Zählungen/80 Millisekunden ist ein Knie in den Daten zu sehen. Die minimale Ratenschwelle wurde deshalb auf 30 Zählungen gesetzt. Aktivierungsfehler umfassen sowohl beabsichtigte Ereignisse, die nicht erkannt werden, als auch Nichterkundungsbewegung, die unbeabsichtigte Ereignisse erzeugt. Bestimmte der beabsichtigten Ereignisse, die nicht erkannt wurden, sind Schließen und Neigen des Glasdachs, das durch Sicherheitsverriegelungsschalter abgebrochen wurde, wobei es sich nicht um Fehler handelt.
Als Nächstes wurde die Einstellung der Signalpegelschwelle zum Erkennen einer gültigen Aktivierung bestimmt. Unter Verwendung eines Ratenüberwachungsalgorithmus konnte der Schwellenpegel herabgesetzt und geprüft werden, wie in Zeile 604 von 25 gezeigt, worin der mittlere Prozentsatz von Aktivierungsfehlern als Funktion der kapazitiven Pegelaktivierungsschwelle für bloßhandige Interaktion gezeigt ist. In diesem Beispiel ist in den Daten bei einem Wert von gerade oberhalb 120 Zählungen ein Knie zu beobachten, worüber eine schnelle Zunahme des Fehlerprozentsatzes besteht.
Mit Bezug auf 26 ist der mittlere Prozentsatz von Aktivierungsfehlern als Funktion der kapazitiven Pegelschwelle für eine mit Handschuh bedeckte Hand durch Zeile 650 dargestellt. Bei etwa 100 Zählungen für die behandschuhte Interaktion ist ein Knie in den Daten zu beobachten, aber nicht so deutlich wie im Fall der bloßhandigen Interaktion. Um eine Wahl für die Signalaktivierungspegelschwelle zu finalisieren, kann die Robustheit des Systems als Funktion von Herstellungsschwankungen und Sensorempfindlichkeit ermittelt werden. Die Pegelschwelle wurde anfänglich auf 120 Zählungen gesetzt, und der Softwaresimulator lief an demselben Datensatz mit verstärktem kapazitivem Signal, um eine Empfindlichkeitsänderung im Bereich von –60% bis +60% zu simulieren.
Mit Bezug auf 27 und 28 sind durch Zeile 660 in 27 gezeigt der mittlere Prozentsatz von Aktivierungsfehlern für zwei Overheadkonsolen-Fahrgastinnenraumleuchtenschalter als Funktion verminderter/vergrößerter Empfindlichkeit (in Prozent ausgedrückt) für bloßhändige Interaktion bzw. behandschuhte Interaktion durch Zeile 670 in 28 gezeigt dargestellt. Eine Verringerung der Empfindlichkeit um 20% (–20) vom Mittelbereichspunkt (0) ist ausreichend, um die Menge der Aktivierungsfehler sowohl bei bloßhändiger als auch behandschuhter Interaktion zu verdoppeln. In diesem Beispiel wurde eine Entscheidung getroffen, die Aktivierungsschwelle auf 80 Zählungen zu setzen. Selbst eine Empfindlichkeitsverschlechterung von 50% (80 auf 100 Zählungen) würde somit einen Aktivierungsfehler von weniger als 1% bei bloßhändiger Interaktion und 15% Aktivierungsfehler bei behandschuhter Interaktion ergeben.
Mit Bezug auf 29 sind vier Versionen von Näherungssensorschnittstellensoftware V₁₀–V₁₃, die geprüft wurden, und verglichen und bewertet als Prozent der korrekten Aktivierung in einem durch den Analysator erzeugten Diagramm mit der Kennzeichnung 680 ausgegeben gezeigt. Das Entwicklungssystem wurde vorteilhafterweise verwendet, um die Endversion der Software für eine Näherungssensorschnittstelle zu entwickeln, die ein Kondensations-Hardwareproblem kompensierte, aber auch ausgezeichnetes Ansprechen und robuste Rauschzurückweisung erzielt. Es versteht sich, dass der Softwarereplikator vorteilhafterweise die Software unter Verwendung des Datenlogs prüfte und dass der Analysator eine Ausgangsbewertung lieferte, die die Leistungsfähigkeit der verschiedenen Versionen der Software angibt, um es einem Entwickler somit zu ermöglichen, effektiv und effizient das optimale Softwarepaket zu bestimmen.
Dementsprechend erlaubt das Näherungsschnittstellen-Entwicklungssystem vorteilhafterweise das Prüfen verschiedener Softwaremodifikationen an einer Näherungssensorschnittstelle, wie etwa einer Näherungsschalterbaugruppe. Das System prüft effizient und effektiv Varianten der Software, ohne Umgebungsprüfung mit einem großen Pool von Benutzern während einer Klinik duplizieren zu müssen. Das System verarbeitet ferner vorteilhafterweise die analysierten Daten, um eine Ausgabe für den Entwickler zum Verwenden oder Entwickeln der optimalen Näherungssensorschnittstelle bereitzustellen.
Es versteht sich, dass Abwandlungen und Modifikationen an der erwähnten Struktur vorgenommen werden können, ohne von den Konzepten der vorliegenden Erfindung abzuweichen, und ferner versteht sich, dass solche Konzepte durch die folgenden Ansprüche abgedeckt werden sollen, wenn es diese Ansprüche durch ihre Sprache nicht ausdrücklich anders angeben.
Bezugszeichenliste
Fig. 19

442: EREIGNISLOG ANALYSIEREN
444: IST EREIGNIS = ACTIVATION_ABORTED?
N: NEIN
446: AKTIVIERUNG-ABGEBROCHEN-ZÄHLER VERGRÖSSERN, K-AKTIVIERUNG-ABGEBROCHEN-ZÄHLER VERGRÖSSERN
448: IST EREIGNIS = DURCHLAUF?
450: DURCHLAUFEREIGNISZÄHLER VERGRÖSSERN, K-DURCHLAUFEREIGNIS-ZÄHLER VERGRÖSSERN
452: IST EREIGNIS = AKTIVIERUNG?
454: AKTIVIERUNGSZÄHLER VERGRÖSSERN, K-AKTIVIERUNGSZÄHLER VERGRÖSSERN
456: BERECHNEN: AKTIVIERUNGSDETEKTIONSZEIT, EREIGNISDAUER, BEREICHE UND HISTOGRAMME AKTUALISIEREN FÜR: AKTIVIERUNGSDETEKTIONSZEIT, EREIGNISDAUER
458: BEREICHE UND HISTOGRAMME AKTUALISIEREN FÜR: MAX_2nd_MAX_CH, MAX_RATIO, MAX_PEAK_MAX_CH, MAX_PEAK_SUM_CH, MAX_RATE, MAX_NOISE
460: SIND WEITERE EREIGNISSE ÜBRIG?
N: NEIN

502: EREIGNISLOG ANALYSIEREN
504: IST EREIGNIS = ACTIVATION_ABORTED?
N: NEIN
506: AKTIVIERUNG-ABGEBROCHEN-ZÄHLER VERGRÖSSERN, K-AKTIVIERUNG-ABGEBROCHEN-ZÄHLER VERGRÖSSERN
508: BEREICHE UND HISTOGRAMME AKTUALISIEREN FÜR: MAX_2nd_MAX_CH, MAX_RATIO, MAX_PEAK_MAX_CH, MAX_PEAK_SUM_CH, MAX_RATE, MAX_NOISE
510: IST MAX_RATE < RATE_TRESHOLD?
518: ZÄHLERAKTIVIERUNG ABGEBROCHEN AUFGRUND UNZUREICHENDER RATE VERGRÖSSERN
512: IST MAX_RATIO < SIGNATURE_THRESHOLD ODER MAX_2ND_MAX_CH/MAX_PEAK_MAX_CH < DUAL_CHANNEL_THRESHOLD?
520: ZÄHLERAKTIVIERUNG ABGEBROCHEN AUFGRUND UNZUREICHENDER RATE VERGRÖSSERN
514: IST MAX_NOISE < NOISE_THRESHOLD?
522: ZÄHLERAKTIVIERUNG ABGEBROCHEN AUFGRUND VON HOHEM RAUSCHEN VERGRÖSSERN
516: ZÄHLERAKTIVIERUNG ABGEBROCHEN AUFGRUND VON NICHTSTABILEM SIGNAL VERGRÖSSERN
524: IST EREIGNIS = DURCHLAUF?
526: DURCHLAUFEREIGNISZÄHLER VERGRÖSSERN, K-DURCHLAUFEREIGNIS-ZÄHLER VERGRÖSSERN
528: BEREICHE UND HISTOGRAMME AKTUALISIEREN FÜR: MAX_2nd_MAX_CH, MAX_RATIO, MAX_PEAK_MAX_CH, MAX_PEAK_SUM_CH, MAX_RATE, MAX_NOISE
530: IST EREIGNIS = AKTIVIERUNG?
532: AKTIVIERUNGSZÄHLER VERGRÖSSERN, K-AKTIVIERUNGSZÄHLER VERGRÖSSERN
534: BERECHNEN: AKTIVIERUNGSDETEKTIONSZEIT, EREIGNISDAUER,
536: BEREICHE UND HISTOGRAMME AKTUALISIEREN FÜR: MAX_2nd_MAX_CH, MAX_RATIO, MAX_PEAK_MAX_CH, MAX_PEAK_SUM_CH, MAX_RATE, MAX_NOISE
538: SIND WEITERE EREIGNISSE ÜBRIG?
N: NEIN

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

ATMEL® Touch Sensors Design Guide, 10620 D-AT42-04/09, vom 9.4.2009 [0039]

Claims

Näherungsschnittstellen-Entwicklungssystem, umfassend: Softwareroutinen, die dafür entwickelt sind, eine Näherungssensorschnittstelle zu bedienen, die mehrere Näherungssensoren aufweist; aus Prüfung der Softwareroutinen beschaffte Prüfdaten; und einen Analysator zum Verarbeiten der Prüfdaten, um Leistungsfähigkeit der Näherungssensorschnittstelle zu bestimmen, und zum Erzeugen einer Ausgabe, die Prüfergebnisse angibt.
System nach Anspruch 1, wobei der Analysator bestimmt, ob eine beabsichtigte Aktivierung eines oder mehrerer der Sensoren detektiert wurde.
System nach Anspruch 2, wobei der Analysator ferner unerwünschte Aktivierungen eines oder mehrerer der Sensoren bestimmt.
System nach Anspruch 1, das ferner einen Replikator zum Replizieren der Softwareroutine auf der Basis eines Datenlog und zum Bestimmen von erwarteten Ausgaben der Näherungssensorschnittstelle umfasst.
System nach Anspruch 4, das ferner einen Eingang zum Empfangen einer oder mehrerer Einstellungen zum Justieren eines oder mehrerer Parameter der Näherungssensorschnittstelle umfasst, wobei der Replikator die Einstellungen in Kombination mit den Softwareroutinen und dem Datenlog verarbeitet, um die Ausgabe zu erzeugen.
System nach Anspruch 1, wobei das System einen Computer umfasst, der von der Näherungssensorschnittstelle getrennt ist.
System nach Anspruch 6, wobei der Computer Speicher umfasst, der die Softwareroutinen speichert.
System nach Anspruch 1, wobei die Näherungssensorschnittstelle einen Näherungsschalter umfasst.
System nach Anspruch 8, wobei der kapazitive Schalter einen Näherungssensor umfasst, wobei ein Signal, das einem Aktivierungsfeld zugeordnet ist, verarbeitet wird, um Aktivierung des Näherungssensors zu bestimmen.
System nach Anspruch 1, wobei die Näherungssensorschnittstelle für Verwendung in einem Fahrzeug durch einen Passagier in dem Fahrzeug entwickelt ist.
Verfahren zum Entwickeln einer Näherungssensorschnittstelle, umfassend: Bereitstellen von Softwareroutinen, die dafür entwickelt sind, eine Näherungssensorschnittstelle zu betreiben, die mehrere Sensoren aufweisen; Prüfen der Softwareroutinen, um Prüfdaten zu erzeugen; Verarbeiten der Prüfdaten, um Leistungsfähigkeit der Softwareroutinen zu bestimmen; und Erzeugen einer Ausgabe, die die Prüfergebnisse angibt.
Verfahren nach Anspruch 11, wobei der Schritt des Verarbeitens Analysieren umfasst, ob eine beabsichtigte Aktivierung eines oder mehrerer der Näherungssensoren detektiert wurde.
Verfahren nach Anspruch 12, wobei der Schritt des Verarbeitens Analysieren umfasst, um unerwünschte Aktivierungen eines oder mehrerer der Näherungssensoren zu bestimmen.
Verfahren nach Anspruch 11, ferner mit dem Schritt des Replizierens der Softwareroutinen auf der Basis eines Datenlog und Bestimmens von erwarteten Ausgaben der Näherungssensorschnittstelle, um die Prüfdaten zu erzeugen.
Verfahren nach Anspruch 14, ferner mit dem Schritt des Empfangens einer oder mehrerer Einstellungen zum Justieren eines oder mehrerer Parameter der Näherungssensorschnittstelle und des Verarbeitens der einen oder mehrerer Einstellungen in Kombination mit den Softwareroutinen und dem Datenlog, um die Ausgabe zu erzeugen.
Verfahren nach Anspruch 11, wobei der Schritt des Analysierens durch einen Computer ausgeführt wird, der von der Näherungssensorschnittstelle getrennt ist.
Verfahren nach Anspruch 16, wobei der Computer Speicher umfasst, der die Softwareroutinen speichert.
Verfahren nach Anspruch 11, wobei die Näherungssensorschnittstelle einen Näherungsschalter umfasst.
Verfahren nach Anspruch 18, wobei der Näherungsschalter einen Näherungssensor umfasst, wobei ein Signal, das einem Aktivierungsfeld zugeordnet ist, verarbeitet wird, um Aktivierung des Näherungssensors zu bestimmen.
Verfahren nach Anspruch 11, wobei die Näherungssensorschnittstelle zur Verwendung in einem Fahrzeug zur Verwendung durch einen Passagier in dem Fahrzeug entworfen ist.