Preconfigured electronic communication modules for smart connectivity

Abstract

The present invention relates to preconfiguration of electronic communication modules for smart connectivity. An embedded modem of a vehicle is preconfigured by requesting confirmation of a modem configuration from a telematics server. A request is received from an electronic control unit (ECU) via a vehicle bus, the electronic control unit requesting confirmation of an ECU configuration assigned by a production line end system. The embedded modem sends the request to a telematics server for confirmation, and the result is reported from the telematics server to the ECU. The telematics server receives a request for preconfiguration of the ECU from an embedded modem of a vehicle preconfigured using the telematics server, forwards the request to a backend system configured to process the request, receives a response to the request from the backend server, and makes the response available to the embedded modem.

Description

Technical Field

[0001] Aspects of the present disclosure are generally directed to preconfiguring vehicle components for smart connectivity. Background Art

[0002] Vehicle connectivity has become increasingly common, from the connection of smart home appliances to smart vehicles. However, vehicle connectivity has also become increasingly complex in terms of security. Summary of the invention

[0003] In one or more illustrative embodiments, a vehicle includes an embedded modem configured to: pre-configure the vehicle's embedded modem by requesting confirmation of a modem configuration assigned by a production line end system from a telematics server; receive a request from an electronic control unit (ECU) via a vehicle bus, the electronic control unit requesting confirmation of the electronic control unit configuration assigned by the production line end system; send the request to the telematics server for confirmation; and report a result from the telematics server to the electronic control unit.

[0004] In one or more illustrative embodiments, a system includes a telematics server configured to: receive a request for preconfiguration of an electronic control unit from an embedded modem of a vehicle that is preconfigured using the telematics server; forward the request to a backend system configured to process the request; receive a response to the request from the backend server; and make the response available to the embedded modem.

[0005] In one or more illustrative embodiments, a method includes: in response to receiving a request for preconfiguring the embedded modem of a vehicle via a telematics server, preconfiguring the embedded modem using modem metadata received from a manufacturer of the embedded modem; in response to receiving a request for preconfiguring a controller of the vehicle from the embedded modem via the telematics server, preconfiguring the controller using controller metadata received from the manufacturer of the controller. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Figure 1 An example diagram of a system configured to provide telematics services to a vehicle is shown;

[0007] Figure 2 An example diagram of provisioning an embedded modem is shown;

[0008] Figure 3 An example diagram showing pre-configuration of a vehicle ECU using services of an embedded modem;

[0009] Figure 4 An example process for preconfiguring an embedded modem is shown;

[0010] Figure 5 An example process for real-time pre-configuration of a vehicle ECU using services of an embedded modem is shown;

[0011] Figure 6 An example process for hybrid pre-configuration of a vehicle ECU utilizing services of an embedded modem is shown;

[0012] Figure 7 An example process for batch pre-configuration of vehicle ECUs utilizing the services of an embedded modem is shown. DETAILED DESCRIPTION

[0013] As required, detailed embodiments of the present invention are disclosed herein; however, it will be understood that the disclosed embodiments are merely examples of the present invention, which may be implemented in various forms and alternative forms. The drawings are not necessarily drawn to scale; some features may be exaggerated or minimized to show details of particular components. Therefore, the specific structural and functional details disclosed herein should not be interpreted as limiting, but merely as a representative basis for teaching those skilled in the art to utilize the present invention in various ways.

[0014] Vehicle pre-configuration of the vehicle's networked components may be performed to ensure that each component of the vehicle that is remotely accessible is correctly configured and authenticated in the backend system. This pre-configuration may be performed before the vehicle is ready to be sold to a customer.

[0015] An improved method for vehicle preconfiguration includes storing metadata of vehicle components, such as embedded modems and electronic control units (ECUs), in a backend system. The data may be stored in the backend system before the vehicle components are shipped to an assembly plant for vehicle installation. The data to be stored may include module electronic serial numbers, security keys, part numbers, media access control (MAC) addresses, integrated circuit card identifiers (ICCIDs), or other uniquely identifiable information.

[0016] The embedded modem can be preconfigured using a cellular connection or a Wi-Fi connection. After the embedded modem is installed in the vehicle and configured, the modem connects to the server and exchanges modem metadata and vehicle data with the backend system to verify the legitimacy of the embedded modem. If the modem is valid and configured correctly, the backend system can send a confirmation. Once the embedded modem is successfully preconfigured, other ECUs can be preconfigured in real time or in a batch manner via the embedded modem's communication service.

[0017] Real-time preconfiguration of the ECU may follow a similar process to preconfiguration of the embedded modem. After the ECU is installed and configured during vehicle assembly, and after the embedded modem is successfully preconfigured, the ECU may exchange ECU metadata and vehicle data with the backend system to verify the legitimacy of the ECU. If the ECU is valid and correctly configured, the backend system may send a confirmation. In one example, the ECU to be configured may be a Bluetooth Low Energy (BLE) ECU designed to provide a BLE connection to the vehicle.

[0018] Pre-configuration of ECUs can also be performed using batch processing. In batch processing, ECU metadata and vehicle data for multiple ECUs can be collected and sent to the backend system in a batch process when the ECUs are installed and configured during vehicle assembly. The backend system can then send a pre-configuration response to the ECU via an embedded modem, or the pre-configuration response information can be retained until the vehicle or a command from a telematics server or other backend system accesses the ECU.

