Proximity interface development system having replicator and method

Abstract

A development system and method are provided for testing proximity sensor interfaces, such as a capacitive switch assembly which may be employed in an automotive vehicle. The system includes software routines stored in memory for operating a proximity sensor interface having a plurality of sensors, and a data log including user outputs of the proximity sensors. The development system includes a replicator for replicating the proximity sensor interface based on the software routines and the data log and generating outputs of the proximity sensor interface to determine performance. The system further includes an analyzer for processing the test data for proper activation of the proximity sensor interface and generating an output indicative of the test results.

Description

FIELD OF THE INVENTION

The present invention generally relates to user interfaces, and more particularly relates to a development tool for testing and development of proximity interfaces such as proximity switches used in vehicles.

BACKGROUND OF THE INVENTION

Capacitive sensor interfaces are increasingly employed on various electronic devices including smartphones, appliances and vehicle instrument panels to replace traditional mechanical switches. In automotive applications, capacitive sensor interfaces may be employed to operate devices including powered windows, headlights, windshield wipers, moonroofs or sunroofs, interior lighting, radio information, infotainment devices and various other devices. Proximity switches, such as capacitive switches, employ one or more proximity sensors to generate a sense activation field and sense changes to the activation field indicative of user actuation of the switch, typically caused by a user's finger in close proximity or contact with the sensor. Capacitive switches are typically configured to detect user actuation of the switch based on comparison of the sense activation field to a threshold.

A capacitive switch typically does not provide a digital on/off input, but instead provides a sensor value dependent on various characteristics including the operator's finger size, posture and distance. As such, the logic to interpret the operator intent to operate one or more switches is generally more complex than a traditional mechanical switch. Due to the different operators and uses, it may be difficult to efficiently develop a capacitive sensor interface that is well suited for use by different operators. In the automotive application, the development of these types of proximity sensor interfaces typically includes environmental testing of the interfaces by a large pool of users in a customer clinic, which generally involves an expensive and time-consuming process. If changes such as changing tuning parameters in software need to be made to the sensor interfaces, the testing may have to be repeated. It would be desirable to provide for a development system that reduces the time and cost for testing and developing capacitive sensor interfaces, particular for use in the automotive environment.

SUMMARY OF THE INVENTION

According to one aspect of the present invention, a proximity interface development system is provided. The proximity interface development system includes software routines developed to operate a proximity sensor interface having a plurality of proximity sensors. The system also includes a data log including expected user outputs of the proximity sensors and a replicator for replicating the proximity sensor interface based on the software routines and the data log and generating an expected output of the proximity sensor interface for determining performance.

According to a further aspect of the present invention, a method of developing a proximity sensor interface is provided. The method includes the steps of providing software routines developed to operate a proximity sensor interface having a plurality of sensors, and receiving a data log including expected user outputs of the proximity sensors. The method further includes the steps of replicating operation of the interface by processing the software routines, and generating data indicative of performance of the capacitive sensor interface.

These and other aspects, objects, and features of the present invention will be understood and appreciated by those skilled in the art upon studying the following specification, claims, and appended drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings:

FIG. 1 is a perspective view of a passenger compartment of an automotive vehicle having an overhead console employing a proximity switch assembly, according to one embodiment;

FIG. 2 is an enlarged view of the overhead console and proximity switch assembly shown in FIG. 1 and further coupled to a data logger for user testing;

FIG. 3 is an enlarged cross-sectional view taken through line III-III in FIG. 2 showing an array of proximity switches in relation to a user's finger;

FIG. 4 is a schematic diagram of a capacitive sensor employed in each of the capacitive switches shown in FIG. 3;

FIG. 5 is a block diagram illustrating the proximity switch assembly, according to one embodiment;

FIG. 6 is a block diagram illustrating a development system employing a replicator and analyzer as a tool for developing the proximity switches, according to one embodiment;

FIG. 7 is a flow diagram illustrating a control routine with wrapper operated by the development system, according to one embodiment;

FIG. 8 is a flow diagram illustrating the extract salient parameters subroutine of FIG. 7;

FIG. 9 is a flow diagram illustrating the event update subroutine of FIG. 8;

FIG. 10 is a flow diagram illustrating the event initialization subroutine of FIG. 8;

FIG. 11 is a flow diagram illustrating the subroutine for finding the second largest signal of FIG. 9;

FIG. 12 is a flow diagram illustrating the process new max channel subroutine of FIG. 8;

FIG. 13 is a flow diagram illustrating the replicator routine, according to one embodiment;

FIG. 14 is a flow diagram illustrating the parse parameter configuration subroutine of FIG. 13;

FIG. 15 is a flow diagram illustrating the acquire list of data logs to process subroutine of FIG. 13;

FIG. 16 is a flow diagram illustrating the parse sensor value from data log subroutine of FIG. 13;

FIG. 17 is a flow diagram illustrating the analyzer routine, according to one embodiment;

FIG. 18 is a flow diagram illustrating the parse DOE file subroutine of FIG. 17;

FIG. 19 is a flow diagram illustrating the analyzer event logs subroutine of FIG. 17, according to one embodiment;

FIG. 20 is a flow diagram illustrating the analyzer event log subroutine of FIG. 17, according to another embodiment;

FIG. 21 is a table illustrating a sampling of proximity switch activation events acquired and processed by the development system, according to one example;

FIG. 22 is a table illustrating event DOE log data showing the output from multiple tests combined by the analyzer into a summary chart, according to one example;

FIG. 23 is a table illustrating a simplified output report presenting test results showing activation type and duration, according to one example;

FIG. 24 is a graph illustrating percentage of activation error as a function of minimum count rate increase over 80 milliseconds for activation without gloves, according to one example;

FIG. 25 is a graph illustrating average percentage of activation as a function of capacitive level activation threshold without gloves, according to one example;

FIG. 26 is a graph illustrating an average percent of activation errors as a function of capacitive level activation threshold for gloved hand interaction, according to one example;

FIG. 27 is a graph illustrating an average percent of activation errors for switches as a function of decreased/increased sensitivity without gloves, according to one example;

FIG. 28 is a graph illustrating an average percent of activation errors for switches as a function of decreased/increased sensitivity for gloved hand interaction, according to one example; and

