EP1754037A1 - Systeme universel de surveillance de la pression d'un pneu et recepteur sans fil - Google Patents

Systeme universel de surveillance de la pression d'un pneu et recepteur sans fil

Info

Publication number
EP1754037A1
EP1754037A1 EP05748696A EP05748696A EP1754037A1 EP 1754037 A1 EP1754037 A1 EP 1754037A1 EP 05748696 A EP05748696 A EP 05748696A EP 05748696 A EP05748696 A EP 05748696A EP 1754037 A1 EP1754037 A1 EP 1754037A1
Authority
EP
European Patent Office
Prior art keywords
tpms
telematics
tire
otr
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP05748696A
Other languages
German (de)
English (en)
Inventor
Vlad Ardelean
Sean Robert Boyle
Douglas Scott Feagan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tirestamp Inc
Original Assignee
Tirestamp Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tirestamp Inc filed Critical Tirestamp Inc
Publication of EP1754037A1 publication Critical patent/EP1754037A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60C—VEHICLE TYRES; TYRE INFLATION; TYRE CHANGING; CONNECTING VALVES TO INFLATABLE ELASTIC BODIES IN GENERAL; DEVICES OR ARRANGEMENTS RELATED TO TYRES
    • B60C23/00—Devices for measuring, signalling, controlling, or distributing tyre pressure or temperature, specially adapted for mounting on vehicles; Arrangement of tyre inflating devices on vehicles, e.g. of pumps or of tanks; Tyre cooling arrangements
    • B60C23/02—Signalling devices actuated by tyre pressure
    • B60C23/04—Signalling devices actuated by tyre pressure mounted on the wheel or tyre
    • B60C23/0408—Signalling devices actuated by tyre pressure mounted on the wheel or tyre transmitting the signals by non-mechanical means from the wheel or tyre to a vehicle body mounted receiver
    • B60C23/0422—Signalling devices actuated by tyre pressure mounted on the wheel or tyre transmitting the signals by non-mechanical means from the wheel or tyre to a vehicle body mounted receiver characterised by the type of signal transmission means
    • B60C23/0433—Radio signals