[0019] If the ECU is being accessed from within the vehicle (e.g., in response to user input to vehicle controls or communication with the vehicle via Bluetooth or Wi-Fi), the ECU will attempt to receive a preconfiguration confirmation from the backend system if the preconfiguration confirmation has not already been transmitted to the ECU.

[0020] If the ECU is being accessed from a backend system, the vehicle (e.g., embedded modem) can verify the ECU's ECU pre-configuration status before allowing the ECU to perform network communications. If the ECU is not pre-configured, the embedded modem can report the ECU to the backend server for further action.

[0021] In a hybrid pre-configuration process (e.g., including aspects of real-time and batch processing), ECU metadata and vehicle data may be collected on the shop floor as ECUs are installed and configured during vehicle assembly, and may be sent to a backend system in real time via an embedded modem. The backend system may then send a pre-configuration response to the ECUs in a batch process via the embedded modem to confirm or reject the pre-configuration of multiple vehicle ECUs. Other aspects of the present disclosure will be discussed in detail below.

[0022] Figure 1 An example diagram of a system 100 configured to provide telematics services to a vehicle 102 is shown. The vehicle 102 may include various types of passenger vehicles (such as a hybrid utility vehicle (CUV), a sport utility vehicle (SUV), a truck, a recreational vehicle (RV)), a boat, an aircraft, or other mobile machines used to transport people or goods. As some non-limiting possibilities, the telematics services may include navigation, turn-by-turn directions, vehicle health reports, local business searches, accident reports, and hands-free calling. In an example, the system 100 may include a SYNC system manufactured by Ford Motor Company of Dearborn, Michigan. It should be noted that the system 100 shown is merely an example and that more, fewer, and / or differently located elements may be used.

[0023] The computing platform 104 may include one or more processors 106 connected to both a memory 108 and a computer-readable storage medium 112 and configured to execute instructions, commands, and other routines that support the processing described herein. For example, the computing platform 104 may be configured to execute instructions of a vehicle application 110 to provide functions such as navigation, accident reporting, satellite radio decoding, and hands-free calling. Various types of computer-readable storage media 112 may be used to store such instructions and other data in a non-volatile manner. The computer-readable medium 112 (also referred to as a processor-readable medium or memory) includes any non-transitory medium (e.g., tangible medium) that participates in providing instructions or other data that can be read by the processor 106 of the computing platform 104. Computer-executable instructions may be compiled or interpreted from a computer program created using a variety of programming languages ​​and / or techniques, including, but not limited to, a single one or a combination of the following: Java, C, C++, C#, Objective C, Fortran, Pascal, Java Script, Python, Perl, and PL / SQL.

[0024] The computing platform 104 may be provided with various functions that allow vehicle occupants to interact with the computing platform 104. For example, the computing platform 104 may include an audio input 114 configured to receive spoken commands from a vehicle occupant through a connected microphone 116 and an auxiliary audio input 118 configured to receive audio signals from a connected device. The auxiliary audio input 118 may be a physical connection (such as a wire or optical cable) or a wireless input (such as a Bluetooth audio connection). In some examples, the audio input 114 may be configured to provide audio processing capabilities, such as pre-amplification of low-level signals and conversion of analog inputs into digital data for processing by the processor 106.

[0025] The computing platform 104 may also provide one or more audio outputs 120 to an input of an audio subsystem 122 having audio playback capabilities. In other examples, the computing platform 104 may provide audio outputs to the occupants using one or more dedicated speakers (not shown). The audio subsystem 122 may include an input selector 124 configured to provide audio content from a selected audio source 126 to an audio amplifier 128 for playback through vehicle speakers 130 or headphones (not shown). As some examples, the audio source 126 may include decoded amplitude modulation (AM) or frequency modulation (FM) radio signals and audio signals from compact disk (CD) or digital versatile disk (DVD) audio playback. The audio source 126 may also include audio received from the computing platform 104 (such as audio content generated by the computing platform 104), audio content decoded from a flash drive connected to a universal serial bus (USB) subsystem 132 of the computing platform 104, and audio content transmitted through the computing platform 104 from an auxiliary audio input 118.

[0026] The computing platform 104 may utilize a voice interface 134 to provide a hands-free interface to the computing platform 104. The voice interface 134 may support voice recognition of audio received via the microphone 116 according to a standard grammar describing available command functions, and may support voice prompt generation for output via the audio subsystem 122. The voice interface 134 may utilize probabilistic voice recognition technology using a standard grammar that is compared with the input voice. In many cases, the voice interface 134 may include a standard user profile tuning for use with the voice recognition function to allow the voice recognition to be tuned to provide average level good results, thereby bringing a positive experience to the maximum number of initial users. In some cases, the system may be configured to temporarily mute the audio source specified by the input selector 124 or otherwise override the audio source specified by the input selector 124 when the audio prompt is ready to be presented by the computing platform 104 and another audio source 126 is selected for playback.

