GB2578646A - Automotive device - Google Patents

Abstract

An automotive device 101 has a processor, a memory, a network connection and an On-Board Diagnostic (OBD) connection connectable to an OBD port of a vehicle. The device is operable to detect when the device is detached from an OBD port of a vehicle. A notification of detachment is transmitted over the network connection when a detachment is detected. Disconnection can be detected by monitoring an electrical connection between the device and an OBD port of the vehicle and monitoring a switch at the OBD connection. A second invention relates to a method of detecting a disconnection of an OBD connection by monitoring an electrical connection and a hardware switch at the OBD connection.

Description

AUTOMOTIVE DEVICE

BACKGROUND

[0001] Modem 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. 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.

[0002] 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.

[0003] The embodiments described below are not limited to implementations which solve any or all of the disadvantages of known vehicle diagnostic or monitoring devices. SUMMARY [0004] The following presents a simplified summary of the disclosure in order to provide a basic understanding to the reader. This summary is not intended to identify key features or essential features of the claimed subject matter nor is it intended to be used to limit the scope of the claimed subject matter. Its sole purpose is to present a selection of concepts disclosed herein in a simplified form as a prelude to the more detailed description that is presented later.

[0005] In addition to the other examples described herein, examples include any combination of the following.

[0006] 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. The device is tamper resistant hardware that can transmit verifiable vehicle information.

[0007] 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.

[0008] Many of the attendant features will be more readily appreciated as the same becomes better understood by reference to the following detailed description considered in connection with the accompanying drawings.

DESCRIPTION OF THE DRAWINGS

[0009] The present description will be better understood from the following detailed description read in light of the accompanying drawings, wherein: 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; and Figures 7a, 7b and 7c illustrate record data stored in a remote server.

[0010] Like reference numerals are used to designate like parts in the accompanying drawings.

DETAILED DESCRIPTION

[0011] The detailed description provided below in connection with the appended drawings is intended as a description of the present examples and is not intended to represent the only forms in which the present example are constructed or utilized. The description sets forth the functions of the example and the sequence of operations for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.

[0012] Although the present examples are described and illustrated herein as being implemented in a vehicular system, or a server and device system, the systems described are provided as examples and not limitations. As those skilled in the art will appreciate, the present examples are suitable for application in a variety of different types of vehicular systems and server and device system.

[0013] Figure la is a female on-board diagnostics (OBD) port pin-out 100 of a vehicle. The 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 modern 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. Modern OBD ports implement an OBD-11 interface, while previous implementations use other standard interfaces.

[0014] OBD port 100 of Figure la is a female connection and has sixteen pins, labelled 1 to 16 in the figure. According to the Society of Automotive Engineers (SAE) J1962 specification, 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 run devices attached to the OBD port. Other SAE standards exist that relate to other aspects of OBD ports. SAE 1962 defines the physical connector used for the OBD-II interface, while SAE 11978 defines minimal operating standards for OBD-II scan tools. Other standard relating to OBD ports will be known to the person skilled in the art and related standards will be encompassed in their knowledge. In a vehicle, an OBD-1I 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. [0015] 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 12012 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; 'B' to designate the body; and U' to designate the user network). Second, a digit indicates whether the code i s generic or manufacturer specific (O' designates a generic fault and '1' 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' , '1' 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', 'B' and 'C' for hybrid propulsion.

[0016] As well as receiving DTC information from an OBD port, data can be written to the port. In response to received written data at an OBD 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.

[0017] 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.

[0018] 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 10 I 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. Depending upon a depth of a recess in which the OBD port is located in a vehicle, 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.

[0019] 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. In the example illustrated in Figure lb, 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.

[0020] Figure 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). 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).

[0021] Figure 2b is a schematic diagram of exemplary hardware to provide a dongle 101. 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. A 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. The role of the secure element is to store sensitive data including device identity systems implemented in parallel on one or Personally Identifiable Information (PI I). Pll 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/SecurCore0. The secure element 220 may itself generate unique identifiers for transmission to a remote server to identify or encode data.

