GB2579390A - Method and system for data collection in a road network - Google Patents

Abstract

A method for collecting information about a vehicle in a road network comprises collecting S500 data from the tyre pressure management system of a vehicle, processing the collected data S502, S504 and transmitting S508 the processed data to another device. The processing includes extracting information identifying the vehicle and obscuring S506 (such as through encryption) the identification information before sending S508 it to another device. A journey time for the vehicle may be calculated S512 by identifying matching pairs S510 of identification information at different locations. The calculated journey times may be transmitted to other systems such as interactive traffic signs, traffic control systems or incident detection systems.

Description

METHOD AND SYSTEM FOR DATA COLLECTION IN A ROAD NETWORK

FIELD OF INVENTION

The present invention relates to a method and system for collecting data in a road network, for example to determine journey times.

BACKGROUND OF INVENTION

The road network is becoming more congested and thus systems to control traffic or provide travel guidance are becoming more useful. Journey time measurement systems (JTMS) are traffic information acquisition systems. The journey time of each link or segment in the road network is representative of the traffic speed and status of traffic congestion on that link.

The journey time along a route can be estimated by adding up all the journey times for the links in the route.

Different methods are known for measuring the journey time. For example, automatic number plate recognition (ANPR) can be used to identify a car and determine its journey time. However, ANPR requires a large amount of processing power at its location on the road network and also requires costly equipment in the form of sophisticated cameras. W02011/120194 identifies these problems with the ANPR system and describes a method and system for measuring journey times in a road network using a plurality of nodes. Each node is placed at a measured point to detect characteristics of a car sequence passing through the measured point of a first node and a neighbouring node. The detected characteristics can be used to find journey times.

An alternative system is described in US2017/0206783 which shows a traffic monitoring system comprising at least one roadside unit (RSU) and a traffic signal controller. The RSU is configured to transmit wireless signals and receive responses from onboard unit (OBU) equipped vehicles. Similar systems using Bluetooth devices are also known. Although such onboard units can be retrofitted to vehicles, there has not been widespread adoption of such systems and thus the limited deployment means that the systems generate a relatively small amount of data.

Therefore, there is a desire to provide an improved method and system for capturing or collecting data which can be used to identify vehicles and to calculate journey times.

SUMMARY OF INVENTION

To address these problems, the present invention provides a monitor for collecting information about a vehicle in a road network, the monitor comprising: a sensor which is configured to collect data from a vehicle; a processor which is configured to process the collected data; and a transmitter which is configured to transmit the processed data to another device; characterised in that the sensor comprises a receiver for receiving data from a tyre pressure management system (TPMS) on a vehicle; and the processor is configured to process the collected data by extracting identification information identifying the vehicle and by obscuring the extracted identification information before transmitting the processed data to another device.

The monitor is typically a road-side monitor, i.e. mounted at one side of a road within a road network. Since November 2014, each new car in the UK has been equipped with a TPMS.

Given that the inclusion of the TPMS is mandatory compared to the voluntary adoption of onboard units using Wi-Fi, Bluetooth or similar wireless communication techniques; the sample size of vehicles with TPMS is increasing each year whereas the sample size for the onboard units is likely to decrease. As the take up of TPMS increases, the use of a receiver which is configured to receive this TPMS data means that each monitor will be able to identify more and more vehicles which can then be used to create a rich set of data for a road network. It will be appreciated that the sensor may further comprise other components, e.g. a camera for taking an image of the vehicle. Alternatively, the sensor may be the receiver.

A TPMS signal typically comprises information including the tyre pressure and a unique identification number (UID). The UID uniquely identifies the vehicle to which the TPMS is fitted. The identification information which is extracted may be this UID. Given that the monitor extracts the identification information for each vehicle, to maintain security of the information it is necessary to obscure this information so that it cannot be obtained by external devices which are not part of the system. Obscuring the extracted identification information may comprise transforming the extracted identification information which was received from a particular vehicle to generate a unique result which is associated with each vehicle. For example, obscuring the extracted identification information comprises encrypting the identification information. The encryption method is selected to make sure that each different piece of identification information will generate a different result, but the same result is generated for each vehicle. One suitable method is hashing because as is well known in the art, each hash is unique to the input identification information. It may also be possible to obscure the information by forming a secure connection between the monitor and the device so that the information is not transmitted in the clear.

Typically, the TPMS information is transmitted using a radio transmitter. Accordingly, the receiver may be a radio receiver. If a different communication method is used to transmit the TPMS information, a corresponding receiver will be used.