[0027] The computing platform 104 may also receive input from human machine interface (HMI) controls 136 configured to provide occupant interaction with the vehicle 102. For example, the computing platform 104 may interact with one or more buttons or other HMI controls (e.g., steering wheel audio buttons, push-to-talk buttons, instrument panel controls, etc.) configured to invoke functions on the computing platform 104. The computing platform 104 may also drive or otherwise communicate with one or more displays 138 configured to provide visual output to vehicle occupants via a video controller 140. In some cases, the display 138 may be a touch screen that is further configured to receive user touch input via the video controller 140, while in other cases, the display 138 may simply be a display without touch input capabilities.

[0028] The computing platform 104 may also be configured to communicate with other components of the vehicle 102 via one or more in-vehicle networks 142. As some examples, the in-vehicle network 142 may include one or more of a vehicle controller area network (CAN), Ethernet, and a media oriented systems transport (MOST). The in-vehicle network 142 may allow the computing platform 104 to communicate with other systems of the vehicle 102, such as an embedded modem 144 (which may not be present in some configurations), a global positioning system (GPS) module 146 configured to provide current location and heading information of the vehicle 102, and various vehicle ECUs 148 configured to cooperate with the computing platform 104. As some non-limiting feasible ways, the vehicle ECU 148 may include: a powertrain control module, which is configured to provide control of engine operating components (e.g., idle control components, fuel delivery components, emission control components, etc.) and monitoring of engine operating components (e.g., the status of engine diagnostic codes); a body control module, which is configured to manage various power control functions (such as exterior lighting, interior lighting, keyless entry, remote start and entry point status verification (e.g., the closed status of the hood, doors and / or trunk of the vehicle 102)); a radio transceiver module, which is configured to communicate with a remote control key or other local device of the vehicle 102; a climate control management module, which is configured to provide control and monitoring of heating and cooling system components (e.g., compressor clutch and blower fan control, temperature sensor information, etc.).

[0029] As shown, the audio subsystem 122 and the HMI controls 136 can communicate with the computing platform 104 via a first in-vehicle network 142A, and the embedded modem 144, the GPS module 146, and the vehicle ECU 148 can communicate with the computing platform 104 via a second in-vehicle network 142B. In other examples, the computing platform 104 can be connected to more or fewer in-vehicle networks 142. Additionally or alternatively, one or more HMI controls 136 or other components can be connected to the computing platform 104 via an in-vehicle network 142 different from the in-vehicle network 142 shown, or directly connected to the computing platform 104 without connecting to an in-vehicle network 142.

[0030] In response to receiving voice input, the voice interface 134 can generate a short list of possible recognitions and the confidence that each possible recognition is the correct option based on a standard grammar. If one of the items on the list has a relatively high confidence and the confidence of the other items on the list is relatively low, the system can execute a high confidence command or macro. If there are more than one high confidence macro or command, the voice interface 134 can synthesize speech, the voice requests clarification between high confidence commands, and the user can respond to the clarification. In another strategy, the voice interface 134 can cause the computing platform 104 to provide a prompt to the display 138 for the user to confirm which command to select. In some examples, the voice interface 134 can receive the user's selection of the correct option, and the voice interface 134 can learn through the clarification and readjust its recognizer to obtain better performance in the future. If there is no item with high confidence, the voice interface 134 can request the user to repeat the request.

[0031] The computing platform 104 may also be configured to communicate with a mobile device 152 of a vehicle occupant. The mobile device 152 may be any of various types of portable computing devices, such as a cellular phone, a tablet computer, a smart watch, a laptop computer, a portable music player, or other devices capable of communicating with the computing platform 104. In many examples, the computing platform 104 may include a wireless transceiver 150 (e.g., a Bluetooth module, a ZIGBEE transceiver, a Wi-Fi transceiver, an IrDA transceiver, an RFID transceiver, etc.), which is configured to communicate with a compatible wireless transceiver 154 of the mobile device 152. Additionally or alternatively, the computing platform 104 may communicate with the mobile device 152 via a wired connection, such as via a USB connection between the mobile device 152 and the USB subsystem 132. In some examples, the mobile device 152 may be battery powered, while in other cases, the mobile device 152 may receive at least a portion of the vehicle power from the vehicle 102 via a wired connection.

[0032] The communication network 156 may provide communication services such as packet-switched network services (e.g., Internet access, VoIP communication services) to devices connected to the communication network 156. Examples of the communication network 156 may include a cellular telephone network. The mobile device 152 may provide a network connection to the communication network 156 via a device modem 158 of the mobile device 152. To facilitate communication over the communication network 156, the mobile device 152 may be associated with a unique device identifier (e.g., a mobile device number (MDN), an Internet Protocol (IP) address, etc.) to identify the mobile device 152 for communication over the communication network 156. In some cases, the occupants of the vehicle 102 or devices with permission to connect to the computing platform 104 may be identified by the computing platform 104 based on the paired device data 160 stored in the storage medium 112. For example, the paired device data 160 may indicate a unique device identifier of a mobile device 152 that was previously paired with the computing platform 104 of the vehicle 102 , such that the computing platform 104 may automatically reconnect to the mobile device 152 referenced in the paired device data 160 without user intervention.