[0022] The SoC 205 has a dedicated Power Management Integrated Chip (PMIC) 250 to manage the power to the dongle 101 hardware components and a battery 251. The charging and discharging of the battery 251 is managed by the 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. In a further example, power management may be controlled by the SoC 205 itself and thereby the Dongle 101 does not include a separate PM IC 250.

[0023] 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. In some examples, additional sensors are connectable to the dongle 101 via the USB hub 240.

[0024] 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.

[0025] As illustrated in Figure I b, the dongle 101 includes engagement means to connect with an OBD port 100. In the figure, 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.

[0026] The disconnection switch 102 illustrated in Figure lb is connected to the SoC 205 and a state of a physical connection between a dongle 101 and an OBD port 100 is monitored by the SoC 205.

[0027] The dongle is illustrated in Figure 2b as including a number of wired (OBD and USB) and wireless (cellular 210. WiFi 214, Bluetooth 215, Global Positioning System (GPS) 216 and V2X/DSRC 217) communications means. 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.

[0028] In one example, the GPS system is a dual frequency GNSS receiver capable of processing satellite signals in both Ll/E1 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.

[0029] Specific wireless communications means are represented in the example illustrated in Figure 2b, but the dongle 101 should not be understood to be limited to only possessing such communications means. Alternative or equivalent communication means as those described may be included, and communication means illustrated in or described in relation to Figure 2b may be excluded in a given example. The cellular communication means comprises a baseband processor 210, RF transceiver 213 and a Subscriber Identify Module (SIM) unit 21L 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 (eSEM) card, which has a space saving advantage As will be appreciated by the skilled addressee, 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 Bluetooth0 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. In some example, the functionality of the V2X or DSCR system may utilize the WiFi hardware instead of having a dedicated transceiver 217 and antenna. Although 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.

[0030] Alternatively, or in addition, the functionality described herein is performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that are optionally used include Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASIC s), Application-specific Standard Products (AS SPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), Graphics Processing Units (GPUs).

[0031] 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. In some examples, for example where a system on a chip architecture is used, 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.

[0032] The computer executable instructions are provided using any computer-readable media that is accessible by the SoC 205, a computing based 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. In contrast, 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. As defined herein, computer storage media does not include communication media. Therefore, a computer storage medium should not be interpreted to be a propagating signal per se.

Although 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).

[0033] 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. In some examples 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.

[0034] 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. Examples of 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.

[0035] in one example, a vehicle 200 itself may include one or more hardware components illustrated in Figure 2b. In such an example, 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.

[0036] The dongle 101 has access to location information using the GPS receiver 216 to gather location information, or by using other wireless signals to triangulate location information. In addition, the dongle 101 remains powered by the OBD port 100 while the engine is switched off, allowing the dongle 101 to function regardless of the engine state while the dongle 101 is within the OBD port 100. The dongle 101 may also function while it is disconnected from the OBD port, but being powered by the onboard battery 251 instead of having power supplied by the vehicle via the OBD port.

[0037] 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.

[0038] 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.

[0039] 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.

[0040] Step 3: First and third party software operate in a trusted environment on an encrypted user partition 302.

[0041] In this example, 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. In some examples, authorization may be given for a further application to be installed on the encrypted user partition 302 e.g. a mapping service.

[0042] 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.

[0043] A device ID for the dongle 101 and a private key for encrypting data with the crypto engine 320 are stored in the hardware 330 in the secure element 220. To enhance security, the device ID and device private key 330 are only accessible to the crypto engine, not the kernel 310 or file system 300 [0044] Figure 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. Gathered data including location data, accelerometer information, gyroscopic information and V1N information is cached in SoC memory prior to being transferred to the secure element where it is encrypted by the secure element. The encrypted data is saved to memory either on the secure element, on the SoC or in an area of SoC memory itself encrypted and reserved for use by the secure element. The dongle registers 408 with a remote server by transmitting data over a wireless communication channel. In one example, 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.

[0045] If an OBD-dongle disconnect is detected, a disconnection process 50 begins at disconnection block 501. The disconnection process 50 is illustrated in Figure 5.

