GB2582059A

GB2582059A - Method and system for data collection in a road network

Info

Publication number: GB2582059A
Application number: GB2000460.2A
Authority: GB
Inventors: Ebsworth Nicholas
Original assignee: Siemens Mobility Ltd
Current assignee: Siemens Mobility Ltd
Priority date: 2019-01-17
Filing date: 2020-01-13
Publication date: 2020-09-09
Anticipated expiration: 2040-01-13
Also published as: GB2580630A; GB202000460D0; GB2580630B; GB2582059B; GB201900674D0

Abstract

Multiple cameras 10 are configured to identify passing vehicles 11 in a road network. Evidence Retrieval and Control Unit (ERCU) 112 collects vehicle identification data from each camera and transmits to it to a processing module via a data diode (Fig.3, 114). The data diode may comprise a transmitter 126 upstream of a receiver 136 whereby the transmission is unidirectional. The cameras may be ANPR cameras and the data may a vehicle registration mark (VRM) or number plate which is obscured (e.g. by hashing) before transmission. Multiple data diodes may connect multiple ports of the ERCU to multiple processors (e.g. Offence Viewing and Decision System (OVDS) 116; journey time management system 122; or a security system such as a Cleartone stealth system or BOF2 police system). The data diode thus obviates the need for an air gap between the ERCU and OVDS and allows the same ANPR data to be used to determine average speed violations, journey time or vehicle tracking information.

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 from speed cameras.

BACKGROUND OF INVENTION

Automatic number plate recognition (ANPR) cameras can be used on a road network to identify a car by obtaining the vehicle registration mark (VRM) as the car passes through its field of view. A typical use is for average speed measurement where cameras are used in pairs to determine the average speed of the vehicle transitioning through the field of view of the cameras. The relationship between the time the vehicle is detected at both cameras and the shortest measured drivable distance between the cameras is used as a basis to mathematically calculate the average speed of the vehicle between the cameras.

Figure 1 shows a current system which uses ANPR cameras 10.

In Figure 1, two cameras 10 are shown but it will be appreciated that any number of ANPR cameras 10 may be present in the system. Each ANPR camera 10 separately transmits information, e.g. via an asymmetric digital subscriber line (ADSL) or via a global system for mobile communication (GSM), on each vehicle 11 in its field of view to an Evidence Retrieval and Control Unit (ERCU) 12. The ERCU 12 and plurality of ANPR cameras may form an approved average speed system.

Under current legislation, data from the approved average speed system must be written to a separate device 14 and transferred across a physical air gap from the ERCU 12 to an Offence Viewing and Decision System (OVDS) 16. Such a transmission is required by law to prevent contamination of the evidential data held on the ERCU and to maintain the evidential integrity of such data.

The separate device 14 is typically a Write Once Read Many (WORM) device which is capable of providing a reliable means of transferring large amounts of data, e.g. a digital versatile disc (DVD) or a universal serial bus (USB) memory stick. The writing to the WORM device and subsequent transfer of the WORM device result in a latency whereby when data loaded from the WORM device onto the OVDS 16 is viewed by an officer 20, the data may be hours or even days later than the time that the vehicle 11 was in the field of view of the ANPR cameras 10. The officer 20 is thus only typically able to use the data to identify a traffic offence, e.g. a speeding offence, which occurred some time ago. The transfer of data is also labour intensive.

Although ANPR cameras may also be used for gathering security information by recording vehicle movements between cameras or by using the average speed data to determine journey times, the current legislation prevents the real-time data from the ERCU 12 from being utilized for other real-time purposes, such as journey time measurement or security. Accordingly, each ANPR camera has a sole, specialised use, namely speed enforcement. One possible solution that has been Proposed is to have separate cameras dedicated to each purpose, e.g. average speed, journey time or security information.

However, this adds considerable cost because of the additional cameras that are required.

Therefore, there is a desire to provide an improved method and system for capturing or collecting data in a system using a plurality of ANPR cameras.

SUMMARY OF INVENTION

To address these problems, the present invention provides a system for generating traffic information for a road network, the system comprising: a collection module which is configured to collect identification data for a plurality of vehicles in the road network from a plurality of cameras arranged within the road network; characterised in that the system further comprises a data diode which is connected to the collection module and through which the collected identification data is transmissible from the collection module to a processing module.

The camera is typically a road-side monitor, i.e. mounted at one side of a road within a road network. The camera may be an automatic number plate recognition camera which determines a unique identification such as a vehicle registration mark (VRM). The VRM uniquely identifies the vehicle having that number plate. To maintain the 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, particularly when sending to an insecure processing module. Obscuring the collected identification data may comprise transforming the collected identification data for a particular vehicle to generate a unique result which is associated with each vehicle. For example, obscuring the collected identification data may comprise encrypting the identification data. The encryption method is selected to make sure that each different piece of identification data 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 data. Thus, the collection module may be configured to obscure the collected identification data by hashing the collected identification data.

