Use of interpretive meta-instructions to implement various RKE protocols

Abstract

Interpretive meta-instructions are used, at a connected vehicle access system (CVAS) device, to implement various RKE protocols by: receiving an RKE-protocol-specific meta-instruction that has been generated by a back-end server; generating an RKE telegram based on the RKE-protocol-specific meta-instruction; and transmitting the RKE telegram to a vehicle. The meta-instruction may include: a device configuration that specifies a set of RF parameters of a CVAS-device transceiver; a template telegram that contains a first set of data fields with data values from the back-end server and that contains a second set of data fields for which data values will be generated and inserted at the CVAS device; and localization-processing commands containing instructions for modifying the second set of data fields of the template telegram.

Claims

1. At a connected vehicle access system (CVAS) device, a method comprising: receiving a Remote Keyless Entry (RKE)-protocol-specific meta-instruction that has been generated by a back-end server; generating an RKE telegram based on the RKE-protocol-specific meta-instruction; and transmitting the RKE telegram to a vehicle; wherein the meta-instruction comprises: a device configuration that specifies a set of RF parameters of a CVAS-device transceiver; a template telegram that contains a first set of data fields with data values from the back-end server and that contains a second set of data fields for which data values will be generated and inserted at the CVAS device; and localization-processing commands containing instructions for modifying the second set of data fields of the template telegram; and wherein the meta-instruction, which is defined in an interpretive language format, has an opcode field, a length field, and a value field, wherein the opcode field specifies arithmetic operations to be performed by the CVAS device, the length field specifies a length in bytes of the value field, and the value field includes one or more numeric values to be written to the key device.

2. The method of claim 1, wherein the instructions specify that at least one data value is to be generated based on information received from a vehicle.

3. The method of claim 1, wherein the set of RF parameters includes a plurality of parameters selected from the group consisting of: carrier frequency, frequency deviation in case of FSK (Frequency Keying Shift), high/low amplitude of the signal, modulation method, data encoding, baud rate, and transmit power.

4. The method of claim 1, further comprising: storing the meta-instruction at the CVAS device for later use by the CVAS device.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) FIG. 1 depicts an operating environment for embodiments of the invention.

(2) FIG. 2 is a data flow diagram that depicts a meta-instruction that is generated and sent from a back-end server to a CVAS device, which generates an RKE telegram based on the meta-instruction and then sends the RKE telegram to a vehicle.

(3) FIG. 3 depicts a meta-instruction format in accordance with embodiments of the invention.

DETAILED DESCRIPTION

(4) FIG. 1 depicts an operating environment for embodiments of the invention. As depicted in FIG. 1, a Remote-Cloud-Key server (also referred to as a backend server) communicates wirelessly with a plurality of mobile devices (e.g., smartphones), which execute a Connected Vehicle Access System (CVAS) mobile app. The mobile apps communicate wirelessly with a Remote-Cloud-Key (RCK) device (also referred to as a CVAS device) in a vehicle. From the point of view of the Remote Keyless Enty (RKE) module and the immobilizer in the vehicle, the RCK device appears to be simply an authorized key device that has been learned to the vehicle when the RCK device transmits commands, which it receives from the server via one of the mobile devices. Such commands may be cached by mobile devices, and there is limited range of valid rolling codes that the vehicle will accept at any particular time. As such, preventing the rolling codes sent by the RCK device to the vehicle from getting outside of the acceptable range by efficiently using rolling codes and minimizing wasted rolling codes improves operation of the system.

(5) Embodiments of the invention are directed to ways to implement various RKE (Remote Keyless Entry) protocols for CVAS (connected vehicle access system) such as conventional key fobs, Bluetooth-enabled key fobs, CSM (Car Share Module), etc.

(6) The CVAS (connected vehicle access system) enables access to the vehicle entry and engine start by downloading necessary authenticated commands from a remote server, then using the information contained in the command to set up the device configuration of the CVAS device, do localized processing to generate telegrams, and then transmit the telegram to unlock locked doors of the vehicle, enable starting of the vehicle, and the like.

(7) To unlock/lock the vehicle, start the engine, or open the trunk, some vehicles require telegrams only from the CVAS device to the car. In such a case, the remote server connected to the CVAS device may generate an authenticated telegram and then transmit the data to the car.