FIG. 29 is a graph comparing four versions of software that were tested using the development tool, according to one example.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

As required, detailed embodiments of the present invention are disclosed herein; however, it is to be understood that the disclosed embodiments are merely exemplary of the invention that may be embodied in various and alternative forms. The figures are not necessarily to a detailed design; some schematics may be exaggerated or minimized to show function overview. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the present invention.

Referring to FIGS. 1 and 2, the interior of an automotive vehicle 10 is generally illustrated having a proximity sensor interface in the passenger compartment referred to as a proximity switch assembly 20 having a plurality of proximity switches 22 with switch activation monitoring and determination, according to one embodiment. The vehicle 10 generally includes an overhead console 12 assembled to the headliner on the underside of the roof or ceiling at the top of the vehicle passenger compartment, generally above the front passenger seating area. The switch assembly 20 has a plurality of proximity switches 22 arranged close to one another in the overhead console 12, according to one embodiment. The various proximity switches 22 may control any of a number of vehicle devices and functions, such as controlling movement of a sunroof or moonroof 16, controlling movement of a moonroof shade 18, controlling activation of one or more lighting devices such as interior map/reading and dome lights 30, and various other devices and functions. However, it should be appreciated that the proximity switches 22 may be located elsewhere on the vehicle 10, such as in the dash panel, on other consoles such as a center console, integrated into a touch screen display 14 for a radio or infotainment system such as a navigation and/or audio display, or located elsewhere onboard the vehicle 10 to enable user interfacing, according to various vehicle applications.

The proximity switches 22 are shown and described herein as capacitive switches, according to one embodiment. Each proximity switch 22 includes at least one proximity sensor that provides a sense activation field to sense contact or close proximity (e.g., within one millimeter) of a user in relation to the one or more proximity sensors, such as a swiping motion by a user's finger. Thus, the sense activation field of each proximity switch 22 is a capacitive field in the exemplary embodiment and the user's finger has electrical conductivity and dielectric properties that cause a change or disturbance in the sense activation field as should be evident to those skilled in the art. However, it should also be appreciated by those skilled in the art that additional or alternative types of proximity sensors can be used, such as, but not limited to, inductive sensors, optical sensors, temperatures sensors, resistive sensors, the like, or a combination thereof. Exemplary proximity sensors are described in the Apr. 9, 2009, ATMEL® Touch Sensors Design Guide, 10620 D-AT42-04/09, the entire reference hereby being incorporated herein by reference.

The proximity switches 22 shown in FIGS. 1 and 2 each provide control of a vehicle component or device or provide a designated control function. One or more of the proximity switches 22 may be dedicated to controlling movement of a sunroof or moonroof 16 to cause the moonroof 16 to move in an open or closed direction, tilt the moonroof, or stop movement of the moonroof based upon a control algorithm. One or more other proximity switches 22 may be dedicated to controlling movement of a moonroof shade 18 between open and closed positions. Each of the moonroof 16 and shade 18 may be actuated by an electric motor in response to actuation of the corresponding proximity switch 22. Other proximity switches 22 may be dedicated to controlling other devices, such as turning an interior map/reading light 30 on, turning an interior map/reading light 30 off, turning a dome lamp on or off, unlocking a trunk, opening a rear hatch, or defeating a door light switch. Additional controls via the proximity switches 22 may include actuating door power windows up and down. Various other vehicle controls may be controlled by way of the proximity switches 22 described herein.

Referring to FIG. 3, a portion of the proximity switch assembly 20 is illustrated having an array of three serially arranged proximity switches 22 in close relation to one another in relation to a user's finger 34 during use of the switch assembly 20. Each proximity switch 22 includes one or more proximity sensors 24 for generating a sense activation field. According to one embodiment, each of the proximity sensors 24 may be formed by printing conductive ink onto the top surface of the polymeric overhead console 12. One example of a printed ink proximity sensor 24 is shown in FIG. 4 generally having a drive electrode 26 and a receive electrode 28 each having interdigitated fingers for generating a capacitive field 32. It should be appreciated that each of the proximity sensors 24 may be otherwise formed such as by assembling a preformed conductive circuit trace onto a substrate according to other embodiments. The drive electrode 26 receives square wave drive pulses applied at voltage V_I. The receive electrode 28 has an output for generating an output voltage V_O. It should be appreciated that the electrodes 26 and 28 may be arranged in various other configurations for generating the capacitive field as the activation field 32.

In the embodiment shown and described herein, the drive electrode 26 of each proximity sensor 24 is applied with voltage input V_I as square wave pulses having a charge pulse cycle sufficient to charge the receive electrode 28 to a desired voltage. The receive electrode 28 thereby serves as a measurement electrode. In the embodiment shown, adjacent sense activation fields 32 generated by adjacent proximity switches 22 overlap slightly, however, overlap may not exist according to other embodiments. When a user or operator, such as the user's finger 34, enters an activation field 32, the proximity switch assembly 20 detects the disturbance caused by the finger 34 to the activation field 32 and determines whether the disturbance is sufficient to activate the corresponding proximity switch 22. The disturbance of the activation field 32 is detected by processing the charge pulse signal associated with the corresponding signal channel. The determination of whether the disturbance is sufficient to activate a switch may include comparing a sensed signal generated in response to the activation field to one or more threshold values, threshold rates, or other known switch activation detection techniques. Additionally, the disturbance to the activation field may be processed to determine whether a user is hunting or exploring the switches or performing a swipe or other gesture as an input. When the user's finger 34 contacts two activation fields 32, the proximity switch assembly 20 detects the disturbance of both contacted activation fields 32 via separate signal channels. Each proximity switch 22 has its own dedicated signal channel generating charge pulse counts which is processed.

Referring to FIG. 5, the proximity switch assembly 20 is illustrated according to one embodiment. A plurality of proximity sensors 24 are shown providing inputs to a controller 40, such as a microcontroller. The controller 40 may include control circuitry, such as a microprocessor 42 and memory 48. The control circuitry may include sense control circuitry processing the activation field of each sensor 22 to sense user activation of the corresponding switch by comparing the activation field generated signal to one or more thresholds and/or rate values pursuant to one or more control routines. It should be appreciated that other analog and/or digital control circuitry may be employed to process each activation field, determine user activation, and initiate an action. The controller 40 may employ a QMatrix acquisition method available by ATMEL®, according to one embodiment. The ATMEL acquisition method employs a WINDOWS® host C/C++ compiler and debugger WinAVR to simplify development and testing the utility Hawkeye that allows monitoring in real-time the internal state of critical variables in the software as well as collecting logs of data for post-processing.

