Patent ID: 12219039

DETAILED DESCRIPTION OF THE INVENTION

In order that embodiments of the disclosure may be clearly understood and readily carried into effect, certain embodiments of the disclosure will now be described in further detail with reference to the accompanying drawings. The description of these embodiments is given by way of example only and not to limit the scope of the disclosure. It will be understood that when an element or layer is referred to as being “on”, “connected to”, “coupled to”, or “adjacent to” another element or layer, it can be directly on, connected, coupled, or adjacent to the other element or layer, or intervening elements or layers may be present. In contrast, when an element is referred to as being “directly on,” “directly connected to”, “directly coupled to”, or “immediately adjacent to” another element or layer, there are no intervening elements or layers present.

FIG.1is an illustrative diagram of a remote vehicle communications system according to some embodiments. A vehicle-side communications device120is connected to the on-board diagnostics (OBD) system of a vehicle100. In some embodiments, the vehicle-side communications device120is connected through a built-in connector (e.g., 16-pin connector215ofFIG.2A) of vehicle100. The vehicle-side communications device120may be further connected to a wide-area network (WAN)125(e.g., the internet) such as through a network adapter. A diagnostics/programming tool150(e.g., a “scan tool”) is connected to a tool-side communications device140that is further connected to WAN125.

Tool150may be a computer installed with diagnostics/programming software configured to perform diagnostics/programming on a vehicle (e.g., vehicle100) through a vehicle's OBD system. Tool150may be a tool system (e.g., a networked system of computers/devices) that includes multiple tools configurable/selectable for use with multiple types of vehicles. Tool150may also be a dedicated (e.g., mobile/hand-held) scan tool. The device and/or software may be authorized/produced by the vehicle's manufacturer (e.g., an OEM scan tool) and designed to establish a direct/local bi-directional connection with the vehicle (e.g., directly through a built-in OBD connector). A network server130and an associated database system160may be connected through a local area network (LAN)145and/or WAN125to assist with operation/updating of tool150, the vehicle-side communications device120, and/or tool-side communications device140. Database system160may be configured for distribution/maintenance of configurations and/or tools for performing diagnostics/programming on a wide variety of years/makes/models of vehicles and their OBD systems.

Tool-side device140and vehicle-side device120are configured to communicate with each other and thereby facilitate communications between a tool150and the OBD system of vehicle100. In some embodiments, a connection between tool-side device140and a vehicle-side device120is used to simulate or mimic a direct-wired connection between vehicle100and tool150. In order to communicate with the vehicle's OBD system, a tool-side device is configured to determine the communication bitrate of the OBD system such as further described herein. In some embodiments, the bitrate is determined by monitoring communications transmitted from the OBD system and analyzing the toggling of bit states of the communication signal over known time intervals.

In some embodiments, additional remote devices (e.g., remote device) may be used to operate, configure, and/or communicate with tool-side device140, tool150, server170/database system160, vehicle-side device120, and/or vehicle100through WAN125and/or LAN145. For example, a remote vehicle shop may use a remote user/shop device110to facilitate/observe a remote programming/diagnostics session between tool150and vehicle100.

FIG.2Ais an illustrative diagram of a vehicle-side communications device according to some embodiments. Vehicle-side device200is configured to communicate with vehicle210such as through the vehicle's OBD system. Vehicle-side device may include a cable and connector215adapted to directly plug into a vehicle's OBD connector (e.g., a standardized 16-pin connector). The vehicle's OBD system may communicate signals through the connector by signaling different pins as “on” or “off” to reflect, for example, a 1 or 0 bit, and modulate or maintain these states at particular frequencies (or bitrates). Vehicle-side device200is configured to adapt to the bit-rate of the vehicle's OBD system in order to effectively read the communications from the OBD system and forward them to a tool-side device (e.g., tool-side device140ofFIG.1). Tool-side device140may also need to adapt its communications with tool150to reflect the bitrate used by the vehicle.

FIG.2Bis an illustrative block diagram of the computing components of a vehicle-side communications device according to some embodiments. Computing components220include a microprocessor240, display225and input circuitry230. Microprocessor240in turn includes read only memory (ROM)245, memory registers250, and timer circuitry or clock255which are used to monitor/track the timing of signal changes from connected OBD systems in order to determine their bitrates such as further described herein.