[0033] When a network-enabled nomadic device 152 is paired with the computing platform 104, the nomadic device 152 may allow the computing platform 104 to use the network connectivity capabilities of the device modem 158 to communicate with a telematics server 162 or other remote computing device over the communication network 156. In one example, the computing platform 104 may utilize a voice or data plan on the nomadic device 152 to transfer information between the computing platform 104 and the communication network 156. Additionally or alternatively, the computing platform 104 may utilize an embedded modem 144 to transfer information between the computing platform 104 and the communication network 156 without using the communication facilities of the nomadic device 152.

[0034] Similar to the computing platform 104, the mobile device 152 may include one or more processors 164 configured to execute instructions of a mobile application 170 loaded from a storage medium 168 of the mobile device 152 to a memory 166 of the mobile device 152. In some examples, the mobile application 170 may be configured to communicate with the computing platform 104 via the wireless transceiver 154 and to communicate with the telematics server 162 or other network services via the device modem 158. The computing platform 104 may also include a device link interface 172 to facilitate integration of the functionality of the mobile application 170 into the syntax of commands available via the voice interface 134. The mobile application 170 is configured to communicate with a device link application core 174 executed by the mobile device 152. In some examples, the mobile application 170 supporting communication with the device link interface 172 may be statically linked to the functionality of the device link application core 174 or otherwise merged into the binary mobile application 170. In other examples, mobile applications 170 supporting communication with the device-link interface 172 may access an application program interface (API) of a shared or independent device-link application core 174 to facilitate communication with the device-link interface 172. The device-link interface 172 may also provide the mobile application 170 with access to vehicle information available to the computing platform 104 via the vehicle network 142. An example of the device-link interface 172 may be the SYNC APPLINK component of the SYNC system provided by FORD MOTOR COMPANY of DEARBORN, MI. Other examples of the device-link interface 172 may include MIRRORLINK, APPLE CARPLAY, and ANDROID AUTO.

[0035] Figure 2 An example diagram 200 of pre-configuring an embedded modem 144 is shown. As shown, a modem manufacturer 202 ships the modem 144 to a vehicle assembly plant 204. The modem manufacturer 202 also provides modem metadata 206 to a backend system 208. The modem metadata 206 may include information such as a module electronic serial number, security key, part number, MAC address, ICCID, or other uniquely identifiable information of the modem 144. The backend system 208 may include various network-capable computing devices configured to receive and store the modem metadata 206 and other information and make determinations related to the configuration and pre-configuration of the modem 144 being installed into the vehicle 102 at the vehicle assembly plant 204.

[0036] An end of line (EOL) system 210 of vehicle assembly plant 204 may be configured to set up an initial configuration of embedded modem 144 installed in vehicle 102. In an example, end of line system 210 may apply software, firmware, and / or default settings based on various factors. As some possible approaches, these factors may include the brand of vehicle 102, the model of vehicle 102, the geographic region where vehicle 102 is going, the country where vehicle 102 is going, and the level of software or firmware currently available for embedded modem 144.

[0037] The embedded modem 144 may communicate via a cellular connection or a Wi-Fi connection through the communication network 156 to the telematics server 162. In some examples, the telematics server 162 may be a cloud server located in an area where the vehicle 102 or vehicle assembly shop 204 is assigned, so that the telematics server 162 being accessed is local to the vehicle 102 or vehicle assembly shop 204. The telematics server 162 may query the backend system 208 to verify the legitimacy and configuration of the embedded modem 144 installed to the vehicle 102. For example, the telematics server 162 may receive the modem metadata 206 and vehicle identification data (e.g., vehicle identification number (VIN), make, model, etc.) from the vehicle 102, and may provide this information to the backend system 208 for inspection. If the configuration is permitted by the backend system 208, the backend system 208 returns a positive configuration result to the telematics server 162, which in turn forwards the result to the vehicle 102. If the pre-configuration of the embedded modem 144 is successful, other ECUs 148 may be pre-configured using the services of the embedded modem 144. If the pre-configuration fails, the backend system 208 may mark the vehicle 102 as requiring further processing to resolve the fault. Figure 4 Other aspects of preconfiguring the embedded modem 144 are discussed in detail in the process 400 shown in FIG.

[0038] Figure 3An example diagram 300 is shown of pre-configuring a vehicle ECU 148 using the services of an embedded modem 144. As shown, an ECU manufacturer 302 ships an ECU 148 to a vehicle assembly plant 204. The ECU manufacturer 302 also provides ECU metadata 304 to a backend system 208. Similar to the modem metadata 206, the ECU metadata 304 may include information such as a module electronic serial number, security key, part number, MAC address, ICCID, or other uniquely identifiable information of the ECU 148. Similar to what is done for the modem 144, the backend system 208 stores the ECU metadata 304 and other information and makes determinations related to the configuration and pre-configuration of the ECU 148 being installed into the vehicle 102 at the vehicle assembly plant 204.

[0039] The end-of-line system 210 of the vehicle assembly shop 204 may also be configured to set up an initial configuration of the ECU 148 installed to the vehicle 102. Similar to what was discussed above with respect to the modem 144, the end-of-line system 210 may apply software, firmware, and / or default settings based on various factors. As some possible approaches, these factors may include the brand of the vehicle 102, the model of the vehicle 102, the geographic region where the vehicle 102 is going, the country where the vehicle 102 is going, and the level of software or firmware currently available for the ECU 148 being installed to the vehicle 102.