The data diode may comprise a transmitter and a receiver and the transmitter is upstream from the receiver whereby data is only transmissible in one direction. The transmitter may be configured to transmit the data together with a timestamp. The transmitter may also transmit the location of the camera. Alternatively, it will be appreciated that the receiver (or the receiving processing module) may be able to add this information. The data diode may further comprise at least one forward error correction module.

The system may comprise a plurality of data diodes, each of which is connected to a dedicated data port on the collection module and through which the collected identification data is transmissible from the collection module to one of a plurality of processing module s. The collection module may be further configured to: determine which processing module of the plurality of processing module s is to receive the collected identification data; and stream the collected identification data to the dedicated port associated with the determined processing module.

The collection module may be an evidence retrieval and control unit. The system may further comprise a plurality of automatic number plate recognition cameras. The processing module may be a server, e.g. a journey time management server (JTMS) and/or an offence viewing and decision system (OVDS).

Another aspect of the present invention is a method for generating traffic information for a road network, the method comprising: collecting, using a collection module, identification data for a plurality of vehicles in the road network from a plurality of cameras arranged within the road network; characterised by transmitting the collected identification data through a data diode from the collection module to a processing module.

As explained above, the method may comprise obscuring, e.g. hashing, the collected identification data before transmitting.

The method may comprise applying a forward error correction 15 to the collected identification data while transmitting through the data diode.

The method may further comprise determining which of a plurality of processing module s is to receive the collected identification data; and streaming the collected identification data to a dedicated port on the collection module associated with the determined processing module.

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

The method may comprise processing the transmitted collected identification data to determine security information, journey time information and/or whether an offence, e.g. a speeding offence has been committed. For example, to determine journey time information, a matching pair of (optionally obscured) identification data will typically be received from two different cameras, although it will be appreciated that a stationery vehicle may result in the same data at different times from the same camera. The journey time may be calculated by dividing the distance between the pair of cameras from which each matching identification data was received by the difference in the timestamp associated with each matching identification data. 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 computer readable medium carrying processor control code which when implemented in a system causes the system to carry out the method described above.

BRIEF DESCRIPTION OF THE DRAWINGS

The abovementioned 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 prior art system for collecting and processing data in a road network; FIG. 2 shows a schematic block diagram of a proposed system for collecting and processing data in a road network; FIG. 3 is a block diagram of the components within the system of FIG. 2; FIG. 4 is a flow chart setting out the method which can be carried out by the system of FIG. 2; and FIG. 5 is a block diagram of the internal components of a 5 module which can be used in the system of FIG. 2.

DETAILED DESCRIPTION OF INVENTION

As described above Figure 1 shows a known system for 10 collecting and processing data from a road network.

Figure 2 shows a proposed system for collecting and processing data from a road network. Elements which are unaltered from the known system shown in Figure 1 have the same reference numbers. As shown in Figure 2, the system comprises a plurality of cameras 10 which are located within the road network, e.g. at the side of the roads. In the Figure, two cameras 10 are shown but it will be appreciated that the number is merely illustrative. As is known in the art, each camera 10 may be an ANPF camera which is configured to identify a vehicle 11, e.g. a car, by obtaining the vehicle registration mark (VRM) as the vehicle passes through its field of view. Just one vehicle is shown in the network, but it will be appreciated that many more vehicles may be present. Additionally, one or more images of the vehicle(s) may be captured as the vehicle passes through the field of view of each camera. These images may comprise views of the vehicle VP}, of the entire vehicle, and/or of the vehicle and its surroundings. These additional images may be captured in visible or infra-red light.

Each camera 10 separately transmits information, e.g. via an asymmetric digital subscriber line (ADSL) or via a global system for mobile communication (GSM), on each vehicle 11 in its field of view to an Evidence Retrieval and Control Unit (ERCU) 112. The ERCU 112 may thus be regarded as a collection module because it gathers together information from a plurality of sources. The data from the ERCU is transferred to an Offence Viewing and Decision System (OVDS) 116 which may be regarded as a data processing module because it processes the received data to determine whether or not an offence has been committed. The OVDS may comprise a user interface, e.g. a display, to display information on any offence to a user 20 such as a traffic officer.

As explained in more detail below, the ERCU 112 and OVDS 116 may have been adapted to allow the transfer of data between the two modules via a data diode 114. The data diode 114 may be a commercial off-the-shelf (COTS) product. The data diode 114 is a network device which allows data to travel only in one direction, e.g. from the ERCU to the OVDS but not from the OVDS to the ERCU. Thus, a data diode may also be termed a unidirectional security gateway or unidirectional network.