The controller 40 provides an output signal to one or more devices that are configured to perform dedicated actions responsive to correct activation of a proximity switch. For example, the one or more devices may include a moonroof 16 having a motor to move the moonroof panel between open and closed and tilt positions, a moonroof shade 18 that moves between open and closed positions, and lighting devices 30 that may be turned on and off. Other devices may be controlled such as a radio for performing on and off functions, volume control, scanning, and other types of devices for performing other dedicated functions. One of the proximity switches 22 may be dedicated to actuating the moonroof closed, another proximity switch 22 may be dedicated to actuating the moonroof open, and a further switch 22 may be dedicated to actuating the moonroof to a tilt position, all of which would cause a motor to move the moonroof to a desired position. The moonroof shade 18 may be opened in response to one proximity switch 22 and may be closed responsive to another proximity switch 22.

The controller 40 is further shown having an analog to digital (A/D) comparator 44 coupled to the microprocessor 42. The A/D comparator 44 receives the voltage output V_O from each of the proximity switches 22, converts the analog signal to a digital signal, and provides the digital signal to the microprocessor 42. Additionally, controller 40 includes a pulse counter 46 coupled to the microprocessor 42. The pulse counter 46 counts the charge signal pulses that are applied to each drive electrode of each proximity sensor, performs a count of the pulses needed to charge the capacitor until the voltage output V_O reaches a predetermined voltage, and provides the count to the microprocessor 42. The pulse count is indicative of the change in capacitance of the corresponding capacitive sensor. The controller 40 is further shown communicating with a pulse width modulated drive buffer 15. The controller 40 provides a pulse width modulated signal to the pulse width modulated drive buffer 15 to generate a square wave pulse train V_I which is applied to each drive electrode of each proximity sensor/switch 22. The controller 40 processes one or more control routines 100 stored in memory to monitor and make a determination as to activation of one of the proximity switches. The control routines 100 may include a routine for executing a method of activating the proximity switches using known detection techniques such as comparing the generated signals to one or more threshold values, and/or threshold rates.

The proximity switch assembly 20 may generate a change in sensor charge pulse counts, also referred to as Δ sensor counts, for a plurality of signal channels associated with a plurality of proximity switches. The change in sensor charge pulse count is the difference between an initialized reference count value without any finger or other object present in the activation field and the corresponding sensor reading. When a user's finger is in contact with or close proximity of a sensor 24, the finger alters the capacitance measured at the corresponding sensor 24. The capacitance is in parallel to the untouched sensor pad parasitic capacitance, and as such, measures as an offset. The user or operator induced capacitance is proportional to the user's finger or other body part dielectric constant, the surface exposed to the capacitive pad, and is inversely proportional to the distance of the user's limb to the switch button. According to one embodiment, each sensor is excited with a train of voltage pulses via pulse width modulation (PWM) electronics until the sensor is charged up to a set voltage potential. Such an acquisition method charges the receive electrode 28 to a known voltage potential. The cycle is repeated until the voltage across the measurement capacitor reaches a predetermined voltage. Placing a user's finger on the touch surface of the switch 24 introduces external capacitance that increases the amount of charge transferred each cycle, thereby reducing the total number of cycles required for the measurement capacitance to reach the predetermined voltage. The user's finger causes the change in sensor charge pulse count to increase since this value is based on the initialized reference count minus the sensor reading. It should be appreciated that other sensor acquisition and detection techniques may be employed in other proximity sensor interfaces.

The proximity sensor interface may employ any of a number of known techniques for monitoring a sensed signal in response to one or more proximity sensors and detecting activation of a switch. One example of a proximity monitoring and determination technique is disclosed in U.S. patent application Ser. No. 13/721,886 filed on Dec. 20, 2012 entitled “PROXIMITY SWITCH ASSEMBLY AND ACTIVATION METHOD USING RATE MONITORING,” which discloses the use of thresholds and a rate monitoring routine to determine valid switch activations. The aforementioned patent application is hereby incorporated herein by reference. It should be appreciated that other sensor monitoring and activation determining techniques may be employed in the proximity sensor interface that is simulated and analyzed for testing by the development system disclosed herein.

A proximity sensor interface development system is employed to test and help develop proximity interface sensors, such as the proximity switch assembly 20 and other proximity sensor interfaces that include proximity and/or gesture recognition interfaces. During the development of such sensor interfaces, it is frequently necessary to modify or write new software applications to eliminate or compensate for potential failures and other limitations. For example, changes made to the software such as changing a tuning parameter like the threshold value used to determine switch activation, or such as changing sensitivity of one or more sensors, or such as adding new modules like a routine to compensate for condensation, would typically require performing a full set of environmental tests as well as a full-blown customer clinic to properly test the newly programmed assembly. The present proximity sensor interface development system advantageously enables the testing and assisted development of proximity sensor interfaces with new software or changes to software in a manner that significantly reduces the expense and time to confirm proper operation and optimal performance without requiring time consuming repeated environmental testing and customer clinics.

The proximity interface development system collects or receives a data log which may be acquired from a full set of environmental tests and/or a customer clinic typically employing many potential operators that may activate the various proximity switches by pressing on switches, perform certain gestures, and perform various other user input proximity sensor interface actions. These data logs may be acquired by employing the proximity switch assembly 20 shown in FIGS. 1-5, according to one example. In doing so, the proximity switch assembly 20 may be installed within a vehicle as shown in FIG. 1, or may be installed within an environmental testing chamber in which environmental conditions, such as temperature, humidity and other factors may be controlled and varied. A data logger 50 may be coupled to the proximity switch assembly 20 as shown in FIGS. 2 and 5 during the customer clinic to record the data used to generate the data log. The data log stored within data logger 50 may include typical activation data as sensed by the various sensors of the assembly 20 while various operators interface with the proximity switch assembly 20. The data collected may include unprocessed hardware sensor outputs and the time stamp. During the test, certain software routines are executed by the proximity switches. The data log records the various sensor inputs and employs the data for use in testing changes to the software or alternative software such that the full-blown customer clinic need not be repeated each time a software change is made to the proximity switch assembly.

