WO2020089643A1 - Dispositif automobile - Google Patents

Dispositif automobile Download PDF

Info

Publication number
WO2020089643A1
WO2020089643A1 PCT/GB2019/053098 GB2019053098W WO2020089643A1 WO 2020089643 A1 WO2020089643 A1 WO 2020089643A1 GB 2019053098 W GB2019053098 W GB 2019053098W WO 2020089643 A1 WO2020089643 A1 WO 2020089643A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
obd
dongle
data
information
Prior art date
Application number
PCT/GB2019/053098
Other languages
English (en)
Inventor
Sai LAKSHMI
Christopher TINGLEY
Original Assignee
Caura Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Caura Ltd. filed Critical Caura Ltd.
Publication of WO2020089643A1 publication Critical patent/WO2020089643A1/fr

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0841—Registering performance data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/20—Administration of product repair or maintenance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/01—Customer relationship services
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C2205/00—Indexing scheme relating to group G07C5/00
    • G07C2205/02—Indexing scheme relating to group G07C5/00 using a vehicle scan tool

Definitions

  • Modern vehicles include a physical diagnostic port that can be used to read vehicle diagnostic information from a vehicle.
  • the most common name for such a vehicle port is an On Board Diagnostic (OBD) port.
  • OBD On Board Diagnostic
  • An OBD port is illustrated in Figure la.
  • Specific, wired, handheld diagnostic devices are connect to the port and can read the vehicle diagnostic information directly from the vehicle.
  • the diagnostic information may be displayed on the handheld diagnostic device or logged for later analysis.
  • the information collected by a handheld diagnostic devices is not security held and cannot be accredited.
  • Paper vehicle logbooks describe a service history of a vehicle and are updated when a vehicle is serviced by a technician as read from a vehicle.
  • examples include any combination of the following.
  • An automotive device comprising: a processor; a memory; a network connection; and an On-Board Diagnostic (OBD) connection connectable to an OBD port of a vehicle; wherein the device is operable to detect when the device is detached from an OBD port of a vehicle; and a notification of detachment is transmitted over the network connection when a detachment is detected.
  • OBD On-Board Diagnostic
  • the device is tamper resistant hardware that can transmit verifiable vehicle information.
  • a method of detecting a disconnection of an On-Board Diagnostic (OBD) connection between a device and a vehicle comprising: monitoring an electrical connection between the device and an OBD port of the vehicle and monitoring a hardware switch at the OBD connection.
  • the method is able to identify a type of OBD disconnection that has occurred, preventing and identifying tampering.
  • Figure la is a schematic diagram of an OBD port of a vehicle
  • Figure lb is a three-dimensional illustration of a dongle connectable to an OBD port
  • Figure 2a is a schematic diagram of a system for uploading vehicle information to a remote server
  • Figure 2b is a schematic diagram of hardware of the dongle
  • Figure 3 a schematic diagram of hardware and software modules to provide a secure element of the dongle
  • Figure 4 is a flow diagram of a method performed when a dongle is connected to an OBD port
  • Figure 5 is a flow diagram of a method for when a dongle is disconnected from an OBD port
  • Figure 6 is a schematic diagram of a remote service for processing data collected by a dongle.
  • Figures 7a, 7b and 7c illustrate record data stored in a remote server.
  • Figure la is a female on-board diagnostics (OBD) port pin-out 100 of a vehicle.
  • OBD port is used for reading self-diagnostic information from the vehicle and reading other information reported by the vehicle; data can also be written to the vehicle via the OBD port.
  • OBD ports have been included in vehicles for a number of years and modem OBD implementations use a standardized digital communications port to provide real-time data in addition to a standardized series of diagnostic trouble codes (DTCs), which can identify and be used to remedy malfunctions of the vehicle.
  • DTCs diagnostic trouble codes
  • Modem OBD ports implement an OBD-II interface, while previous implementations use other standard interfaces.
  • OBD port 100 of Figure la is a female connection and has sixteen pins, labelled 1 to 16 in the figure.
  • OBD-II diagnostic connectors have a number of specific pins, such as chassis ground 4, signal ground 5, battery voltage 16, Controller Area Network (CAN) bus High 6, CAN-Low 14, and that can be set to the manufacturer’s discretion.
  • the OBD port is configured to supply power from a vehicle battery sufficient to ran devices attached to the OBD port.
  • SAE 1962 defines the physical connector used for the OBD-II interface, while SAE J1978 defines minimal operating standards for OBD-II scan tools.
  • OBD-II connector In a vehicle, an OBD-II connector is required to be within 0.61 m (2 feet) of a steering wheel unless an exemption was granted to the manufacturer, in which case it must be somewhere within reach of the driver. This ensures that an OBD port and device connected thereto are both accessible from within a vehicle.
  • the SAE J1962 specification states that the battery voltage pin 16 must be unswitched, thereby remaining live even when the ignition is switched off. Further, the battery voltage pin 16 terminal must be able to supply a minimum of 4.0 A.
  • a number of electrical signaling protocols and messaging formats are standardised for use with OBD ports.
  • DTCs compatible with OBD-II are defined in SAE J2012 and are mostly equivalent to ISO 15031-6:2010.
  • a DTC will have a standard format of first a letter to designate a‘family’ (‘P’ to designate the powertrain, e.g. engine or gearbox;‘C’ to designate the chassis; ⁇ ’ to designate the body; and‘U’ to designate the user network).
  • a digit indicates whether the code is generic or manufacturer specific (‘O’ designates a generic fault and‘ G designates a manufacturer fault).
  • This second digit is required as the list of generic DTC codes may not be sufficient for a particular vehicle, so manufacturers can add their own DTC codes as required.
  • Three final digits detail the specific error.
  • the first digit of the final three digits designates a‘sub-family’:‘0’ ,‘ G and ‘2’ for the air/fuel mixture;‘3’ for the ignition system;‘4’ for checking auxiliary emissions; ‘5’ for engine idling;‘6’ for the onboard computer and ancillary outputs;‘7’,‘8’ and‘9’ for the transmission; and‘A’, ⁇ ’ and‘C’ for hybrid propulsion.
  • data can be written to the port.
  • a vehicle computer can transmit vehicle information using the same OBD port. For example, writing‘0902’ to an OBD-II port of a vehicle will cause a Vehicle Identification Number (VIN) to be received from the vehicle's OBD port.
  • VIN Vehicle Identification Number
  • OBD ports were designed for Diagnostic Interface Tools (DITs) to be connected to them in order for a user of the device to read vehicle information and transmit information to the vehicle.
  • DITs Diagnostic Interface Tools
  • a device or dongle 101 for connecting to an OBD port 100 of a vehicle is illustrated in Figure lb.
  • the front right surface of the dongle 101 engages with an OBD port 100 of a vehicle, making electrical contact and allowing a data transfer from and to the dongle via the OBD port to which it is connected.
  • the dongle 101 may partially protrude from the recess.
  • the dongle 101 comprises engagement means extending from a body that contains an electronic system, described in detail later in relation to Figure 2b. Pins of the OBD port provide power to the dongle 101 from a vehicle battery that is sufficient to power the electronic system within the dongle body.
  • the dongle 101 can detect when it is connected to a vehicle OBD port 100 regardless of whether the vehicle ignition switch is powered. Power is supplied by OBD port pins from the vehicle battery, which is detectable by the dongle.
  • the dongle 101 has a disconnection switch 102, which is a physical protrusion on the inside of the engaging means that physically engages an OBD port when the dongle is fully inserted into the OBD port. The state of the disconnection switch 102 is detectable by the dongle 102. In other examples, disconnection switch 102 is not present.
  • FIG. 2a is a schematic diagram of a system for transmitting vehicle information from a dongle 101 within a vehicle 200 to a remote server 201.
  • the information can then be transmitted to other devices including PCs or Macs 202, mobile devices 203 or me made accessible to other devices via a webpage 204.
  • the remote server 201 may communicate to remote devices 200, 202, 203, 204 using an Application Programming Interface (API).
  • API Application Programming Interface
  • the vehicle 200 shown in Figure 2a can be any vehicle that includes an OBD port 100 that the dongle 101 is connectable to. Data is gathered by the dongle 101 via the OBD port, by sensors contained within or on the dongle, and from additional devices connected to the dongle 101 in a wired or wireless manner from within or outside of the vehicle 200.
  • the data gathered may be operated on by the dongle 101 and encrypted prior to transmission to the remote server 201 with which the dongle 101 is registered.
  • Methods of transmitting the data from the dongle 101 within the vehicle 200 include WiFi, Bluetooth®, cellular, Vehicle-to-everything (V2X), which may include Dedicated Short- Range Communications (DSRC).
  • V2X Vehicle-to-everything
  • DSRC Dedicated Short- Range Communications
  • Figure 2b is a schematic diagram of exemplary hardware to provide a dongle
  • the dongle comprises a System-on-a-Chip (SoC) 205, which is an integrated circuit (IC) that integrates all components of a computer or other electronic system. These components typically include a central processing unit (CPU), memory, input/output ports and secondary storage all on a single substrate.
  • SoC will consume less power and take up less IC area than multi-chip designs with equivalent functionality, although such a substitution is included within the scope of this disclosure.
  • the SoC 205 is connected to a number of other functional units including a secure element 220, which itself comprises a processor and optionally may comprise on-board memory. Alternatively or additionally, the secure element shares Random Access Memory (RAM) with the SoC 205, but uses an encrypted portion of the RAM.
  • RAM Random Access Memory
  • the role of the secure element is to store sensitive data including device identity systems implemented in parallel on one or Personally Identifiable Information (PII).
  • PII may include a location history of a vehicle and therefore the location history of its driver.
  • the secure element 220 may also store and manage encryption keys for encrypting and/or decrypting data on the Dongle 101.
  • the secure element may be a proprietary implementation or a third-party solution, such as the ARM TrustZone/SecurCore ⁇ .
  • the secure element 220 may itself generate unique identifiers for transmission to a remote server to identify or encode data.
  • the SoC 205 has a dedicated Power Management Integrated Chip (PMIC)
  • the dongle 101 hardware elements can be run using power supplied by the internal battery 251 or by an external source, which can also charge the battery 101.
  • power management may be controlled by the SoC 205 itself and thereby the Dongle 101 does not include a separate PMIC 250.
  • a Universal Serial Bus (USB) hub 240 is included in some examples and is connected to the SoC 205.
  • the USB Hub 240 may comprise an external USB interface, such as a standard, mini, micro or full duplex connection.
  • the USB interface may be used to power the dongle 101 or battery 251.
  • the USB hub 240 may be used to transmit data to or from an external device for programming the dongle 101, e.g. programming or upgrading software or firmware on the SoC 205 or connected elements.
  • additional sensors are connectable to the dongle 101 via the USB hub 240.
  • the dongle 101 may incorporate a number of hardware sensors, including but not limited to an accelerometer and or a gyroscope 230.
  • the accelerometer measures non-gravitational acceleration and the gyroscope determines orientation of the dongle 101.
  • the gyroscope and accelerometer unit 230 is pre-calibrated to provide accurate sensor readings to the dongle 101.
  • the dongle 101 includes engagement means to connect with an OBD port 100.
  • a dashed line represents the internal features of the dongle 101 with the OBD port 100 being outside the dashed line and therefore exterior to the dongle 101.
  • the SoC 205 may be coupled an OBD port 100 of a vehicle and communicate with the vehicle using the physical connection. Power may be received by a dongle 101 from a connected OBD port 100 and used to power the dongle 101 and/or charge the dongle battery 251 via the PMIC 250.
  • SoC 205 and a state of a physical connection between a dongle 101 and an OBD port 100 is monitored by the SoC 205.
  • the dongle is illustrated in Figure 2b as including a number of wired (OBD and USB) and wireless (cellular 210.
  • GPS Global Positioning System
  • the use of the term GPS is not intended to limit the scope of this feature to that of only the satellite-based radio navigation system owned by the U.S. Government, but should be read to encompass any satellite navigation system and, in some examples, includes multiple satellite navigation systems implemented in parallel on one or more ICs, which can be used in parallel to increase reliability or accuracy of the locating system.
  • the GPS system is a dual frequency GNSS receiver capable of processing satellite signals in both Ll/El and L5/E5 frequency bands providing a highly accurate satellite location system.
  • the GPS system may be provided by a third party chipset in the dongle 101.
  • the cellular communication means comprises a baseband processor 210, RF transceiver 213 and a Subscriber Identify Module (SIM) unit 211.
  • the baseband processor 210 manages radio transmission of cellular communication and required information from the SIM unit 211 to do so.
  • the SIM unit may be a conventional SIM card insertable into the dongle 101, an internal and non removable SIM card built into the device, or an Electronic SIM (eSIM) card, which has a space saving advantage.
  • a SIM unit 211 comprises an integrated circuit that securely stores the international mobile subscriber identity (IMSI) number and its related key to enable cellular communication.
  • the baseband processor 210 is connected to the RF transceiver 213 and coupled to an antenna in order for the dongle 101 to broadcast and receive cellular signals.
  • the cellular signals may relate to 2G, 3G, 4G, 5G and/or related standards.
  • the dongle 101 comprises a WiFi transceiver 214 to communicate with other devices using an Institute for Electrical and Electronic Engineers (IEEE) 802.11 standard.
  • the WiFi transceiver 214 is coupled to an antenna.
  • the dongle 101 further comprises a Bluetooth® transceiver 215 to communicate with other devices using short-wavelength UHF radio waves.
  • the Bluetooth® transceiver 215 is coupled to an antenna.
  • the dongle 101 further comprises a GPS receiver 216 coupled to an antenna.
  • the dongle 101 further comprises a V2X and/or DSCR transceiver 217 coupled to an antenna.
  • the functionality of the V2X or DSCR system may utilize the WiFi hardware instead of having a dedicated transceiver 217 and antenna.
  • Figure 2b illustrates the device having distinct wired and wireless communication devices all coupled to the SoC, it should be understood that one or more of the devices may share some or all of the illustrated hardware in order to reduce the IC footprint, production costs and/or power consumption.
  • the functionality described herein is performed, at least in part, by one or more hardware logic components.
  • illustrative types of hardware logic components include Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs), Application-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), Graphics Processing Units (GPUs).
  • SoC 205 is a computing-based device and comprises one or more processors which are microprocessors, controllers or any other suitable type of processors for processing computer executable instructions to control the operation of the device in order to control the coupled hardware elements illustrated in Figure 2b.
  • the processors include one or more fixed function blocks (also referred to as accelerators) which implement a part of the method of Figure 4 or Figure 5 in hardware (rather than software or firmware).
  • Platform software comprising an operating system or any other suitable platform software is provided at the computing-based device to enable application software to be executed on the device.
  • Computer- readable media includes, for example, computer storage media such as memory and communications media.
  • Computer storage media such as memory, includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or the like.
  • Computer storage media includes, but is not limited to, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM), electronic erasable programmable read only memory (EEPROM), flash memory or other memory technology, or any other non-transmission medium that is used to store information for access by a computing device.
  • communication media embody computer readable instructions, data structures, program modules, or the like in a modulated data signal, such as a carrier wave, or other transport mechanism.
  • computer storage media does not include communication media. Therefore, a computer storage medium should not be interpreted to be a propagating signal per se.
  • the computer storage media (including memory on the SoC 205) is shown within dongle 101 hardware, it will be appreciated that the storage is, in some examples, distributed or located remotely and accessed via a network or other communication link (e.g. using a communication interface, such as the USB hub 240).
  • the input/output controller provided by the USB hub 240 is also arranged to receive and process input from one or more devices, such as a user input device, e.g. a camera, microphone or other sensor.
  • a user input device e.g. a camera, microphone or other sensor.
  • the user input device detects voice input, user gestures or other user actions and provides a natural user interface (NUI). This user input may be used to record ambient sounds associated with an external event.
  • NUI natural user interface
  • the input/output controller or a user input device may comprise NUI technology which enables a user to interact with the computing-based device in a natural manner, free from artificial constraints imposed by input devices such as mice, keyboards, remote controls and the like.
  • NUI technology that are provided in some examples include but are not limited to those relying on voice and/or speech recognition, touch and/or stylus recognition (touch sensitive displays), voice and speech, and machine intelligence.
  • a vehicle 200 itself may include one or more hardware components illustrated in Figure 2b.
  • the hardware element in the dongle 101 can be either not used or may be excluded from the hardware design to reduce the IC footprint of the dongle 101, reduce production costs of the dongle 101 and reduce the power consumption of the dongle 101.
  • Hardware components illustrated in Figure 2b that can be implemented by a vehicle 200 include accelerometers and gyroscopes 230, and/or wireless communication means, e.g. an RF 213, WiFi 214, or Bluetooth® 215 transceiver, or GPS receiver 216.
  • the OBD port 100 can be used to access accelerometer or gyroscopic information or other information collected by the vehicle; alternatively, data may be exchanged with the vehicle via the USB hub 240 or by wireless communication means.
  • the dongle 101 has access to location information using the GPS receiver
  • Figure 3 is an exemplary schematic diagram of software, firmware and hardware modules that provide the secure element 220 of the dongle 101.
  • the secure element 220 provides a tamper-resistant hardware platform, capable of securely hosting applications and storing confidential and cryptographic data. Below is described a boot process for the system of Figure 3.
  • Step 1 Switch on/reset. Check boot hardware with a trusted boot board verifying Device ID, Device Private Key 330. (Not illustrated in the figure rollback prevention fuses to prevent physical tampering of the hardware.) This first boot loader process loads a second level image.
  • Step 2 Trusted Boot Firmware in conjunction with a Crypto Engine 320 and the secure Kernel 310 create a trusted OS Kernel. (Not illustrated in the figure are software rollback prevention measures to prevent tampering.)
  • This second level boot loaders permits Hypervisor and permits an instance of Android or Linux to launch, running from a Linux/ Android partition 301.
  • Step 3 First and third party software operate in a trusted environment on an encrypted user partition 302.
  • the Android® operating system is specifically named, however other operating systems may be implemented to achieve the same result.
  • the file system has two partitions: an encrypted user partition 302 and an Android® partition 301 on which the operating system is stored.
  • the user partition may contain first party software, installed by either the manufacturer or distributer of the dongle 101, and third party software running on the OS to provide data collection, data transfer and/or data processing services.
  • authorization may be given for a further application to be installed on the encrypted user partition 302 e.g. a mapping service.
  • a crypto engine 320 is implemented in hardware to perform cryptographic operations.
  • the benefit of implementing cryptographic function in a hardware module are that the software overhead of the dongle 101 is reduced and actions such as encryption, decryption, and authentication can execute more quickly.
  • FIG. 4 is a flow diagram of a connection method 40 performed when the dongle 101 is connected to an OBD port 100 and the vehicle ignition system is turned on. The connection method 40 begins at connection block 401 when the dongle 101 is powered from a voltage present at the OBD battery voltage pin 16.
  • the SoC begins a boot process 402 and, once the boot and any self-validation is complete, the SoC instructs the PCIM to enter a high power mode 403 to ensure that all modules of the dongle 101 are powered and battery charging begins.
  • the secure element is initialized and validated 404 by the SoC.
  • Data is gathered 405 from sensor modules including the GPS receiver.
  • Data is gathered 405 from the attached OBD port 100 by transmitting requests to the vehicle and receiving the requested information back.
  • the information requested may include an odometer reading from the vehicle, a current speed of the vehicle, and a VIN, which can be validated against a previously received VIN from when the dongle was previously attached to a vehicle.
  • a clock on the SoC is synchronized 406 with the received GPS signal.
  • the dongle registers 408 with a remote server by transmitting data over a wireless communication channel.
  • the wireless communication channel is a cellular channel and the registration data is transmitted via the RF transceiver and antenna.
  • the OBD-dongle connection is checked 409 by monitoring a voltage at the OBD battery voltage pin 16, by monitoring other OBD pins and/or by checking a physical disconnection connection switch 102 of the dongle.
  • a disconnection process 50 begins at disconnection block 501.
  • the disconnection process 50 is illustrated in Figure 5.
  • the encrypted data is transmitted to the remote server 410. Further data is gathered 411, the gathered data including location data, accelerometer information, gyroscopic information and VIN information is cached in SoC 205 memory prior to being transferred to the secure element 220 where it is encrypted by the secure element. The encrypted data is saved to memory and the process rechecks 409 the OBD-dongle physical connection, as previous. The gathering of data 411, encrypting and saving to memory 412 of encrypted data and transmission of the encrypted data to the remote server continues while the OBD-dongle connection is present.
  • Figure 5 is a flow diagram of a disconnection method 50 for when a dongle
  • the disconnection method 50 begins at disconnection block 501.
  • the SoC 205 instructs the PCIM 250 to enter a low power mode 502.
  • the battery 251 is powering the dongle 101 and, in one example, the frequency that encrypted data is transmitted to a remote server is less frequent than when the PCIM is in high power mode in order to reduce power consumption.
  • non-essential modules of the dongle 101 are unpowered.
  • the SoC enters a low power mode, reducing clock speed to reduce power consumption.
  • sensor data and other data gathered by the SoC that had been cached are transferred to the secure element 220 where they are encrypted 503.
  • the encrypted data is saved to memory.
  • the dongle 101 is already registered 408 with the remote server 201 using a wireless communication channel and the encrypted data is transmitted from the dongle 101 to the remote server 201.
  • the OBD-dongle connection is checked 505 by monitoring a voltage at an
  • OBD battery voltage pin 16 by monitoring other OBD pins and/or by checking a physical disconnection connection switch 102 of the dongle 101.
  • a reconnection process 42 begins at reconnection block 421.
  • the reconnection process 42 is illustrated in Figure 4 and begins with the PCIM entering high power mode 422, which is discussed previously in relation to block 403 in the connection process 40. After the PCIM enters high power mode 422, data is gathered at block 405, which is discussed previously in relation to connection process 40.
  • the SoC 205 queries 509 the PCIM 250 for a battery level.
  • a shutdown process begins at shutdown block 511.
  • data stored in volatile memory is saved to non-volatile memory; the last known location of the device is saved to non-volatile memory so that the location information can be used by the dongle in the future to achieve a quicker GPS location lock.
  • Figure 6 illustrates actions performed by the dongle 101.
  • the dongle gathers data from integrated hardware sensors and also by receiving information from a vehicle via the OBD port.
  • the encrypted data is periodically transmitted to a remote server 201 where it is stored in a telematics database 611.
  • the remote server 201 has a device registration database, which holds a device identity (ID) 613 for each dongle, and a device private encryption key 602 for each dongle.
  • ID 613 and device private key 602 for each dongle 101 is recorded when a dongle is manufactured and is not replicated outside the device registration database except in order to decrypt individual pieces of encrypted data.
  • data encrypted by the unique dongle is received by the remote server from the dongle, stored in the telematics database and then retrieved from the telematics database. Also retrieved are the corresponding device ID 613 and device private key 602 for the dongle from the device registration database 612.
  • the telematics information is decrypted 614 using the associated unique device private key 602 and made available in an unencrypted form as record data 615.
  • the record data 615 contains all information received by the remote server 201 that was transmitted to it by the dongle.
  • encrypted data relating to a dongle or to a vehicle to which a dongle is connected is entered into the telematics database 611 by a third party and will also be present on a decrypted record data 615.
  • Figure 7a illustrates encrypted data stored in the telematics database 611, under the headings Journeys and Events.
  • the Telematics Data Journeys and Events
  • the dashed arrow indicates a passage of time, so the individual journeys and events are illustrated linearly.
  • Tinder the Journeys heading in Figure 7a records of a number of journeys are represented pictorially. Each journey has associated metrics (not shown) that may include a start and end point of the journey, a total distance driven during the journey, a total time taken for the journey, detected driving/driver characteristics for the journey, regular speed readings read from the OBD port and/or calculated from GPS location data, average vehicle speed calculations, a VIN number of an attached vehicle read from a vehicle OBD port, an odometer reading at beginning and end of a journey read from the OBD port, etc. Each journey was recorded, encrypted and transmitted to the remote server by a dongle as described above. The first 701, second 702 and third 703 journeys that were recorded and encrypted by a dongle are at the top of the figure, with later recorded j oumey s illustrated underneath in the figure.
  • event types are listed and each is associated with a specific time.
  • the events relate to data captured by a dongle, for example, impacts registered by the accelerometer, erratic driving detected by an accelerometer and/or gyroscope, a vehicle ignition circuit being activated or deactivated, disconnection or reconnection of a dongle to an OBD port along with a time and location, engine warning indicators read from an OBD port, vehicle speed values read from the OBD port, or other events either detected by the dongle device or read from the vehicle OBD sensor.
  • the first recoded event is the Tax event 711, indicating an associated vehicle has been taxed.
  • This tax information may be retrieved from an official database, such as a government database, by the remote server 201 and stored in the telematics database 611, or the tax information may have been added to the telematics database 611 by an accredited person, possibly entering the information in a an application running on a mobile device.
  • the third recorded event is a Collision event 713.
  • the encrypted event information will include details of a vehicular collision detected by the dongle 101 attached to a vehicle.
  • a dongle 101 may also send additional data to the remote server 201 indicating a detected collision, prompting the remote server to perform additional tasks described below.
  • the encrypted and stored events in the events database include any events transmitted by a third party to the remote server 202 to be associated with an individual dongle, user or vehicle.
  • the events transmitted by the third party may relate to, for example: (i) servicing of the vehicle, whereby service information from a garage is encoded and transmitted to the remote server 201 for storing in the telematics database; (ii) legal information, such as the registered owner or change of registered owner may be encrypted and transmitted to the remote server 201 by a third party that may be an official trusted information source; or (iii) parking payment information from a recognised parking service.
  • Figure 7b illustrates an example whereby every time an encrypted journey or event is received at the remote server 201 from a dongle 101 or third party, it is individually stored in the telematics database 611.
  • the telematics database 611 contains a large number of individually encrypted records 72 that relate to a specific dongle, user or vehicle.
  • the individually encrypted records may be arranged in chronological order for archiving purposes by the telematics database 611 as illustrated in Figure 2b, where the first occurring record of the individually encrypted records 72 is ‘Event O’ 721, the second occurring record is‘Journey O’ 722 and‘Event G is the third occurring event. Later occurring event and journeys are illustrated below in the figure.
  • journeys and events in this application; however, only journeys or events may be recoded, encrypted and transmitted by the dongle 101 to the remote server 201, the dongle 101 or remote server 201 may draw no distinction between the data to which the records relate and all items are entered as events, for example, or the dongle 101, remote server 201 or telematics database 611 may draw more distinctions between the types of data to which encrypted items relate to. Alternatively or additionally, single encrypted entries may relate to more than one event/journey or only to a partial event/ journeyney.
  • Figure 7c illustrates another method of storing data in the telematics database
  • Each block in the telematics database 611 contains a cryptographic hash of the previous block, a timestamp, and encrypted event/journey data.
  • This example utilizes a hash tree to structure the block data, but other blockchain methods are equally as applicable and may be used instead.
  • every leaf node is labelled with the hash of a data block and every non-leaf node is labelled with the cryptographic hash of the labels of child nodes.
  • the first block,‘Event O’ is a leaf node.
  • the telematics database 611 contains Event 0 data 731D and Event 0 block information 731B.
  • the Event 0 block information 731B includes a cryptographic hash of Event 0 data 731D.
  • the second block, ‘Journey 0, is a non-leaf node.
  • the telematics database 611 contains Journey 0 data 732D and Journey 0 block information 732B.
  • the Journey 0 block information 732B includes a cryptographic hash of Journey 0 data 732D and block information of its child nodes, i.e. of Event 0 block information 731B.
  • the third block,‘Event 1, is also a non- leaf node.
  • the telematics database 611 contains Event 1 data 733D and Event 1 block information 733B.
  • the Event 1 block information 733B includes a cryptographic hash of Event 1 data 733D and block information of its child nodes, i.e. of Journey 0 block information 732B.
  • the hashing system continues for all blocks associated with an individual dongle, user and/or vehicle therefore the hash tree can be used to verify data stored in the telematics database 611. In addition, the telematics data can be verified if it is transferred in and between computers.
  • the dongle 101 may cache a large number of journeys and events using on board memory before they transmitted to a remote server 201.
  • the frequency of data collection by the dongle 101 and/or encrypted data transmission to a remote server is customisable and can be altered remotely.
  • the frequency of encrypted data transmission from a dongle to a remote server may be made on a journey per journey basis; when connecting to a specific data network or by a specific wireless connection channel, e.g. when connected to WiFi; at regular intervals, e.g. daily, hourly, every 10 minutes, every minute, every second down to every time a single piece of data is available providing near real-time reporting; and alternatively or additionally, a specific event may trigger encrypted data transmission to a remote server, e.g. a disconnection of the dongle from an OBD port, or a detected high level of acceleration or deceleration that may relate to a vehicular collision.
  • a dongle 101 is attached to a vehicle 200 as described. From information available to the dongle from on-board components, from information accessible using on board communication means and from information retrievable from a vehicle via an OBD port, vehicle collision information is detectable and recordable.
  • information retrievable from a vehicle via an OBD may include vehicle accelerometer readings, vehicle gyroscopic readings, bodywork impact sensors, airbag activation, etc. Such information is recorded, encrypted and transmitted to the remote server 201.
  • additional information that a collision has been detected is separately sent to the remote server.
  • the remote server may take steps to decrypt and analyze the received information, categorize the collision based on potential severity (using accelerometer information to detect a deceleration, for example) and then perform additional actions dependent upon the collision categorization.
  • a first additional action may include transmitting a message to a mobile device prompting the user to interact with an application running on the device.
  • the application may prompt the user to enter information relating to the collision.
  • the entered information may include photographs, videos, first and third party driver details, occupant details and any other material details relating to a vehicular incident.
  • the entered information can then be encrypted and transmitted to the remote server 203 for storing and/or further processing.
  • the entered information is added as event information to a telematics database 611, or as an additional type of information category either to a telematics database 611 or to another database.
  • a second additional action may include requesting assistance for the driver and providing collision information, including a location, to the assistor.
  • a remote server 201 stores a large amount of vehicle 200 data that has been encrypted and transmitted by a dongle 101. Some of the information stored by the remote server 201 relates to personally identifiable information (PII). The remote server 201 is able to decrypt the encoded information using information retrieved from a device registration database 612. The decrypted information forms record data 615, however this may include PII data not suitable for distribution to an intended recipient. In addition, the content of the record data 615 may be too great for a practical review by an intended recipient.
  • PII personally identifiable information
  • a report creation system 620 may have (i) a set number of predetermined reporting option that each include or exclude types of data items stored in the telematics databases 61 1 or in record data 615, or (ii) means for receiving data relating to a format of a report to be produced by record creation 620, whereby a list of types of data items and/or a historic data range for data items are specified in the received data.
  • the report creation system 620 received a report specification 621 that specifies details of the report and the action to be taken with the report, i.e. store, transmit internally/externally, or make available via a web interface for a party with specific credentials for a set duration.
  • a first exemplary report format is that of a vehicle log. Some or all of the contents of the report will have been verified as accurate for a vehicle 200 by a dongle 101 that correlated a VIN number using an ODB port of the vehicle.
  • the report may list: distance travelled as detected by the dongle GPS unit; vehicle odometer readings as read from the vehicle via an OBD port; a breakdown of distance travelled under specific conditions, e.g. in an urban environment, on motorways, at high speed, at low speed, etc.; detected collisions and an associated severity; servicing information supplied by a third part service.
  • a second exemplary report format is that of a valuation and will include the details for the first exemplary report and perform additional analysis to estimate the wear that has occurred to a vehicle over a period and, in addition, a residual value or a depreciation in value of the vehicle over a period.
  • a third exemplary report format is that of an accident report and will list information associated with a detected collision.
  • the details include measurements by the dongle device in relation to a collision and information obtained by a vehicle connected to the dongle via an OBD port.
  • the report may include information submitted to an application on a mobile device by a person proximal to the collision.
  • Other types and styles of report relevant to vehicles may be implemented by the report creation 620 using information from the report specification 621 system.
  • the term 'computer' or 'computing-based device' is used herein to refer to any device with processing capability such that it executes instructions. Those skilled in the art will realize that such processing capabilities are incorporated into many different devices and therefore the terms 'computer' and 'computing-based device' each include personal computers (PCs), servers, mobile telephones (including smart phones), tablet computers, set-top boxes, media players, games consoles, personal digital assistants, wearable computers, and many other devices.
  • PCs personal computers
  • servers mobile telephones (including smart phones)
  • tablet computers set-top boxes
  • media players including games consoles
  • personal digital assistants personal digital assistants
  • wearable computers and many other devices.
  • remote server is used herein to refer to any or computer program or a device that provides functionality for other programs or devices.
  • the functionality of the remote server may be distributed across multiple processes or devices.
  • the methods described herein are performed, in some examples, by software in machine readable form on a tangible storage medium e.g. in the form of a computer program comprising computer program code means adapted to perform all the operations of one or more of the methods described herein when the program is run on a computer and where the computer program may be embodied on a computer readable medium.
  • the software is suitable for execution on a parallel processor or a serial processor such that the method operations may be carried out in any suitable order, or simultaneously.
  • a remote computer is able to store an example of the process described as software.
  • a local or terminal computer is able to access the remote computer and download a part or all of the software to run the program.
  • the local computer may download pieces of the software as needed, or execute some software instructions at the local terminal and some at the remote computer (or computer network).
  • a dedicated circuit such as a digital signal processor (DSP), programmable logic array, or the like.
  • DSP digital signal processor