[0040] If the embedded modem 144 has been preconfigured, the communication functionality of the embedded modem 144 can also be used to preconfigure the ECU 148. For example, the embedded modem 144 can communicate via a cellular connection or a Wi-Fi connection through the communication network 156 to the telematics server 162 to facilitate preconfiguration of the ECU 148. Typically, the embedded modem 144 can facilitate the provision of ECU metadata 304 and vehicle identification data (e.g., VIN, make, model, etc.) from the vehicle 102 to the telematics server 162. The telematics server 162 can receive the information accordingly and provide the information to the backend system 208 for inspection. If the configuration is permitted by the backend system 208, the backend system 208 will return a positive configuration result to the telematics server 162, and the telematics server 162 will then forward the result to the vehicle 102. If the preconfiguration fails, the backend system 208 can mark the vehicle 102 as requiring subsequent processing to resolve the fault. Reference Figures 5 to 7 Processes 500 through 700 shown in FIG. 1 discuss other aspects of pre-configuring embedded modem 144 in detail.

[0041] Figure 4An example process 400 is shown for preconfiguring the embedded modem 144. In an example, the process 400 may be performed using system elements such as those shown above with reference to diagram 200.

[0042] At operation 402, the embedded modem 144 is manufactured by the modem manufacturer 202, and the modem manufacturer 202 sends the modem metadata 206 to the backend system 208. Thus, the backend system 208 may be operable to receive the modem metadata 206 for further processing.

[0043] At operation 404, the backend system 208 determines whether modem metadata 206 has been received. In an example, the backend system 208 may receive a request to provision a modem 144, but may not have found any modem metadata 206 corresponding to any identifier of the modem 144 being provisioned. If no such data is found, control passes to operation 406. If such data is found, control passes to operation 408.

[0044] At operation 406, the backend system 208 requests the modem metadata 206 from the embedded modem 144. The embedded modem 144 being provisioned may respond accordingly and provide the backend system 208 with the modem metadata 206 corresponding to the embedded modem 144. After operation 406, control returns to operation 404.

[0045] At operation 408, embedded modem 144 is shipped to vehicle assembly plant 204. At operation 410, embedded modem 144 is installed in vehicle 102. At operation 412, embedded modem 144 is configured via end-of-line system 210. For example, end-of-line system 210 may apply software, firmware, and / or default settings based on the make, model, destination geographic location, destination country, or other factors of vehicle 102. It should be noted that the specific order of the particular steps in process 400 may vary. For example, embedded modem 144 may be shipped to vehicle assembly plant 204 before operations 404 and / or 406 are performed.

[0046] At operation 414, the embedded modem 144 initiates modem preconfiguration. In the example, the embedded modem 144 detects via the end-of-line system 210 that the modem 144 has been powered on using the vehicle 102. In response to detecting that the modem 144 is powered on, the modem 144 queries its memory to determine whether the modem 144 has attempted preconfiguration. If the modem 144 has not attempted preconfiguration, the modem 144 initiates preconfiguration mode.

[0047] At operation 416, the embedded modem 144 determines whether the embedded modem 144 is configured to be preconfigured via Wi-Fi. In an example, the embedded modem 144 queries its memory to determine whether the settings applied to the modem 144 (e.g., at operation 412) indicate that the modem 144 can be preconfigured using a Wi-Fi connection. If the settings applied to the modem 144 indicate that the modem 144 can be preconfigured using a Wi-Fi connection, control passes to operation 418, where the embedded modem 144 connects to the telematics server 162 via a Wi-Fi connection. Otherwise, control passes to operation 420, where the embedded modem 144 connects to the telematics server 162 via a cellular connection.

[0048] At operation 422, the embedded modem 144 sends the modem pre-configuration data to the telematics server 162. In an example, the modem pre-configuration data includes the modem metadata 206 and vehicle identification data (e.g., VIN, make, model, etc.). The telematics server 162 may receive the modem pre-configuration data and may provide the information to the backend system 208 for review.

[0049] In operation 424, the embedded modem 144 determines whether a response to the sending of the modem pre-configuration data is received. In an example, if the configuration of the vehicle 102 is permitted by the backend system 208, the backend system 208 returns a positive configuration result to the telematics server 162, which in turn forwards the result to the vehicle 102. If the pre-configuration fails, the backend system 208 may mark the vehicle 102 as requiring subsequent processing to resolve the fault. During a failed pre-configuration, the backend system 208 may also return a negative configuration result to the telematics server 162, which in turn forwards the result to the vehicle 102. If the pre-configuration is successful and the configuration is verified, control passes to operation 426. Otherwise, control passes to operation 428.

[0050] At operation 426, the embedded modem 144 is preconfigured and ready to be used. In some examples, the embedded modem 144 may write to memory that the modem 144 was successfully preconfigured. Once the embedded modem 144 is preconfigured, the embedded modem 144 may be used for communications with the vehicle 102. Additionally, the preconfigured embedded modem 144 may also be used to preconfigure the ECU 148 of the vehicle 102. Figures 5 to 7Other aspects of pre-configuring the ECU 148 using the embedded modem 144 are discussed in detail in processes 500 through 700 shown in FIG.