Referring to FIG. 6, the proximity interface development system 60 is illustrated, according to one embodiment. The proximity interface development system 60 includes a development tool 62 having a microprocessor 64 and memory 66. The development tool 62 may include a dedicated processing machine capable of processing proximity sensor interface software routines and the data log to replicate operation of the software on a proximity sensor interface and to analyze the data generated during the replication to provide performance outputs. The development tool 62 may include a computer programmed to perform the functionality, as described herein, according to one embodiment.

The proximity interface development system 60 receives one or more data logs from input 74 and stores the data log in data log storage 68 of memory 66. Additionally, a plurality of control routines 72A-72I may be stored in memory 66. The control routines 72A-72I are software routines that are designed to operate a proximity sensor interface, such as a proximity switch assembly but include a wrapper to process data without the proximity switch hardware. The software routines 72A-72I may be the same software configured to operate on a proximity switch assembly and may include additional code to enable execution without the hardware. Variations of the software of control routines 72A-72I may include changes to the software or alternative software that may be stored in memory 66 and processed by the development tool 62. The development tool 62 receives various other inputs 76 including alternative control routines 82 which may include changes to the software programs which are intended to be tested by the proximity interface development system 60. Other inputs include parameter configurations to test 84 such as threshold values, calibration rate values, rate monitoring threshold, signature ratios, number of active channels, time period required for a stable signal, ranges for stable signal, and other parameters. Further inputs include sensor value scaling matrixes 86 which may include multiplication factors to tune or adjust sensitivities of sensors. The development tool 62 generates outputs 78 which include configuration/performance charts such as the percent successfully recognized intended activations, percent triggered inadvertent activations, type of activations, type of not recognized activations, score rating data, and other performance data.

The proximity interface development system 60 includes a replicator 70, shown stored in memory 66 and executed by microprocessor 64. The replicator 70 replicates or simulates the proximity sensor interface based on the control routines, including software changes and alternative control routines, and determines outputs of the proximity sensor interface that are analyzed to determine proper or optimal operation of the software as it is expected to operate on the proximity sensor interface. The replicator 70 processes the data log generated during environmental testing, such as data acquired in a customer clinic, through the actual source code used in the production unit of the proximity sensor interface without the need for physical hardware associated with the interface. The replicator 70 processes inputs which include the capacitive sensor readings from the data log and generates outputs which include triggering decisions, such as whether or not a user intends to activate a switch. The software used in the replicator 70 may be identical to the production code used in the proximity sensor interface, such that the output from the replicator 70 would match the data presented in the data log for the identical software control routine. When a change is made to the software code, such as the addition of a new module or the tuning of a parameter, the replicator output generated by the proximity interface development system predicts with certainty what would occur in the actual production part using the new software code, as if the test were actually performed using the actual hardware in an environmental chamber and/or using customer clinics. By using the replicator 70, the effect of any software code changes can be tested on a previously collected data log in almost no time.

The proximity interface development system 60 further includes an analyzer 80 shown stored in memory 66 and executable by microprocessor 64. The analyzer 80 post-processes the data generated by the replicator 70 to determine whether intended activations of proximity switches were missed (e.g., the operator attempted to activate a switch to open the roof, but nothing happened), or unwanted activations were triggered (e.g., the operator was moving the hand close to the interface reaching for the overhead glasses compartment and a switch was inadvertently triggered). When a large number of customer data samples are collected, hand processing the data is time-consuming and prone to error. The analyzer 80 automatically processes the data output from the replicator 70 in a manner that is accurate and much less time-consuming.

Referring to FIGS. 7-12, a control routine 100 with wrapper used by the replicator 70 is illustrated, according to one embodiment. Routine 100 begins at step 102 and proceeds to step 104 to initialize hardware state variables to compensate for hardware associated with the proximity sensor interface but not implemented during testing with the development system. The control routine 100 is software code that may include an exact replica of the software running on the actual production hardware components, with embedded extra code in the form of the software analyzer to provide additional information about the system behavior. The control routine 100 is processed with various inputs such as sensor values including raw channel signals from the data log, parameter values to be tested including thresholds, and rate values, and scaling matrixes. The control routine 100 software generates outputs based on the data log as if it would have been generated if running a test on the production part, and additionally generates salient parameters and event logs.

Routine 100 includes step 106 which sets the control routine parameters values as required, such as, for example, setting a threshold equal to threshold i. This sets the new values of the control routine parameters that will be tested for performance, such as, for example, what would happen if a threshold is lowered or if a calibration rate is increased. Next, at decision step 108, routine 100 determines if there is more than one raw channel set equal to zero. If more than one raw sensor value is set equal to zero in the data log, this means that a reset occurred in the hardware as the data log was collected. When this happens, the hardware state variables are reinitialized. Next, at step 112, routine 100 scales the raw values to simulate increased/decreased sensitivity by multiplying the raw channel signal by scaling matrix S[ ]. In one embodiment, the scaling matrix may be linear. However, it should be appreciated that the scaling matrix may be a negative exponential or logarithmic value or may otherwise be defined by another function or equation. By adjusting the scaling matrix, a multiplier may be used to simulate a change in software such as a change in sensor sensitivity and the effect thereof on the proximity sensor interface may be tested by the development system.

Proceeding to step 114, routine 100 runs the control routine i code which is a copy of the actual code that is run on the production sensor interface assembly. The control routine is executed with inputs which include a sensor value, such as a raw channel scaled value, and outputs such as the switch active state. As such, the software code may be executed and tested without hardware, while providing the same outputs as if the code had been run on the actual production assembly. Routine 100 then proceeds to step 116 to extract salient parameters such as maximum signal channels, noise and signal range, maximum rate, second maximum channel, the number of active channels above an active threshold, ratio (max/sum) maximum ratio, maximum peak of other parameters Thus, key events and parameters are extracted, which may be used as inputs to the analyzer. Next, at step 118, the code running on the replicator outputs the processed information on the processed data log on a dedicated interface. This module sends the log directly to a file, which is used as an input to the analyzer. At step 120, routine 100 outputs the salient parameter/event log which contains processed information regarding the signal, such as the maximum signal during an event, signal range, etc. Next, at decision step 122, routine 100 determines if the input from the data log is complete processed (done) and, if so, ends at step 124. Otherwise, routine 100 returns to step 108.