The transmitter may be configured to transmit the processed data together with a timestamp.

The transmitter may also transmit the location of the monitor. Alternatively, it will be appreciated that the receiving device may be able to add this information. Time and location may be used to calculate journey times as explained below.

Another aspect of the present invention is a method for collecting information about a vehicle in a road network, the method comprising: collecting data from a vehicle; processing the collected data; and transmitting the processed data to another device; characterised by collecting data from a tyre pressure management system on a vehicle; and processing the collected data by extracting identification information identifying the vehicle and obscuring the extracted identification information before transmitting the processed data to another device.

The method of obscuring the extracted identification information may comprise transforming the extracted identification information which was received from a particular vehicle to generate a unique result which is associated with each vehicle. The advantages associated with such obscuring are described above. Obscuring the extracted identification information may comprise encrypting, e.g. hashing the identification information.

The method may comprise transmitting the processed data together with a timestamp and/or location.

According to another aspect of the invention, there is provided a device for generating traffic information, the device comprising: a receiver which is configured to receive obscured identification information from at least one monitor described above; and a processor which is configured to process the received data; characterised in that the processor is configured to process the received data by identifying at least one matching pair of obscured identification information and calculating a journey time for each vehicle corresponding to a matching pair. The device may be a server, e.g. a journey time management server (JTMS) or may be any other device for generating traffic information.

According to another aspect of the invention, there is provided a method for generating traffic information, the method comprising: receiving obscured identification information from at least one monitor as described above; and processing the received data; characterised by processing the received data by identifying at least one matching pair of obscured identification information and calculating a journey time for each vehicle corresponding to a matching pair.

According to another aspect of the invention, there is provided a system for generating traffic information for a road network, the system comprising a device as described above and a plurality of monitors as described above, wherein the plurality of monitors are arranged within the road network to collect data from vehicles within the road network.

According to another aspect of the invention, there is provided a system for generating traffic information for a road network, the system comprising a plurality of monitors each of which comprise a sensor which is configured to collect data from a vehicle; a processor which is configured to process the collected data; and a transmitter which is configured to transmit the processed data; and a device which comprises a receiver which is configured to receive processed data from the plurality of monitors; and a processor which is configured to process the received data; characterised in that the system further comprises: a plurality of removable components each of which comprises a receiver for receiving data from a tyre pressure management system on a vehicle and each which is configured to be connectable to a corresponding monitor to cause the processor of the monitor to process the collected data by extracting identification information identifying the vehicle and by obscuring the extracted identification information before transmitting the processed data and; wherein the processor of the device is configured to process the received data by identifying at least one matching pair of obscured identification information and calculating a journey time for each vehicle corresponding to a matching pair of identification information.

A matching pair of obscured identification information will typically be received from two different monitors, although it will be appreciated that a stationery vehicle may transmit two or more signals to the same monitor. The journey time may be calculated by dividing the distance between the pair of monitors from which each matching identification information was received by the difference in the fimestamp associated with each matching identification information. The overall journey time may be calculated by summing individual journey times for each link in a route. The processor of the device may be further configured to process the received data to identify congestion within the network, e.g. by comparing the calculated journey time to an expected journey time.

According to another aspect of the invention, there is provided a method for generating traffic information for a road network, the method comprising collecting data from a vehicle; processing the collected data; transmitting the processed data; and receiving the processed data; characterised by processing the collected data by extracting identification information identifying the vehicle and by obscuring the extracted identification information before transmitting the processed data; and processing the received data by identifying at least one matching pair of obscured identification information and calculating a journey time for each vehicle corresponding to a matching pair of identification information.

There are many monitors currently deployed in road networks and thus it would also be desirable to adapt these monitors to collect information from TPMS. According to another aspect of the invention, there is provided a removable component for connection to one of the currently deployed plurality of monitors, the removable component comprising a receiver for receiving data from a tyre pressure management system on a vehicle and a module which is configured to cause the processor of the monitor to process the collected data by extracting identification information identifying the vehicle from the received data from the tyre pressure management system and to obscure the extracted identification information before transmitting the processed data. The module may be a software update and the removable component may be in the form of a dongle or similar device.

According to another aspect of the invention, there is provided a computer readable medium carrying processor control code which when implemented in a monitor causes the monitor to carry out the method described above. According to another aspect of the invention, there is provided a computer readable medium carrying processor control code which when implemented in a device causes the device to carry out the method described above.