[0051] At operation 428 , the embedded modem 144 remains unpreconfigured. Therefore, the embedded modem 144 is not ready to be used, and the vehicle 102 is not ready to be used by a customer, as indicated at operation 430 .

[0052] Figure 5 An example process 500 for real-time provisioning of a vehicle ECU 148 utilizing the services of an embedded modem 144 is shown.

[0053] At operation 502 , the ECU 148 is manufactured by the ECU manufacturer 302 , and the ECU manufacturer 302 sends the ECU metadata 304 to the backend system 208 .

[0054] At operation 504, the backend system 208 determines whether ECU metadata 304 has been received. In an example, the backend system 208 may receive a request to provision an ECU 148, but may not have found any ECU metadata 304 corresponding to any identifier of the ECU 148 being provisioned. If no such data is found, control passes to operation 506. If such data is found, control passes to operation 508.

[0055] At operation 506, the backend system 208 requests the ECU metadata 304 for the ECU 148 from the embedded modem 144. The embedded modem 144 may forward the request to the ECU 148, and the ECU 148 being provisioned may respond accordingly to the embedded modem 144 and provide information back to the embedded modem 144. The embedded modem 144 may then send the ECU metadata 304 corresponding to the ECU 148 back to the backend system 208. After operation 506, control returns to operation 504.

[0056] At operation 508, the ECU 148 is shipped to the vehicle assembly plant 204. At operation 510, the ECU 148 is installed in the vehicle 102. At operation 512, the ECU 148 is configured via the end-of-line system 210. For example, the end-of-line system 210 may apply software, firmware, and / or default settings based on the make, model, destination geographic location, destination country, or other factors of the vehicle 102. It should be noted that the specific order of the particular steps in the process 500 may vary. For example, the ECU 148 may be shipped to the vehicle assembly plant 204 before performing operations 504 and / or 506.

[0057] At operation 514, the ECU 148 initiates preconfiguration of the ECU 148. In an example, the ECU 148 detects via the end-of-line system 210 that the ECU 148 has been powered on with the vehicle 102. In response to detecting that the ECU 148 is activated, the ECU 148 queries its memory to determine whether the ECU 148 has attempted preconfiguration. If the ECU 148 has not attempted preconfiguration, the ECU 148 initiates a preconfiguration mode. For example, the ECU 148 may request the embedded modem 144 to proceed with preconfiguration of the ECU 148. In another possible approach, the embedded modem 144 may be responsible for initiating the ECU 148 for preconfiguration, and may query the ECU 148 via the vehicle bus 142 to determine whether any ECU 148 needs to be preconfigured.

[0058] At operation 516, the ECU 148 sends the ECU metadata 304 to the embedded modem 144. Thus, the embedded modem 144 receives the data for transmission. At operation 518, the embedded modem 144 sends the ECU pre-configuration data to the telematics server 162. In an example, the ECU pre-configuration data includes the ECU metadata 304 as well as vehicle identification data (e.g., VIN, make, model, etc.). As described above, the embedded modem 144 may send the data via a cellular connection or a Wi-Fi connection. The telematics server 162 may receive the ECU pre-configuration data and may provide the information to the backend system 208 for review.

[0059] At operation 520, the embedded modem 144 determines whether a response to sending the ECU pre-configuration data is received. In the example, if the configuration of the vehicle 102 is permitted by the backend system 208, the backend system 208 returns a positive configuration result to the telematics server 162, which in turn forwards the result to the embedded modem 144 of the vehicle 102, which in turn forwards the result to the ECU 148. If the pre-configuration fails, the backend system 208 may mark the vehicle 102 as requiring subsequent processing to resolve the fault. During a failed pre-configuration, the backend system 208 may also return a negative configuration result to the telematics server 162, which in turn forwards the result to the embedded modem 144 of the vehicle 102, which in turn forwards the result to the ECU 148. If the pre-configuration is successful and the configuration is verified, control passes to operation 522. Otherwise, control passes to operation 524.

[0060] At operation 522, the ECU 148 is preconfigured and ready to be used. In some examples, the ECU 148 may write to memory that the ECU 148 was successfully preconfigured. Once the ECU 148 is preconfigured, the ECU 148 is able to operate (including using networked communication services via the embedded modem 144). At operation 524, the ECU 148 remains unpreconfigured. Therefore, the ECU 148 is not ready to be used, and as indicated at operation 526, the vehicle 102 is not ready to be used by the customer.

[0061] Figure 6 An example process 600 is shown for hybrid provisioning of the vehicle ECU 148 utilizing the services of the embedded modem 144. As shown, operations 602 through 618 of process 600 are consistent with operations 502 through 518 of process 500 and will not be repeated here.

[0062] At operation 620 of process 600, the ECU metadata is validated offline. Thus, rather than the ECU 148 waiting for an immediate response from the backend system 208 via the telematics server 162, the ECU 148 may receive a validation response at a later time. For example, the backend system 208 may process the pre-configured request periodically (e.g., every hour or day), upon retrieving a predefined number of requests (e.g., 10, 100), or simply at the convenience of the backend system 208.