This one-way flow of data can be used to guarantee information security and thus the evidential integrity of the data which is required by current legislation.

The ERCU 112 has also been adapted to allow some of the collected data or a duplicate of some or all of the collected data to be transmitted to an alternative data processing module 122 for different use of the data.

For example, the data processing module 122 may be a journey time monitoring system (JTMS). A JTMS is not typically a secure system. Accordingly, the data from the ERCU may be hashed or otherwise encrypted before sending to the JTMS. It will be appreciated that hashing or encrypting the data obscures the data so that the data, e.g. the vehicle registration mark (VRM) is not transmitted in the clear or 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.

Both the JTMS and ERCU must use the same method to obscure the data, 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 for the JTMS to derive the original data, e.g. the VRM, 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 data. In other words, two different pieces of data will generate two different obscured pieces of data.

A JTMS typically processes the received data to determine journey times between two monitors as explained in more detail below. For example, when two matching obscured VRMs are identified, the journey time may be calculated by dividing the distance between the pair of ANPR cameras which captured each VRM by the difference in a timestamp associated with each obscured VRM.

As another example, the data processing module 122 may be a security system such as a Cleartone stealth system or a police system such as BOF2 (Back Office Facility -which is a database of vehicle movements on UK roads and which allows police and security services to track vehicle movements). Such systems are typically secure systems and thus obscuring the data is not typically necessary. Accordingly, the real-time data from the ERCU can be sent without hashing or other encryption to such security systems. These systems process the VRM to obtain security information, e.g. the presence of a vehicle in an unauthorised location or to alert the authorities to a suspect vehicle.

Figure 3 shows more detail of the data diode 114 connection between the ERCU 112 and a another processing module 122 such as the FTMS. The ERCU 112 is connected via a secure two-way connection 128 to a first (or transmitting) central processing unit 120. The secure two-way connection 128 may be any suitable link, e.g. a TCP/IP link using acknowledgements. The central processing unit 120 may process the data and may forward the data to optionally apply a forward error correction (FEC) using a first (or transmitting) FEC module 124. In this arrangement, the FEC module 124 is shown as a separate module but it will be appreciated that this is just one illustration and the functionality may be carried out in the first central processing unit 120. The data is then passed to a transmitter 126.

A receiver 136 receives the data from the transmitter. The transmitter and receiver may be optical devices. The transmitter is thus upstream of the receiver and the use of the transmitter and receiver in this order ensures that the data diode only transmits data in one direction, e.g. from the ERCU 112 to the other processing module 122 and not the other way round. As before, an optional FEC may be applied by a second (or receiving) FEC module 134 (again illustrated as a separate component in this arrangement). A second (or receiving) central processing unit 130 then receives the transmitted data.

The second central processing unit 130 is connected via a two-way connection 138 to the other processing module 122. As above, the two-way connection 138 may be any suitable link, e.g. a TCP/IP link using acknowledgements. If the other processing module 122 is a JTMS or other insecure

II

processing module, the two-way connection 138 may be over an insecure channel. Alternatively, if the other processing module 122 is a security module, the two-way connection 138 may be over a secure channel. The data may also be buffered as needed in a buffer storage 140.

Figure 4 is a schematic flowchart illustrating the steps which are carried out by the various components in the system. At step 3400, an ANPR camera captures an image of a vehicle number plate. The ANPR camera determines (step S402) the unique identification number for the vehicle, e.g. the vehicle registration mark (VRM). The VRM uniquely identifies the vehicle having the photographed number plate. At step 5404, the VRM is sent to the ERCU and is received at step 3406. The ERCU then streams the received VRM to the appropriate port for sending via the data diode to a processing module such as the JTMS at step S408. Similarly, at step 5412, the ERCU streams the received VRM to the appropriate port for sending via the data diode to a processing module such as the OVDS. The streaming steps may take place simultaneously or in a different order.

Streaming to the appropriate port which is dedicated for data transfer to a particular module ensures that the total evidential security of streamed data is maintained. Furthermore, complete electrical and protocol isolation of the ERCU from the downstream modules, e.g. the OVDS or JTMS is maintained. As explained above, the streamed data to the JTMS may be hashed or otherwise encrypted. A timestamp may also be transmitted to indicate when the data was received. The JTMS may then process the received data to determine journey times (step S410). Similarly, the OVDS or an officer using the OVDS may process the received data to determine whether a speeding offence has been committed (step S414). As explained above, the streamed data to the OVDS need not be hashed or otherwise encrypted.