Vehicle communications interface265may include an OBD connection interface (e.g., for connecting through a cable and connector215). Vehicle communications interface265may include a pin selector260which activates/deactivates communication through particular pins (e.g., 1 through 16 as shown in connector215), which may be configured to correspond with the pins used by a particular vehicle/OBD system being communicated with. In some embodiments, the pin selector is configured based on information (e.g., a database with records of VINs and pin configurations) for connecting with the particular vehicle210. A network interface235is utilized to communicate with other systems through a network (e.g., across WAN125), including with a remote tool-side communications device (e.g., tool-side device140) and further with a connected programming/diagnostics tool (e.g, tool150ofFIG.1).

A microprocessor240may be programmed with instructions to determine the bitrate of communications received from a vehicle OBD system such as by using hardware-driven interrupts and memory registers250. The programming may be first loaded into RAM270, transmitted from an external and/or internal storage device (e.g., disk drive, Cloud storage), and executed by microprocessor240. In some embodiments, other components of device200and/or external connected devices (e.g., servers, network devices, storage devices and others that are not shown) may be configured to implement the features and processes described herein alone or in combination with device200.

A computer display225(e.g., as shown in device200) may be used to provide status messages about the communications process and/or other information. User input/output (I/O)230(e.g., mouse, keyboard) may be used by an operator to control the vehicle communications device200such as to initiate communications, select parameters, and/or perform/program other operations. In some embodiments, computer display225operates as an I/O device (e.g., a touchscreen).

Vehicle-side device is configured to convert communications from vehicle210into packets that can be communicated to a remote tool-side device through a network interface235. Likewise, network interface235may receive packets from a tool-side communication device/tool and convert those packets into corresponding pin signals that are transmitted to the vehicle's OBD system via connector215. In some embodiments, a tool-side communications device may be configured in similar fashion to device200in order to communicate with a tool.

FIG.3is a process flow diagram for remotely communicating with an onboard vehicle diagnostics system according to some embodiments. At block310, a connection is established between vehicle-side communications device(s) (e.g., device120ofFIG.1) and tool-side communications device(s) (e.g., device140ofFIG.1). A network server (e.g., server130ofFIG.1), for example, may assist with facilitating connections between the devices (e.g., for establishing links, parameters, etc.). In some embodiments, numerous vehicle-side and tool-side devices are connected/available through one or more networks (e.g., LAN145and WAN125). At block320, the vehicle-side and tool-side communications devices (e.g., communications devices120and140) are paired with each other for facilitating a communications session (e.g., between a tool150and a vehicle100). That way, for example, communications between communications devices not intended for each other can be ignored/dismissed.

At block330, a vehicle-side communications device is connected with a vehicle in order to perform communications between the vehicle and tool via tool-side and vehicle-side communications devices. The connection may be through a vehicle OBD pin connector, for example, and a cable extending between the connector and a vehicle-side communications device.

For some vehicle diagnostics systems, the communications bit rate of a vehicle or tool is not published or standardized (e.g., as many that operate under the general CAN Protocol). In some embodiments, performing scans/programming with a particular tool commences by first determining the bit rate of the vehicle diagnostics system and/or tool. In some vehicle diagnostics systems, the bitrate of a vehicle OBD/CAN system or tool is standardized or published such as with those compliant with certain standardized protocols (e.g., in compliance with the OBD-II standard).

At block340, the bitrate of the vehicle OBD system and/or tool is determined so that the vehicle-side or tool-side communications device can communicate with the vehicle and/or tool. In some embodiments, information about the vehicle (e.g., VIN number, make/model/manual entry) is utilized to configure a vehicle-side device/tool-side device to use the proper bitrates, protocol parameters, and/or tools for communicating with the vehicle. In such instances, some embodiments proceed without independently determining the bitrate by monitoring/analyzing bit-streams such as further described herein. In some embodiments, the bitrate used by the vehicle OBD system cannot be determined without obtaining additional information about the OBD system.

