1. Field
The present disclosure relates generally to the detection of hardware malfunctions of user devices, and more particularly to the detection, prediction and correction of hardware lockups of user devices.
2. Background
User devices, such as laptops, smartphones, net books, tablets, etc, may experience hardware lockups and subsequent failures in the lower level software, which causes unpleasant user experience. “Hardware lockup” as used herein refers to situations where a user device enters a hang condition or a power reset condition due to hardware issues. Hardware lockups are distinct from software lockups, wherein device operation may freeze due to software issues.
A “hang” condition refers to a condition where the device is powered up but no longer functioning for reasons related to hardware. For example, a hardware lockup of a video module may cause the device display to freeze during playback of a video. More specifically, a hang of the video module may result in a subsequent failure in the lower level video playback software leading to the screen freeze. If the user leaves the device as it is when the situation happens, the device will not reset, nor will the device come out of the situation by itself. In this case, the user may have to remove the device battery or push a device button long enough to cause a power reset. If left untouched, the device will remain in a hang condition indefinitely or until the battery is completely discharged.
A “power reset” condition refers to a condition wherein a power management module of a user device determines to initiate a power reset of the user device. For example, the power management module may detect an abnormal condition, such as an insufficient current supply to a hardware component. Upon detection of the condition, the power management module may cause a trip in the power circuitry of the user device to thereby reset the entire user device by turning the user device off and then back on.
Existing user devices suffer from inefficient use of hardware resources. For example, if one hardware module is the source of the lockup, the entire circuitry is reset for recovery.
In an aspect of the disclosure, a method, a computer program product, and an apparatus are provided. An apparatus, e.g., user device, has a plurality of modules for implementing one or more use cases. The user device maps one or more sensor outputs to a use case based on sensor outputs obtained during a hang/reset state of the user device during the use case. Each of the one or more sensor outputs is associated with one of the plurality of modules. The user device also maps one or more actions to each sensor output mapped to the use case. The one or more actions affect a change in an operating parameter of a module associated with the sensor output mapped to the use case during a hang/rest state of the user device during the use case. The one or more actions also affect a corresponding change in the sensor output mapped to the use case.
The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known structures and components are shown in block diagram form in order to avoid obscuring such concepts.
Several aspects of detecting, predicting and correcting hardware lockups of user devices are presented below with reference to various apparatuses and methods. These apparatuses and methods are described in the following detailed description and illustrated in the accompanying drawings by various blocks, modules, components, circuits, steps, processes, algorithms, etc. (collectively referred to as “elements”). These elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.
By way of example, an element, or any portion of an element, or any combination of elements may be implemented with a “processing system” that includes one or more processors. Examples of processors include microprocessors, microcontrollers, digital signal processors (DSPs), field programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functionality described throughout this disclosure. One or more processors in the processing system may execute software. Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise.
Accordingly, in one or more exemplary embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or encoded as one or more instructions or code on a computer-readable medium. Computer-readable media includes computer storage media. Storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer.
The user device 100 may include various hardware components or modules supporting various functionalities or use cases of the device. For example, a multimedia content player function 102 may rely on one or more audio modules 104, such as DSP module, Low Power Audio module, SLIM Bus interface, and one or more video modules 106, such as Video Core, Venus Video driver, Shared Memory manager. A graphics rendering function 108 may rely on one or more video modules 110, such as Adreno Graphics Core, VBIF interface module, and one or more graphics processors 112. A communication/call function 114 may rely on one or more audio modules 116, one or more video modules 118 and one or more data modules 120. A browser function 122 may rely on one or more modules 124, 126, such as a network operations center (NOC) module, a central processing unit, e.g. KRAIT processor, an Adreno Graphics Processor.
The user device 100 also includes operation modules 128, 130, that provide operation parameters to the functional modules 104, 106, 110, 112, 116, 118, 120, 124, 126. The operational modules may include one or more supply modules 128 that supply voltages to the functional modules 104, 106, 110, 112, 116, 118, 120, 124, 126, and one or more clocks 130 that supply clock signals to the functional modules. One or more busses 132 interconnect the various functional and operation modules.
In accordance with embodiments disclosed herein, the user device 100 includes various sensors 134 located at various points of interest of the device, and an error handler 136 configured to collect, process and validate information related to lockups of hardware modules of the device, and to predict potential lockups and take corrective actions to avoid such lockups. In one implementation, voltage sensors S1, S3, S5, S7, S9, 511, S13, S15 and S17 may be located on a printed circuit board of the device at locations corresponding to an input point where a functional module 104, 106, 110, 112, 116, 118, 120, 124, 126 receives its power. These sensors 134 may be configured to sense the voltage being supplied to the modules and to provide a measure of the voltage to the bus 132. In another implementation, clock sensors S2, S4, S6, S8, S10, S12, S14, S16 and S18 may be located on a printed circuit board of the device at locations corresponding to an input point where a functional module 104, 106, 110, 112, 116, 118, 120, 124, 126 receives its clock signal. These sensors 134 may be an edge/level detect sensor configured to detect the physical characteristics, e.g. amplitude, of the clock input signal being supplied to the module.
In one aspect, the user device 100 is configured to collect and process sensor outputs 146 to build a database of knowledge related to the operational conditions of the device during hardware lockups of the device. To this end, the error handler 136 includes a hang/reset detector/predictor 138. The hang/reset detector/predictor 138 may be included as part of the software operating system of the device 100. For example, the hang/reset detector/predictor 138 may be a software module of a high level operating system, such as Windows Phone, Linux, Android, MeeGo, Chrome, RIM QNX, BREW MP and Apple's iOS.
The hang/reset detector/predictor 138 is configured to detect for either of a hang condition or a power reset condition. These conditions may be detected using any of several known methods such as: invocation of panic handler, invocation of HW reset module, or invocation of corruption handler. This may be done using the sensors/detectors strategically placed on all the points on the printed circuit board surface, buses and hardware pin points, where internal modules will be powered from. Whenever the software/operating system detects a hang/device shut down or error condition, a complete dump of these sensor outputs 146 is taken by the error handler 136 and stored in a database 144.
The hang/reset detector/predictor 138 is also configured to predict a potential hang/reset. To this end, the hang/reset detector/predictor 138 may obtain sensor outputs 146 corresponding to the use case of the device at a particular time. The sensor outputs 146 may be compared to corresponding information in the database 144. For example, the sensor outputs 146 may be compared to expected sensor outputs during normal operation, of the device during the particular use case. If the difference is greater than a threshold value, the hang/reset detector/predictor 138 may conclude that a hang/reset may occur. Alternatively, the difference between the sensor output and the expected sensor output may be determined and compared to a vector weight of the sensor output. If the difference is within a threshold value of the vector weight, the hang/reset detector/predictor 138 may conclude that a hang/reset may occur.
The error handler 136 also includes a sensor drive manager 140. The sensor drive manager 140 may be included as part of the software operating system of the device 100. The sensor drive manager 140 is configured to trigger one or more of the sensors 134 to provide sensor outputs 146 corresponding to the operation parameter, e.g., supply voltage, clock signal, being sensed by the sensor. Such triggering may be in response to a detection of a hang or power set by the hang/reset detector 138 or may be periodic during normal operation of the device. Upon being triggered, the one or more sensors 134 provide sensor outputs 146 to the sensor drive manager 140 over the bus 132. In one implementation, the sensor drive manager 140 triggers outputs from all sensors 134; thus providing a data dump of sensor outputs 146 from all available sensors 134. In other implementations, the sensor drive manager 140 may trigger a subset of sensors 134 to provide sensor outputs 146. For example, depending on the function being performed, i.e., the use case, of the device at the time of hang/reset, the sensor drive manger 140 may only trigger sensor outputs 146 from those sensors 134 associated with functional modules 104, 106, 110, 112, 116, 118, 120, 124, 126 that implement the use case.
The error handler 136 may also include a use case mapper 142. The use case mapper 142 may be included as part of the software operating system of the device 100. The use case mapper 142 is configured to determine the use case the device 100 is in at the time of the detected hang/reset, and to associate or map one or more of the sensor outputs 146 obtained as a result of the hang/reset with the determined use case. Software of the use case mapper 142 determines the use case of the device using the code path execution for a given module. If a code snippet is being executed using the assembly instructions based on the physical address of the instruction cache, the module knows where the control is. This physical address information may be analyzed with respect to the executable and linkable format (ELF) image or SW image that is flashed on the device. Together they provide accurate use case information from the software that is tracking the use cases. The use case mapper 142 provides the use case information and corresponding sensor outputs 146 to a database 144.
Use cases may be, for example, a communication/call use, e.g., audio call, video call, data call, performed by communication/call 114 modules; a browser use performed by browser 122 modules; a multimedia-content-play use performed by player 102 modules, or a graphics-rendering use performed by graphics rendering 108 modules. Examples of specific use cases include:
Voice call over 4G live network @ −85 dBm
4G Standby
4G+WIFI+BT standby
4G Talk with BT
Email Sync over 4G
3G Standby
3G+WIFI+BT standby
SMS Receive
Email Sync over 3G
Email Sync over WiFi
Voice call over 3G live network @ −85 dBm
5 MB File Upload over 3G live network @ −85 dBm
5 MB File Download over 3G live network @ −85 dBm
Background data sync over 3G live network @ −85 dBm
10 KB Email Send over 3G
Email Compose at 1 char per 500 msec in 3G mode
MP3 @ 44.1 kHz 128 kbps Stereo in 3G mode
Audio Streaming MP3 @ 44.1 kHz 128 kbps Stereo over 3G
1080p H.264 20 Mbps AAC+ Video Playback in 3G mode
720p H.264 2.3 Mbps AAC+Video Streaming over Wi-Fi in 3G mode
1080p 20 Mbps H264 AAC+30 fps Video encode in 3G mode
Camera Snapshot @ Max supported resolution in 3G mode
HQ Video call (Skype) over Wi-Fi in 3G mode
Static image display in 3G mode
Powerlift Scene6 30 fps in 3G mode
Egypt Scene57 30 fps in 3G mode
Browser (30 sec refresh rate) over 3G live network @ −85 dBm
Browser (30 sec refresh rate) over Wi-Fi in 3G mode
Address look-up using Maps over 3G live network @ −85 dBm
Scroll 10 pages/scroll every 10 sec in 3G mode
Voice Search over 3G live network @ −85 dBm
5 MB File Upload over 4G live network @ −85 dBm
5 MB File Download over 4G live network @ −85 dBm
Background data sync over 4G live network @ −85 dBm
10 KB Email Send over 4G
Email Compose at 1 char per 500 msec in 4G mode
MP3 @ 44.1 kHz 128 kbps Stereo in 4G mode
Audio Streaming MP3 @ 44.1 kHz 128 kbps Stereo over 4G
1080p H.264 20 Mbps AAC+Video Playback in 4G mode
720p H.264 2.3 Mbps AAC+Video Streaming over Wi-Fi in 4G mode
1080p 20 Mbps H264 AAC+30 fps Video encode in 4G mode
Camera Snapshot 30 fps @ Max supported resolution in 4G mode
HQ Video call (Skype) over Wi-Fi in 4G mode
Static image display in 4G mode
Powerlift Scene6 30 fps in 4G mode
Egypt Scene57 30 fps in 4G mode
Browser (30 sec refresh rate) over 4G live network @ −85 dBm
Browser (30 sec refresh rate) over Wi-Fi in 4G mode
Address look-up using Maps over 4G live network @ −85 dBm
Scroll 10 pages/scroll every 10 sec in 4G mode
Voice Search over 4G live network @ −85 dBm
3G Talk with BT
5 MB File Download over 3G live network @ −85 dBm in W+G mode
The use case mapper 142 may determine the most relevant sensor outputs 146 for a use case and map those sensor outputs to the use case. For example, upon a hang/rest during a particular use case, the use case mapper 142 may obtain sensor outputs 146 from all sensors 134 and compare these sensor outputs to baseline sensor outputs previously obtained during normal operation of the device. These baseline sensor outputs 146 may be stored in the database 144. For each obtained sensor output, the use case mapper 142 may assign a weight to the sensor output based on the difference between the baseline sensor output and the hang/reset sensor output, wherein larger weights are assigned to sensor outputs 146 having larger differences between baseline and hang/reset outputs. In one configuration, the weight corresponds to a vector difference between baseline and hang/reset outputs. For each sensor output, the use case mapper 142 may assign a rank based on the weight of the sensor output relative to the weights of other sensor outputs 146, wherein sensors are ranked in order from highest to lowest based on corresponding largest to smallest weight.
Overtime, the use case mapper 142 may identify those sensor outputs 146 most affected during a use case hang/reset. Such identification may be based on previously determines weights and ranks of sensor outputs 146. For example, those sensor outputs 146 having a weight above a threshold value for a specific use case hang/rest may be identified as relevant sensor outputs for the use case. A mapping of these identified sensor outputs 146 to the specific use case is maintained in the database 144.
During a subsequent hang/reset during a specific use case, the use case mapper 142 may trigger sensor outputs 146 only for those sensor outputs mapped to the specific use case. For each sensor output, the use case mapper 142 may adjust the weight and rank to the sensor output based on the difference between the baseline reading and the hang/reset reading of the sensor, and update the database 144 accordingly. The foregoing establishes a database of use-case-to-sensor-output mappings along with expected sensor readings during normal operation and weights and ranks associated with sensor outputs 146 during a hang/rest during the use case.
In another aspect, the user device 100 is configured to associate potential corrective actions to the sensor outputs 146 mapped to use case. To this end, the error handler 136 further includes an action mapper 148. In response to a detected hang/reset, the action mapper 148 may implement an action in an attempt to prevent a hang/reset. Such actions may include adjustment of the voltage or the clock signal being supplied to the module associated with the sensor output.
Upon implementing the action, the action mapper 148 obtains sensor outputs 146 mapped to the use case and compares the outputs to corresponding information in the database 144 to determine if the action has improved the stability of the device. For example, the sensor output may be compared to the expected output during normal operation, of the device during the particular use case. If the difference is now less than a threshold value, the action mapper 148 may conclude that device stability has improved and a hang/reset is not likely to occur. Alternatively, the difference between the sensor output and the expected output may be determined and compared to a vector weight of the sensor. If the difference is not within a threshold value of the vector weight, the action mapper 148 may conclude that device stability has improved and a hang/reset is not likely to occur.
If the action does not result in improved stability of the device, the action mapper 148 may implement another action, such as a further adjustment of voltage supply and/or clock signal, and repeat the foregoing process to determine if stability is improved. During this iterative process, information corresponding to the actions taken and the affect on stability is maintained in the database. For example, each of the actions mapped to a use case may be maintained in the database along with a corresponding ranking indicative of the affect of the action, with the most effective action having the highest ranking Upon a subsequent hang/reset, or predicted hang/reset, during the use case, the action mapper 148 may implement one or more actions based on the information stored in the database. The information stored in the database may be, for example, a specific voltage value or clock timing setting for the component associated with the sensor, or a change, e.g., increase or decrease, in such setting.
The foregoing adjustment and feedback process may be individually performed for each sensor output associated with a particular use case. As a result of these individual processes each sensor output may be assigned a rank based on its effect on device stability. For example, a particular use case may have five sensors mapped to it by the use case mapper 142. The action mapper 148 may determine that actions associated with one or more of these sensors outputs have no impact on device stability when the device hangs/resets upon such adjustment, and may accordingly disassociate these sensor outputs 146 with the use case.
For other sensors, the action mapper 148 may determine that actions associated with the sensor outputs 146 improve device stability, in that the action results in the device not hanging/resetting. For these sensor outputs 146, particular actions are ranked as to whether the action worked. For example, if a first action corresponding to a first adjustment of voltage supply to a component associated with a sensor output does not result in avoidance of a hang/reset, that first action is ranked lower than a second action corresponding to a second adjustment that resulted in avoidance of a hang/reset.
In another aspect, the user device 100 is configured to periodically monitor sensor outputs 146 and predict potential hardware lockups based on sensor information stored in the database. To this end, the sensor drive manager 140 triggers sensor outputs 146 at intervals of, for example, every 5 seconds. At the time of trigger, the sensor drive manager 140 may determine the use case of the device as described above. The hang/reset detector/predictor 138 processes the sensor outputs 146 as described above to determine if a hang/reset may occur. If a potential hang/reset is detected, the action mapper 144 implements one or more actions mapped to the use case in order to prevent the hang/reset. The action mapper 144 may implement actions one at a time based on the sensor output weights and rankings. For example, the highest ranked actions associated with the highest weighted sensor output may be implemented first. If that action does not improve device stability, the next highest ranked action associated with the action with the highest weighted sensor output may be implemented next. This process may be repeated until an implemented action improves device stability.
With reference to
At step 304 the user device may detect a hang/reset state during the use case. For example, the hang/reset detector/predictor 138 may detect a hang or reset condition using any of several known methods such as: invocation of panic handler, invocation of hardware reset module, or invocation of corruption handler, as described above.
At step 306 the user device receives sensor outputs 146 in response to detecting the hang/reset state. To this end, the sensor drive manager 140 may obtain sensor outputs 146 from all available sensors 134 during the use case.
At step 308 the user device determines a weight for each sensor output 146. To this end, the use case mapper 142 may obtain the baseline sensor output for each sensor output from the database 144 and determine a difference between the baseline sensor output and the received sensor output. For example, with reference to
At step 310 the user device associates one or more sensor outputs 146 with the use case based on the weights of the sensor outputs. To this end, the use case mapper 142 may associate sensor outputs 146 having a weight that satisfies a mapping criterion, to the use case. A mapping criterion may be a threshold value, for example sensors placed for voltage detection at a video core can obtain a ceiling voltage read from the sensor and divide it by the maximum allowed value of voltage at that point. This threshold or weight can range from −1 thru +1 and those sensor outputs 146 having a weight above the threshold value may be identified as relevant sensor outputs for the use case. A mapping of these identified sensor outputs 146 to the specific use case is maintained in the database 144. For example, with reference to
At step 312 the user device ranks sensor outputs 146 based on weights. For example, with reference to
Returning to
With reference to
At step 404 the user device receives a hang/reset sensor output during the hang/reset state. To this end, the action mapper 144 may receive sensor outputs 146 from those sensor outputs mapped to the use case. For example, with reference to
At step 406 the user device determines a first action intended to provide a result, the result being improved device stability that may result in avoidance of the hang/reset in the future. For example, due to the hang/reset state of the device, a difference between the hang/reset sensor output received by the action mapper 144 and the corresponding baseline sensor output may be expected. An action that removes this difference, accordingly, may be considered to provide improved device stability and thereby may result in avoidance of a hang/reset during a future occurrence of the use case. In cases where the operating parameter is a supply voltage or current, the first action may be an increase in the supply by a first amount. In cases where the operating parameter is a clock signal, the first action may be one of a ramp up or ramp down in by a first amount. The amount may be percentage defined as a change in clock amplitude divided by current clock level amplitude.
At step 408 the device determines if the intended result was provided. To this end, upon a subsequent prediction of a hang/reset during the use case, the device may implement the first action mapped to the use case and detect for a hang/reset. If a hang/reset occurs then the desired result is not provided, and the method proceeds to step 410, where the user device determines a second (third, fourth, etc.) action intended to provide the result. In cases where the operating parameter is a supply voltage or current, the second action may be an increase in the supply by a second amount. In cases where the operating parameter is a clock signal, the action may be one of a ramp up or ramp down by a second amount corresponding to a percentage change with respect to change in clock amplitude divided by the current clock level amplitude. Steps 408 and 410 are repeated until an action provides the intended result.
Returning to step 408, if a hang/reset does not occur then the desired result is provided, and the method proceeds to step 412, where the user device ranks the first, second (third, fourth, etc.) actions based on likelihood of providing the intended result. As for different actions that may result in no hang/reset, granularity between different actions may be determined and actions ranked accordingly. This may be done using the following granular approach: An action is made up of series of sub actions. If an action resulted in a desired result, the entire subset of sub actions will be ranked better. On the other hand if an action did not result in a desired output, then the entire subset of sub-actions will be ranked accordingly. Next time an action is being put together, these sub-actions will be weighed accordingly.
At step 414 the user device stores actions and associated ranks in a database 144. For example, with reference to
Returning to
With reference to
At step 504 the user device compares the one or more of the sensor outputs 146 to a corresponding prediction criterion indicative of a potential hang/reset. To this end, the hang/reset detector/predictor 138 may determine whether a difference between a sensor output and its corresponding baseline exceeds a threshold value.
At step 506 the hang/reset detector/predictor 138 determines if the prediction criterion is met. In other words, the hang/reset detector/predictor 138 predicts whether the device is likely to hang or reset. If the prediction criterion is not met, meaning the device is not predicted to hang or reset, the method stops. If, however, the prediction criterion is met, meaning the device is predicted to hang or reset, the method proceeds to step 508, where the user device implements one or more of the actions mapped to the one or more sensor outputs 146 mapped to the use case.
At step 510 the hang/reset detector/predictor 138 again determines if the prediction criterion is met. If the prediction criterion is met, meaning the device is still predicted to hang or reset, the method proceeds to step 512, where the user device implement a second (third, fourth, etc.) action of the one or more actions mapped to the sensor output. Steps 510 and 512 are repeated until the prediction criterion is not met. At step 514 the user device updates the ranking of the one or more actions associated with the sensor output based on the repeating and determining.
The sensor-output-to-use-case mapping module 704 maps one or more sensor outputs 146 to a use case based on sensor outputs obtained during a hang/reset state of the device during the use case. Each of the one or more sensor outputs 146 is associated with one of the plurality of modules. The action-to-sensor-output mapping module 706 maps, for each sensor output mapped to the use case, one or more actions to the sensor output. The one or more actions affect a change in an operating parameter of the module associated with the sensor output during a hang/rest of the device during the use case. The one or more actions also affect a corresponding change in the sensor output.
The hang/reset detection/prediction module 708 predicts and detects for a hang/reset state during use cases. The action module 710 implements one or more of the actions mapped to the one or more sensor outputs mapped to the use case. The one or more operating parameter module(s) 712 supply operating parameters, e.g., voltage, clock signals, etc., to functional modules of the device. The database module 714 stores information that maps sensor output and actions to use cases.
The apparatus may include additional modules that perform each of the steps of the algorithm in the aforementioned flow charts of
The processing system 814 includes a processor 804 coupled to a computer-readable medium 806. The processor 804 is responsible for general processing, including the execution of software stored on the computer-readable medium 806. The software, when executed by the processor 804, causes the processing system 814 to perform the various functions described supra for any particular apparatus. The computer-readable medium 806 may also be used for storing data that is manipulated by the processor 804 when executing software. The processing system further includes at least one of the modules 704, 706, 708, 710, 712, and 714. The modules may be software modules running in the processor 804, resident/stored in the computer readable medium 806, one or more hardware modules coupled to the processor 804, or some combination thereof.
In one configuration, the user device 702 includes means for mapping one or more sensor outputs 146 to a use case based on sensor outputs obtained during a hang/reset state of the device during the use case, each of the one or more sensor outputs associated with one of the plurality of modules; and means for mapping, for each sensor output mapped to the use case, one or more actions to the sensor output, the one or more actions affecting a change in an operating parameter of the module associated with the sensor output during a hang/rest of the device during the use case, the one or more actions also affecting a corresponding change in the sensor output. The apparatus may further include means for predicting a hang/reset state during a subsequent occurrence of the use case, subsequent to mapping one or more sensor outputs and mapping one or more actions; and means for implementing one or more of the actions mapped to the one or more sensor outputs mapped to the use case upon predicting a hang/rest. The aforementioned means may be one or more of the aforementioned modules of the apparatus 702 and/or the processing system 814 of the apparatus 702′ configured to perform the functions recited by the aforementioned means.
It is understood that the specific order or hierarchy of steps in the processes disclosed is an illustration of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged. Further, some steps may be combined or omitted. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.
The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more.” Unless specifically stated otherwise, the term “some” refers to one or more. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. No claim element is to be construed as a means plus function unless the element is expressly recited using the phrase “means for.”