[0063] At operation 622, the embedded modem 144 determines whether a response to sending the ECU pre-configuration data is received. In an example, if the configuration of the vehicle 102 is permitted by the backend system 208, the backend system 208 returns a positive configuration result to the telematics server 162. The embedded modem 144 may then query the telematics server 162 for the configuration result. If the configuration result is available, the embedded modem 144 may retrieve the result from the telematics server 162, and control is transferred to operation 624 to provide the result to the ECU 148. If the configuration result is not available, the embedded modem 144 may query the telematics server 162 again at a later time. For example, the embedded modem 144 may maintain a retry counter and may repeatedly query the telematics server 162 for a predefined number of retries and / or a predefined number of hours or a predefined number of days. If the embedded modem 144 fails to receive a response within a predefined number of retries or a predefined time or if the response indicates that the pre-configuration failed, control is transferred to operation 626.

[0064] As in operation 522, at operation 624, the ECU 148 is preconfigured and ready to be used. As in operation 524, at operation 626, the ECU 148 remains unpreconfigured. Therefore, the ECU 148 is not ready to be used, and as indicated at operation 628, the vehicle 102 is not ready to be used by a customer.

[0065] Figure 7 An example process 700 is shown for batch preconfiguring vehicle ECUs 148 using services of embedded modems 144. As shown, operations 702 to 716 of process 700 are consistent with operations 502 to 516 of process 500 and operations 602 to 616 of process 600 and are not repeated here.

[0066] At operation 718 of process 700, assembly of vehicle 102 is completed. Other vehicles 102 may accordingly continue through vehicle assembly shop 204 and be assembled, each with their own ECU 148 to be preconfigured.

[0067] At operation 720, the telematics server 162 creates a batch file for the plurality of vehicles 102 waiting to be preconfigured. In an example, the telematics server combines the requests for the plurality of vehicles 102 waiting to preconfigure the ECU 148 into a single batch request. For example, the telematics server 162 may combine the plurality of requests into a single batch request until a predefined number (e.g., 10, 100, etc.) of requests are received and / or until a predefined time period (e.g., one hour, one day, etc.) has been reached. The batch request may then be sent to the backend system 208 at operation 722. The backend system 208 may verify the batch of requests received and may return a batch response including the results to the telematics server 162 at operation 724. Similar to the processing of a single vehicle 102 , as discussed above with respect to operations 620 through 626 of process 600 , a response to the preconfiguration request may be received by the telematics server 162 from the backend system 208 and may be provided to the vehicle 102 in response to a query by the vehicle 102 .

[0068] Thus, pre-configuration of the ECU 148 may be performed using real-time processing, using batch processing, or using a hybrid approach that uses aspects of each approach. Thus, pre-configuration of the ECU 148 may be performed using the embedded modem 144 of the vehicle 102 once the embedded modem 144 itself has been pre-configured. By using the described approach, each component of the remotely accessible vehicle 102 is properly configured and verified in the backend system 208, wherein the pre-configuration may be performed before the vehicle 102 is ready to be sold to a customer.

[0069] The computing devices described herein, such as computing platform 104, mobile device 152 and telematics server 162, backend system 208 and end-of-line system 210, generally include computer-executable instructions that can be executed by one or more computing devices such as those described above. The computer-executable instructions can be compiled or interpreted from a computer program created using a variety of programming languages ​​and / or technologies, including, but not limited to, one or a combination of the following: Java; TM , C, C++, C#, Visual Basic, Java Script, Python, Perl, PL / SQL, Prolog, LISP, Corelet, etc. In general, a processor (e.g., a microprocessor) receives instructions from, for example, a memory, a computer-readable medium, etc., and executes these instructions to perform one or more processes, including one or more of the processes described herein. Various computer-readable media can be used to store and transmit such instructions and other data.

[0070] With respect to the processes, systems, methods, teachings, and the like described herein, it should be understood that although the steps of such processes, and the like have been described as occurring according to a particular ordered sequence, such processes may be implemented with the steps performed in sequences other than the sequence described herein. It should also be understood that certain steps may be performed simultaneously, other steps may be added, or certain steps described herein may be omitted. In other words, the descriptions of processes herein are provided for the purpose of illustrating particular embodiments and should not be construed in any way as limiting the claims.

[0071] Accordingly, it should be understood that the above description is intended to be illustrative and not restrictive. When reading the above description, many embodiments and applications outside the examples provided will be apparent. The scope should not be determined with reference to the above description, but with reference to the full scope of the equivalents claimed by the claims and these claims. It is anticipated and planned that future developments will occur in the technology described herein, and the disclosed systems and methods will be incorporated into such future embodiments. In a word, it should be understood that the present application can be modified and changed.

[0072] Unless expressly indicated to the contrary herein, all terms used in the claims are intended to be given their broadest reasonable constructions and their ordinary meanings as understood by those skilled in the art described herein. In particular, unless a claim recites an express limitation to the contrary, the use of singular articles such as "a," "said," "the," etc. should be understood to describe one or more of the indicated elements.