BRIEF DESCRIPTION OF THE DRAWINGS

The above mentioned attributes and other features and advantages of this invention and the manner of attaining them will become more apparent and the invention itself will be better understood by reference to the following description of embodiments of the invention taken in conjunction with the accompanying drawings, wherein FIG. 1 shows a schematic diagram of a system for collecting and processing data in a road network; FIG. 2 shows a block diagram of an example tyre pressure management system within a vehicle; FIG. 3 is a block diagram of the components of a monitor for collecting data from the tyre pressure management system of FIG. 2; FIG. 4 is a block diagram of the components of an alternative monitor; FIG. 5 is a flow chart setting out the method which can be carried out by the system of FIG. 1; and FIG. 6 is a block diagram of the components of a component for processing data which can be used in the system of FIG. 1.

DETAILED DESCRIPTION OF INVENTION

Figure 1 shows a system for collecting and processing data from a road network. The system comprises a plurality of monitors 10, 12 which are located within the road network, e.g. at the side of the roads. In the Figure, two monitors are shown but it will be appreciated that the number is merely illustrative. Each monitor 10, 12 is configured to receive and interpret messages from a tyre pressure monitoring system (TPMS) on a vehicle 14, 16. Again just two vehicles are shown in the network, but it will be appreciated that many more vehicles may be present.

As explained in more detail below, the received TPMS message may be processed and at least part of the data is transmitted to a journey time monitoring system (JTMS) 20 together with a timestamp for further processing. The JTMS 20 processes the received data to determine journey times between two monitors as explained in more detail below. The data may be transmitted from each monitor to the JTMS via any suitable network or communication means. For example, the network may include one or more different types of communications networks such as, for example, cable networks, public networks (e.g., the Internet), private networks (e.g., frame-relay networks), wireless networks, cellular networks, telephone networks (e.g., a public switched telephone network), or any other suitable private or public packet-switched or circuit-switched networks. Further, the network may have any suitable communication range associated therewith and may include, for example, global networks (e.g., the Internet), metropolitan area networks (MANs), wide area networks (WANs), local area networks (LANs), or personal area networks (PANs). In addition, the network may include communication links and associated networking devices (e.g., link-layer switches, routers, etc.) for transmitting network traffic over any suitable type of medium including, but not limited to, coaxial cable, twisted-pair wire (e.g., twisted-pair copper wire), optical fibre, a hybrid fibre-coaxial (HFC) medium, a microwave medium, a radio frequency communication medium, a satellite communication medium, or any combination thereof.

As shown schematically in Figure 1, the calculated journey time may be transmitted to other systems, such as interactive traffic signs 22, urban traffic control systems 24 or incident detection systems 26 for additional processing. Again, the transmission may be via any suitable network or communication means. For example, the interactive traffic signs may use the data to estimate travel times by summing the journey times for the relevant links. The urban traffic control systems 24 may use the journey times to identify congestion on the network and to make adjustment to traffic lights 28 or other interactive traffic control mechanisms to alter the flow of vehicles through other parts of the network to relieve the identified congestion.

Figure 2 is a schematic block diagram for an example tyre pressure monitoring system (TPMS) in a vehicle 14. As shown, the system comprises a tyre pressure sensor 30 and a transmitter 32 for each tyre 34. Each transmitter 32 transmits the tyre pressure separately for each tyre to an on-board management unit 36. The transmission may take place periodically at regular intervals or be triggered by a change in time pressure. The transmission is typically via radio waves. It will be appreciated that other arrangements for the TPMS are possible, e.g. a single transmitter for all the sensors.

Figure 3 is a schematic illustration of the components of a monitor 40 which is a stand-alone device to be mounted at the roadside. As shown, the monitor 40 comprises a receiver 42 for receiving the signals from the TPMS and a transmitter 44 for sending signals to the JTMS.

These functions could be incorporated into a single transceiver if appropriate. The monitor also comprises one or more processors 46 for processing the received data as described in more detail below. The monitor 40 may also comprise memory 48 for storing received or processed data as needed. Such monitors are relatively low cost and simple, e.g. when compared to the cameras in the ANPR system and thus more monitors are likely to be deployed.

Figure 4 shows a schematic illustration of an alternative monitor 50 which is designed to be retrofitted to existing road side devices, e.g. traffic controllers or outstations which are already configured to send information to a JTMS. Such retro-fitting will enable even more monitors to be deployed simply and at low cost so that the road network can be monitored in more detail to provide richer journey time data as described below. Although the TPMS protocols are relatively straightforward, a receiver which is configured to receive the radio signals from the TPMS is essential and a radio receiver will not typically be included in any existing road side device. Accordingly, a hardware update is required to make use of the existing device.