(8) On the other hand, some vehicles require bi-directional communication so that the next communication between the CVAS device and the vehicle should take into account the response information delivered from the vehicle to the CVAS device triggered by the previous communication. This bi-directional communication requirement inhibits the remote server from generating the whole authenticated telegram without having the response information available on the server side. On many occasions, the CVAS device cannot communicate back to the remote server to deliver the response information for various reasons such as being out of wireless network coverage, or the car being located in an underground parking structure, or a temporary server shutdown. Some vehicles require multiple bi-directional communications between the vehicle and the CVAS device in a timely manner, so generating the authenticated telegrams and conducting the bidirectional communication may not be possible within applicable time constraints.

(9) One more consideration regarding the bi-directional communication is, to support multiple RKE protocol by one CVAS device, the CVAS device should either (1) contain all the various protocol-data-generation algorithms prior to the access to the car, or (2) download the necessary information from the remote server and then generate the telegram based on the downloaded information.

(10) Embodiments of the invention are directed to defining an RKE-protocol-data-generation algorithm and to using downloaded data to generate authenticated telegrams to be sent to the vehicle.

(11) The localization process is the way the CVAS device generates necessary telegrams by combining the server-initiated operation (meta-instruction) with local operations happening inside the remote cloud key device to modify some part of the template telegram, for example, including Rolling Code and/or Message Authentication Signature.

(12) The local operation contains minimum logic to manipulate only necessary part of server-generated telegram (i.e. template telegram) so that still majority of the RKE protocol algorithm is implemented at the remote server.

(13) FIG. 2 is a data flow diagram that depicts a meta-instruction that is generated and sent from a back-end server to a CVAS device, which generates an RKE telegram based on the meta-instruction and then sends the RKE telegram to a vehicle.

(14) The meta-instruction is initially generated by the remote server and then transmitted to the CVAS device, and then used, or it can be stored on the NV (Non-Volatile) memory of the CVAS device and used later when it is needed. Since the meta-instruction doesn't contain any specific value that will be later generated by the CVAS device, it can be used multiple times.

(15) The CVAS (Connected Vehicle Access System) device provides the capability of RF transmission between the device and the car. Also it provides communication methods to connect the device to the remote server. The CVAS device can provide Bluetooth LE communication, by which the device is connected to a smartphone, then the smartphone may connect to the remote server via an ip network.

(16) The meta-instruction defines the RKE protocol by providing three major types of information: (1) Device Configuration as a set of RF parameters of the transceiver, (2) Template Telegram that will get transmitted to the car after localization processing, and (3) localization-processing commands containing instructions for modifying part of the template telegram.

(17) The Device Configuration is a set of information containing the microcontroller RF transmitter register values specific to the physical characteristics of the RKE protocol, such as carrier frequency, frequency deviation in case of FSK (Frequency Keying Shift), high/low amplitude of the signal, modulation method (FSK, ASK, OOK, etc), data encoding (Manchester Encoding, NRZ, etc), baud rate, transmit power, etc.

(18) The device configuration also contains instructions to direct the CVAS device how to set the microcontroller register values with the information contained in it.

(19) The Template Telegram is a combination of actual data to be transmitted to the car and a place holder for data to be generated and inserted by the CVAS device after the localization processing. For example, an RKE protocol may contain 2-byte Rolling Code at 4th and 5th byte position in a telegram that gets updated to the value the vehicle gives back through a response message, incremented by 1. In such a case, the template telegram contains actual values for other fields such as Device Identifier and Command Code (unlock/lock/window open/trunk release/etc), but the template telegram keeps pseudo values at the 4th and 5.sup.th byte positions. These pseudo values get updated by the localization processing explained below.

(20) If the RKE protocol doesn't involve any localized processing so that the remote server can generate the whole actual telegram, then the template telegram contains actual values without any pseudo values in it. In such a case, the localization processing commands are not included in the meta-instruction.

(21) The Localization-Processing Commands implement the RKE-protocol-specific algorithm such as how to update specific fields on the template telegram. The commands define generalized memory access method to RAM buffer and NV memory pages, plus arithmetic-operation instructions such as XOR, shift, increment, etc. The localization processing command itself is RKE-protocol agnostic, with the use of the localization commands themselves implementing the specific algorithm of the specific RKE protocol.