In some embodiments, the bitrate of the vehicle OBD system or tool is determined by monitoring communications from the vehicle OBD system or tool. The vehicle-side or tool-side device may be configured with a built-in timer and registers (e.g., timer255and registers250ofFIG.2B) in which changes in the states (e.g., bit states of the pins) of communications from the OBD system trigger the communications device to record the timing of the changes (e.g., falling or rising) in the registers (e.g., as shown inFIG.5). The recorded timing differences of the changing states are then analyzed to identify the bit-rate of OBD communications from the vehicle. In some embodiments, information about the protocol used by the vehicle or tool (e.g., a bit-stuffing protocol) is used to determine the bitrate as further described herein.

At block350, the protocol and programming parameters of the OBD system are determined to facilitate communications using the identified bitrate. The protocol and parameters may be determined based on known information about the vehicle (e.g., VIN number, make/model/manual entry) or based on communications monitored from the OBD system/tool using the identified bitrate. For example, monitoring and parsing certain communications from the vehicle/tool may be indicators of certain protocols.

At block360, if not already selected, a tool-side device (e.g., diagnostics scan tool, vehicle programming tool) is selected for performing diagnostics and/or programming on the vehicle through the communications link between the tool-side communications device and the vehicle-side communications device. The tool may be selected (or configured) based on the determined bitrate and/or programming/protocol parameters so as to be compatible with the vehicle OBD system.

At block370, using the determined bitrate between the vehicle-side device and vehicle and using the selected tool, diagnostics and/or programming are performed via the communications link between the tool-side communications device and vehicle-side communications device. In some embodiments, the bitrate between the tool-side device and tool is configured to be the same as that used between the vehicle-side device and vehicle (or vice versa) so as to mimic a direct communication between the tool and vehicle.

FIG.4is a process flow diagram for remotely communicating with an onboard vehicle diagnostics system according to some embodiments. At block410, network communications are established between a vehicle-side communications device and a tool-side communications device. The tool-side device (and/or a network server) may be configured to identify/authenticate the vehicle-side device by a unique identifier (e.g., a hard-coded identifier in ROM of the vehicle-side communications device).

At block420, a vehicle-side and/or tool-side communications device is connected to the connector of a vehicle OBD system (e.g., a 16-pin connector215ofFIG.2A). In some embodiments, the vehicle-side communications device has a connector (e.g., 16-pin connector) compatible with that of the vehicle's OBD connector. Prior to forwarding communications to a remote tool, the vehicle-side communications device is used to determine/confirm the bitrate of the vehicle's OBD system.

At block430, the vehicle-side or tool-side communications device monitors communications transmitted from the OBD connector in a “listening mode.” In some embodiments, the communications received from a vehicle by a vehicle communications device during the listening mode are not forwarded to a tool-side communications device. For example, because the bitrate of the vehicle may not have been determined, these communications may not be properly transferred.

At block440, the bits received from the vehicle during the listening mode are analyzed in order to calculate/determine the bitrate used by the vehicle's OBD/CAN system. These bits may be analyzed by monitoring the state (e.g., high or low) of an output channel (e.g., pin of a pin connector) of the vehicle. In some embodiments, a timing circuit (e.g., clock/circuit255ofFIG.2B) of the vehicle-side communications device operates to increment clock cycles (e.g., each increment representing a number of nanoseconds) during the listening mode. In some embodiments, the vehicle/tool-side communications device is configured to be triggered (e.g., by hardware-driven interrupts) to record the clock count by the timing circuit when the signal state of a pin toggles (i.e., from low to high or high to low).

At block450, the widths of signal pulses are estimated based on analyzing the timing of the bit state changes. For example,FIG.5shows an illustrative chart of signals and device registers used for determining the bitrate of a communications device according to some embodiments. An “A” register is used to record a first change in pin state (e.g., high to low or low to high) while a “B” register is used to record the next change of pin state. In some embodiments, an interrupt handler is responsible for reading the values from the registers and calculating the difference between them to determine the width of a pulse in timer ticks (and thereby total time). Multiple pulse widths for multiple signals may be calculated.