Definitions

  • the present invention relates to tire monitoring systems and to interfacing and decoding radio frequency signals generated by such systems. More particularly, the invention relates to telematics devices, which will allow wireless data transmission from the present invention to a data processing centre.
  • This information can be generally divided into two categories: 1 ) the information associated with the performance of tires while they are operating on a vehicle, i.e., pressure, temperature, mileage, tread depth, tire failures, retreadings, and warranty expirations, and 2) the information associated with servicing the tires in a garage, i.e., repairs, rotations, etc.
  • 1 the information associated with the performance of tires while they are operating on a vehicle, i.e., pressure, temperature, mileage, tread depth, tire failures, retreadings, and warranty expirations
  • the information associated with servicing the tires in a garage i.e., repairs, rotations, etc.
  • TPMS tire pressure monitoring system
  • a typical TPMS consists of a receiver and a wireless sensor/transmitter that is attached to a valve stem, a rim, a tire's surface or even integrated right into the tire's rubber.
  • TPMS devices communicate tire temperature and pressure along with other relevant TPMS data to a receiver on the vehicle at regular intervals.
  • TPMS systems are unable to archive or analyze the TPMS readings they generate over an extended period of time.
  • the TPMS readings are also not integrated with other vehicle related data.
  • a telematics device is defined as a wireless communications system for the collection and dissemination of data.
  • Applications of telematics devices commonly include vehicle-based electronic systems, e.g., mobile telephony, vehicle tracking and positioning, on-line navigation and information services and emergency assistance. While telematics devices communicate a wide array of vehicle information, communicating data related to vehicle tires has not been available to date.
  • TPMS and the telematics manufacturing industries are separate industries. As such, there are a wide variety of TPMS and telematics devices which are likely not directly compatible for communication purposes. It is not uncommon for each telematics manufacturer to have its own proprietary communication protocol and specific hardware communication requirements. Therefore, communication between a telematics device and a TPMS device requires that both have knowledge of their communication protocol and hardware requirements. In view of the aforementioned shortcomings, there is a need to provide an industry-wide solution that tracks the location, performance, and servicing of a tire by seeking to provide a multifunctional TPMS which can communicate data related to tires off the vehicle for further performance analysis and tracking.
  • the present invention provides a universal receiver device, referred to herein as the Omni TPMS Receiver (OTR) device, which functions within a vehicle (e.g. automobile, or fleet truck) in an "under-the-hood" (UTH) environment.
  • OTR Omni TPMS Receiver
  • the individual TPMS transmitters located within, upon or near a vehicle's tires, transmit tire data, such as transmitter identification Number (TIN), a tire unique identifier (TUID), a vehicle identification number (VIN), tire pressure, tire temperature, tire rotation, tire gravitational, acceleration change data and other tire relevant data, to the OTR device.
  • the OTR device receives, collects and optionally analyzes the data, from any existing TPMS device as currently exists, or may be contemplated in the future.
  • the OTR device also identifies and classifies all TPMS tire data types, stores the tire data and then optionally analyzes such data. The analysis enables efficient and optimized movement and/or transmission of such data for future analysis both within and off the vehicle.
  • the OTR also stores or retrieves information related to the various telematics and TPMS devices in order to identify these devices.
  • the OTR device is able to receive, capture and process information from differently manufactured TPMS devices, regardless of frequency, data transfer speed or data format.
  • the data processing inside the OTR device consists of data validation, data analysis and data preparation for transmission to a telematics device, which will transfer the processed information to an enhanced processing center (e.g., a remote computer equipped with specialized software).
  • the OTR device also interfaces with various telematics devices, regardless of the type of transmission or communication protocol used. To interface with the telematics device, the OTR identifies the type of telematics device, the transmission type and communication protocol required to then reliably send the information to the processing centre.
  • the present invention is advantageous in that an OEM automotive manufacturer, dealership, garage, tire distributor or other such tire service provider would be able to select from among various manufacturers' TPMS and telematics solutions for installation within the vehicle.
  • the installation of the OTR device enables the user to capture TPMS data for future analysis.
  • the present invention in combination with other tire tracking systems facilitates the complete intelligent analysis of a vehicle's tires.
  • the OTR device can generate, or provide the interface to the processing center which generates, reports on how tires impact the rest of the vehicle and the fleet's performance, as well as the overall cost associated with tire maintenance.
  • the present invention provides a universal receiver device for interfacing between a tire pressure management system (TPMS) device, operatively installed to capture information associated with a vehicle's tire, and a telematics device, capable of wirelessly transmitting processed information to a remote processing unit
  • the universal receiver device comprising: a receiver unit, operatively connected to a transmitter of the TPMS device, having a sensor discriminator for identifying a type of TPMS device to communicate therewith, and for receiving the information associated with a vehicle's tire, previously captured by the TPMS device, in a communication format associated with the identified TPMS device; a processing unit, operatively coupled to the receiver unit, for processing the information into at least one data record; and a data transmission unit, operatively coupled to the processing unit, having a telematics discriminator for identifying a type of telematics device to communicate therewith, and for forwarding the at least one data record in a communication format associated with the identified telematics device.
  • TPMS tire pressure management system
  • the present invention provides a method of interfacing between a tire pressure management system (TPMS) device, operatively installed to capture information associated with a vehicle's tire, and a telematics device, capable of wirelessly transmitting processed information to a remote processing unit, comprising steps of: a) identifying a type of TPMS device to communicate therewith; b) receiving the information associated with a vehicle's tire, previously captured by the TPMS device, in a communication format associated with the identified TPMS device in step a); c) processing the information into at least one data record; d) identifying a type of telematics device to communicate therewith; and e) forwarding the at least one data record in a communication format associated with the identified telematics device in step d).
  • TPMS tire pressure management system
  • FIGURE 1 is a high-level functional block diagram of an OTR device according an aspect of the present invention.
  • FIGURE 2 is a detailed block diagram of the OTR device of FIGURE 1 ;
  • FIGURE 3 is a connection block diagram showing the OTR device of FIGURE 1, a TPMS front end receiver and a telematics device connected according to an aspect of the present invention
  • FIGURE 4 is a schematic drawing showing an example of a relay and optical interface for communication between the OTR device, the TPMS front end receiver and the telematics device of FIGURE 3;
  • FIGURE 5 is a flowchart of the process of the OTR device of FIGURE 1 ;
  • FIGURE 6 is a detailed flowchart of the TPMS identification process initiated in the process of FIGURE 5;
  • FIGURE 7 is a detailed flowchart of the telematics identification process initiated in the process of FIGURE 5;
  • FIGURE 8 is a flowchart detailing an example of a source validation and filtering process for a specific TPMS manufacturer in accordance with an aspect of the present invention
  • FIGURE 9 is a communication state flow chart for a telematics unit according to an aspect of the present invention.
  • a stub is defined as a small program routine that substitutes for a longer program, possibly to be loaded later or that is located remotely.
  • a main program that uses remote procedure calls (RPCs) is compiled with stubs that substitute the main program for a requested procedure.
  • RPCs remote procedure calls
  • the stub accepts the request and then forwards it (through another computer program) to a remote procedure.
  • FIGURE 1 shows a high-level functional block diagram of a OTR device 10.
  • the OTR device comprises a front-end receiver 20, a data processing engine 30, and a data transmission port 40.
  • the front-end receiver 20 is built in modules.
  • the OTR 10 accommodates several modules (stubs) in order to correctly receive information from various TPMS transmitters and sensors.
  • the modules are classified based on: 1 ) frequency used (i.e. 125kHz, 315MHz 50A, 433MHz 50B, 900MHz, 2.4GHZ 50C, etc.); 2) type of modulation (i.e. amplitude-shift-keying (ASK), frequency-shift-keying (FSK), on-off keying (OOK), etc.); and 3) brand of TPMS transmitter or sensor.
  • frequency used i.e. 125kHz, 315MHz 50A, 433MHz 50B, 900MHz, 2.4GHZ 50C, etc.
  • type of modulation i.e. amplitude-shift-keying (ASK), frequency-shift-keying (FSK), on-off keying (OOK), etc.
  • 3) brand of TPMS transmitter or sensor i.e. amplitude-shift
  • TPMS controller area network
  • LIN local interconnect network
  • RS232 serial
  • RKE remote keyless entry
  • the data processing engine 30 executes a plurality of functions.
  • the engine 30 decodes the data from different modulation schemes and line coding (i.e. Manchester, non-return-to-zero (NRZ), return-to-zero (RZ), etc.).
  • the engine 30 performs data integrity checks and data recovery based on single error correction techniques known to those having ordinary skill in this art.
  • the engine 30 also performs data validation based on the receiver's initialization parameters.
  • the data received by the engine 30 is broken into data blocks using the methodology of an embodiment of the present invention.
  • the engine then formats the processed data into a data stream to be sent out to a processing center (not shown) via a telematics device (shown in FIGURE 3).
  • the data transmission port 40 has the capability of communicating with various telematics devices (not shown).
  • the data port classification method is based on: 1) physical port type (i.e. RS232, universal serial bus (USB), Ethernet, etc.); 2) transmission Speed (i.e. Baud Rate); and 3) communication protocol (packet assembler/disassembler (PAD), serial, point-to-point protocol (PPP), serial line internet protocol (SLIP), transmission control protocol/Internet protocol (TCP/IP), etc.); and 4) telematics transmission types such as WiFi (wireless fidelity), ZigBeeTM, and BlueToothTM communication protocols , global positioning system (GPS), global system for communications and general packet radio service (GSM/GPRS), and code division multiple access (CDMA), etc.
  • PDA packet assembler/disassembler
  • PPP point-to-point protocol
  • SLIP serial line internet protocol
  • TCP/IP transmission control protocol/Internet protocol
  • telematics transmission types such as WiFi (wireless fidelity),
  • FIGURE 2 shows a detailed hardware block diagram of the OTR device 10 of the present invention.
  • the OTR device 10 includes a main central processing unit (CPU) module 80, peripherals 90 (i.e., communication ports, analog input interface, output relays), and a switching power supply 100.
  • the data processing engine 30 forms part of the main CPU module 80.
  • the term 'embodied' referred to herein means that an executable software version of given module can run as a computer program on a microprocessor, microcontroller, or comparable semiconductor-based device resident on the OTR device 10.
  • the main CPU module 80 is embodied as programmed logic instructions stored in either a micro controller or a micro processor (not shown).
  • the main CPU module 80 includes a basic input/output system (BIOS) 110.
  • the (BIOS) 110 embodied either in a ROM, or Flash type of memory, loads upon start-up the required information (i.e., software code) to access the OTR components, such as the data memory 120 and the peripherals 90.
  • RAM random access memory
  • program memory flash 140 of at least 512Kb
  • data memory 120 flash disk, battery backed-up static random access memory (SRAM) or electrically erasable programmable read-only memory (EEPROM) of at least 512Kb.
  • the main CPU module 80 includes a battery backed-up real time clock (RTC) 150, an input/output (I/O) controller module 160, and an analog to digital (A/D) converter 170.
  • RTC 150 The purpose of the RTC 150 is to keep the time updated even when the OTR device 30 is powered off, thus saving energy when the vehicle is not running.
  • An I/O controller module 160 manages a plurality of input output ports (digital I/O ports) 180, the communication ports to the peripherals 90 and a microcontroller 190 which controls the switching power supply 100.
  • the two channel analog inputs at the A/D converter 170 read information from the analog interface 200 and convert it into a digital stream of data for the micro controller 190.
  • a suitable minimum recommended resolution for the A/D converter 170 is 10 bits.
  • the peripherals 90 are utilized to interface with various TPMS radio frequency (RF) front end receivers and Telematics devices (shown in FIGURE 3).
  • the peripherals 90 include a series of ports: a serial peripheral interface (SPI) port 210, an intelligent interface controller (I2C) port 220, serial ports (recommended standard (RS) 232, RS 485) 230, a USB port 240, CAN/LI N/remote keyless entry (RKE) interface 250, optoisolated l/Os 260, and control relays 270.
  • a TPMS RF front end receiver 300 is a module that plugs in one of the available peripheral ports 90 (e.g., RS232 230, SPI 210, I2C 220, CAN, LIN, RKE 250).
  • a telematics device 400 also shown in
  • FIGURE 3 is a wireless transmitter (wireless modem) that plugs into one of the available ports, such as RS232 230 or USB 240. It is understood that the TPMS RF front end receiver 300 reports data from all tires on a vehicle.
  • the OTR device 10 also includes the switching power supply 100 which is operatively coupled to the microcontroller 190.
  • the switching power supply includes a voltage regulator 280, a power fail detect circuit 290, and a power on reset circuit 310 directly coupled to the microcontroller 190.
  • the switching power supply 100 allows the main core module 80 and peripherals 90 to operate in a range from approximately 8 VDC to 42 VDC. The power supply should be optimized for best efficiency at 12V to preserve the life of the vehicle's battery.
  • the power-on reset circuit 310 allows the microcontroller 190 to be reset during the power-on cycle.
  • the power fail detect circuit 290 allows the OTR main computer program to save all available information prior to shutting down the power on the OTR 10. Referring now to FIGURE 3, an OTR device connection diagram is shown.
  • the OTR device 10 includes a dual channel analog interface block 410 used to collect information on the ambient temperature from two different points on a vehicle (not shown).
  • the two digital inputs (digital I/O) 180 are optically isolated ports used to sense information from different points in the vehicle, such as the ignition switch 425 and the engine switch on/off (not shown), as well as to control the TPMS RF front end receiver 300 and the telematics device 400.
  • the OTR program can accommodate several modules (stubs) in order to correctly receive information from various TPMS transmitters and sensors.
  • the stubs for the TPMS RF front-end receivers are typically classified based on: 1 ) the port required to interface with the OTR (RS232, 12C, SPI, CAN); 2) the brand of TPMS transmitter or sensor; 3) frequency used (i.e. 315MHz, 433MHz, 900MHz, 2.4GHZ, 125kHz RFID, etc.) and 4) the type of modulation (i.e. ASK, FSK, OOK, etc.) . It should also be mentioned that only one TPMS RF front-end receiver stub is used in any given period of time.
  • the OTR device can communicate with several telematics device stubs through the corresponding communication ports.
  • the telematics device are typically classified based on: physical port type (i.e. RS232, USB, Ethernet, etc.); 2) transmission speed (i.e. Baud Rate); 3) communication protocol (PAD, Serial, PPP, SLIP, TCP/IP, etc.); and 4) telematics transmission type (WiFi, ZigBeeTM, BlueToothTM, GPS, GSM/GPRS, CDMA, etc.).
  • the main OTR computer program embodied in the microcontroller 190 has the capability of detecting the type of TPMS RF front-end receiver and the port used for the TPMS, and similarly the type and port of the telematics device during the start-up initialization process. To prevent vehicle battery drainage, the OTR computer program continuously monitors the status of the engine ignition switch (on or off), and decides if the TPMS and the telematic device should be powered on or off. This decision is based on the time delay from when the ignition was switched off. A running error status loop in the main OTR computer program will also monitor the correct activity of the OTR 30 and reset the microcontroller 180 in case of a fault.
  • the TPMS raw data is then processed as it arrives into a designated communication port for example, PORT 1, in Figure 3 of the OTR device 10.
  • the processed data is then packed into a data record (not shown) and then later sent through another designated communication port (PORT 2 for example) through to the telematics device 400.
  • the telematics device 400 may then send the data through the Internet 460, for example, to a data processing and data management server (not shown), or a proprietary data portal, such as the TireStampTM server.
  • the OTR device must connect to the Telematics device 400 to send the packed record.
  • the packed data record is deleted and a new data record is created in the OTR device 10.
  • the main CPU module 80 and peripherals 90 of the OTR device 10 may be embodied in programmed microcontroller circuits.
  • the OTR device 10 controls power to the TPMS front end receiver 300 and the telematics device 400 via an optical relay interface.
  • FIGURE 4 shows an example of a relay and optical interface 500 schematic for this purpose.
  • connectors J1-1, J1-2, ...J1-10 form part of the OTR peripherals 90, and are used to isolate the optical interface 500 from the peripherals 90 and the main CPU module 80.
  • Connectors J2-1, J2-2, ...J2-10 are attached as physical connectors from the OTR device 10 to allow interfacing with the TPMS RF receiver 400 and the telematics unit 300.
  • Three optocouplers U1, U2 and U3 protect the OTR device 10 against high voltage transients on the inputs and against possible ground loop noisy currents.
  • the power source (+12V) from the vehicle's battery (not shown) is routed to the TPMS and the telematics devices respectively through a dual pole relay K1-A, K1-B.
  • the LED indicators D2 and D3 are used for status monitoring.
  • the diodes D1 and D4 protect the optocouplers against high voltage reverse biasing currents.
  • the OTR device 10 upon connection to the vehicle's power source on connector J2-2, the OTR device 10 does not power up. Rather, the ignition switch is monitored via connector J2-10. When the ignition switch is powered to +12V, the relay K1 energizes applying power to the OTR device 10 and at the same time through K1-A and K1-B contacts connected respectively to the telematics device 400 and the TPMS RF front-end receiver 300 (shown in FIGURE 3).
  • circuit shown in FIGURE 4 may be more defined to separate the power supplied to the telematics and the TPMS devices respectively, through two independent relays, representatively shown as part of the OTR peripherals 90, as control relays 270.
  • the OTR microcontroller 190 (not shown) is programmed to monitor the status of the ignition switch via the optocoupler U3 at the connector pin J1-8. Based on the signal output at this pin, the OTR device 10 decides whether to remain active or retreat into a power saving shutdown mode.
  • a first reset signal from the OTR device 10 is fed from the J1-4 connector, into the U1 optocoupler and in turn to the J2-8 connector to set the ignition of the telematic device.
  • a second reset signal to the TPMS RF front end receiver may be sent from the OTR peripherals 90 to the TPMS RF front end receiver 300.
  • a relay K1 is maintained energized by the optocoupler U2. As such, even if the ignition is turned off, the OTR device 10 will continue to be powered until the OTR computer program initiates a power saving mode.
  • the optocoupler U2 is activated by the OTR program through the J1-6 connector.
  • the OTR computer program can run under a disk operating system (DOS) environment.
  • DOS disk operating system
  • RTOS real time operating system
  • the OTR computer program described herein may be written in C, C++, and/or assembly computer languages.
  • FIGURE 5 is a state diagram showing the process flow 510 of the OTR computer program.
  • the OTR process Upon powering up, the OTR process first loads the required code in the computer program embodied on the existing hardware.
  • Step 520 represents the BIOS boot loading which is part of the operating system environment of the OTR device.
  • the process initiates stubs in step 530.
  • a first stub identifies the TPMS RF receiver type and port used in step 540, and returns the TPMS related information to the OTR.
  • a second stub identifies the telematics device type and port used in step 550, and returns the telematics related information to the OTR.
  • the process After a successful identification of the TPMS RF and the telematics units, the process initializes the remaining peripheral modules (A/D, relay and optical isolated controls) in step 560. Next, the process initiates the software initialization protocol in step 570. The process then initiates the RTOS in step 580 to collect, process, and transmit raw TPMS data. The RTOS initiates the next step 590 of processing TPMS data by loading the raw TPMS data and returning same to the RTOS for processing. Next, the RTOS performs an error checking procedure loop in step 600 to check the raw data. In step 600 the raw data may be validated using a double error detection and single error correction mechanism, followed by data source identification, filtering and error tracking mechanisms.
  • the RTOS then proceeds to load the processed TPMS data to pack the data into records in step 610.
  • Process step 610 returns the packed records to the RTOS.
  • the RTOS loads the packed records and sends the data records via the telematics to a further processing unit either on board the vehicle or remotely located.
  • the TPMS RF receiver may have an error detection and correction mechanism built in which would eliminate step 600 from the OTR process flow.
  • FIGURES 6 and 7 show flow charts 630, 705 further detailing the respective TPMS and telematics identification processes. Upon a successful identification of the respective device, each process returns to the main OTR program a set of variables containing all the required information to properly communicate with the attached device.
  • the TPMS identification process 630 is detailed in a flowchart.
  • the process begins at step 640 and waits for an interrupt signal at one of the existing ports, at decision step 650. If the process receives an interrupt then the process continues to step 660, otherwise the process waits for an interrupt signal in step 650.
  • the process determines which TPMS device port is communicating with the OTR device and assigns the port a value in step 660.
  • the process collects information from that particular port to check for known TPMS protocols and data format stored in the OTR device's memory. The process then determines whether the data format has been successfully decoded, in decision step 680.
  • step 690 returns a set of environment variables containing information regarding the TPMS RF receiver and then exits the process to return to the OTR stubs, at step 530, shown in FIGURE 5. If no known TPMS data format is detected by the OTR device, the RTOS times out, the processor is reset, and the process returns to step 650.
  • the telematics detection process 705 is detailed in a flowchart.
  • the process begins at step 710.
  • the process then acknowledges the telematics device type by sending an inquiry, in a known format, to the appropriate port and waiting for the correct response in step 720.
  • the decision step 730 which follows step 720, if the inquiry receives the correct response, the process proceeds to a final step 750. Otherwise, the process follows step 740 and changes the message and port type to send another inquiry at step 730.
  • the process proceeds, at step 750, to set the environment variables describing the type of telematics device and port used and then exits the process to return the OTR stubs, at step 530, shown in FIGURE 5. If no known telematics device is detected, the RTOS times out and the processor is reset.
  • the hardware and software initializations, steps 560 and 570, discussed with reference to FIGURE 5, are performed upon successfully loading the TPMS and the telematics environment variables.
  • the hardware initialization, step 560 consists in setting the communication ports, A/D decoders and I/O interfaces to the correct values.
  • the software initialization, step 570 reads the required information from an OTR data file located in the OTR device's memory.
  • the process starts collecting TPMS raw data information from the TPMS RF front end receiver coupled to the OTR.
  • FIGURE 8 is a flowchart 770 showing an example of a source validation and filtering process for a specific manufacturer's TPMS device.
  • the TPMS data validation process is executed using a manufacturer's proprietary cyclic redundancy check (CRC) algorithm 780.
  • CRC cyclic redundancy check
  • the OTR may generate statistical analysis: calculate a running average for acquired TPMS data over a certain period of time, and calculate minimum, maximum and last transmitted values. The OTR may also count the number of errors during transmission over a period of time to asses the TPMS transmitter's reliability.
  • the tire data is extracted from the TPMS data stream and parsed into a temporary data structure.
  • the temporary data structure will later form a packed record suitable for transmitting to the telematics device as detailed in the OTR process of FIGURE 5.
  • the packed records are then transmitted to a processing unit by means of the telematics device.
  • FIGURE 9 is a communication state flow chart 800 for communication with a particular telematics unit which represents the internal operation of the RTOS for Packet Assembler/Disassembler (PAD) type of communication.
  • the loop first checks ignition status to see if the engine of the vehicle has been turned on or off. If the engine is on, it starts communicating to the modem in command mode, sets the PAD communication parameters and escape sequence and initiates PAD communication and data transfer.
  • TSCP Communication Protocol
  • the TSCP protocol is a type of Connection-Oriented Service protocol. As such, any of the connected devices should be able to query the other device to initiate communication.
  • either the OTR device or the telematics device can initiate a connection by sending a request. The request can either be accepted or rejected. If the request is refused, the connection fails, otherwise the connection is established.
  • the TSCP protocol is based on the International Consultative Committee for Connectiony and Telephony (CCITT), known as the International
  • the X.25 protocol is a packet switched data network protocol which defines an international recommendation for the exchange of data as well as control information between a user device (host), called Data Terminal Equipment (DTE) and a network node, called Data Circuit Terminating Equipment (DCE).
  • DTE Data Terminal Equipment
  • DCE Data Circuit Terminating Equipment
  • the X.25 protocol utilizes a connection-oriented service. In connection-oriented service, the end node first informs the network it wishes to start a conversation with another end node, the network sends the request to the destination that accepts or rejects the request. If the destination refuses, a connection fails, otherwise a connection is established. This service insures that packets are transmitted in order.
  • the X.25 protocol includes three levels based on the first three layers of the Open Systems Interconnection (OSI) seven layer.
  • OSI Open Systems Interconnection
  • the same definitions used by CCITT are adapted for the communication devices (the OTR device and the telematics device): Data Terminal Equipment (DTE) and Data Communication Equipment (DCE).
  • DTE Data Terminal Equipment
  • DCE Data Communication Equipment
  • both communication devices can be a DTE or a DCE, depending on the direction of communication.
  • the TSCP protocol is a simplified version of the X.25 protocol.
  • the table below shows an example of a proprietary OTR data record definition that may be utilized to transmit data to the telematics device according to the TSCP.
  • the data record At the end of every predetermined period of time, e.g., one hour, a file will be generated containing information about the vehicle and its tires, the data record should contain a data packet header; and 'n' data packets (where 'n' is the number of tires on the vehicle being monitored).
  • the data packet header may also contain information as follows:
  • Time at which the data record was created (e.g. 6 bytes in length)
  • OTR unit ID for identification (e.g. 4 bytes in length)
  • Telematics unit ID e.g. 2 bytes in length
  • TPMS system ID (e.g. 2 bytes in length)
  • VIN number (e.g. 8 bytes in length)
  • Odometer reading may be optionally implemented (e.g. 4 bytes in length)
  • the data record may also contain 'n' OTR data packets, one per tire. The following describes the header information in the data packet.
  • each file may have a format (e.g. a DOS short file naming scheme limitation).
  • all files may be transmitted from an OTR device as zipped files.
  • a password can also be assigned to the zipped file.
  • the present invention incorporates herein by reference the following references: TANENBAUM, A.: “Computer Networks,” Prentice-Hall, Inc, 1981 ; and SIAN, K.: “Inside TCP/IP,” Third Ed., New Riders Publishing.1997.
  • the present invention can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combination thereof.
  • Apparatus of the invention can be implemented in a computer program product tangibly embodied in a machine-readable storage device for execution by a programmable processor; and methods actions can be performed by a programmable processor executing a program of instructions to perform functions of the invention by operating on input data and generating output.
  • the invention can be implemented advantageously in one or more computer programs that are executable on a programmable system including at least one input device, and at least one output device.
  • Each computer program can be implemented in a high-level procedural or object oriented programming language, or in assembly or machine language if desired; and in any case, the language can be a compiled or interpreted language.
  • Suitable processors include, by way of example, both general and specific microprocessors. Generally, a processor will receive instructions and data from a read-only memory and/or a random access memory. Generally, a computer will include one or more mass storage devices for storing data files; such devices include magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and optical disks. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM disks. Any of the foregoing can be supplemented by, or incorporated in ASICs (application-specific integrated circuits).
  • ASICs application-specific integrated circuits
  • Examples of such types of computers are programmable processing systems contained in performing the apparatus or methods of the invention.
  • the system may comprise a processor, a random access memory, a hard drive controller, and an input/output controller coupled by a processor bus. It will be apparent to those skilled in this art that various modifications and variations may be made to the embodiments disclosed herein, consistent with the present invention, without departing from the spirit and scope of the present invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Mechanical Engineering (AREA)
  • Arrangements For Transmission Of Measured Signals (AREA)

