Central Unit On-Board Unit Verification Road Toll System
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current road toll systems face challenges in detecting fake or tampered hardware in on-board units, which can lead to incorrect billing and evasion of tolls.
Innovation Solution
A method where the central unit sends a software routine to the on-board unit to perform specific actions and verify the results, comparing them to expected answers to determine if the hardware or software has been exchanged, using checks like software version verification, memory read-outs, and cyclic redundancy checks, and evaluating interface characteristics and serial numbers.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If encryption methods are used to securely transmit data from the on-board unit, then data security is improved, but the system cannot detect if wrong data is encrypted and transmitted
Solution Approach 1:
The system performs preliminary verification by sending a software routine that instructs the on-board unit to perform defined actions before actual toll data transmission. This preliminary action checks whether the on-board unit contains correct software or hardware, preventing wrong data from being encrypted and transmitted in the first place
Solution Approach 2:
The system implements a feedback mechanism where the on-board unit transmits an answer back to the central unit regarding the results of the defined actions. The central unit compares this answer to an expected answer, providing feedback that confirms whether the on-board unit is functioning correctly and has not been tampered with
2Adaptability or versatility
If the on-board unit software is replaced or the unit itself is exchanged, then system flexibility is improved, but data integrity is compromised
Solution Approach 1:
Before allowing software updates or unit exchanges, the system performs a preliminary verification using a software routine that checks the on-board unit's responses against expected answers. This ensures that any software replacement or unit exchange maintains data integrity by confirming the new software/unit behaves as expected
Solution Approach 2:
The system creates a verification copy of the expected behavior by defining specific actions and expected answers in advance. The on-board unit's actual responses are compared against these pre-established expected answers, allowing verification of software authenticity without restricting legitimate software updates
3Reliability
If regular software updates are performed between the on-board unit and central unit, then system currency is improved, but communication volume and complexity increase
Solution Approach 1:
The verification function is extracted as a separate, dedicated software routine that operates independently from the main toll data transmission protocol. This separation allows regular software updates and verification communications without increasing the complexity of the primary toll collection system
Solution Approach 2:
The software routine serves multiple functions: it verifies the on-board unit's authenticity, checks software currency, and confirms hardware integrity. This multi-functionality reduces the need for separate verification protocols, thereby reducing overall communication complexity while maintaining software currency
Data Source
Figure 1~2
Figure 3
Figure 4
AI summary
A method for operating a central unit (2) in a road toll system comprises sending a verification command or a software routine from the central unit (2) to an on-board unit (1), thereby instructing the on-board unit (1) to perform one or more defined actions and to transmit an answer to the central unit (2) that includes results of the defined actions. The method further comprises waiting for an answer from the on-board unit (1) in response to the verification command or software routine. If an answer is received from the on-board unit (1), the received answer is compared to an expected answer. The on-board unit (1) is classified as not trustworthy if no answer is received or if the received answer differs from the expected answer and the on-board (1) is classified as trustworthy if the received answer matches the expected answer.