Figure 5 is a schematic block diagram illustrating the components of the ERCU. It will be appreciated that each of the JTMS, the OVDS and/or the processing modules which receive the data from the ERCU may have similar components. The ERCU 600 may be formed from one or more servers that may include one or more processors 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 data ports 610, and data storage 612. The ERCII 600 may further include one or more buses 614 that functionally couple various components of the ERCU 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 comouterexecutable code), signalling, etc.) between various components of the ERCU 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 PCT-Express architecture, a Personal Computer Memory Card International Association (PCMCIA) architecture, a Universal Serial Bus (USB) architecture, and so forth.

The memory 606 of the ERCU 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 nonvolatile 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 multi-level cache organized as a hierarchy of one or more cache levels (Dl, 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 streaming engine 618. The streaming engine 618 may be an adaptation of the ERCU to stream the data to the appropriate dedicated data port of the EACH. 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 ERCU 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 ERCU 600 and hardware resources of the ERCU 600. More specifically, the 0/5 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/5 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 ERCU 600, the input/output (I/O) interface(s) 608 may facilitate the receipt of input information by the ERCU 600 from one or more I/O devices as well as the output of information from the ERCU 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 ERCU 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 ERCU 600 may further include one or more data Ports 610 via which the ERCU 600 may communicate with any of the processing modules. The data ports(s) 610 may enable communication via one or more data diodes, for example, with the JTMS and OVDS shown in Figure 2 and/or other sensors or systems. It is noted that even if there is a change of legislation which may allow an ERCU to pass data to other systems given levels of integrity system, such systems may be prone to penetration and associated loss of evidential integrity. However, the proposed use of dedicated data ports and data diodes addresses this issue.

It will be appreciated that the methods and systems above are described in the context of ANPR cameras. However, other sensors may be used to collect traffic data. Where this data is sensitive, the data diode approach described above may also be implemented to ensure data integrity from the sensor to a collection module and on to the ultimate processing module.

It should be appreciated that the engines and the Program modules depicted in Figures 2, 3 and 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 4 may be performed by a system having the illustrative configuration depicted in Figure 2 or 3, 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 4 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 4 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 comouterexecutable 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

CLAIMS1. A system for generating traffic information for a road 5 network, the system comprising: a collection module (112) which is configured to collect identification data for a plurality of vehicles (11) in the road network from a plurality of cameras (10) arranged within the road network; characterised in that the system further comprises a data diode (114) which is connected to the collection module and through which the collected identification data is transmissible from the collection module to a processing module (122).
2. The system of claim 1, wherein the collection module (112) is configured to obscure the collected identification data before transmission to the processing module (122).
3. The system of claim 2, wherein the collection module is configured to obscure the collected identification data by hashing the collected identification data.
4. The system of any one of the preceding claims, wherein the data diode comprises a transmitter (126) and a receiver (136) and the transmitter is upstream from the receiver whereby data is only transmissible in one direction.
S. The system of claim 4, wherein the data diode further comprises at least one forward error correction module (124, 134).
6. The system of any one of the preceding claims, further comprising a plurality of data diodes, each of which is connected to a dedicated data port on the collection module and through which the collected identification data is transmissible from the collection module to one of a plurality of processing modules.
7. The system of claim 6, wherein the collection module is further configured to: determine which processing module of the plurality of processing modules is to receive the collected identification 10 data; and stream the collected identification data to the dedicated port associated with the determined processing module.
8. The system of any one of the preceding claims, wherein the collected identification data is a vehicle registration mark.
9. The system of claim 8, wherein the collection module is 20 an evidence retrieval and control unit.
10. The system of claim 8 or claim 9, further comprising a plurality of automatic number plate recognition cameras.
11. The system of any one of the preceding claims, further comprising a processing module which is an offence viewing and decision system.
12. The system of any one of the preceding claims, further 30 comprising a processing module which is a journey time management system.
13. A method for generating traffic information for a road network, the method comprising: collecting, using a collection module, identification data for a plurality of vehicles in the road network from a plurality of cameras arranged within the road network; characterised by transmitting the collected identification data through a data diode from the collection module to a processing module.
14. The method of claim 13, comprising obscuring the collected identification data before transmitting.
15. The method of claim 14, comprising obscuring the collected identification data by hashing.
16. The method of any one of claims 13 to 15, comprises 15 applying a forward error correction to the collected identification data while transmitting through the data diode.
17. The method of any one of claims 13 to 16, further comprising: determining which of a plurality of processing modules is to receive the collected identification data; and streaming the collected identification data to a dedicated port on the collection module associated with the determined processing module.
18. The method of any one of claims 13 to 17, further comprising processing the transmitted collected identification data to determine security information.
19. The method of any one of claims 13 to 18, further comprising processing the transmitted collected identification data to determine journey time information.
20. A_ computer readable medium carrying processor control code which when implemented in a system causes the system to carry out the method of any one of claims 13 to 19.