Referring again toFIG.4, at block460, based on the width(s) of bit pulse(s) estimated at block450, the bitrate of the OBD system is determined. In some embodiments, after a number of pulse widths are measured, certain bitrates are eliminated as possibilities to the point where a single possible bitrate is identified. For example, if a pulse width of two microseconds is detected among the possibilities ofFIGS.6B and7, the only remaining possibility is a bitrate of 500 KHz.

In some embodiments, information about the standards or boundary conditions used by the vehicle OBD/tool system (e.g., a bit-stuffing protocol) are used to determine or accelerate determination of the bitrate of the OBD system. For example, if a particular vehicle make and model are known to use only a subset of possible bitrates, this information may be used to narrow the possibilities of bitrates with the recorded pulse widths.

Referring toFIG.6A, for example, an OBD/tool system may be known to use a particular synchronization protocol regardless of bitrate. In some OBD systems, to maintain synchronization between two controllers, for example, a bit stuffing protocol is used that sets a maximum consecutive/successive number (e.g., five) of bits of the same polarity. As shown inFIG.6A, after5consecutive bits of the same polarity, an opposite polarity bit is inserted. This bit is inserted by the sending controller and removed in the receiving controller and is not part of the data being transmitted.FIG.6Aillustrates a stream of bits showing the logic-level bit stream having the stuffed bits shown as “X”. While bit stuffing is designed for synchronization, some embodiments utilize the maximum number of consecutive bits to accelerate determination of the bit rate.

FIG.6Bis a table of bitrates and the number of respective bits transmitted during a particular time period. In an embodiment, a select number of possible bit rates are possible for a given OBD system that utilizes a 5-bit stuffing protocol. The table ofFIG.6Bindicates the time interval for particular numbers of bits to be transmitted for each given possible bit rate whileFIG.7indicates the corresponding clock cycles using with a 16 MHz clock.

At block470, using the bitrate determined at block460, bidirectional communications are established between the vehicle and a tool through the vehicle-side communications device and the remote tool-side communications device. In some embodiments, the selected bitrate is confirmed such as by monitoring the communications utilizing the selected bitrate and determining that errors do not repeatedly arise indicative of an incorrect bitrate.

FIG.8is a process flow diagram for selecting a bit rate among possible bit rates of an onboard vehicle diagnostics system according to some embodiments. At block810, the process for determining the bitrate of a vehicle OBD (or a tool) system begins after a vehicle-communications device is connected to the OBD system (or a tool-side communications device is connected to a tool). The vehicle-communications device is configured to monitor changes in the states of bit signals (e.g., from an OBD connector). At block820, a free-running clock (e.g., clock255ofFIG.2B) is started which cycles (“ticks”) at a known frequency (e.g., 16 MHz). In some embodiments, the speed/frequency of the clock used/selected is based on the greatest possible bit rate expected of the on-board diagnostics system. In some embodiments, the clock frequency is adjusted/selected to be at least about twice that of the greatest possible bit rate expected of the vehicle OBD system. For example, where the greatest expected frequency of the vehicle OBD system is 500 KHz, the clock speed/frequency should be at least about 1 MHz, and a 4 MHz clock may be utilized for bit rate determination rather than a 16 MHz clock. One of ordinary skill in the art will recognize that there are a variety of ways to determine and adjust to a variety of clock speeds/frequencies.

At block830, using the monitoring of changes in bit-states, a first (falling/rising) edge of the bit stream signal is detected. When the edge is detected, the number of clock cycles is recorded in computer memory. In some embodiments, an interrupt-driven process records the tick count of the clock in a memory register when a falling or rising edge of a bit-stream signal is detected (e.g., as illustrated inFIG.5). At block840, a second edge of a pair of edges of the bit-stream signal is detected and the number of clock cycles associated with the second edge is recorded in memory.

At block850, after the second edge is recorded in response to an interrupt, the difference in recorded clock counts is calculated and the width of the pulse representing one or more bits is estimated based on the clock frequency. In some embodiments, various factors may impact the precision of the calculated pulse widths including, for example bus capacitance, clock differences between controllers, and alignment of the pulses with clock transitions of the OBD system.