Landscapes

  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Traffic Control Systems (AREA)

Abstract

L'invention concerne un dispositif automobile comprenant : un processeur ; une mémoire ; une connexion réseau ; et une connexion de diagnostic embarqué (OBD) pouvant être connectée à un port OBD d'un véhicule ; le dispositif étant conçu pour détecter lorsque le dispositif est détaché d'un port OBD d'un véhicule ; et une notification de détachement étant transmise sur la connexion réseau lorsqu'un détachement est détecté. Le dispositif automobile est conçu pour détecter une déconnexion d'une connexion OBD entre un dispositif et un véhicule en surveillant une connexion électrique entre le dispositif et un port OBD du véhicule et en surveillant le commutateur matériel au niveau de la connexion OBD.
PCT/GB2019/053098 2018-11-02 2019-10-31 Dispositif automobile WO2020089643A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB1817984.6A GB2578646A (en) 2018-11-02 2018-11-02 Automotive device
GB1817984.6 2018-11-02

Publications (1)

Publication Number Publication Date
WO2020089643A1 true WO2020089643A1 (fr) 2020-05-07

Family

ID=64655684

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2019/053098 WO2020089643A1 (fr) 2018-11-02 2019-10-31 Dispositif automobile

Country Status (2)

Country Link
GB (1) GB2578646A (fr)
WO (1) WO2020089643A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230028917A1 (en) * 2021-07-14 2023-01-26 Secturion Systems, Inc. Secure data transfer over wireless networks using data storage encryptors
US20230282038A1 (en) * 2022-03-02 2023-09-07 Moj.Io, Inc. Mobile compute system with interface verification mechanism and method of operation thereof

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130253760A1 (en) * 2011-12-08 2013-09-26 Michael J. Berman Vehicle Text-Cell Sensor
US20160125669A1 (en) * 2013-05-31 2016-05-05 Tomtom Telematics B.V. Wireless communication devices
US20170228945A1 (en) * 2014-09-29 2017-08-10 Sang J. Lee Telematics system, methods and apparatus for two-way data communication between vehicles in a fleet and a fleet management system
US20180182182A1 (en) * 2015-06-24 2018-06-28 Tomtom Telematics B.V. Wireless Communication Devices

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040249557A1 (en) * 2003-05-28 2004-12-09 Wherenet Corp Vehicle tag used for transmitting vehicle telemetry data
GB2498793B (en) * 2012-01-30 2014-01-01 Eui Ltd Apparatus for monitoring driver behaviour
US9251629B2 (en) * 2013-12-03 2016-02-02 Hti Ip, Llc Determining a time gap variance for use in monitoring for disconnect of a telematics device
EP3523785A4 (fr) * 2016-10-07 2020-05-27 Cyber Physical Systems, Inc. Système et procédé de détection et de notification de conditions de conduite

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130253760A1 (en) * 2011-12-08 2013-09-26 Michael J. Berman Vehicle Text-Cell Sensor
US20160125669A1 (en) * 2013-05-31 2016-05-05 Tomtom Telematics B.V. Wireless communication devices
US20170228945A1 (en) * 2014-09-29 2017-08-10 Sang J. Lee Telematics system, methods and apparatus for two-way data communication between vehicles in a fleet and a fleet management system
US20180182182A1 (en) * 2015-06-24 2018-06-28 Tomtom Telematics B.V. Wireless Communication Devices

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230028917A1 (en) * 2021-07-14 2023-01-26 Secturion Systems, Inc. Secure data transfer over wireless networks using data storage encryptors
US11641398B2 (en) * 2021-07-14 2023-05-02 Secturion Systems, Inc. Secure data transfer over wireless networks using data storage encryptors
US20230282038A1 (en) * 2022-03-02 2023-09-07 Moj.Io, Inc. Mobile compute system with interface verification mechanism and method of operation thereof