Abstract

La présente invention se rapporte à un dispositif récepteur universel (OTR) qui fonctionne à l'intérieur d'un véhicule dans l'environnement 'sous le capot' (UTH) de manière que divers types de dispositifs d'un système de gestion des pneus (TPMS), disposés au sein de cet environnement, sur ou à proximité des pneus d'un véhicule, puissent transmettre des informations relatives aux pneus, telles qu'un numéro d'identification d'émetteur (TIN), l'identificateur unique du pneu (TUID), le numéro d'identification du véhicule (VIN), la pression du pneu, la température du pneu, la rotation du pneu et toute autre donnée relative au pneu, à destination du dispositif (OTR) aux fins d'un traitement ultérieur indépendamment de la fréquence, de la vitesse de transfert des données ou du format des données du dispositif TPMS. Le dispositif OTR effectue, en séquence, l'identification du dispositif TPMS, la réception des informations relatives aux pneus en provenance du dispositif TPMS et le traitement de ces informations relatives aux pneus afin de constituer des enregistrements de données pour une transmission efficace et optimisée de ces enregistrements de données aux fins de leur analyse ultérieure à la fois à l'intérieur du véhicule et en dehors de celui-ci. Le dispositif OTR est également interfacé avec divers types de dispositifs télématiques, indépendamment du type de transmission ou de protocole mis en oeuvre, par identification du type du dispositif télématique. Ce dispositif OTR permet également l'enregistrement et la récupération des informations associés à divers dispositifs télématiques et dispositifs TPMS afin d'identifier ces dispositifs. Par exemple, un fabriquant d'automobiles, un concessionnaire ou un distributeur de pneus ont la possibilité de sélectionner divers dispositifs télématiques et TPMS de fabriquants aux fins d'une installation au sein du véhicule et de recueillir avec le dispositif OTR des données TPMS précédemment capturées aux fins d'une analyse ultérieure.
EP05748696A 2004-05-25 2005-05-25 Systeme universel de surveillance de la pression d'un pneu et recepteur sans fil Withdrawn EP1754037A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US57384004P 2004-05-25 2004-05-25
PCT/CA2005/000792 WO2005116603A1 (fr) 2004-05-25 2005-05-25 Systeme universel de surveillance de la pression d'un pneu et recepteur sans fil