[0073] An abstract of the specification of the present disclosure is provided to allow the reader to quickly determine the essence of the technical disclosure. The abstract of the specification of the present disclosure is submitted with the understanding that the abstract will not be used to interpret or limit the scope or meaning of the claims. In addition, in the aforementioned detailed description, it can be seen that for the purpose of simplifying the present disclosure, multiple features are combined together in multiple embodiments. The method of the present disclosure will not be interpreted as reflecting that the embodiments intended to be protected require more features than those clearly stated in each claim. More precisely, as reflected in the claims, the subject matter of the invention lies in less than all the features of a single disclosed embodiment. Therefore, the claims are included herein in the detailed description, wherein each claim exists independently as a separately claimed subject matter.

[0074] Although exemplary embodiments are described above, these embodiments are not intended to describe all possible forms of the present invention. More specifically, the words used in the specification are descriptive rather than restrictive, and it should be understood that various changes may be made without departing from the spirit and scope of the present invention. In addition, the features of the various embodiments of implementation may be combined to form further embodiments of the present invention.

Claims

1. A vehicle comprising: Embedded modem, configured as: pre-configuring an embedded modem of the vehicle by requesting confirmation of a modem configuration assigned by a production line end system from a telematics server; receiving a request from an electronic control unit via a vehicle bus, the electronic control unit requesting confirmation of an electronic control unit configuration assigned by an end-of-line system; sending the request received from the electronic control unit to the telematics server for confirmation; The results are reported from the telematics server to the electronic control unit.

2. The vehicle according to claim 1, wherein: The request received from the electronic control unit includes electronic control unit metadata, which includes uniquely identifiable information of the electronic control unit and uniquely identifiable information of the vehicle, and the result of the confirmation is determined based on a comparison of the electronic control unit information and the vehicle information with the electronic control unit metadata provided from the manufacturer of the electronic control unit.

3. The vehicle according to claim 1, wherein: The result is received from a telematics server in response to the request received from the electronic control unit.

4. The vehicle according to claim 1, wherein: The results are received from the telematics server in response to the embedded modem periodically querying the telematics server for the results.

5. The vehicle according to claim 4, wherein: The embedded modem is configured to report an error condition if the result is not received from the telematics server after a predetermined number of queries to the telematics server.

6. The vehicle of claim 1, wherein: The embedded modem is also configured to determine whether the embedded modem is configured to be preconfigured using a Wi-Fi connection, and if the embedded modem is configured to be preconfigured using a Wi-Fi connection, attempt to send a request for confirmation of the modem configuration assigned by the production line terminal system to the telematics server via the Wi-Fi connection before attempting to send the request for confirmation of the modem configuration assigned by the production line terminal system to the telematics server via the cellular connection.

7. The vehicle of claim 6, wherein: The embedded modem is also configured to utilize a Wi-Fi connection according to a configuration received by the embedded modem from an end-of-line system of the vehicle assembly plant.

8. The vehicle of claim 1, wherein: The electronic control unit is a Bluetooth low energy controller.

9. A system for pre-configuring vehicle components, comprising: The telematics server is configured to: receiving a request to preconfigure an electronic control unit from an embedded modem of a vehicle being preconfigured using the telematics server; forwarding the request to a backend system configured to process the request; receiving a response to the request from a backend system; The response is made available to the embedded modem.

10. The system of claim 9, wherein: The telematics server is further configured to send the response to the embedded modem via the same connection used by the telematics server to receive the request.

11. The system of claim 9, wherein: The telematics server is also configured to: receiving another request to preconfigure another electronic control unit from another embedded modem of another vehicle that is preconfigured using the telematics server; The request and the other request are included in a single batch request to be sent to the backend system.

12. The system of claim 9, wherein: The backend system is further configured to process the request and other requests in a plurality of batch processing requests to preconfigure a plurality of electronic control units.

13. The system of claim 12, wherein: The backend system is further configured to process the request and other electronic control unit pre-configuration requests in response to determining that a predefined number of the requests are waiting to be processed.

14. The system of claim 12, wherein: The backend system is further configured to process the request and other electronic control unit preconfiguration requests in response to determining that a predefined period of time has elapsed since the backend system previously processed the electronic control unit preconfiguration request.

15. The system of claim 12, wherein: The backend system is further configured to, in response to determining that the current time is a scheduled time for processing the electronic control unit pre-configuration request, process the request and other electronic control unit pre-configuration requests.

16. A method for pre-configuring a vehicle component, comprising the following operations performed by a backend system: In response to receiving a request from an embedded modem of a vehicle via a telematics server to preconfigure the embedded modem, preconfiguring the embedded modem using modem metadata received from a manufacturer of the embedded modem; In response to receiving a request from the embedded modem via the telematics server to preconfigure a controller of a vehicle, the controller is preconfigured using controller metadata received from a manufacturer of the controller.

17. The method of claim 16, further comprising the following operations performed by a backend system: receiving, from the telematics server, a plurality of requests for preconfiguring a controller in a batch, the batch including the requests for preconfiguring the controller; In response to receiving the batch, preconfiguring the controller and other controllers; In response to the preconfiguration, the result of preconfiguring the controller and the other controllers is included in a response batch and sent.

18. The method as claimed in claim 16 also includes the following operations performed by the back-end system: processing the request for preconfiguration of the controller in response to determining one or more of the following conditions: a predefined number of controller preconfiguration requests are waiting to be processed; a predefined time period has passed since the back-end system previously processed the controller preconfiguration request; the current time is the scheduled time for processing the controller preconfiguration request.

Images