Also Published As

Publication number Publication date
GB201817984D0 (en) 2018-12-19
GB2578646A (en) 2020-05-20

Similar Documents

Publication Publication Date Title
GB2578647A (en) Encrypted automotive data
US10970676B2 (en) Vehicle inventory and customer relation management system and method
US20240119768A1 (en) Recording and reporting of driving characteristics with privacy protection
US9886800B2 (en) Engine state detection device
US10255606B2 (en) Method and system for authenticating a driver for driver compliance
US8706318B2 (en) Docking terminal and system for controlling vehicle functions
KR102471498B1 (ko) 차량을 진단하는 전자 장치 및 방법
CN109890004B (zh) 具有增强的隐私的安全的车辆数据管理
US8825280B2 (en) Vehicle data storage system, vehicle data storage apparatus, vehicle data storage server, and vehicle data storage method
CN111295862A (zh) 用于密码地保证车辆身份的系统和方法
AU2016282349A1 (en) Wireless communication devices
CN105474274A (zh) 无线通信装置
WO2020089643A1 (fr) Dispositif automobile
US20130253760A1 (en) Vehicle Text-Cell Sensor
US20190206151A1 (en) On-board device adapted to acquire data relating to motion and/or driving parameters of a vehicle
KR102170247B1 (ko) 블록체인 기반 차량 마일리지 위변조 방지 시스템 및 장치
US20060170531A1 (en) Next generation vehicle keys
US11544408B2 (en) Method and system for managing vehicle generated data
CN101837732A (zh) 一种防疲劳驾驶安全控制系统
US11203325B2 (en) System and method for identifying a driver of a vehicle after the vehicle has been started
CN109255260B (zh) 一种北斗警用安全终端处理方法
CN115484028A (zh) 车辆用认证控制装置、车辆控制系统、车辆、车辆用认证处理方法
RU162376U1 (ru) Тахограф
CN117935386A (zh) 一种车载单元及电子收费系统
CN115135537A (zh) 车载装置及服务器

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19798371

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19798371

Country of ref document: EP

Kind code of ref document: A1