As in Figure 3, the monitor 50 comprises a receiver 52, one or more processors 56 and optionally memory 58. In this arrangement, the monitor 50 does not include a transmitter but relies on the communication infrastructure of the existing device to which it is fitted to transfer data to the JTMS. Instead, the monitor 50 comprises an I/O interface 54 which communicates with the corresponding I/O interface on the device to which the monitor 50 is attached. The one or more processors 56 within the monitor 50 may process the data as described below or alternatively, the processor of the existing device may also receive a software update to enable it to process the information received from the monitor 50. Thus, in this arrangement, the one or more processors 56 of the monitor 50 may just decode the received data before communicating the decoded data to the device. Alternatively, the one or more processors 56 of the monitor 50 may fully process the received data before communicating with the device.

Figure 5 is a schematic flowchart illustrating the steps which are carried out by the various components in the system. At step S500, a radio transmitter in the TPMS on a first vehicle transmits a signal which is received by the monitor. The signal may comprise information including the tyre pressure and a unique identification number (UID). The UID uniquely identifies the vehicle to which the TPMS is fitted. At step S502, the monitor processes the received radio signal by first decoding the signal. At step S504, information within the decoded signal is then extracted, in particular, the UID may be extracted. The extracted UID is then hashed or otherwise encrypted at step S506. The hashed UID is then transmitted from the monitor to the JTMS at step S508 together with a timestamp to indicate when the data was received.

It will be appreciated that hashing or encrypting the data obscures the data so that the UID is not transmitted in the clear. This means that the identification of the vehicle is not broadcast openly for interception by any third party. The hashing or encrypting also can be used by the JTMS to verify that the data has been received from the correct source. Each monitor must use the same method to obscure the UID, e.g. the same hashing technique or the same encryption method, so that the obscured data can be compared. In this way, it is not necessary to derive the UID from the obscured data. The method of obscuring the data is chosen so that the same result will only be obtained by obscuring the same UID. In other words, two different UIDs will generate two different obscured data. It will be appreciated that steps S500 to S508 will be repeated for a plurality of monitors and thus a plurality of obscured data will be received by the JTMS.

The received obscured data from one monitor is compared in real-time with other received data to identify any matching pairs of data at step S510. As shown at step S512, when two matching obscured UIDs are identified, the journey time may be calculated by dividing the distance between the pair of monitors from which each UID was received by the difference in the timestamp associated with each UID.

Figure 6 is a schematic block diagram illustrating the components of the JTMS. It will be appreciated that each of the urban traffic control systems, the incident detection systems and/or the interactive traffic information signs may have similar components. The JTMS 600 may be formed from one or more servers that may include one or more processors (processor(s)) 604, one or more memory devices 606 (generically referred to herein as memory 606), one or more input/output ("I/O") interface(s) 608, one or more network interfaces 610, and data storage 612. The JTMS 600 may further include one or more buses 614 that functionally couple various components of the JTMS 600.

The bus(es) 614 may include at least one of a system bus, a memory bus, an address bus, or a message bus, and may permit exchange of information (e.g., data (including computer-executable code), signalling, etc.) between various components of the JTMS 600. The bus(es) 614 may include, without limitation, a memory bus or a memory controller, a peripheral bus, an accelerated graphics port, and so forth. The bus(es) 614 may be associated with any suitable bus architecture including, without limitation, an Industry Standard Architecture (ISA), a Micro Channel Architecture (MCA), an Enhanced ISA (EISA), a Video Electronics Standards Association (VESA) architecture, an Accelerated Graphics Port (AGP) architecture, a Peripheral Component Interconnects (PCI) architecture, a PCIExpress architecture, a Personal Computer Memory Card International Association (PCMCIA) architecture, a Universal Serial Bus (USB) architecture, and so forth.

The memory 606 of the JTMS 600 may include volatile memory (memory that maintains its state when supplied with power) such as random access memory (RAM) and/or non-volatile memory (memory that maintains its state even when not supplied with power) such as read-only memory (ROM), flash memory, ferroelectric RAM (FRAM), and so forth. Persistent data storage, as that term is used herein, may include non-volatile memory. In certain example embodiments, volatile memory may enable faster read/write access than non-volatile memory. However, in certain other example embodiments, certain types of non-volatile memory (e.g., FRAM) may enable faster read/write access than certain types of volatile memory.