In some embodiments, a tolerance (e.g., +5% tolerance) is utilized when estimating pulse widths and the widths may be adjusted based on their proximity to expected possible pulse widths. In some embodiments, when an estimated width is ambiguous with respect to multiple possible widths, this ambiguity is factored into the calculation/estimation made at block860. For example, if a possible detected pulse width could be either 8 microseconds or 10 microseconds based on tolerances, this ambiguity can be factored into eliminating/narrowing possible bitrates.

At block860, the determined widths of one or more pulses is analyzed to determine whether the widths are correlated with a single possible bitrate or a subset of possible bitrates. For example,FIG.9shows an exemplary table of detected pulse widths and corresponding possible bitrates. In some embodiments, the selection of possible bitrates is based on information about the vehicle or more broadly on bitrates used generally within the automobile industry and/or manufacturer.

In some embodiments, edge detection is performed by a process (e.g., of a multi-process program) that polls/monitors the output of a pin signal. When the bit signal state changes, the number of clock counts of a clock is recorded (e.g., in a memory register) by the process. After an initial state change (e.g., the first edge) is detected, the process continues monitoring for an additional state change. After the second state change is detected, the value of clock counts is recorded, and an interrupt is called for calculating/estimating the respective pulse width and determining if the bit rate can be determined at block860. In some embodiments, a circuit (e.g., edge-triggered S-R circuit) can be configured to receive an input signal (i.e., from the OBD system) and trigger an output (i.e., a trigger/clock count) when a rising or falling edge occurs over the signal.

After each of the possible bitrates has been eliminated as a possibility, the process is finished and the bitrate is selected at block870. For example, if two of the three possible bitrates ofFIG.9are eliminated, the remaining bitrate is selected. In some embodiments, if multiple possible bitrates correlate with the determined pulse width(s), the process continues by resetting the routine at block855of recording first and second edges and calculating additional pulse width(s) beginning at block830. This cycle may continue until each of the possible bitrates is eliminated and a single possible bitrate remains and is selected. In some embodiments, the process may “time-out”/abort if a maximum number of iterations occurs and a single bitrate has not been determined.

In some embodiments, if each possible bitrate other than one cannot be readily eliminated based on the estimated pulse widths after a particular number of pulses are recorded, the process may perform additional analysis after that particular number of pulses occurs. For example, the process may factor in a bit-stuffing protocol to further eliminate various possibilities. In an embodiment, recorded pulse widths that correlate directly with particular bitrates are compared to the presence of recorded pulse widths that exceed certain widths compliant with the bit-stuffing protocol for that particular bitrate but would not comply with another possible bitrate, thereby further eliminating one or more possible bitrates. This process may continue (of analyzing sequences of predetermined number of pulses/pulse widths) until all but one possible bitrate is eliminated.

The processes described herein (e.g., the processes ofFIGS.3,4, and8) are not limited to use with the hardware shown and described herein. They may find applicability in any computing or processing environment and with any type of machine or set of machines that is capable of running a computer program. The processes described herein may be implemented in hardware, software, or a combination of the two. The processes described herein may be implemented in computer programs executed on programmable computers/machines that each includes a processor, a non-transitory machine-readable medium or other article of manufacture that is readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and one or more output devices. Program code may be applied to data entered using an input device to perform any of the processes described herein and to generate output information.

The processing blocks (for example, in the processes ofFIGS.3,4, and8) associated with implementing the system may be performed by one or more programmable processors executing one or more computer programs to perform the functions of the system. All or part of the system may be implemented using electronic hardware circuitry that include electronic devices such as, for example, at least one of a processor, a memory, a programmable logic device, and/or a logic gate. All or part of the system may be implemented as special purpose logic circuitry (e.g., an FPGA (field-programmable gate array) and/or an ASIC (application-specific integrated circuit)).

The processes described herein are not limited to the specific examples described. For example, the process ofFIGS.3,4, and8are not limited to the specific processing orders illustrated. Rather, any of the processing blocks may be re-ordered, combined or removed, performed in parallel or in serial, as necessary, to achieve the results set forth above.

Elements of different embodiments described herein may be combined to form other embodiments not specifically set forth above. Various elements, which are described in the context of a single embodiment, may also be provided separately or in any suitable sub-combination. Other embodiments not specifically described herein are also within the scope of the following claims.