Referring to FIG. 8, the extract salient features subroutine of step 116 is further illustrated beginning at step 130 and proceeding to perform an event update at step 132. The event update step 132 is shown and described in connection with a subroutine shown in FIG. 9. Following the event update, routine 116 proceeds to decision step 134 to determine if a signal channel was active previously and, if not, proceeds to decision step 136. At decision step 136, routine 116 determines if there is a new maximum channel and, if so, processes the new maximum channel at step 130 before ending at step 140. If there is not a new maximum channel, routine 116 proceeds to decision step 142 to determine if the maximum channel was activated and, if so, enters the event for the maximum channel activated the step 144 before ending at step 140. If a channel was determined in step 134 to be active previously, routine 116 proceeds to decision step 146 to determine if the channel was released and, if not, ends at step 140. If the channel was released, routine 116 enters the event for the current channel release at step 148, and then proceeds to step 150 to set the next event initialization before ending at step 140.

The event update subroutine 132 is illustrated in FIG. 9, beginning at step 154 and proceeding to step 156 to find the largest signal (max_channel), and then to step 158 to find the second largest signal (second_max_channel). Next, routine 132 proceeds to decision step 160 to determine if the maximum channel is greater than a threshold noise and, if so, sets a ratio equal to the maximum channel divided by the sum channel at step 162. The sum channel is a summation of all signal channels associated with the proximity sensor interface. Thereafter, routine 132 proceeds to step 164 to update the maximum observed ratio with the current ratio value if this is greater than the current maximum observed ratio. Next, at step 166, the maximum observed max_ch is updated with the current max_ch if this is greater. Thereafter, at step 168, the maximum observed second largest channel is updated with the current second largest channel if this is greater. Routine 132 then proceeds to decision step 170 to determine if the peak maximum channel is greater than the maximum peak maximum channel and, if so, proceeds to step 172 to set the maximum peak maximum channel equal to peak maximum channel and to set the maximum peak sum channel equal to the peak sum channel. Following step 172 or the negative decision of step 170, routine 132 proceeds to step 174 to set the maximum number (N) of active channels equal to the maximum max_number of active channel (N_active_ch). Thereafter, at step 176, the maximum observed rate is set equal to the current rate if this is greater. The maximum observed noise is then compared to the current noise and the maximum noise is set equal to the current noise if this is greater at step 178 before ending at step 180. If the maximum channel is not greater than the noise threshold in decision step 160, routine 130 proceeds directly to step 178 to update the maximum observed noise before ending at step 180.

The event initialization subroutine 150 is illustrated in FIG. 10. Routine 150 begins at step 184 and proceeds to step 186 to set the maximum second maximum channel equal to the lowest integer available for that variable, to set the maximum ratio equal to the lowest integer available for that variable, to set the maximum peak maximum channel equal to the lowest integer available for that variable and to set the maximum peak sum channel equal to the lowest integer. The event detected is then set equal to none at step 188. Next, routine 150 proceeds to step 190 to reset all timers and to reset all flags before ending at step 192.

The subroutine 156 defining the second largest signal (second max channel) is illustrated in FIG. 11 beginning at step 200 and proceeding to step 202 to set the second maximum channel equal to the lowest integer. Next, routine 156 proceeds to decision step 204 to determine if the channel is the max channel and, if so, proceeds to decision step 210 to determine if all channels are scanned and, if so, stores the information in the event log at step 212 before ending at step 214. If all channels are not scanned as determined by decision step 210, routine 156 returns to step 204. At step 204, if the current channel is not the max channel, routine 156 proceeds to decision block 206 to determine if the channel is greater than the second maximum channel and, if so, sets the second maximum channel equal to the current channel at step 208, before proceeding to decision step 210. If the current channel is not greater than the next channel in decision step 206, routine 156 jumps forward to decision step 210.

The process new max channel subroutine 138 is shown in FIG. 12 beginning at step 220 and proceeding to decision step 222 to determine if the previous channel was greater than the threshold noise and, if not, ends at step 232. If the previous channel was greater than the threshold noise, routine 138 proceeds to decision step 224 to determine if the new channel is active, which may be determined by a new channel being greater than a threshold active value. If the new channel is not active, routine 138 proceeds to set the event equal to activation aborted at step 228 and to set the next event initialization at step 230 before ending at step 232. If the new channel was determined to be active at step 224, routine 138 sets the event to event hunting at step 226 before proceeding to step 230.

The software replicator may be implemented as an activation detection module as an exact replica of the software running on the actual production hardware component. The replicator may be embedded with additional software code referred to as the software analyzer to provide information to a developer about the system behavior. As a comprehensive customer clinic is run on a hardware implementation, the full sensor signal log is collected and the data log can be used as an input to the software replicator, implemented using the same source code running on the actual hardware sensor interface module. Parameters in the software can quickly be changed as needed and tested in the replicator. The activation log is collected and matched against the desired outcome, using the difference (Δ) between desired and actual activations in addition to the number of unintended activations as two quality metrics. Additionally, the sensor data log can be preprocessed through a signal amplifier to simulate boards with higher or lower sensitivity, sensor boards with more or less cross-talk between channels, or sensor boards with the same layout but with redesigned individual switches having either different pad sizes or templates. The activation detection in the software replicator processes the modified data log to predict what the effect of these changes would be on the physical hardware, such that a full clinic's worth of data can be quickly processed. A proper sensor pad design can be quickly selected, the software parameters optimally tuned, and the robustness of the proximity sensor interface to manufacturing variability quickly accessed.

In lieu of using collected sensor log data, the actual operator hand posture log data may be fed into a software model of the actual hardware module to generate the data log, according to another embodiment. Thus, software model may predict what the sensor response would be. The hand motion log can be collected from an actual clinic or generated using one of the available human modeling packages.