In various implementations, the memory 606 may include multiple different types of memory such as various types of static random access memory (SRAM), various types of dynamic random access memory (DRAM), various types of unalterable ROM, and/or writeable variants of ROM such as electrically erasable programmable read-only memory (EEPROM), flash memory, and so forth. The memory 606 may include main memory as well as various forms of cache memory such as instruction cache(s), data cache(s), translation lookaside buffer(s) (TLBs), and so forth. Further, cache memory such as a data cache may be a multilevel cache organized as a hierarchy of one or more cache levels (L1, L2, etc.).

The data storage 612 may include removable storage and/or non-removable storage including, but not limited to, magnetic storage, optical disk storage, and/or tape storage. The data storage 612 may provide non-volatile storage of computer-executable instructions and other data. The memory 606 and the data storage 612, removable and/or non-removable, are examples of computer-readable storage media (CRSM) as that term is used herein.

The data storage 612 may store computer-executable code, instructions, or the like that may be loadable into the memory 606 and executable by the processor(s) 604 to cause the processor(s) 604 to perform or initiate various operations. The data storage 612 may additionally store data that may be copied to memory 606 for use by the processor(s) 604 during the execution of the computer-executable instructions. Moreover, output data generated as a result of execution of the computer-executable instructions by the processor(s) 604 may be stored initially in memory 606, and may ultimately be copied to data storage 612 for non-volatile storage.

More specifically, the data storage 612 may store one or more operating systems (0/S) 616; and one or more program modules, applications, engines, computer-executable code, scripts, or the like such as, for example, a journey time engine 618. Any of the components depicted as being stored in data storage 612 may include any combination of software, firmware, and/or hardware. The software and/or firmware may include computer-executable code, instructions, or the like that may be loaded into the memory 606 for execution by one or more of the processor(s) 604 to perform any of the operations described earlier in connection with correspondingly named engines.

The data storage 612 may further store various types of data utilized by components of the JTMS 600. Any data stored in the data storage 612 may be loaded into the memory 606 for use by the processor(s) 604 in executing computer-executable code. In addition, any data depicted as being stored in the data storage 612 may potentially be stored in one or more of the datastores and may be accessed and loaded in the memory 606 for use by the processor(s) 604 in executing computer-executable code.

The processor(s) 604 may be configured to access the memory 606 and execute computer-executable instructions loaded therein. For example, the processor(s) 604 may be configured to execute computer-executable instructions of the various program modules, applications, engines, or the like of the system to cause or facilitate various operations to be performed in accordance with one or more embodiments of the disclosure. The processor(s) 604 may include any suitable processing unit capable of accepting data as input, processing the input data in accordance with stored computer-executable instructions, and generating output data. The processor(s) 604 may include any type of suitable processing unit including, but not limited to, a central processing unit, a microprocessor, a Reduced Instruction Set Computer (RISC) microprocessor, a Complex Instruction Set Computer (CISC) microprocessor, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), a System-on-a-Chip (SoC), a digital signal processor (DSP), and so forth. Further, the processor(s) 604 may have any suitable microarchitecture design that includes any number of constituent components such as, for example, registers, multiplexers, arithmetic logic units, cache controllers for controlling read/write operations to cache memory, branch predictors, or the like. The microarchitecture design of the processor(s) 604 may be capable of supporting any of a variety of instruction sets.

Referring now to other illustrative components depicted as being stored in the data storage 612, the 0/S 616 may be loaded from the data storage 612 into the memory 606 and may provide an interface between other application software executing on the JTMS 600 and hardware resources of the JTMS 600. More specifically, the 0/S 616 may include a set of computer-executable instructions for managing hardware resources of the system and for providing common services to other application programs (e.g., managing memory allocation among various application programs). In certain example embodiments, the 0/S 616 may control execution of one or more of the program modules depicted as being stored in the data storage 612. The 0/S 616 may include any operating system now known or which may be developed in the future including, but not limited to, any server operating system, any mainframe operating system, or any other proprietary or non-proprietary operating system.