Publications (1)

Publication Number Publication Date
EP1754037A1 true EP1754037A1 (fr) 2007-02-21

Family

ID=35450983

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05748696A Withdrawn EP1754037A1 (fr) 2004-05-25 2005-05-25 Systeme universel de surveillance de la pression d'un pneu et recepteur sans fil

Country Status (3)

Country Link
EP (1) EP1754037A1 (fr)
CA (1) CA2568346A1 (fr)
WO (1) WO2005116603A1 (fr)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008127294A1 (fr) * 2006-10-20 2008-10-23 Schrader Electronics Ltd. Procédé pour détecter et corriger des erreurs de données dans un lien de données rf
US7592903B2 (en) 2006-10-30 2009-09-22 Spx Corporation Tire pressure monitor system tool with re-learn and diagnostic procedures
KR101552264B1 (ko) 2007-07-03 2015-09-09 컨티넨탈 오토모티브 시스템즈 인코포레이티드 범용 타이어의 압력 모니터링 센서
WO2009073945A1 (fr) * 2007-12-12 2009-06-18 Tirestamp Inc. Système de suivi de pneu considéré en tant qu'élément d'actif
US8659412B2 (en) 2009-12-10 2014-02-25 Continental Automotive Systems, Inc. Tire pressure monitoring apparatus and method
US8751092B2 (en) 2011-01-13 2014-06-10 Continental Automotive Systems, Inc. Protocol protection
CN102288346B (zh) * 2011-07-11 2013-07-03 南京航空航天大学 一种小型化数字式的大规模传感器阵列冲击监测系统
US9676238B2 (en) 2011-08-09 2017-06-13 Continental Automotive Systems, Inc. Tire pressure monitor system apparatus and method
WO2013022435A1 (fr) 2011-08-09 2013-02-14 Continental Automotive Systems, Inc. Appareil et procédé de surveillance de pression de pneu
KR101599780B1 (ko) 2011-08-09 2016-03-04 컨티넨탈 오토모티브 시스템즈 인코포레이티드 타이어 압력 모니터링 시스템을 위한 프로토콜 오해 회피 장치 및 방법
KR101599373B1 (ko) 2011-08-09 2016-03-03 컨티넨탈 오토모티브 시스템즈 인코포레이티드 타이어 압력 모니터에 대한 로컬화 과정을 활성화하기 위한 장치 및 방법
US8576060B2 (en) 2011-08-09 2013-11-05 Continental Automotive Systems, Inc. Protocol arrangement in a tire pressure monitoring system
US9091537B2 (en) * 2012-04-18 2015-07-28 Bosch Automotive Service Solutions Inc. Tire pressure monitor system tool with active tire pressure display
US9446636B2 (en) 2014-02-26 2016-09-20 Continental Automotive Systems, Inc. Pressure check tool and method of operating the same
US9517664B2 (en) 2015-02-20 2016-12-13 Continental Automotive Systems, Inc. RF transmission method and apparatus in a tire pressure monitoring system
DE102016213290A1 (de) 2015-08-03 2017-02-09 Continental Automotive Systems, Inc. Vorrichtung, System und Verfahren zum Konfigurieren eines Reifeninformationssensors mit einem Übertragungsprotokoll auf der Basis von Fahrzeugtriggerkenngrößen
CN109080380B (zh) * 2018-09-29 2020-11-24 深圳市道通科技股份有限公司 胎压传感器信号解析方法、其装置、胎压接收器及诊断系统
DE102019205298A1 (de) * 2019-04-12 2020-10-15 Continental Reifen Deutschland Gmbh Reifen
CN112114542B (zh) * 2020-06-10 2024-05-10 上汽通用五菱汽车股份有限公司 车辆远程控制方法、车辆及可读存储介质

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2421993C (fr) * 1994-06-03 2005-01-25 Bridgestone/Firestone, Inc. Procede de controle de conditions des pneus et pneus comprenant ce disposisitif
FR2798238B1 (fr) * 1999-09-03 2008-05-09 Sagem Recepteur de surveillance de la pression des pneumatiques d'un vehicule et emetteur associe de telecommande d'organes du vehicule
JP2001108551A (ja) * 1999-10-13 2001-04-20 Pacific Ind Co Ltd タイヤ空気圧監視装置及び外部通信装置
NO20013182L (no) * 2000-06-26 2001-12-27 Nokian Tyres Plc System og fremgangsmåte for konvertering og overföring av driftsdata for dekk

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2005116603A1 *