The replicator routine 300 is illustrated in FIGS. 13-16, according to one embodiment. Referring to FIG. 13, the replicator routine 300 begins at step 302 and proceeds to step 304 to parse the configuration file. Next, at step 306, routine 300 acquires the signal scaling matrix S[ ], and proceeds to step 308 to acquire a list of data logs to process, such as data log 0, data log 1, data log i. The inputs to the replicator may be sent as a template text file, such as a set of instructions, and steps 304, 306 and 308 are utilized to parse through these files. It should be appreciated that various inputs are provided to the replicator including a configuration to analyze the data logs. The configuration to analyze may include control routines to be tested, parameter configurations to test such as, for example, thresholds and calibration rates, and sensor value scaling matrixes such as a scaling matrix to multiple sensor raw values from the data log.

The replicator routine 300 parses the sensor values at step 310. The data log may contain information that is not relevant to the replicator and, as such, this routine may identify which data is the raw sensor value data to use as an input to the replicator. Next, at step 312, routine 300 performs the wrapper control routine. In doing so, the raw sensor values from the data log are sent to the control routine. The routine has a wrapper that performs tasks that would otherwise be done by hardware modules in the production assembly. Thus, the wrapper serves as an interface to replace lines of code that are hardware dependent with code that is hardware independent. Next, routine 300 proceeds to save the output logs from the control routine at step 314. Two output logs may be saved to storage including a processed data log which is the data log as it would have been generated if running a test on a production sensor interface assembly, and a salient parameters/events log. Thereafter, routine 300 proceeds to decision step 316 to determine if there are any data logs left and, if so, returns to step 310. Otherwise, routine 300 ends at step 318.

The parse parameter configuration file subroutine 304 is illustrated in FIG. 14. The parameter configuration file to initialize the replicator may be sent as a text file which ensures the replicator can be used as a separate tool. The text file may be parsed to acquire the list of parameters and their respective values. Beginning at step 320, routine 304 proceeds to step 322 to acquire a tag, and then to step 324 to match the tag with a database of tunable parameters. A tag is specific parameter identifier associated with a list of parameter values. Routine 304 determines at decision step 326 if a match was successful and, if so, proceeds to step 328 to acquire a tuning value. Next, at decision step 330, routine 304 determines if the tuning value is within a valid range and, if so, adds the matched parameter to a list of parameters to be tuned at step 322. If the match was not successful or if the tuning level is not within the valid range, routine 304 proceeds directly to decision step 334. At decision step 334, routine 304 determines if more tags are to be processed and, if so, returns to step 322. Otherwise, routine 304 ends at step 336.

The acquire list of data logs to process subroutine 308 is illustrated in FIG. 15. The list of data log to be processed by the replicator may be sent as a text file which also ensures the replicator can be used as a separate tool, and the text file may be parsed to acquire the list. Routine 308 begins at step 340 and proceeds to step 342 to parse the data log list configuration file and then to step 344 to acquire a tag. At decision step 346, routine 308 determines if the tag is included and, if so, acquires a template and adds the template to include a template list at step 352. If the tag is not included, routine 308 proceeds to decision step 348 to determine if the tag is excluded and, if so, acquires a template and adds a template to exclude the template list at step 350. In any event, routine 308 proceeds to decision step 354 to determine if there are more tags to process and, if so, returns to step 342. If there are no more tags to process, routine 308 proceeds to step 356 to scan the data log folder and then to decision step 358 to determine if the file name i matches any include template and, if so, proceeds to decision step 360. At decision step 360, routine 308 determines if the file name i matches any exclude template and, if not, acquires a template to add the template to the include template list at step 336. In any event, routine 308 proceeds to decision step 364 to determine if there are more files in the folder and, if so, returns to step 358. Otherwise, step 308 ends at step 366.

The parse sensor value from data log subroutine 310 is illustrated in FIG. 16. The data log may contain information not relevant to the replicator, and as such, the routine 310 will identify which data is the raw sensor value data to use as an input to the replicator. Routine 310 begins at step 370 and proceeds to step 372 to, if this is the first time, build a data log parameter list, time stamp, Delta_0, Delta_N, Raw_N, from the data log header. Next, at decision step 374, routine 310 proceeds to determine if the parameter list (i) is set equal to Raw_N and, if so, sets the raw channel i equal to the data log i at step 376. If the parameter list i is not equal to Raw_N, routine 310 proceeds to decision step 378. At decision step 378, routine 310 determines if parsing of the parameter list is completed and, if not, returns to step 374. Otherwise, routine 310 ends at step 380.

Referring to FIGS. 17-20, the analyzer routine 400 is illustrated, according to one embodiment. The analyzer 400 receives inputs including the design of experiment (DOE). The DOE is the design of any information gathering exercise performed in a controlled experiment configuration to analyze and provides outputs including the configuration/performance charts. The inputs may include alternative control routines, the parameter configuration to test such as thresholds and calibration rates, and sensor value scaling matrix S [ ] as a scaling matrix to multiply sensor raw values from the data log and may include other parameters. The outputs may include percentage successfully recognized intended activations, percentage triggered inadvertent activations, and other various possible outputs. The analyzer routine 400 begins at step 402 and proceeds to step 404 to parse the DOE file and then to step 406 to pick the first selection in the DOE table. At step 408, the analyzer routine 400 sets the replicator configuration file and then proceeds to run the replicator at step 410. Following operation of the replicator, the analyzer routine 400 proceeds to analyze the replicator logs at step 412. The output logs from each replicator operation may be analyzed to extract benchmarking information for use in testing and developing the proximity sensor interface.

Following the analysis of the replicator logs, the analyzer routine 400 proceeds to decision step 414 to determine if more selections are left in the DOE table and, if so, picks the next selection in the DOE table and returns to step 408. If more selections are not left in the DOE table, the analyzer routine 400 proceeds to compile the output in step 418 before ending at step 420. The analyzed data of all software configurations may be aggregated into one or more configuration/performance charts. The charts may include compiled and categorized performance data.

The parse DOE file subroutine 404 is illustrated in FIG. 18, beginning at step 422 and proceeding to acquire the tag data at 424 and to match the tag with the database of tunable parameters at step 426. Next, routine 404 proceeds to decision step 428 to see if the match was successful and, if so, acquires tuning values at step 430 and adds parameter and values to the analyzer DOE table at step 432 and proceeds to step 434. If the match was not successful, routine 404 proceeds to step 434. At step 434, routine 404 determines if more tags are to be processed and, if so, returns to step 424. Otherwise, routine 404 ends at step 436.

