Universal TPMS Sensor Using Runtime Interpreter for Cross-Platform Adaptability
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing tire pressure monitoring systems (TPMS) face challenges in being adaptable to various vehicle models and sensor hardware platforms, leading to high initial investment, complex handling, and limited flexibility, with current solutions requiring multiple sensor types or large memory storage, which increases costs and reduces the ability to adapt to new requirements.
Innovation Solution
A universal TPMS wheel sensor with a processing unit, non-volatile memory, and a communication module that uses an Intermediate Language (IL) interpreted by a runtime interpreter, allowing for platform-independent operation and flexibility, eliminating the need for distinct software versions and reducing memory requirements, enabling quick programming without a wired interface.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a multitude of sensor types are implemented to cover all relevant TPMS modes, then the sensor can support more vehicle models and protocols, but the initial investment for installers and supply chain increases significantly
Solution Approach 1:
The patent implements a universal sensor design that can operate in multiple TPMS modes (OEM, After-Market, Refurbishment) through a single hardware platform. The sensor includes a microcontroller capable of executing different software implementations and a communication module that supports various protocols, eliminating the need for installers to maintain multiple sensor types in inventory while maintaining full compatibility across all vehicle models and protocols.
2Adaptability or versatility
If full software is loaded to the sensor via low speed communication interface, then the sensor can be programmed flexibly, but the programming time becomes comparatively long
Solution Approach 1:
The patent implements a dynamic programming approach where the communication interface can operate at different speeds depending on the programming stage. During initial full software loading, a high-speed wireless interface is used to minimize programming time. Once the sensor is programmed, it switches to normal operational communication speeds. This dynamic adjustment of communication speed resolves the contradiction between flexible software loading and long programming times.
3Adaptability or versatility
If intense communication is used for programming, then the sensor can be configured for specific vehicles, but the battery capacity is reduced due to high energy consumption
Solution Approach 1:
The patent implements periodic communication during the programming phase, where the sensor enters brief high-intensity communication bursts to transfer configuration data quickly, then returns to low-power sleep mode. This periodic action pattern allows the sensor to complete vehicle configuration through intense communication while minimizing overall battery consumption by limiting the duration of high-power states.
4Reliability
If a wired interface is used for programming, then the communication can be reliable, but additional hardware like drivers and electrical contacts are required which make the sensor susceptible to ESD damage and corrosion
Solution Approach 1:
The patent replaces the mechanical wired interface with a wireless communication interface for programming the sensor. The wireless interface uses electromagnetic fields instead of physical electrical contacts, eliminating the sensor's susceptibility to ESD damage and corrosion at contact points while maintaining communication reliability through protocol error correction and retransmission mechanisms.
5Productivity
If pre-stored programs are kept in the sensor for different vehicle models, then the sensor can be quickly programmed, but a large number of programs must be stored which increases memory overhead and sensor costs
Solution Approach 1:
The patent extracts the vehicle-specific configuration data from the sensor's internal memory and stores it externally in a database accessible by the programming tool. The sensor retains only a minimal bootstrap program and runtime interpreter. During programming, the external database provides vehicle-specific parameters, which are loaded into the sensor's memory only when needed. This extraction of bulk storage requirements to an external system enables quick programming without requiring large onboard memory capacity.
Data Source
AI summary
A tire pressure monitoring sensor comprises an environmental pressure sensor, a non-volatile memory for storing a first program and a second program, a processing unit for executing the first program, a communication module including a wireless transmitter for transmitting at least one parameter indicative of conditions within a tire and a wireless or wired receiver for loading the second program into the non-volatile memory and a battery for powering the sensor. The second program contains a sensor operation description which is used by the first program.