Referring now to other illustrative components of the JTMS 600, the input/output (I/O) interface(s) 608 may facilitate the receipt of input information by the JTMS 600 from one or more I/O devices as well as the output of information from the JTMS 600 to the one or more I/O devices. The I/O devices may include any of a variety of components such as a display or display screen having a touch surface or touchscreen; an audio output device for producing sound, such as a speaker; an audio capture device, such as a microphone; an image and/or video capture device, such as a camera; a haptic unit; and so forth. Any of these components may be integrated into the JTMS 600 or may be separate. The I/O devices may further include, for example, any number of peripheral devices such as data storage devices, printing devices, and so forth.

The I/O interface(s) 608 may also include an interface for an external peripheral device connection such as universal serial bus (USB), FireWire, Thunderbolt, Ethernet port or other connection protocol that may connect to one or more networks. The I/O interface(s) 608 may also include a connection to one or more antennas to connect to one or more networks via a wireless local area network (WLAN) (such as Wi-Fi) radio, Bluetooth, and/or a wireless network radio, such as a radio capable of communication with a wireless communication network such as a Long Term Evolution (LTE) network, WiMAX network, 3G network, etc. The JTMS 600 may further include one or more network interfaces 610 via which the JTMS 600 may communicate with any of a variety of other systems, platforms, networks, devices, and so forth. The network interface(s) 610 may enable communication via one or more networks, for example, with the monitors, the interactive traffic signs, the urban traffic control systems or incident detection systems shown in Figure 1 and/or other sensors or systems.

It should be appreciated that the engines and the program modules depicted in Figure 5 are merely illustrative and not exhaustive and that processing described as being supported by any particular engine or module may alternatively be distributed across multiple engines, modules, or the like, or performed by a different engine, module, or the like. In addition, various program module(s), script(s), plug-in(s), Application Programming Interface(s) (API(s)), or any other suitable computer-executable code hosted locally on the system and/or hosted on other computing device(s) accessible via one or more of the network(s), may be provided to support the provided functionality, and/or additional or alternate functionality. Further, functionality may be modularized differently such that processing described as being supported collectively by the collection of engines or the collection of program modules may be performed by a fewer or greater number of engines or program modules, or functionality described as being supported by any particular engine or module may be supported, at least in part, by another engine or program module. In addition, engines or program modules that support the functionality described herein may form part of one or more applications executable across any number of devices of the system in accordance with any suitable computing model such as, for example, a client-server model, a peer-to-peer model, and so forth. In addition, any of the functionality described as being supported by any of the engines or program modules may be implemented, at least partially, in hardware and/or firmware across any number of devices.

It should further be appreciated that the system may include alternate and/or additional hardware, software, or firmware components beyond those described or depicted without departing from the scope of the disclosure. More particularly, it should be appreciated that software, firmware, or hardware components depicted as forming part of the system are merely illustrative and that some components may not be present or additional components may be provided in various embodiments. While various illustrative engines have been depicted and described as software engines or program modules, it should be appreciated that functionality described as being supported by the engines or modules may be enabled by any combination of hardware, software, and/or firmware. It should further be appreciated that each of the above-mentioned engines or modules may, in various embodiments, represent a logical partitioning of supported functionality. This logical partitioning is depicted for ease of explanation of the functionality and may not be representative of the structure of software, hardware, and/or firmware for implementing the functionality. Accordingly, it should be appreciated that functionality described as being provided by a particular engine or module may, in various embodiments, be provided at least in part by one or more other engines or modules. Further, one or more depicted engines or modules may not be present in certain embodiments, while in other embodiments, additional engines or modules not depicted may be present and may support at least a portion of the described functionality and/or additional functionality. Moreover, while certain engines modules may be depicted or described as sub-engines or sub-modules of another engine or module, in certain embodiments, such engines or modules may be provided as independent engines or modules or as sub-engines or sub-modules of other engines or modules.

One or more operations of the method shown in Figure 5 may be performed by a system having the illustrative configuration depicted in Figure 6, or more specifically, by one or more engines, program modules, applications, or the like executable on such device(s). It should be appreciated, however, that such operations may be implemented in connection with numerous other system configurations.

The operations described and depicted in the illustrative method of Figure 5 may be carried out or performed in any suitable order as desired in various example embodiments of the disclosure. Additionally, in certain example embodiments, at least a portion of the operations may be carried out in parallel. Furthermore, in certain example embodiments, less, more, or different operations than those depicted in Figure 5 may be performed.

Although specific embodiments of the disclosure have been described, one of ordinary skill in the art will recognize that numerous other modifications and alternative embodiments are within the scope of the disclosure. For example, any of the functionality and/or processing capabilities described with respect to a particular system, system component, device, or device component may be performed by any other system, device, or component. Further, while various illustrative implementations and architectures have been described in accordance with embodiments of the disclosure, one of ordinary skill in the art will appreciate that numerous other modifications to the illustrative implementations and architectures described herein are also within the scope of this disclosure.