[0046] If an OBD-dongle disconnect is not detected, 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.

[0047] Figure 5 is a flow diagram of a disconnection method 50 for when a dongle 101 is disconnected from an OBD port 100 as described in relation to Figure 4. The disconnection method 50 begins at disconnection block 501. The SoC 205 instructs the PCIM 250 to enter a low power mode 502. In the low power mode, 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 KIM is in high power mode in order to reduce power consumption. In other examples, non-essential modules of the dongle 101 are unpowered. In a further example, the SoC enters a low power mode, reducing clock speed to reduce power consumption. After the SoC 205 instructs the PCIM 250 to enter a low power mode 502, 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 sewer 201 using a wireless communication channel and the encrypted data is transmitted from the dongle 101 to the remote sewer 201.

[0048] 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.

[0049] If an OBD-dongle reconnection is detected, 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.

[0050] If an OBD-dongle reconnection 505 is not detected, data is gathered 507 and the gathered data including location data, accelerometer information, gyroscopic information and VIN information is cached in SoC 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 until it is transmitted 509 to the remote sewer over a wireless channel.

[0051] The SoC 205 queries 509 the PCIM 250 for a battery level.

[0052] If the battery level is below a predetermined critical threshold 510, a shutdown process begins at shutdown block 511. In the shutdown process, 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.

[0053] If the battery level is not below a predetermined critical threshold 510, the gathering of data 507, encrypting and saving to memory 508 and transmission 509 of encrypted data to the remote server is repeated.

[0054] 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. A device private key 602 held by the dongle secure element and is used to encrypt the data 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. The device 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. To access telematics data held in the telematics database 211 for a unique dongle, data encrypted by the unique dongle is received by the remote sewer from the dangle, 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.

[0055] In one example, 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.

[0056] Figure 7a illustrates encrypted data stored in the telematics database 611, under the headings Journeys and Events. The Telematics Data (Journeys and Events) in the figure will relate to the record data 615 decrypted by the data decryption block 614 in Figure 6. The dashed arrow indicates a passage of time, so the individual journeys and events are illustrated linearly.

[0057] Under 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 YIN 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 journeys illustrated underneath in the figure.

[0058] Under the Events heading in Figure 7a, 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.

[0059] 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.

[0060] 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. In addition to the encrypted Collision event 713, 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.

[0061] In additional to the aforementioned events, 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.

[0062] Figure 7b illustrates an example whereby even* 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. In this example, the telematics database 6t I 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 0' 721, the second occurring record is 'Journey 0' 722 and 'Event l' is the third occurring event. Later occurring event and journeys are illustrated below in the figure. It should be noted that a distinction is drawn between 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/journey.

[0063] Figure 7c illustrates another method of storing data in the telematics database 611 as a blockchain 73 comprising a number of blocks. 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. In this tree structure, 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. In the example in Figure 7c, the first block, 'Event 0', is a leaf node. The telematics database 611 contains Event 0 data 731D and Event 0 block information 731B. As a leaf node, 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. As a non-leaf node, 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. As a non-leaf node, 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 7328. 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.

[0064] The dongle 101 may cache a large number of j ourneys 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 sewer, 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.

[0065] 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 onboard communication means and from information retrievable from a vehicle via an OBD port, vehicle collision information is detectable and recordable. In such a scenario, 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 sewer 201.

[0066] In one example, 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.

[0067] Implementing a blockchain enables independent verification of vehicle mileage and an estimate of vehicle condition to be shared with third parties, such as leasing companies in order for them to verify the mileage of a vehicle.

[0068] 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 (P11). 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 PH 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. To overcome this issue, a report creation system 620 is provided that may have (i) a set number of predetermined reporting option that each include or exclude types of data items stored in the telematics databases 611 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.

[0069] 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.

[0070] 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.

[0071] 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.

[0072] 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.

[0073] The term '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.

[0074] 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.