The analyze event routine 440 is illustrated in FIG. 19, according to one embodiment. The analyze event routine 440 may be implemented as a module that compiles the replicator output logs into a performance chart. In doing so, routine 440 begins at step 442 and proceeds to decision step 444 to determine if the event is an activation aborted event and, if so, increases the activation aborted counter and increases the channel activation aborted counter at step 446 before proceeding to step 458. If the event is not an activation aborted event, routine 440 proceeds to decision step 448 to determine if the event is a hunting event and, if so, increases the hunting event counter and increases the channel hunting event counter at step 450 before proceeding to step 458. If the event is not a hunting event, routine 440 proceeds to decision step 452 to determine if the event is an activation event and, if so, increases the activation counter and increases the channel activation counter at step 454. Thereafter, routine 440 calculates each of the following: the activation detection time, event duration, update ranges, and histograms for activation detection time and event duration at step 456, before proceeding to step 458. If the event is not an activation event, routine 440 proceeds to decision step 460. At step 458, routine 440 sets the update ranges and the histograms for each of the following: the second maximum max channel, the max ratio, the max_peak_max_ch, the max_peak_sum_ch, the max_rate, and the max_noise. Thereafter, routine 440 proceeds to decision step 460 to determine if more events are left and, if so, returns to step 444. Otherwise routine 440 ends at step 462.

An analyze event log routine 500 for a specific proximity switch assembly is illustrated, according to another embodiment. In this embodiment, additional information regarding the control routine is available that can be extracted from the log. This module may be implemented with a specific proximity sensor interface having more specific steps than the prior embodiment. In this embodiment, routine 500 begins at step 502 and proceeds to decision step 504 to determine if the event is an activation aborted event and, if so, proceeds to increase the activation aborted counter and increase the channel activation aborted counter in step 506. Thereafter, at step 508, routine 500 updates the ranges and histograms for each of the following: the max_second_max_channel, max_ratio, max_peak_max_channel, max_peak_sum_channel, max_rate, and max_noise. Thereafter, at decision step 510, routine 500 determines if the max rate is less than a rate threshold and, if so, increases the counter activation aborted due to insufficient rate at step 518. If the max rate is not less than the rate threshold, routine 500 proceeds to decision step 512 to determine if the max ratio is less than a signature threshold or if the max_second_max_channel divided by the max_peak_max_channel is less than a dual channel threshold and, if so, increases the counter activation aborted due to insufficient signature at step 520. If the output of decision block 512 is no, routine 500 proceeds to decision step 514 to determine if the max_noise is less than the noise threshold and, if so, increases the counter activation aborted due to high noise at step 522. Otherwise, routine 500 proceeds to increase the counter activation aborted due to the signal not being stable before proceeding to step 538.

If the event is not an activation aborted event, routine 500 proceeds to decision step 524 to determine if the event is a hunting event and, if so, proceeds to step 526 to increase the hunting event counter, and to increase the channel hunting event counter, and then to step 528 to update the ranges and histograms for each of the following: the max_second_max_channel, max_ratio, max_peak_max_channel, max_peak_sum_channel, max_rate, and max_noise before proceeding to step 538.

If the event is not a hunting event, routine 500 proceeds to decision step 530 to determine if the event is an activation event and, if so, increases the activation counter and increases the channel activation counter at step 532, and then proceeds to step 534 to calculate the activation detection time and event duration. Next, routine 500 proceeds to step 536 to update the ranges and histograms for each of the following: the max_second_max_channel, max_ratio, max_peak max_channel, max_peak_sum_channel, max_rate, max_noise activation time and event duration. Thereafter, method 500 proceeds to decision block 538 to see if there are more events left and, if so, returns to step 504. Otherwise, routine 500 ends at step 540.

To improve responsiveness of a proximity sensor interface and to reduce inadvertent actuations, it is advantageous to know whether the current tuning and setup of the software to be tested would result in a motion event triggering a switch activation event or not, and to further determine its classification, such as a tap or stable press event, a bare hand or a gloved hand event. If an event does not occur, it is further desirable to know whether it was because the operator was exploring the switches or whether the activation was aborted because of a safety lockout or because a triggering motion is deemed too slow or because the channel never reached a stable state due to presence of noise on the signal or because the signature ratio was not sufficient. The software replicator generates information to help understand whether an intended event, such as a moonroof close event was recognized, but not triggered because of suboptimal tuning of the interface or whether the operator had inadvertently triggered the lockout switch, or whether too many intended dome lamp activations were rejected because a humidity compensation mechanism was tuned too aggressively, according to some examples.

The software replicator may record various parameters that provide metrics for the development system to test and determine responsiveness and robustness of the proximity sensor interface. Parameters recorded may include the signal peak during the activation motion and its signature, the number of channels active during the motion, the second largest signal level as the event peaked, the fastest rate of the largest channel, and the duration of the motion event from start to detection and from start to completion. It should be appreciated that the replicator may record various other parameters and combinations of parameters.

Referring to FIG. 21, an example output of the software analyzer is illustrated in which five press events are processed by the software replicator and analyzer. All switch press events were interpreted as stable press events in this example. Each signal channel reached a peak capacitive count in the range of 191 to 324, with a maximum rate in the range of 195 to 325. The data illustrated is data acquired from testing by a single user. It should be appreciated that the user may activate one or more switches in a variety of activation techniques and that a plurality of users may operate the proximity sensor interface during data logging for acquisition and analysis of the data. The data acquired for channels 0-4 during an active stable event include glove wait, wait, max_channel, sum_channel, ratio of sum_channel to max_channel, peak_max, peak_sum, max_ratio, number of channels above activation threshold (N_act_channel), second max_channel, max_channel stable state, rate inhibit, and rate max. It should be appreciated that various other parameters may be acquired, recorded and analyzed by the development system.