Also Published As

Publication number Publication date
WO2005116603A1 (fr) 2005-12-08
CA2568346A1 (fr) 2005-12-08

Similar Documents

Publication Publication Date Title
US20080024287A1 (en) Universal Tire Pressure Monitoring System and Wireless Receiver
WO2005116603A1 (fr) Systeme universel de surveillance de la pression d'un pneu et recepteur sans fil
JP4416649B2 (ja) 車両に係るテレマチックサービスのための方法及び装置
KR101094213B1 (ko) 차량용 게이트웨이 전자제어장치 및 그의 주행정보기록방법
US7788003B2 (en) Remote troubleshooting system
JP3151831B2 (ja) 車両情報通信装置及び車両情報通信システム
EP2178257B1 (fr) Procédé de routage dans un dispositif de passerelle dans un véhicule
EP2257934B1 (fr) Dispositif de détection d'anomalie, procédé de détection d'anomalie, et système de transmission d'informations d'anomalie
KR101780278B1 (ko) Can 통신에서의 통신 부하 절감 방법 및 장치
EP1826946A2 (fr) Système de diagnostic de réseau embarqué et appareil de commande embarqué correspondant
CN103121435A (zh) 车辆通信和进入
JP2009164882A (ja) 移動端末及び移動体通信管理システム
CN101799362A (zh) 基于驾驶员行为的远程车辆误操作报警和自动维护
Cho et al. Who killed my parked car?
JP2003092574A (ja) ネットワークシステム
CN110995823B (zh) 车载终端离线处理方法、设备、存储介质及装置
JP5019983B2 (ja) 車載通信システム、中継装置及び通信方法
CN106528146B (zh) 一种车载obd终端远程升级方法
CN102401740B (zh) 胎压监控系统车辆智能调试方法、服务器及调试仪
JPH08163151A (ja) シリアル通信装置
CN109080380B (zh) 胎压传感器信号解析方法、其装置、胎压接收器及诊断系统
KR101362718B1 (ko) 연속적 소프트웨어 리셋이 발생하는 전자 제어 장치에서의 고장 진단 방법
EP3616366A1 (fr) Procédé d'écriture de demandes sur un bus de diagnostic de véhicule
CN109572335B (zh) 轮胎定位方法及系统
CN101559746B (zh) 一种汽车线控转向系统的故障诊断系统

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20061221

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20101103