(22) The meta-instruction is defined in a way that it can be interpreted by the CVAS device and thereafter executed by the device without knowing the context of the specific RKE protocol.

(23) FIG. 3 depicts a meta-instruction format in accordance with embodiments of the invention. As depicted in FIG. 2, meta-instruction may come in a format having [O(opcode) L(length) V(value)]. The opcode defines the type of value and what action needs to be done on the value. The length specifies length of the <value> field in bytes. It doesn't include the length of opcode and the length field itself. The value has numeric values that will be written to the key device's settings blocks or data frame pages.

(24) The data configuration, template telegram, and localization processing commands are defined in this interpretive language format.

(25) For device configuration, the value field contains actual microcontroller register values specific to the RKE protocol being implemented.

(26) For template telegram, the value contains actual values according to the RKE protocol and pseudo values that the localization processing updates to generate authenticated telegram corresponding to the previous response from the vehicle.

(27) For localization-processing commands, the value contains addressing specifier pointing to RAM buffer or NV memory page. The opcode instruction specifies what arithmetic or cryptology operation the device should perform.

(28) To summarize, with conventional RKE systems, RKE commands are generated locally on the RKE key fob. When an RCK system includes a mobile device (e.g., a smartphone) between a remote-cloud-key server and a remote-cloud-key device inside a vehicle, RKE commands are generated at the RCK server. So, when a user presses the lock button in the app, the app notifies the server that a lock command is to be sent, and the server generates the lock command and sends it to the mobile app. The mobile app then sends the lock command to the RCK device in the vehicle. But, in accordance with the hybrid approach in accordance with embodiments of the invention, the RCK server will not generate a complete lock command. Instead, the RCK server will generate most of it. It will create a template, and it will send instructions to the RCK device regarding how to generate the rest of the command before the RCK device sends the command to the vehicle.

(29) So the RCK server handles most of the differences that exist between different protocols for different types of vehicles so that a single RCK/RKE device may be used with any of the different types of vehicles. Typically, the same RKE device would not work on a different types of vehicles because the RKE device is implemented with a piece of code that is specific for that vehicle. An RCK device will work universally on many different types of vehicles because the server is creating the right commands to handle the different protocols of different types of vehicles.

(30) In accordance with embodiments of the invention, the server generates a template and then tells the RCK device, if the RCK device is going to be used only for one vehicle, then the RCK device can simply store the template once, and then after that, every time a command is sent, instructions on how to use the template to finish generating the remaining parts of the command may be sent. And, in some cases, that is done because, sometimes, the actual missing piece of information (i.e., the data to be generated locally at the RCK device and inserted into the command to be sent to the vehicle) comes from (or is generated based on information that comes from) the vehicle. So, otherwise, for the server to generate a complete command, the missing piece of information would have to go (from the vehicle to the RCK device) back to the server, and then the server can use the information to generate the complete command and then send it back. So, instead, in accordance with embodiments of the invention, the server sends the template and instructions on how to generate and insert any information into the template using local information in order to generate the command based on the template and the locally generated data at the RCK device.

(31) And such a hybrid approach produces significant efficiencies in making regular RKE key fobs as well. A conventional physical key fob works for one vehicle, but has different software than a key fob for other types of vehicles. But according to embodiments of the invention, key fobs that implement different protocols for different vehicles, can be running the same software, and the different protocols may be implemented by the server sending different templates to one key fob versus another key fob. And then the key fobs will implement different protocols. It's almost like configuring the key fob at the time of learning, so every key fob is learning the same piece of code, so the codes doesn't have to be compiled because all the key fobs are learning the same software, but now depending on their differences, a different template is sent from the server.

(32) While the present invention has been illustrated by a description of various embodiments and while these embodiments have been described in considerable detail, it is not the intention of the applicants to restrict or in any way limit the scope of the appended claims to such detail. Additional advantages and modifications will readily appear to those skilled in the art. The invention in its broader aspects is therefore not limited to the specific details, representative apparatus and method, and illustrative example shown and described. Accordingly, departures may be made from such details without departing from the spirit or scope of applicant's general inventive concept.