Referring to FIG. 22, the output parameters from multiple tests are showed combined in a joint summary chart for multiple subjects, multiple test runs, and tests that are compiled automatically by the analyzer. The analyzer processes the outputs generated by the replicator and produces one or more performance charts indicative of the performance of the proximity sensor interface being tested. The joint summary performance chart in FIG. 22 shows compiled data for each of certain parameters and results for channels ch0-ch7 and assigns a pass and a fail number for each channel and a score indicative of the pass to fail ratio. In the example chart shown, a high failure rate was experienced for signal channels ch0 and ch1 which in a specific example was due to an aggressive rate monitoring algorithm for compensating for hardware condensation events. The software under test in this example includes an aggressive calibration setting which results in the failure of certain channels as determined by the development system without the need to repeat environmental testing with a large user clinic. Thus, software can be modified and tested efficiently and effectively.

Referring to FIG. 23, another simplified report generated by the analyzer is shown for Design Verification (DV) and Product Verification (PV) testing which only records the order in which channels were activated, whether the activation was with a long press or a tap, and the duration of the press. This simplified report can be used to match the activation sequence output to the desired target, the order in which the mechanical fingers activate the switches in the thermal environmental chamber, and determine whether all presses triggered activation or to check for the presence of extra unintended activations triggered by thermal-climatic events.

FIGS. 24-29 illustrate various charts generated during the testing of an overhead console having a capacitive switch assembly. In order to tune the capacitive switch assembly software, the simulator was operated with different threshold values for a rate monitoring algorithm, ranging from no rate monitoring to very aggressive rate monitoring (rate threshold of 0 counts/80 millisecond and 70 counts/80 milliseconds, respectively). More than 100 samples were collected in environmental chambers which had a maximum recorded humidity triggered event rate of around 25 counts/80 milliseconds.

The line 630 in the chart shown in FIG. 24 illustrates the percent of activation error as a function of the rate monitoring threshold for a bare hand activation without gloves. A knee in the data can be seen at a range of 30 counts/80 milliseconds. The minimum rate threshold was therefore set at 30 counts. Activation errors include both intended events not recognized and not exploring motion generating unintended events. Some of the intended events not recognized are the moonroof close and tilt aborted by the safety lockout switches which are not errors.

Next, the setting of the signal level threshold to recognize a valid activation was determined. Using a rate monitoring algorithm, the threshold level could be lowered and tested as shown in the line 604 of FIG. 25 which shows the average percent of activation errors as a function of capacitive level activation threshold for a bare handed interaction. In this example, a knee can be observed in the data at a value of just greater than 120 counts, above which there is a rapid increase in the error percent.

Referring to FIG. 26, the average percent of activation errors as a function of capacitive level threshold for a glove covered hand is illustrated by line 650. A knee is observed in the data at around 100 counts for the gloved interaction, but not as clearly marked as in the case of the bare handed interaction. To finalize a choice for the signal activation level threshold, the robustness of the system as a function of manufacturing variations and sensor sensitivity may be established. The threshold level was initially set at 120 counts and the software simulator ran on the same data set with the capacitive signal amplified to simulate a change in sensitivity ranging from −60% to +60%.

Referring to FIGS. 27 and 28, average percent of activation errors for two overhead console dome lamp switches as a function of decreased/increased sensitivity (expressed in percent) for bare handed interaction shown by line 660 in FIG. 27 and gloved interaction shown by line 670 in FIG. 28 are illustrated. A 20% reduction in sensitivity (−20) from the midrange point (0) is sufficient to double the amount of activation errors in both bare handed and gloved interaction. In this example, a decision was made to set the activation threshold to 80 counts. Thus, even a sensitivity deterioration of 50% (80 to 100 counts) would yield a less than 1% activation error with bare handed interaction and 15% activation error with gloved interaction.

Referring to FIG. 29, four versions of proximity sensor interface software V₁₀-V₁₃ that were tested are compared and scored as a percent of the correct activation are shown output in a chart labeled 680 generated by the analyzer. The development system advantageously was employed to develop the final software release for a proximity sensor interface that compensated for a condensation hardware issue, but also achieve excellent responsiveness and robust noise rejection. It should be appreciated that the software replicator advantageously tested the software using the data log and that the analyzer provided an output score indicative of the performance of the various versions of the software, thus enabling a developer to effectively and efficiently determine the optimal software package.

Accordingly, the proximity interface development system advantageously allows for the testing of various software modifications to a proximity sensor interface, such as a proximity switch assembly. The system efficiently and effectively tests variations in the software without having to duplicate environmental testing with a large pool of users during a clinic. The system further advantageously processes the analyzed data to provide an output for the developer to use and developing the optimal proximity sensor interface.

It is to be understood that variations and modifications can be made on the aforementioned structure without departing from the concepts of the present invention, and further it is to be understood that such concepts are intended to be covered by the following claims unless these claims by their language expressly state otherwise.

Claims

1. A proximity interface development system comprising: one or more software routines developed are stored in a memory to operate a proximity sensor interface having a plurality of proximity sensors;a data logger acquiring proximity sensor data while operating the proximity sensor interface; anda processor configured as a replicator for replicating the proximity sensor interface based on the one or more software routines and generating outputs of the replicated proximity sensor interface based on the proximity sensor data, said processor further generating performance data and further comprising an analyzer for analyzing the outputs of the replicator and generating a report indicative of the performance data of the proximity sensor interface with the one or more software routines.

2. The system of claim 1 further comprising an input for receiving at least one setting to adjust one or more parameters of the proximity sensor interface, wherein the processor processes the at least one setting in combination with the software routines and the proximity sensor data to generate the outputs.

3. The system of claim 2, wherein the at least one setting comprises a scaling factor for setting sensor sensitivity.

4. The system of claim 2, wherein the at least one setting comprises a threshold value.

5. The system of claim 1, wherein the proximity sensor interface comprises a capacitive switch.

6. The system of claim 5, wherein the capacitive switch comprises a proximity sensor, wherein a signal associated with an activation field is processed to determine activation of the proximity sensor.

7. The system of claim 1, wherein the proximity sensor interface is developed for use on a vehicle by a passenger in the vehicle.

8. The system of claim 7, wherein the proximity sensor interface comprises a capacitive switch comprising one or more capacitive sensors.

9. The system of claim 1, wherein the development system comprises a computer having the processor separate from the proximity sensor interface, wherein the computer comprises the memory.