[0075] This acknowledges that software is a valuable, separately tradable commodity. It is intended to encompass software, which runs on or controls "dumb" or standard hardware, to carry out the desired functions. It is also intended to encompass software which "describes" or defines the configuration of hardware, such as HDL (hardware description language) software, as is used for designing silicon chips, or for configuring universal programmable chips, to carry out desired functions.

[0076] Those skilled in the art will realise that storage devices utilized to store program instructions are optionally distributed across a network. For example, 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. Alternatively, 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). Those skilled in the art will also realize that by utilizing conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a digital signal processor (DSP), programmable logic array, or the like.

[0077] Any range or device value given herein may be extended or altered without losing the effect sought, as will be apparent to the skilled person.

[0078] Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

[0079] It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. The embodiments are not limited to those that solve any or all of the stated problems or those that have any or all of the stated benefits and advantages. It will further be understood that reference to 'an' item refers to one or more of those items.

[0080] The operations of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. Additionally, individual blocks may be deleted from any of the methods without departing from the scope of the subject matter described herein. Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the effect sought.

[0081] The term 'comprising' is used herein to mean including the method blocks or elements identified, but that such blocks or elements do not comprise an exclusive list and a method or apparatus may contain additional blocks or elements.

[0082] It will be understood that the above description is given by way of example only and that various modifications may be made by those skilled in the art. The above specification, examples and data provide a complete description of the structure and use of exemplary embodiments. Although various embodiments have been described above with a certain degree of particularity, or with reference to one or more individual embodiments, those skilled in the art could make numerous alterations to the disclosed embodiments without departing from the scope of this specification.

Claims (22)

1. CLAIMS: 1. 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.
2. 2. The device of claim 1, wherein the detachment of the device from an OBD port is detected using electrical sensing of pins of the OBD connection.
3. 3. The device of claim I or claim 2, further comprising a physical switch to detect if the device is either attached or detached from the OBD port of the vehicle.
4. 4. The device of any preceding claim, wherein the notification of detachment identifies if the detachment is a loss of data from a pin of the OBD port or a physical removal of the device from the OBD port.
5. 5. The device of any preceding claim, further comprising an accelerometer, wherein information generated by the accelerometer is transmitted over the network connection.
6. 6. The device of any preceding claim, further comprising a gyroscope, wherein information generated by the gyroscope is transmitted over the network connection.
7. 7. The device of any preceding claim, further comprising a location detection system, wherein location information is transmitted over the network connection.
8. 8. The device of any preceding claim, further comprising a battery, wherein the battery is arranged to power the device.
9. 9. The device of any preceding claim, wherein the device is arranged to transmit information over the network connection at a predetermined interval.
10. 10. The device of any preceding claim, wherein the device is arranged read a Vehicle Identification Number (VIN) from an OBD port of a vehicle.
11. 11. The device of claim 10, wherein the device is arranged to compare the read VIN number to a YIN stored in memory.
12. 12. The device of claim 10 or claim 1 1, wherein the device is arranged to transmit the read VIN over the network connection.
13. 13. The device of any preceding claim, wherein the device is arranged read an odometer reading of a vehicle from an OBD port of the vehicle.
14. 14. The device of claim 13, wherein the device is arranged to transmit the read odometer reading over the network connection.
15. 15. The device of claim any preceding claim, wherein the device is arranged read airbag deployment information from an OBD port of a vehicle and, if airbag deployment is detected, transmit airbag deployment information and location information over the network connection.
16. 16. The device of any preceding claim, wherein when the device is operable to detect a collision of a vehicle coupled to the OBD port and transmit collision information over the network connection.
17. 17. The device of any preceding claim, wherein the processor is arranged to encrypt data prior to transmission of the data over the network connection.
18. 18. The device of claim 17, wherein data is encrypted using an encryption key stored in memory.
19. 19. The device of any preceding claim, further comprising a tamper-resistant hardware platform operable to store cryptographic data.
20. 20. The device of claim 19, wherein data is encrypted using the tamper-resistant hardware platform.
21. 21. 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.
22. 22. The method of claim 21, further comprising: transmitting disconnection information over the network connection if a disconnection is detected.