Certain aspects of the disclosure are described above with reference to block and flow diagrams of systems, methods, apparatuses, and/or computer program products according to example embodiments. It will be understood that one or more blocks of the block diagrams and flow diagrams, and combinations of blocks in the block diagrams and the flow diagrams, respectively, may be implemented by execution of computer-executable program instructions. Likewise, some blocks of the block diagrams and flow diagrams may not necessarily need to be performed in the order presented, or may not necessarily need to be performed at all, according to some embodiments. Further, additional components and/or operations beyond those depicted in blocks of the block and/or flow diagrams may be present in certain embodiments.

Accordingly, blocks of the block diagrams and flow diagrams support combinations of means for performing the specified functions, combinations of elements or steps for performing the specified functions, and program instruction means for performing the specified functions. It will also be understood that each block of the block diagrams and flow diagrams, and combinations of blocks in the block diagrams and flow diagrams, may be implemented by special-purpose, hardware-based computer systems that perform the specified functions, elements or steps, or combinations of special-purpose hardware and computer instructions.

Program modules, applications, or the like disclosed herein may include one or more software components including, for example, software objects, methods, data structures, or the like. Each such software component may include computer-executable instructions that, responsive to execution, cause at least a portion of the functionality described herein (e.g., one or more operations of the illustrative methods described herein) to be performed.

A software component may be coded in any of a variety of programming languages. An illustrative programming language may be a lower-level programming language such as an assembly language associated with a particular hardware architecture and/or operating system platform. A software component comprising assembly language instructions may require conversion into executable machine code by an assembler prior to execution by the hardware architecture and/or platform.

Another example programming language may be a higher-level programming language that may be portable across multiple architectures. A software component comprising higher-level programming language instructions may require conversion to an intermediate representation by an interpreter or a compiler prior to execution.

Other examples of programming languages include, but are not limited to, a macro language, a shell or command language, a job control language, a script language, a database query or search language, or a report writing language. In one or more example embodiments, a software component comprising instructions in one of the foregoing examples of programming languages may be executed directly by an operating system or other software component without having to be first transformed into another form.

A software component may be stored as a file or other data storage construct. Software components of a similar type or functionally related may be stored together such as, for example, in a particular directory, folder, or library. Software components may be static (e.g., pre-established or fixed) or dynamic (e.g., created or modified at the time of execution).

Software components may invoke or be invoked by other software components through any of a wide variety of mechanisms. Invoked or invoking software components may comprise other custom-developed application software, operating system functionality (e.g., device drivers, data storage (e.g., file management) routines, other common routines and services, etc.), or third-party software components (e.g., middleware, encryption, or other security software, database management software, file transfer or other network communication software, mathematical or statistical software, image processing software, and format translation software).

Software components associated with a particular solution or system may reside and be executed on a single platform or may be distributed across multiple platforms. The multiple platforms may be associated with more than one hardware vendor, underlying chip technology, or operating system. Furthermore, software components associated with a particular solution or system may be initially written in one or more programming languages, but may invoke software components written in another programming language.

Computer-executable program instructions may be loaded onto a special-purpose computer or other particular machine, a processor, or other programmable data processing apparatus to produce a particular machine, such that execution of the instructions on the computer, processor, or other programmable data processing apparatus causes one or more functions or operations specified in the flow diagrams to be performed. These computer program instructions may also be stored in a computer-readable storage medium (CRSM) that upon execution may direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement one or more functions or operations specified in the flow diagrams. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational elements or steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process.

Additional types of CRSM that may be present in any of the devices described herein may include, but are not limited to, programmable random access memory (PRAM), SRAM, DRAM, RAM, ROM, electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the information and which can be accessed. Combinations of any of the above are also included within the scope of CRSM. Alternatively, computer-readable communication media (CRCM) may include computer-readable instructions, program modules, or other data transmitted within a data signal, such as a carrier wave, or other transmission. However, as used herein, CRSM does not include CRCM.

Although embodiments have been described in language specific to structural features and/or methodological acts, it is to be understood that the disclosure is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as illustrative forms of implementing the embodiments. Conditional language, such as, among others, "can," "could," "might," or "may," unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments could include, while other embodiments do not include, certain features, elements, and/or steps. Thus, such conditional language is not generally intended to imply that features, elements, and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements, and/or steps are included or are to be performed in any particular embodiment.

