Patent Application
20240070258
The present disclosure generally relates to authentication between computing devices and secure remote entry control systems for vehicles. Authentication, encryption, and secure communication techniques are used by many different kinds of computing devices to prevent third party devices from reading communications between the computing devices and/or gaining unauthorized access. Limiting the number of messages that are encrypted with the same encryption key, over time, helps reduce the risk of a successful cryptanalysis brute-force attack.
The present disclosure provides a new and innovative system, methods and apparatus for user-customized vehicle control using serverless functions. In an example, a method that may be used to provide user-customized vehicle control is generally described. In various examples, first vehicle identifier data identifying a first vehicle may be received. In some cases, first state data may be received by a serverless function. The first state data may representing a first condition of the first vehicle. In some examples, a first user-defined rule may be evaluated using the first state data. In further examples, first control data may be sent to a first computing device of the first vehicle based on the evaluation of the first user-defined rule using the first state data. The first control data may be effective to control operation of at least one component of the first vehicle.
In another example, a system for user-customized vehicle control is generally described. In some examples, the system may comprise at least one processor. In various further examples, the system may include non-transitory computer-readable memory storing instructions that, when executed by the at least one processor, are configured to receive first vehicle identifier data identifying a first vehicle. In various cases, the non-transitory computer-readable memory may store further instructions that, when executed by the at least one processor, are configured to receive, by a serverless function executed by the at least one processor, first state data representing a first condition of the first vehicle. In various other examples, the non-transitory computer-readable memory may store further instructions that, when executed by the at least one processor, are further configured to evaluate a first user-defined rule using the first state data. In some cases, the non-transitory computer-readable memory may store further instructions that, when executed by the at least one processor, are further configured to send first control data to a first computing device of the first vehicle. In some examples, the first control data may be determined based on the evaluation of the first user-defined rule using the first state data and wherein the first control data is effective to control operation of at least one component of the first vehicle.
In yet another example, another method to provide user-customized vehicle control is generally described. In some examples, the method may sending, by first computing device of a first vehicle, first vehicle identifier data to a serverless function. In various further examples, the method may include sending, by the first computing device, first state data representing a first condition of the first vehicle. In some further examples, the method may include receiving, by the first computing device, first control data. In some examples, the first control data may be determined based on an evaluation of a first user-defined rule using the first state data. In some cases, the first control data may be effective to control operation of at least one component of the first vehicle.
Additional features and advantages of the disclosed methods, devices, and/or systems are described in, and will be apparent from, the following Detailed Description and the Figures.
Vehicles continue to employ more and more computer systems and sub-systems for operation, control, monitoring, entertainment, etc. In various cases, an owner of a vehicle may wish to customize vehicle operation and/or control. For example, a vehicle owner may set various conditions that dictate how, and/or under what circumstances or conditions, the vehicle may be operated.
In various examples, systems and methods are described that enable remote, serverless function-based control of vehicle operation based on both user-defined (e.g., owner-defined) and manufacturer-defined rules. In various examples described herein, a user may configure rules and conditions for how a vehicle may be operated through a remote device (e.g., a mobile application and/or web application). The user may be authenticated (through the remote device) to a remote system that is configured to accept the user-customized rules and conditions and generate control instructions that may be sent to the relevant vehicle's electronic control unit (ECU). In various examples, in order to be able to create such user-customized vehicle control rules, the user may be authenticated to not only the remote system (e.g., a serverless function executed by a cloud-based computing platform), but also to the vehicle itself. In some cases, the serverless function, a remote device (e.g., a key fob, a mobile device, etc.), and the vehicle ECU may all participate in the authentication procedure to ensure that the user is privileged to access and/or modify the vehicle control rules. This reduces security vulnerabilities that may otherwise be present if authentication was only required for either the serverless function or the vehicle ECU. For example, if a non-authorized user was able to gain access to the serverless function the non-authorized user could potentially push malicious code and/or control vehicles remotely. However, the various authentication procedures described herein involve interplay between the vehicle ECU, the serverless function, and a key fob or other remote device associated with the vehicle and thereby provide enhanced security.
After authentication, the user may set the particular conditions for vehicle operation through the mobile and/or web application. In turn, the mobile and/or web application may generate control data that may include computer-executable instructions that may be effective to control various components and/or systems within the vehicle. The control data may be sent to the vehicle ECU and may be used to control operation of the various components and/or systems of the vehicle. The vehicle's ECU may collect state data describing states of vehicle systems and/or sensors. The state data may be sent to the serverless function wirelessly and may be used to evaluate both user-defined and manufacturer defined rules to determine the appropriate control data to push to the vehicle's ECU. The state data sent to the serverless function from the vehicle's ECU may be encrypted to alleviate privacy concerns. Accordingly, a vehicle owner (or other authorized user) may remotely customize their vehicle's operation (and/or vehicle subsystem operation) according to their preferences. The serverless function may include logic (e.g., user-defined rule data) that may evaluate the state data using various thresholds and/or conditions to determine what action should be taken (or prevented) by the vehicle's ECU. Control data and/or status data determined by the serverless function may be sent to the vehicle's ECU via a wireless network communication interface and the vehicle's ECU may update the status and/or execute the control data.
The particular customizations depend on the desired implementation, but some examples may include disabling the motor/ignition when the vehicle is more than a certain distance from a predefined location (e.g., the owner's home), disabling the motor/ignition when the vehicle is in certain predefined weather conditions, controlling the vehicle to navigate to a charging station/fueling station when the battery life/fuel is below a certain level, etc. In some cases, the vehicle identifier data that is sent by the vehicle's ECU to the remote system/serverless function and which is used to retrieve the user-defined rule data may include metadata identifying a particular user of the vehicle (e.g., from among multiple users). The metadata identifying the user may be determined based on authentication data entered by the user (e.g., on a touchscreen display of the vehicle), based on a particular passcode transmitted by a key fob (e.g., a properly-licensed teenager's key fob may transmit a code that may be used to retrieve rule data for the teenager), based on computer vision and/or other sensors distinguishing between different users (an owner vs. the owner's spouse), etc. Each individual user may be associated with a specific rule and/or set of rules. For example, the rule set applicable to a teenaged user (e.g., the child of the owner) may cause the vehicle's engine to become inoperable if the vehicle is taken more than 10 miles from the owner's home. In another example, taking the vehicle more than 10 miles from the owner's home may cause the vehicle to call a mobile telephone number associated with the owner. In another example, a volume level of the entertainment system may be capped at a certain setting for certain users. In another example, operating the vehicle during a snow storm may cause modifications to the anti-lock braking system of the vehicle. The foregoing rules are merely examples. The particular user-defined rule data depends on the desired implementation and on the rules supplied by the user via a mobile application and/or web application.
Key fob 162 may be a remote keyless entry system that is associated with vehicle 125. The key fob 162 may include a network communications interface 164 (e.g., network communications hardware) effective to enable the key fob 162 to communicate over a network 104 (e.g., the Internet or another network). Additionally, key fob 162 may comprise a radio 166 including a transmitter and/or a receiver which may enable the key fob 162 to communicate with vehicle 125 and/or computing device(s) 121 via radio frequency (e.g., for situations in which no connection to network 104 is available).
In various examples, upon receipt of a user press (or other activation) of a control on the key fob 162, the key fob may send a radio signal (and/or network communication) to the computing device(s) 121 of vehicle 125. In response, the vehicle 125 may authenticate itself to computing device(s) 123 using authentication data 176. Upon successful authentication, vehicle 125 may generate a random number 172 and may send the random number 172 to the computing device(s) 123 using a secure Internet communication protocol (e.g., HTTPS, TLS, etc.). The computing device(s) 123 may receive the random number 172 and may store the random number 172 in a data structure 106. Although not shown in
After generating and storing the code 174, the cloud service instantiated by computing device(s) 123 may send an indication (e.g., a ping) to key fob 162. In response, the key fob 162 may authenticate itself to the cloud service using the authentication data 176 (or other authentication credentials). Upon successful authentication of the key fob 162, the cloud service may retrieve the random number 172 from the messages associated with the key fob 162. The cloud service may input the random number 172 into the cryptographic function to generate a second instance of the unlock code 174. The second instance of the code 174 may be compared with the unlock code 174 which was previously generated in response to the communication with the computing device(s) 121. If the codes match, the cloud service may send an instruction to the computing device(s) 121 effective to perform the requested action (e.g., unlock of one or more doors of vehicle 125, starting a motor of vehicle 125, etc.).
After authentication, the computing device(s) 121 of vehicle 125 may be effective to send vehicle identifier (ID) data 180 that is effective to identify the vehicle 125 from among other vehicles. In addition, the vehicle 125 may send vehicle state data 182 together with the vehicle ID data 180. The vehicle state data 182 may describe a state of the vehicle 125 and/or of various systems/sub-systems of the vehicle 125. For example, the vehicle state data 182 may describe current states of software executing on computing device(s) 121 and/or version numbers of the software. In addition, the vehicle state data 182 may describe other state data of the vehicle. Some examples of state data may include current speed, motor status (e.g., engine/motor “ON” or “OFF”), battery life/fuel remaining, odometer reading, bearing, windshield wiper status, cabin preset temperature, climate system information, fluid levels, tire pressure data, geolocation data, etc. The computing device(s) 123 may use the vehicle ID data 180 to determine user-defined rule data 186. The user-defined rule data 186 may be specific logic implemented by the computing device(s) 123 in response to a user 132 specifying various user-defined vehicle rules 136 through a device 134 (e.g., a client device such as a mobile device, a desktop computer, etc.). The device 134 may be properly authenticated with the computing device(s) 123 and/or with a serverless function that communicates with data structure 106. In various examples, the device 134 may be authenticated to computing device(s) 123 using the procedure described above in reference to computing device(s) 121. For example, the device 134 may participate in a three-way authentication procedure with the computing device(s) 123 and the key fob 162 in order to verify that the user 132 of device 134 is associated with the vehicle 125. The serverless function may receive the user-defined vehicle rules 136 and may generate the user-defined rule data 186. The user-defined rule data 186 may be specific to a particular user and/or may be general for any user of the vehicle 125. The user-defined rule data 186 may be associated, in memory, with the vehicle ID data 180 so that when the vehicle ID data 180 and/or vehicle state data 182 is received from the vehicle 125, the appropriate set or sets of user-defined rule data may be retrieved and applied.
For example, the computing device(s) 123 may use the vehicle ID data 180 to lookup the user-defined rule data 186 that is associated with the vehicle ID data 180. The user-defined rule data 186 may be used to evaluate the received vehicle state data 182 using predefined rules and/or thresholds in order to determine one or more conditions associated with the vehicle. For example, if a rule specifies that the vehicle's engine is to be disabled if the vehicle is located more than 50 miles from the user's home, and the GPS coordinates of the vehicle 125 indicate that the vehicle is beyond the distance threshold, user-defined rule data 186 may set an inhibitor bit associated with the vehicle 125 and may send control data to the vehicle 125 that is effective to cause computing device(s) 121 to disable the engine. In some examples, a first tier of remote control of the vehicle 125 may be applicable to the vehicle manufacturer and/or the police or other authorities. These entities may be able to provide control data that may be used to set the inhibitor bit to disable the motor/engine of the vehicle 125. The inhibitor bit may be stored in data structure 106. The inhibitor bit set by this tier of entity (e.g., the manufacturer or the authorities) may supersede control instructions received from the user-defined rule data 186. In various examples, if a user-defined rule results in the inhibitor bit being set, the serverless function may first determine if the inhibitor bit has already been set by the manufacturer/authorities. If so, the serverless function may take no action on the inhibitor bit. Conversely, if the inhibitor bit is not set and the vehicle is fully operational, but the user-defined rule data 186 indicates that the inhibitor bit should be set based on evaluation of the user-defined rule data 186 using the vehicle state data 182, the inhibitor bit may be set and control data may be sent to the vehicle 125 (and/or to computing device(s) 121) to take the appropriate action (e.g., to control one or more components of the vehicle 125).
Depending on the condition that is determined using the user-defined rule data 186, the vehicle 125 may be disabled (e.g., control data may be sent to the vehicle's ECU to prevent the vehicle from starting), control data may trigger a software update to remedy the condition, and/or the control data may allow limited operation of the vehicle (e.g., the control data may prevent the user from violating a predefined rule or threshold that is defined by the user-defined rule data 186). For example, the control data may govern the engine to prevent the user from exceeding a maximum speed limit. As previously described, in some examples, different priorities may be determined for modifications of different vehicle systems/sub-systems. Accordingly, the control data sent to the vehicle 125 may be prioritized and/or may include dependencies. For example, vehicle control systems may take precedence over climate systems and/or GPS systems. In some examples, a serverless function may determine various dependencies of different software systems of the vehicle 125 and may determine whether or not to send particular control data to the computing device(s) 121 based on the dependencies. For example, if modification of a first system is determined to affect a second system, the serverless function may wait until the vehicle state data 182 indicates that the dependencies are resolved prior to updating or otherwise modifying the first system. In another example, the order in which control data is sent to and/or applied to systems may be controlled. For example, control data may instruct the vehicle ECU to turn off the climate control system when starting the vehicle's motor/engine, but may thereafter permit operation of the climate control system. In some further examples, the user-defined rule data 186 may include one or more machine learning-based encoder networks (e.g., a neural network, an auto-encoder, a transformer-based encoder, etc.) that may receive state data from a plurality of vehicles (e.g., vehicles of the same make and model). Such models may be effective to generate a high-dimensional embedding representing the state data and may determine one or more conditions of the vehicle and/or remedial actions to be taken that may not be apparent when using a rule-based system.
The computing device(s) 121 and 123 may be effective to execute software that is configured to perform the various ECU and/or cloud-based (e.g., serverless function) techniques described herein.
As discussed herein, memory devices 114A-B refer to volatile or non-volatile memory devices, such as RAM, ROM, EEPROM, or any other device capable of storing data. In an example, memory devices 114A may be persistent storage devices such as hard drive disks (“HDD”), solid state drives (“SSD”), and/or persistent memory (e.g., Non-Volatile Dual In-line Memory Module (“NVDIMM”)). Memory devices 114A-B may additionally include replication of data to prevent against data loss due to a failure in any one device. This replication may be implemented through, for example, a redundant array of independent disks (“RAID”) setup. RAID arrays may be designed to increase performance, to provide live data backup, or a combination of both. As discussed herein, I/O device(s) 116A refer to devices capable of providing an interface between one or more processor pins and an external device, the operation of which is based on the processor inputting and/or outputting binary data. CPU(s) 112A may be interconnected using a variety of techniques, ranging from a point-to-point processor interconnect, to a system area network, such as an Ethernet-based network. Local connections within physical hosts 110A, including the connections between processors 112A and memory devices 114A-B and between processors 112A and I/O device 116A may be provided by one or more local buses of suitable architecture, for example, peripheral component interconnect (PCI).
In an example, physical host 110A may run one or more isolated guests, for example, VM 155, which may in turn host additional virtual environments (e.g., VMs and/or containers). In an example, a container (e.g., storage container 160, service containers 150A-B) may be an isolated guest using any form of operating system level virtualization, for example, Red Hat® OpenShift®, Docker® containers, chroot, Linux®-VServer, FreeBSD® Jails, HP-UX® Containers (SRP), VMware ThinApp®, etc. Storage container 160 and/or service containers 150A-B may run directly on a host operating system (e.g., host OS 118) or run within another layer of virtualization, for example, in a virtual machine (e.g., VM 155). In an example, containers that perform a unified function may be grouped together in a container cluster that may be deployed together (e.g., in a Kubernetes® pod). In an example, a given service may require the deployment of multiple VMs, containers and/or pods in multiple physical locations. In an example, VM 155 may be a VM executing on physical host 110A.
Computing device(s) 121 and/or computing device(s) 123 may run one or more VMs (e.g., VMs 155), by executing a software layer (e.g., hypervisor 120) above the hardware and below the VM 155, as schematically shown in
In an example, a VM 155 may be a virtual machine and may execute a guest operating system 196A which may utilize the underlying VCPU 190A, VIVID 192A, and VI/O 194A. Processor virtualization may be implemented by the hypervisor 120 scheduling time slots on physical CPUs 112A such that from the guest operating system's perspective those time slots are scheduled on a virtual processor 190A. VM 155 may run on any type of dependent, independent, compatible, and/or incompatible applications on the underlying hardware and host operating system 118. The hypervisor 120 may manage memory for the host operating system 118 as well as memory allocated to the VM 155 and guest operating system 196A such as guest memory 195A provided to guest OS 196A. In an example, storage container 160 and/or service containers 150A, 150B are similarly implemented.
In an example, in addition to distributed storage provided by storage container 160, storage may be deployed in dedicated storage nodes (e.g., NAS, SAN, etc.). In an example, a storage controller may deploy storage in large logical units with preconfigured performance characteristics (e.g., storage nodes 170A). In an example, access to a given storage node (e.g., storage node 170A) may be controlled on an account and/or tenant level. In an example, a service container (e.g., service containers 150A-B) may require persistent storage for application data, and may request persistent storage with a persistent storage claim to an orchestrator (not shown). In the example, a storage controller may allocate storage to service containers 150A-B through a storage node (e.g., storage nodes 170A) in the form of a persistent storage volume. In an example, a persistent storage volume for service containers 150A-B may be allocated a portion of the storage capacity and throughput capacity of a given storage node (e.g., storage nodes 170A). In various examples, the storage container 160 and/or service containers 150A-B may deploy compute resources (e.g., storage, cache, etc.) that are part of a compute service that is distributed across multiple clusters (not shown in
In response to receipt of the request 202, vehicle 225 may check for network access. If network access is available, vehicle 225 may generate a random number (which may instead be a pseudo-random number or even a predefined number). Vehicle 225 may also send identifier data that uniquely identifies the vehicle 225 from among other vehicles (and/or a computing device of vehicle 225 from among other computing devices). The vehicle 225 may authenticate with the cloud service 206 (e.g., by providing access credentials that were previously established during registration with the cloud service). Upon successful authentication, the random number 204 may be sent to cloud service 206 via a secure, encrypted Internet communication protocol. The cloud service 206 may generate a first authentication code from the received random number (block 208). For example, the cloud service 206 may input the received random number into a cryptographic hash function that may generate the first authentication code. The cloud service 206 may store the first authentication code in a data store associated with the vehicle 225 (block 210).
The cloud service may also store the random number in a message generated by a messaging protocol (block 212). The message may be associated with the vehicle 225 and/or the key fob 262. Accordingly, successful authentication with the cloud service 206 may be required in order to access the message. The message may be associated with a time-to-live (TTL) value. Upon expiration of the TTL, the message may be deleted, which may require the procedure described in
In various examples, the user-defined rule data may be stored in a data structure in association with the vehicle ID data 180. Accordingly, the cloud service 206 may use the vehicle ID data 180 to query the data structure to determine the user-defined rule data. The user-defined rule data may specify rules and/or thresholds related to various components, systems, and/or subsystems of the vehicle. In addition, in some examples, the user-defined rule data may be associated with a particular user. For example, there may be multiple users of vehicle 225 (e.g., members of a family or employees of a business) and different users may have different privilege levels and/or access levels for the vehicle that are defined by the user-defined rule data 222. For example, an employee having a first privilege level may not be permitted to start an engine/motor of the vehicle 225, while an employee having a second privilege level may be permitted to start the vehicle 225. However, the user-defined rule data 222 may be effective to disable the vehicle 225 motor if the employee having the second privilege level attempts to drive the vehicle beyond a predefined geo-fence (e.g., defined by the user-defined rule data).
Other examples of rules that may be instantiated as user-defined rule data 222 may include a rule that prohibits starting the motor of the vehicle when the software version of an artificial intelligence algorithm used to control operation of the vehicle 225 is out of date. In such an example, the cloud service may check an inhibitor bit (block 224) that permits or disables starting of the vehicle. In an example, the inhibitor bit, if set, may prevent starting the vehicle 225. The inhibitor bit may be set by cloud service 206 and/or by another computing device that is properly authenticated to the cloud service 206. For example, a vehicle manufacturer, a law enforcement or government agency, etc., may be provided with authentication credentials to cloud service 206 and may be set the inhibitor bit. For example, if the vehicle 225 is reported stolen, law enforcement officers may contact the vehicle manufacturer who may set the inhibitor bit for the vehicle 225 so that the vehicle motor cannot be started. In another example, there may be a safety issue with vehicle operation. In the example where the artificial intelligence software is out of date, the inhibitor bit may be set by the cloud service 206 to prevent the vehicle from being started. In another example, control data may be sent to the vehicle (e.g., control data 228) that may force the vehicle 225 to update the artificial intelligence software. In addition, the control data 228 may prevent starting the vehicle 225 until the artificial intelligence software is updated. In another example, the control data 228 may permit the vehicle to be started, but may prevent the vehicle 225 from using any mode that employs the out of data artificial intelligence software (e.g., an autopilot feature).
In cases where the vehicle or vehicle functionality has been temporarily disabled as a result of the user-defined rules, an authorized user (e.g., the owner of the vehicle) may send an authorization code to the cloud service 206 that may enable the user to override the control data and reset the inhibitor bit(s) such that the vehicle can again be started and/or such that the disabled functionality is permitted.
User-defined rule data 222 may define which users can access which systems/subsystems of a vehicle and may control a level of access to these systems. For example, the user-defined rule data 222 may set minimum and maximum setting values for climate control, may disable manual vehicle navigation (in favor of autonomous navigation), may limit entertainment system access/volume, may disable vehicle operation for given weather conditions (determined using sensor data and/or external data sources such as external forecasting systems), may cause the vehicle to navigate to a refueling/charging station when the fuel/battery level is less than a certain percentage, etc. The particular user-defined rule data 222 depends on the desired implementation.
In another example, vehicle sensor software that is configured in communication with the ECU may be out of data causing a potential safety issue. In such an example, the cloud service 206 may set the inhibitor bit and/or may trigger update of the sensor software. The inhibitor bit may prevent starting the vehicle 225 until the sensor software issue is remedied. In other examples, the vehicle manufacturer may detect a safety issue (e.g., an issue resulting in a recall) and may set the inhibitor bit remotely by authenticating with and communicating with the cloud service 206. The inhibitor bit may be set to prevent operation of the vehicle until the safety issue is remediated. The motor inhibition example is merely illustrative and other components of the vehicle may also be controlled using such rules and/or control bits (such as the aforementioned inhibitor bit). In some examples, setting such control bits and/or defining the rule data to be stored in association with the vehicle identifier data may not require the same authentication procedure as the key fob. For example, the vehicle identifier data and one or more passwords may be used to authenticate to the cloud service 206 in order to modify the rule data and/or control bits.
For example, operation of the vehicle may be inhibited outside of a particular geofence, electronic locks may be inhibited until the appropriate vehicle taxes are paid (preventing access to the vehicle), etc. Accordingly, if the vehicle state data 182 indicates that the vehicle is currently outside the relevant geofence, the inhibitor bit may be set and the operability of the vehicle may be prohibited. In some examples, setting of the inhibitor bit by the manufacturer and/or law enforcement may supersede the ability of user-defined rule data 222 from setting/flipping the inhibitor bit. Accordingly, if law enforcement, for example, has set the inhibitor bit due to the vehicle being reported as stolen or due to a vehicle seizure order, the user-defined rule data 222 may not be privileged to flip the bit (such that the vehicle 225 is able to be operated) until the inhibitor bit is set by the relevant law enforcement agency to uninhibited.
At block 224, the inhibitor bit(s) associated with the particular condition determination logic (which is, in turn, associated with the identifier data (e.g., the ECU ID) may be checked in order to evaluate the user-defined rule data 222 using the most recent vehicle state data 182. As previously described, in some examples, the inhibitor bit may already be set either due to a prior rule evaluation of the user-defined rule data or due to a higher-privileged operation (such as setting of the control bit by the vehicle manufacturer or by a relevant authority). Control data (e.g., executable instructions) may be sent to the vehicle ECU (block 226). For example, control data 228 may prevent the motor from starting for the current key fob press (or other vehicle start control) until a software issue is remedied and/or until the relevant condition of the user-defined rule data is no longer applicable (and the inhibitor bit is set to non-inhibited). In addition, the inhibitor status 230 may be sent to the vehicle. The inhibitor status may output relevant data according to the pertinent condition. For example, if the vehicle motor is inhibited due to a missed payment, expired registration, the vehicle being operated outside of a pre-defined geofence, the vehicle being operated with less than a certain percentage of fuel/battery life, the vehicle being greater than a threshold distance from the owner's home, etc., the inhibitor status may display (or otherwise output) that the vehicle cannot be started (or the relevant vehicle system cannot be used or has limited functionality) until the situation is remediated. Upon successful remediation, the relevant party may access the cloud service 206 in order to have the inhibitor bit changed. The inhibitor status 230 may not, in all cases, be output by the vehicle so that it is perceivable by the vehicle owner.
In some examples, an inhibitor bit may be associated with each user-defined rule. In some cases, a status of the inhibitor bit for each user-defined rule may be determined and a logical AND operation may be used to generate combined results for each user-defined rule. The control data may correspond to the combined results of the user-defined rules.
In various examples, the cloud service 206 may be implemented as a serverless function (e.g., in a container-based cloud-computing architecture). Software implemented on such serverless functions may awaken in response to a service call (e.g., from the vehicle 225, the key fob 262, and/or another device). Accordingly, there may be no requirement that a server constantly execute a service that can receive, parse, and respond to inputs and provide the relevant outputs. Instead, the serverless function may deploy the functionality described above only when required. This may provide greater accessibility for the service as the service may not be interrupted by downtime and/or maintenance of any particular server. Additionally, the particular authentication procedure described above using a serverless function such as cloud service 206 may prevent spoofing attacks, such as the rolling code attacks described above. The compute resources needed to execute the logic described above may be deployed on an as-needed basis in response to receipt of a request. It should be noted that although some specific examples are provided herein, the particular condition determination logic as well as the vehicle state data being evaluated using such logic depends on the desired implementation by the vehicle manufacturer. Similarly, the vehicle state data 182 sent by the vehicle 225 may depend on the sensors and other systems communicating with the ECU of the vehicle 225 and on the implementation of the cloud-based vehicle control system. Although in some examples vehicle 225 may be an automobile, in some other examples, the vehicle 225 may be an autonomous and/or remotely controlled vehicle (e.g., a drone), robot, etc.
The example process 300 includes receiving first identifier data identifying a first vehicle (block 310). For example, the ECU of the vehicle (e.g., vehicle 225) may authenticate with a cloud service (e.g., a serverless function, such as cloud service 206). As previously described, in some examples, in order to provision the user-customized rule data (e.g., user-defined rule data 186) a user may authenticate a client (e.g., a web application executing on a mobile device, such as device 134) with the serverless function. In some examples, a third device may also be used to ensure that the user is properly-associated with the vehicle. For example, the key fob or another device may be used along with the cloud service 206 and the device 134 to authenticate the user. After successful authentication, the web application may provide options for the user to define a set of user-customized rules for vehicle and/or vehicle system/sub-system operation, as described herein. Additionally, in some examples, the properly-authenticated user may provide different rules and/or rule-sets for different users of the vehicle.
In various examples, the cloud service may input a first number received from the vehicle ECU into a cryptographic function (e.g., a hash function) to generate a first authentication code (e.g., a hash value). In various examples, the cloud service may send the first number to a messaging service to have a message that includes the first number generated by the messaging service. The message may only be accessed when a key fob or other device (e.g., device 134) that pertains to the vehicle system that sent the first number is successfully authenticated to the cloud service. The cloud service may store the first authentication code in a data store that is specific to the authenticated vehicle system. In various examples, a notification may be sent to a remote device associated with the vehicle. For example, the cloud service may send a notification to a key fob associated with the vehicle. The notification may be data indicating that a request is pending and may cause the key fob to send authentication credentials to the cloud service in order to have the request performed. Accordingly, the key fob may authenticate to the cloud service. In various examples, a second authentication code may be generated based on a request received from the remote device associated with the vehicle. After authentication, the remote device (e.g., the key fob) may retrieve the first number from the messaging service. The cloud service may input the retrieved first number into the cryptographic function (e.g., a hash function) to generate the second authentication code (e.g., a hash value). The cloud service may compare the first authentication code with the second authentication code to determine if there is a match.
Upon determining that the first authentication code and the second authentication code match, a secure communication channel may be established between the serverless function and the vehicle ECU. The first vehicle identifier data that identifies the first vehicle may be sent (e.g., in encrypted format) via the secure communication channel.
Processing may continue at block 315, at which first state data representing a first condition of the first vehicle may be received by the serverless function from the vehicle ECU. The first state data may comprise various information about the vehicle (among which the first condition is a quantum of received information) and/or about systems/sub-systems of the vehicle. For example, the first condition may describe a software version of each software being executed by the various systems/subsystems of the vehicle. In other examples, the first condition may describe an operating state of a system of the vehicle such as air intake, autonomous vehicle control, braking, emergency brake status, windshield wipers, climate control, entertainment system status, etc.
Processing may continue at block 320, at which a first user-defined rule may be evaluated using the first state data. In various examples, the first user-defined rule may be looked up using the first vehicle identifier data. In some further examples, the first user-defined rule may be associated with a particular user of the vehicle identified by the first vehicle identifier data. The particular user may be identified by metadata (which may be included in the first vehicle identifier data, the first state data, or separately received). For example, the metadata identifying the particular user may be determined using computer vision from cameras within the first vehicle, based on voice recognition software, based on a code transmitted from the key fob (or other physical device) of the particular user, based on a mobile device associated with the particular user, etc.
In various examples, prior to evaluating the first user-defined rule, the vehicle ECU may check a higher-priority vehicle control system (including checking the inhibitor bit associated with the vehicle) to see if the vehicle is subject to control from a higher-priority system (e.g., where a manufacturer has inhibited vehicle start due to a dangerous condition/recall/necessary software update, where an authority has inhibited vehicle start due to vehicle theft/unpaid taxes, etc.). If the vehicle is subject to higher-priority control, inhibitor status may be sent to the vehicle to provide information about the current vehicle operability and/or inhibition. Conversely, if the higher-priority control system is currently not enabled and/or the inhibitor bit is not set, the first user-defined rule may be evaluated using the latest vehicle state data (e.g., the first state data). For example, the first user-defined rule may indicate that vehicle operation over 55 mph is not permitted within a particular geofence and/or on a particular road or route. The first state data may indicate that the vehicle is being operated at 57 mph in the applicable area. Accordingly, the first user-defined rule may be violated. Control data may be generated to bring the speed of the vehicle to within the applicable limit defined by the user-defined rule. In various examples, different systems may have different priorities when applying the user-defined rules. For example, a user-defined rule may indicate that the anti-lock braking control instructions are sent and executed prior to entertainment related control instructions. In another example, control data related to system updates may be applied prior to control data related to climate control systems.
Processing may continue to block 325, which may include sending first control data to a first computing device of the first vehicle (e.g., an ECU of the first vehicle) based at least in part on the evaluation of the first user-defined rule using the first state data. In various examples, the first control data may be effective to control operation of at least one component of the vehicle. For example, the first state data and the first user-defined rule may indicate that automatic windshield wiper control software may be out of date and an updated version is available. The older version may have a bug that causes the windshield wiper motor to operate in an overspeed mode that may result in motor burnout when a particular wiper speed setting is selected. In this example, the first control data may allow nominal vehicle operation (according to the user-defined rule), but may prevent the relevant windshield wiper setting from being selected until the control software has been updated to fix the bug. In some examples, the user-defined rules may determine what control data is to be generated based on the evaluation of the vehicle state data. For example, the user-defined rule may cause control data to be generated that is effective to cause the vehicle ECU to disable vehicle operation (e.g., a user may be prevented from starting the vehicle motor) and/or may not allow a user to enter the vehicle (all doors may remain locked). The particular control data generated may, again, depend on the desired implementation, the particular user-defined rules, the user operating the vehicle, and the received vehicle state data.
In the example depicted in
The cloud service 406 may enqueue the random number into a message with a TTL value (block 418). For example, the cloud service 406 may use a messaging protocol to generate a message that includes the random number 413. The message may be specific to the vehicle device 402 and the key fob 404. The TTL value may define a time period. After the time period elapses, the random number may be deleted. The cloud service 406 may send a notification 422 to the key fob 404 (block 420). The notification 422 may be sent via the secure Internet communication protocol. The key fob 404 may receive the notification 422 (block 423). The notification 422 may be effective to trigger the key fob 404 to send authentication credentials 426 to the cloud service 406 (block 424). The cloud service 406 may authenticate the key fob 404 (block 428) using the authentication credentials 426. In response to successful authentication of the key fob 404, the cloud service 406 may dequeue the message(s) that are associated with the key fob 404 using the messaging protocol (block 430) (e.g., by communicating with a message broker of the messaging protocol).
In the example, the cloud service 406 may generate a second hash by inputting the random number into the hash function (block 432). For example, the random number retrieved from the message may be input into the cryptographic hash function to generate a second hash (e.g., a second unlock code). The cloud service 406 may compare the second hash to the first hash (block 434). The cloud service 406 may determine that the first hash and the second hash match. The cloud service 406 and the vehicle device 402 may establish a secure communication channel 438 (blocks 436, 440). For example, the vehicle device 402 and/or the cloud service 406 may perform a handshake procedure and may exchange cryptographic keys. The vehicle device 402 may send (e.g., periodically) vehicle identifier data and current vehicle state data 443 (block 442) to the cloud service 406. The cloud service 406 may receive the vehicle identifier data and the associated current vehicle state data (block 444). In some examples, metadata may be included to identify the particular user that is attempting to operate the vehicle. The cloud service 406 may use the vehicle identifier data (and/or any user identifying metadata) to lookup the user-defined rules associated with the vehicle identifier data and may evaluate the user-defined rules using the vehicle state data (block 446). Various examples of such evaluation are described above; however, the particular workflow, algorithm, etc., is dependent on the desired use case. In various examples, the user-defined rules may prioritize different actions and/or may determine dependencies between different vehicle systems/subsystems in order to determine the relevant condition and control data. As previously described, certain rules may take precedence over others and there may be tiered priorities of vehicle control. The cloud service 406 may determine a condition of the vehicle (block 448) which may be the result of evaluating the user-defined rules and/or the current setting of the inhibitor bit using the current vehicle state data. The determined condition may, in turn, be associated with a particular control action (or multiple control actions) that is to be used to control the vehicle and/or the vehicle device 402 (e.g., in order to remediate a dangerous condition and/or fix a known issue). In various examples, if the inhibitor bit is set by a privileged entity (e.g., as indicated by metadata indicating a level of privilege of the inhibitor bit setting), the user-defined rules may be superseded and the inhibitor bit setting may be maintained. Control data 451 (e.g., executable instructions effective to control operation of one or more vehicle systems/subsystems) may be generated and sent to the vehicle device 402 using the secure communication channel 438. The vehicle device 402 may receive and execute the control data (block 452) in order to control operation of one or more systems/subsystems of the vehicle in accordance with the control data 451. In various examples, status indicator data may also be sent to update the current status of the vehicle and/or to output the current status to the user. Some examples of status indicator data may be a message indicating the maximum speed for a current zone, a message indicating that vehicle operation is disabled during non-business hours, a message indicating that vehicle operation is disabled while system software is being updated, etc.
A serverless function 516 executed by the one or more processors 502 may store a first user-defined rule 550. The serverless function 516 may receive the first state data 510 including the first condition of the first vehicle 512. In various examples, the serverless function 516 may evaluate the first user-defined rule 550 using the first state data 510. The serverless function 516 may send first control data 522 to the first computing device 520 of the first vehicle 502. The first control data 522 may be determined based on the evaluation of the first user-defined rule 550 using the first state data 510. The first control data 522 may be effective to control operation of at least one component 530 of the first vehicle 502. In various examples, the order of control data sent to the first computing device 520 (e.g., an ECU of vehicle 502) and/or instructions specifying an order of execution of the control data may also be provided. Additionally, the first control data 522 may have different levels of privilege and may be used to affect an inhibitor bit that may be used to permit or disable operation of the at least one component 530 of the first vehicle.
It will be appreciated that all of the disclosed methods and procedures described herein can be implemented using one or more computer programs or components. These components may be provided as a series of computer instructions on any conventional computer readable medium or machine readable medium, including volatile or non-volatile memory, such as RAM, ROM, flash memory, magnetic or optical disks, optical memory, or other storage media. The instructions may be provided as software or firmware, and/or may be implemented in whole or in part in hardware components such as ASICs, FPGAs, DSPs or any other similar devices. The instructions may be executed by one or more processors, which when executing the series of computer instructions, performs or facilitates the performance of all or part of the disclosed methods and procedures.
It should be understood that various changes and modifications to the example embodiments described herein will be apparent to those skilled in the art. Such changes and modifications can be made without departing from the spirit and scope of the present subject matter and without diminishing its intended advantages. It is therefore intended that such changes and modifications be covered by the appended claims.