Claims (16)

1. CLAIMS1. A monitor for collecting information about a vehicle in a road network, the monitor comprising: a sensor which is configured to collect data from a vehicle; a processor which is configured to process the collected data; and a transmitter which is configured to transmit the processed data to another device; characterised in that the sensor comprises a receiver for receiving data from a tyre pressure management system on a vehicle; and the processor is configured to process the collected data by extracting identification information identifying the vehicle and by obscuring the extracted identification information before transmitting the processed data to another device.
2. 2. The monitor of claim 1, wherein obscuring the extracted identification information comprises transforming the extracted identification information which was received from a particular vehicle to generate a unique result which is associated with each vehicle.
3. 3. The monitor of claim 1 or claim 2, wherein obscuring the extracted identification information comprises encrypting the identification information.
4. 4. The monitor of any one of the preceding claims, wherein the receiver is a radio receiver.
5. 5. The monitor of any one of the preceding claims, wherein the transmitter is configured to transmit the processed data together with a timestamp.
6. 6. A method for collecting information about a vehicle in a road network, the method comprising: collecting data from a vehicle; processing the collected data; and transmitting the processed data to another device; characterised by collecting data from a tyre pressure management system on a vehicle; and processing the collected data by extracting identification information identifying the vehicle and obscuring the extracted identification information before transmitting the processed data to another device.
7. 7. The method of claim 6, wherein obscuring the extracted identification information comprises transforming the extracted identification information which was received from a particular vehicle to generate a unique result which is associated with each vehicle.
8. 8. The method of claim 6 or claim 7, wherein obscuring the extracted identification information comprises encrypting the identification information.
9. 9. The method of any one of claims 6 to 8, comprising transmitting the processed data together with a timestamp.
10. 10. A device for generating traffic information, the device comprising: a receiver which is configured to receive obscured identification information from at least one monitor as set out in any one of claims 1 to 5; and a processor which is configured to process the received data; characterised in that the processor is configured to process the received data by identifying at least one matching pair of obscured identification information and calculating a journey time for each vehicle corresponding to a matching pair.
11. 11. A method for generating traffic information, the method comprising: receiving obscured identification information from at least one monitor as set out in any one of claims 1 to 5; and processing the received data; characterised by processing the received data by identifying at least one matching pair of obscured identification information and calculating a journey time for each vehicle corresponding to a matching pair.
12. 12. A system for generating traffic information for a road network, the system comprising a device as claimed in claim 10 and a plurality of monitors as claimed in any one of claims 1 to 5, wherein the plurality of monitors are arranged within the road network to collect data from vehicles within the road network.
13. 13. A system for generating traffic information for a road network, the system comprising a plurality of monitors each of which comprise a sensor which is configured to collect data from a vehicle; a processor which is configured to process the collected data; and a transmitter which is configured to transmit the processed data; and a device which comprises a receiver which is configured to receive processed data from the plurality of monitors; and a processor which is configured to process the received data; characterised in that the system further comprises: a plurality of removable components each of which comprises a receiver for receiving data from a tyre pressure management system on a vehicle and each which is configured to be connectable to a corresponding monitor to cause the processor of the monitor to process the collected data by extracting identification information identifying the vehicle and by obscuring the extracted identification information before transmitting the processed data and; wherein the processor of the device is configured to process the received data by identifying at least one matching pair of obscured identification information and calculating a journey time for each vehicle corresponding to a matching pair.
14. 14. A method for generating traffic information for a road network, the method comprising collecting data from a vehicle; processing the collected data; transmitting the processed data; and receiving the processed data; characterised by processing the collected data by extracting identification information identifying the vehicle and by obscuring the extracted identification information before transmitting the processed data; and processing the received data by identifying at least one matching pair of obscured identification information and calculating a journey time for each vehicle corresponding to a matching pair.
15. 15. A removable component for connection to one of the plurality of monitors in the system of claim 13, the removable component comprising a receiver for receiving data from a tyre pressure management system on a vehicle and a module which is configured to cause the processor of the monitor to process the collected data by extracting identification information identifying the vehicle from the received data from the tyre pressure management system and to obscure the extracted identification information before transmitting the processed data.
16. 16. A computer readable medium carrying processor control code which when implemented in a monitor causes the monitor to carry out the method of any one of claims 6 to 9.