Command and control delivery mechanism

Abstract

The invention relates to a command and control delivery mechanism. A system includes a first device, an Internet of Things ecosystem, and a vehicle. The first device is operable to transmit a message to the Internet of Things ecosystem. The Internet of Things ecosystem is operable to wirelessly transmit messages to the vehicle in accordance with a given Internet of Things protocol. A circuit in a vehicle that supports an Internet of Things protocol is operable to receive a message, wake up one or more modules in response to receipt of the message, and deliver the message to the module. The module is operable to process the message. The one or more modules do not support the Internet of Things protocol. In response to completion of the message processing, the vehicle is operable to transmit an acknowledgement signal to the outside of the vehicle.

Description

[0001] introduce

[0002] This disclosure relates to systems and methods for command and control delivery mechanisms.

[0003] Current automotive command and control mechanisms rely on Short Message Service (SMS) messages sent via the Integrated Management System (IMS). Such messages consume significant power due to registration overhead and can lead to unexpected latency.

[0004] Therefore, those skilled in the art continue to conduct research and development in the field of command and control delivery mechanisms. Summary of the Invention

[0005] This document provides a system. The system includes a first device, an Internet of Things (IoT) ecosystem, and a vehicle. The first device is operable to transmit messages via a first protocol. The IoT ecosystem has an IoT controller and one or more nodes supporting the IoT protocol. The IoT controller is operable to receive the messages from the first device according to the first protocol. One of the following is operable to wirelessly transmit the messages according to a given IoT protocol: (i) the IoT controller and (ii) the one or more nodes supporting the IoT protocol. The given IoT protocol is different from the first protocol. The vehicle has circuitry supporting the IoT protocol and one or more modules. The circuitry supporting the IoT protocol is operable to: receive the messages from the IoT ecosystem according to the given IoT protocol; wake up the one or more modules in response to receiving the messages; and deliver the messages to the one or more modules. The one or more modules are operable to process the messages. The one or more modules do not support the IoT protocol. In response to completion of message processing, the vehicle is operable to transmit an acknowledgment signal to an external location.

[0006] In one or more embodiments of the system, the circuitry supporting the Internet of Things (IoT) protocol is also operable to: filter the message among a plurality of permissible messages of the given IoT protocol; accept the message if it passes the filter; and reject the message if it fails the filter.

[0007] In one or more embodiments of the system, the IoT protocol-supporting circuitry includes a vehicle transceiver operable to receive the message from the IoT ecosystem according to the given IoT protocol. When in standby mode, the vehicle transceiver is a low-power transceiver. The IoT protocol-supporting circuitry is operable to further wake up the one or more modules in response to the receipt of the message.

[0008] In one or more embodiments of the system, the IoT ecosystem is also operable to register the vehicle with the IoT controller before transmitting the message to the vehicle. The vehicle is an IoT device at the time of registration.

[0009] In one or more embodiments of the system, the vehicle further includes a vehicle transceiver. The vehicle transceiver is operable to directly wirelessly transmit the response signal to the first device using a second protocol. The second protocol differs from the given Internet of Things protocol.

[0010] In one or more embodiments of the system, the vehicle further includes a vehicle transceiver. The vehicle transceiver is operable to wirelessly transmit the response signal to the IoT controller in accordance with the given IoT protocol.

[0011] In one or more embodiments of the system, the circuit-hosted IoT hub supports IoT protocols. The IoT hub is operable for communication via a variety of IoT-enabled technologies.

[0012] In one or more embodiments of the system, the IoT ecosystem is also operable to establish multi-hop paths via the one or more IoT nodes between the IoT controller and the vehicle.

[0013] In one or more embodiments, the system includes a smart device operable to transmit the message to the first device. The first device is a server computer operable to receive the message from the smart device. The server computer is operable to wirelessly transmit the message to the IoT controller via the first protocol.

[0014] In one or more embodiments, the system includes a smart device operable to transmit the message directly to the IoT controller via the given IoT protocol. The first device is a server computer. The message from the smart device to the IoT controller bypasses the server computer.

[0015] In one or more embodiments of the system, the IoT ecosystem is also operable to cascade messages received from the first device. The IoT ecosystem includes a designated trusted IoT node among the one or more IoT nodes. The vehicle includes a vehicle transceiver. The vehicle transceiver is operable to periodically wirelessly transmit check command messages to the designated trusted IoT node of the message according to a second protocol. The second protocol differs from the given IoT protocol. The IoT ecosystem is also operable to wirelessly transmit the check command message to the vehicle transceiver according to the second protocol in response to the receipt of the check command message.

[0016] In one or more embodiments of the system, the vehicle transceiver may also be operable to wirelessly transmit the response signal to the designated trusted IoT node in accordance with the second protocol.

[0017] In one or more embodiments of the system, the vehicle further includes a battery. The battery has a state of charge. The transmission period of the check command message from the vehicle transceiver changes in response to one or more of the following: (i) the state of charge of the battery and (ii) a configuration wait time.

[0018] In one or more embodiments of the system, the circuit supporting the Internet of Things protocol is also operable to register the one or more modules as a prerequisite for transmitting the message from the circuit supporting the Internet of Things protocol to the one or more modules.

[0019] In one or more embodiments of the system, a designated trusted IoT node of the one or more IoT nodes in the IoT ecosystem may also be operable to: authenticate the one or more additional circuits in the vehicle as a prerequisite for transmitting the message from the designated trusted IoT node to the vehicle.

[0020] In one or more embodiments of the system, the designated trusted IoT node may also be operable to filter the message based on authentication from the one or more modules. In response to passing the filter, the message is transmitted to the vehicle. In response to failing the filter, the message is withheld from transmission to the vehicle.

[0021] In one or more embodiments of the system, the given Internet of Things protocol is the Matter protocol defined by Matter.

[0022] This document provides a method for a command and control delivery mechanism. The method includes: transmitting a message from a first device via a first protocol; and receiving the message from the first device at an IoT controller in an IoT ecosystem according to the first protocol.

[0023] The message is wirelessly transmitted according to a given Internet of Things (IoT) protocol from one of the following: (i) the IoT controller and (ii) one or more IoT nodes in the IoT ecosystem; the message is received according to the given IoT protocol at a circuit in a vehicle from the IoT ecosystem that supports the IoT protocol; and in response to receiving the message, one or more modules in the vehicle are woken up using the circuit that supports the IoT protocol. The one or more modules do not support the IoT protocol. The method includes transmitting the message from the circuit that supports the IoT protocol to the one or more additional modules; processing the message with the one or more modules; and transmitting an acknowledgment signal from the vehicle in response to completion of message processing.

[0024] In one or more embodiments, the method includes: cascading messages received from a first device in the Internet of Things (IoT) ecosystem. The IoT ecosystem includes a designated trusted IoT node among the one or more IoT nodes. The vehicle includes a vehicle transceiver. The method further includes: periodically wirelessly transmitting an inspection command message from the vehicle transceiver to the designated trusted IoT node of the message according to a second protocol, wherein the second protocol is different from the given IoT protocol; and in response to receiving the inspection command message at the IoT ecosystem, wirelessly transmitting the message from the IoT ecosystem to the vehicle transceiver according to the second protocol.

[0025] This document provides a vehicle. The vehicle includes a vehicle transceiver, one or more modules, circuitry supporting an Internet of Things (IoT) protocol, and a wireless transceiver. The vehicle transceiver is operable to receive messages from an IoT ecosystem according to a given IoT protocol. The vehicle registers with the IoT ecosystem as an IoT device. The one or more modules are operable to process the messages. The one or more modules are circuitry that does not support the IoT protocol. The circuitry supporting the IoT protocol is operable to: wake up the one or more modules in response to receiving the message; deliver the message to the one or more modules; and host an IoT hub. The IoT hub is operable to communicate via various IoT-enabled technologies. The vehicle transceiver is also operable to transmit an acknowledgment signal to an external location of the vehicle in response to completion of message processing. The wireless transceiver is operable to connect the vehicle to the Internet, send data to the Internet, and receive data from the Internet.

[0026] This disclosure provides the following examples:

[0027] Example 1. A system comprising:

[0028] A first device, operable for transmitting messages via a first protocol;

[0029] An Internet of Things (IoT) ecosystem consists of an IoT controller and one or more nodes that support IoT protocols, wherein:

[0030] The IoT controller is operable to receive the message from the first device according to the first protocol; and

[0031] One of the following is operable to wirelessly transmit the message according to a given Internet of Things (IoT) protocol: (i) the IoT controller and (ii) the one or more nodes supporting the IoT protocol; and

[0032] The given IoT protocol is different from the first protocol;

[0033] The vehicle has circuitry and one or more modules that support Internet of Things (IoT) protocols, wherein:

[0034] The circuit supporting the Internet of Things protocol is operable for:

[0035] Receive the message from the IoT ecosystem in accordance with the given IoT protocol;

[0036] In response to receiving the message, wake up the one or more modules; and send the message to the one or more modules;

[0037] The one or more modules are operable to process the message;

[0038] One or more modules do not support IoT protocols; and

[0039] In response to the completion of message processing, the vehicle is operable to transmit a response signal to the outside of the vehicle.

[0040] Example 2. According to the system described in Example 1, the circuit supporting the Internet of Things protocol is also operable to:

[0041] Filter the message among multiple permissible messages of the given Internet of Things protocol;

[0042] Accept the message when passing through the filter; and

[0043] The message is rejected if it fails the filter.

[0044] Example 3. The system according to Example 2, wherein:

[0045] The circuitry supporting the Internet of Things (IoT) protocol includes a vehicle transceiver operable to receive the message from the IoT ecosystem in accordance with the given IoT protocol.

[0046] When in standby mode, the vehicle transceiver is a low-power transceiver; and

[0047] The circuitry supporting the Internet of Things protocol is operable to wake up the one or more modules in further response to the receipt of the message.

[0048] Example 4. The system according to Example 1, wherein:

[0049] The IoT ecosystem is also operable to register the vehicle with the IoT controller before transmitting the message to the vehicle; and

[0050] The vehicle was registered as an Internet of Things (IoT) device.

[0051] Example 5. The system according to Example 1, wherein

[0052] The vehicle also includes a vehicle transceiver;

[0053] The vehicle transceiver is operable to directly wirelessly transmit the response signal to the first device using a second protocol; and

[0054] The second protocol is different from the given IoT protocol.

[0055] Example 6. The system according to Example 1, wherein the vehicle further includes:

[0056] A vehicle transceiver operable to wirelessly transmit the response signal to the IoT controller in accordance with the given IoT protocol.

[0057] Example 7. The system according to Example 1, wherein:

[0058] The circuit-hosted IoT hub that supports IoT protocols; and

[0059] The IoT hub is operable for communication via a variety of IoT-enabled technologies.

[0060] Example 8. The system according to Example 1, wherein:

[0061] The IoT ecosystem is also operable to establish multi-hop paths through one or more IoT nodes between the IoT controller and the vehicle.

[0062] Example 9. The system according to Example 1 further includes:

[0063] A smart device, operable to transmit the message to the first device, wherein:

[0064] The first device is a server computer operable to receive the message from the smart device; and

[0065] The server computer is operable to wirelessly transmit the message to the IoT controller via the first protocol.

[0066] Example 10. The system according to Example 1 further includes:

[0067] A smart device operable to transmit the message directly to the IoT controller via the given IoT protocol, wherein:

[0068] The first device is a server computer; and

[0069] The messages from the smart device to the IoT controller bypass the server computer.

[0070] Example 11. The system according to Example 1, wherein:

[0071] The IoT ecosystem is also operable for cascading the messages received from the first device;

[0072] The IoT ecosystem includes a designated trusted IoT node among the one or more IoT nodes;

[0073] The vehicle includes a vehicle transceiver;

[0074] The vehicle transceiver is operable to periodically wirelessly transmit inspection command messages to the designated trusted IoT node of the message in accordance with a second protocol.

[0075] The second protocol differs from the given IoT protocol; and

[0076] The IoT ecosystem is also operable to wirelessly transmit the inspection command message to the vehicle transceiver in response to the receipt of the message, in accordance with the second protocol.

[0077] Example 12. The system according to Example 11, wherein:

[0078] The vehicle transceiver is also operable to wirelessly transmit the response signal to the designated trusted IoT node in accordance with the second protocol.

[0079] Example 13. The system according to Example 11, wherein:

[0080] The vehicle also includes a battery;

[0081] The battery is in a charging state; and

[0082] The transmission cycle of the inspection command message from the vehicle transceiver may be changed in response to one or more of the following: (i) the state of charge of the battery and (ii) the configuration wait time.

[0083] Example 14. The system according to Example 1, wherein:

[0084] The circuit supporting the Internet of Things (IoT) protocol is also operable to register the one or more modules as a prerequisite for transmitting the message from the circuit supporting the IoT protocol to the one or more modules.

[0085] Example 15. The system according to Example 1, wherein:

[0086] The designated trusted IoT node of the one or more IoT nodes in the IoT ecosystem can also be operated to: authenticate the one or more additional circuits in the vehicle as a prerequisite for transmitting the message from the designated trusted IoT node to the vehicle.

[0087] Example 16. The system according to Example 15, wherein:

[0088] The designated trusted IoT node can also be operated to filter the messages based on authentication from the one or more modules;

[0089] In response to passing the filter, the message is transmitted to the vehicle; and

[0090] In response to failing the filter, the message is withheld and not transmitted to the vehicle.

[0091] Example 17. The system according to Example 1, wherein:

[0092] The given IoT protocol is the Matter protocol, defined by the Matter specification of the Connectivity Standards Consortium.

[0093] Example 18. A method for a command and control delivery mechanism, comprising:

[0094] Messages are transmitted from the first device via the first protocol;

[0095] The message is received from the first device at the IoT controller in the IoT ecosystem in accordance with the first protocol;

[0096] The message is wirelessly transmitted from one of the following in accordance with a given Internet of Things (IoT) protocol: (i) the IoT controller and (ii) one or more IoT nodes in the IoT ecosystem;

[0097] The message is received at a circuit in a vehicle from the IoT ecosystem that supports the IoT protocol, in accordance with the given IoT protocol.

[0098] In response to receiving the message, one or more modules in the vehicle are woken up using the circuitry that supports the Internet of Things (IoT) protocol, wherein the one or more modules do not support the IoT protocol.

[0099] The message is transmitted from the circuit supporting the Internet of Things protocol to the one or more additional modules;

[0100] The message is processed using one or more of the modules; and

[0101] In response to the completion of message processing, an acknowledgment signal is transmitted from the vehicle.

[0102] Example 19. The method according to Example 18 further includes:

[0103] The cascade receives messages from the first device in the IoT ecosystem, wherein:

[0104] The IoT ecosystem includes designated trusted IoT nodes among the one or more IoT nodes; and

[0105] The vehicle includes a vehicle transceiver;

[0106] Periodically transmit inspection command messages wirelessly from the vehicle transceiver to the designated trusted IoT node according to a second protocol, wherein the second protocol differs from the given IoT protocol; and

[0107] In response to receiving the inspection command message at the IoT ecosystem, the message is wirelessly transmitted from the IoT ecosystem to the vehicle transceiver in accordance with the second protocol.

[0108] Example 20. A vehicle comprising:

[0109] Vehicle transceivers, operable to receive messages from the IoT ecosystem according to a given IoT protocol, wherein

[0110] The vehicle registers itself as an IoT device with the IoT ecosystem.

[0111] One or more modules operable for processing the message, wherein the one or more modules are circuits that do not support Internet of Things protocols;

[0112] Circuits that support IoT protocols can be used for:

[0113] In response to receiving the message, wake up the one or more modules;

[0114] Send the message to the one or more modules; and

[0115] Hosted IoT hub, wherein the IoT hub is operable for communicating via a variety of IoT-enabled technologies;

[0116] The vehicle transceiver is also operable to transmit an acknowledgment signal to the outside of the vehicle in response to completion of message processing; and

[0117] A wireless transceiver operable to connect the vehicle to the Internet, send data to the Internet, and receive data from the Internet.

[0118] The above features and advantages, as well as other features and advantages, will become apparent when understood in conjunction with the accompanying drawings, based on the following detailed description of the best mode for carrying out this disclosure. Attached Figure Description

[0119] Figure 1 This is a schematic plan view illustrating a system relating to a vehicle according to one or more exemplary embodiments.

[0120] Figure 2 It is a schematic functional flowchart of the operation of a system according to one or more exemplary embodiments.

[0121] Figure 3 It is a schematic functional flowchart illustrating the operation of another system according to one or more exemplary embodiments.

[0122] Figure 4 It is a schematic sequence diagram of a first sequence according to one or more exemplary embodiments.

[0123] Figure 5 It is a schematic functional flowchart illustrating the operation of yet another system according to one or more exemplary embodiments.

[0124] Figure 6 It is a schematic sequence diagram of a second sequence according to one or more exemplary embodiments. Detailed Implementation

[0125] Embodiments of this disclosure provide systems and / or methods for command and control mechanisms. A general feature of these systems / methods is the use of a Small Message Service (SMS) protocol as an alternative to communication between an Internet of Things (IoT) ecosystem and a vehicle, which may be in an ignition-off mode (i.e., a low-power mode) and capable of using minimal power. Using SMS to execute commands and controls over the vehicle consumes high energy and can result in high latency, leading to rapid battery depletion and potentially a poor customer experience. The vehicle can register as an IoT device with the IoT ecosystem. The vehicle's IoT-enabled modules (or circuitry) can be continuously or intermittently powered via low-power, standby, or sleep modes, even when the rest of the vehicle system is powered down. Continuous power supply enables the vehicle's IoT-enabled modules to remain responsive (e.g., listening for new incoming messages, sending responses to incoming messages, and / or sending periodic messages to maintain connectivity and membership in the IoT ecosystem operating through IoT ecosystem protocols such as Matter).

[0126] When a message containing commands for the vehicle is received—commands that the vehicle intends to take (such as collecting diagnostic data, starting the vehicle, or adjusting vehicle settings such as seat or mirror positions)—a module supporting the IoT protocol can wake up one or more conventional (e.g., non-IoT-compliant) modules (or circuits) to execute the command. Once the command is executed, the vehicle can send an acknowledgment (ACK) signal back to the user who initiated the command via the IoT ecosystem network. Alternatively, the ACK can be sent to a backend entity that manages and processes vehicle commands and control services using a communication method that does not support the IoT protocol (e.g., via cellular connectivity). In various embodiments, when a user's smart device (such as a smartphone or smartwatch) is part of the same IoT ecosystem as the vehicle, commands issued by the user are transmitted to the IoT ecosystem via the smart device. In some embodiments, when a vehicle joins the IoT ecosystem, it registers itself with the IoT controller via an application service to request that command and control messages arriving from a remote (backend) command and control server (a backend entity that may run on a cloud platform) be sent to the IoT controller, which is responsible for dispatching command and control services to the vehicle. The IoT controller, as part of the services requested in the application, establishes a relationship with the backend command and control ecosystem. In one embodiment, when the device used by the user to issue commands to the vehicle is not in the same IoT network as the vehicle, the command is first sent to a remote (backend) cloud server via the internet. The cloud server then sends a message containing the command to the vehicle through the internet-connected IoT controller. The IoT controller then relays the arriving messages for the vehicle to the vehicle via the IoT network.

[0127] refer to Figure 1 The illustration shows a schematic plan view of a system 70 relating to a vehicle 90 according to one or more exemplary embodiments. System 70 may include a vehicle 90, an IoT ecosystem 92, an (optional) Internet 94, and an (optional) cellular network 96. The vehicle 90 typically includes a first electronic control unit (ECU), a plurality of second ECUs 102a-102n, an optional cellular transceiver 106, and a battery 108. An IoT (or Matter)-enabled ECU 100 may include IoT (or Matter)-enabled circuitry 110, a wireless vehicle transceiver 112, and a wireless transceiver 114. The IoT-enabled circuitry 110 may host an IoT hub 116 operable for translating and mapping messages from various IoT protocols or conventional IoT devices. Each second ECU 102a-102n typically includes one or more circuits 120 that do not support IoT protocols (or non-Matter) (one is shown in each second ECU 102a-102n).

[0128] Vehicle 90 can be a gas-powered vehicle, an electric vehicle, a hybrid vehicle, or a plug-in hybrid vehicle. In various embodiments, vehicle 90 can be, but is not limited to, a bus, truck, autonomous vehicle, motorcycle, boat, and / or aircraft. Other types of vehicle 90 can be implemented to meet design standards for specific applications.

[0129] The IoT ecosystem 92 can realize a home IoT ecosystem. In various embodiments, the IoT ecosystem 92 can conform to Matter. Protocols in Matter may be referred to herein as Matter protocols. In other embodiments, the IoT ecosystem 92 can conform to a given IoT protocol among other IoT protocols. In such cases, the connectivity protocol may be referred to herein as a given IoT protocol. The IoT ecosystem 92 is operable for transmitting information 121 to and from the vehicle transceiver 112.

[0130] The Internet 94 can exchange data 124 with the wireless transceiver 114. Data 124 can be transmitted along the Internet 94 via wired and / or wireless means. In various embodiments, the IoT ecosystem 92 can communicate via the Internet 94.

[0131] Cellular network 96 enables telephone / data networks. Cellular network 96 typically provides wireless data and / or voice communication with network nodes (such as cellular transceiver 106).

[0132] The first electronic control unit (ECU) 100 implements multiple digital computing circuits. These digital computing circuits can exchange data across a communication bus. The digital computing circuits can be implemented in hardware, software executing on the hardware, or a combination of both. The first ECU 100 may include low-power circuitry and conventional circuitry. When the vehicle 90 is in a powered-off state, the low-power circuitry can enter a low-power mode to listen for a wake-up signal. The conventional circuitry may be inoperable when the vehicle 90 is powered-off, but operable when the vehicle 90 is powered-on and / or in one or more intermediate states. In response to receiving a wake-up signal, the low-power circuitry can operate to wake up the conventional circuitry within the first ECU 100. In some embodiments, the wake-up signal is an initial message received when the low-power circuitry is in low-power mode. In other embodiments, the wake-up signal is a signal separate from subsequent messages containing vehicle commands.

[0133] The first ECU 100 can send and receive messages 121 to and from the IoT ecosystem 92 via the vehicle transceiver 112. Two-way data 124 can also be exchanged with the Internet 94 using the wireless transceiver 114. Additional two-way data 126 can be exchanged with other devices (not shown) on the cellular network via the cellular transceiver 106.

[0134] Each second ECU 102a-102n implements multiple digital computing circuits. These digital computing circuits can exchange data across a communication bus. The digital computing circuits can be implemented in hardware, software executed on hardware, or a combination of both. Each second ECU 102a-102n may include conventional circuitry. The conventional circuitry may include circuitry 120 that does not support the IoT protocol. Circuitry 120 that does not support the IoT protocol communicates with circuitry 110 that supports the IoT protocol. Circuitry 120 that does not support the IoT protocol may be inoperable when the vehicle 90 is in a closed state and operable when the vehicle 90 is in an open state and / or one or more intermediate states. The transition of circuitry 120 from inoperability to operability is partially controlled by circuitry 110 that supports the IoT protocol, which receives either (i) a wake-up signal followed by an initial message, or (ii) only an initial message as a tacit wake-up signal.

[0135] Cellular transceiver 106 implements a cellular network node that is operable to transmit digital messages on cellular network 96.

[0136] Battery 108 realizes an automotive battery, battery module, or battery pack. Battery 108 may have a state of charge 128, which depends on the amount of energy stored in the battery. The state of charge 128 typically affects the periodic rate at which the first ECU 100 sends check command messages to the IoT ecosystem 92. Waiting time standards can also affect the periodic rate at which the first ECU 100 sends check command messages to the IoT ecosystem 92.

[0137] The IoT protocol-enabled circuitry 110 implements a continuous response circuit, operable to listen for wake-up signals / initial messages, providing bidirectional communication with the IoT ecosystem 92 and providing bidirectional cellular communication 126. Wake-up signals can be received by the IoT protocol-enabled circuitry 110 from the IoT ecosystem 92 via vehicle transceiver 112, from the Internet 94 via wireless transceiver 114, and / or via a cellular network via cellular transceiver 106. The IoT protocol-enabled circuitry 110 is operable to communicate with the IoT ecosystem 92 using a given IoT protocol via vehicle transmitter 104 and vehicle receiver 112. The IoT protocol-enabled circuitry 110 can also host an IoT hub 116.

[0138] Vehicle transceiver 112 implements low-power wake-up of the transceiver. Vehicle transceiver 112 is operable to receive communication from IoT ecosystem 92 using IoT protocols (such as the Matter protocol). The received communication can be provided in the first ECU 100, and specifically, to the circuitry 110 that supports the IoT protocol.

[0139] Wireless transceiver 114 implements a radio frequency transceiver. Wireless transceiver 114 is operable to exchange information between vehicle 90 and Internet 94. This information can be transmitted using a wireless Internet protocol.

[0140] The IoT hub 116, which acts as a Matter hub, can be defined in Matter.

[0141] Modules (or circuits) 120 that do not support IoT protocols implement various circuits commonly found in vehicles 90. For example, circuits 120 that do not support IoT protocols may include vehicle control module circuits, infotainment circuits, etc. Other non-IoT protocol circuits can be implemented to meet the design standards of specific applications. Circuits 120 that do not support IoT protocols are not designed to communicate via a given IoT protocol.

[0142] refer to Figure 2This diagram illustrates a schematic functional flowchart of a first example operation of a system 70 according to one or more exemplary embodiments. System 70 may include a smart device 82 operated by a user 80, a first device 84, an IoT ecosystem 92, and a vehicle 90. The IoT ecosystem 92 typically includes an IoT controller 130 and multiple nodes 132a-132c supporting IoT protocols. As illustrated, the operation may include steps 140 to 150. The sequence of steps is shown as a representative example. Other step sequences may be implemented to meet the standards of a particular application.

[0143] Smart device 82 is implemented as a handheld device. In various embodiments, smart device 82 may be a smartphone, laptop computer, notebook computer, tablet computer, or the like. Smart device 82 may be implemented via a cellular network (e.g., Figure 1 Cellular networks (96) and / or the Internet (94) Figure 1 The smart device 82 exchanges information with the first device 84. The smart device 82 can receive input from the user 80 and convert that input into command and control messages 86. For example, the command and control message 86 could be an engine start message. Another command and control message 86 could be a climate control setting message.

[0144] In various embodiments, the first device 84 implements a cloud server computer or multiple server computers, which may be implemented on a cloud platform or in a commercial setting. The first device 84 can communicate with the smart device 82 and the IoT controller 130. Communication with the IoT controller 130 may follow a first protocol. The first protocol may be a wired and / or wireless protocol. For example, the first protocol may be the Wi-Fi protocol. In other embodiments, the first device 84 may be the smart device 82. Therefore, the smart device 82 can communicate directly with the IoT controller 130, bypassing the cloud server computer (if present).

[0145] IoT controller 130 implements a Wi-Fi-enabled access point, using Wi-Fi technology to communicate with one or more IoT devices within the IoT ecosystem. The application / service layer of IoT controller 130 uses Matter or another IoT protocol. IoT controller 130 can be connected directly or indirectly to an internet gateway. IoT controller 130 and the internet gateway can be located in the same place. IoT controller 130 is operable to exchange data with a cloud server computer (first device 84) via a first protocol 134. Data can also be exchanged between IoT controller 130 and IoT protocol-enabled nodes 132a-132c via a given IoT protocol 136. In various embodiments, the first protocol 134 differs from the given IoT protocol 136. In other embodiments, the first protocol 134 may implement the given IoT protocol 136.

[0146] Each node 132a-132c that supports the IoT protocol implements an addressable entity that supports the IoT protocol stack. The nodes 132a-132c that support the IoT protocol can communicate with each other and with the IoT controller 130 via a given IoT protocol and / or Matter protocol.

[0147] In step 140, user 80 can trigger the message via a command and control application executed on smart device 82. In step 142, smart device 82 can transmit message 86 to first device 84. First device 84 can exchange data with IoT controller 130 to determine whether vehicle 90 has registered with IoT controller 130. Registration can be a prerequisite for delivering message 86. If registered, first device 84 transmits message 86 to IoT controller 130 in step 144. If not registered, first device 84 can provide a message to user 80 to prompt user 80 to take action to register vehicle 90 at that time or later. If registration is not completed, command messages from first device 84 will not reach vehicle 90 via Matter with the assistance of IoT controller 130. Based on this determination, the message can be delivered to vehicle 90 via an alternative route (such as SMS).

[0148] In step 146, the IoT controller 130 sends a message to the vehicle 90 according to a given IoT protocol. The IoT protocol-enabled circuitry 110 in the vehicle 90 can receive message 86. If a circuitry 120 in the vehicle that does not support the IoT protocol loses power and message 86 is a wake-up signal, then in step 146, the IoT protocol-enabled circuitry 110 wakes up one or more IoT protocol-unsupporting circuitries 120 and sends message 86. If one or more IoT protocol-unsupporting circuitries 120 to which the action requested in message 86 is intended are already awake, an action request signal is sent from the IoT protocol-enabled circuitry 110. Subsequently, the action(s) requested in message 86 are executed by one or more modules whose actions are adapted to complete the command included in message 86.

[0149] Once the message execution is complete, vehicle 90 can, in step 150, send an ACK message 138 directly to first device 84 (via a Wi-Fi or cellular link connected to the Internet) or respond back to IoT controller 130. IoT controller 130 can notify first device 84 of the completion. First device 84 notifies smart device 82, and smart device 82 notifies user 80 that the message has been executed.

[0150] refer to Figure 3This illustrates a schematic functional flowchart of a second example operation of system 70a according to one or more exemplary embodiments. System 70a may be system 70( Figure 1 and 2 A variant of ), system 70a includes a smart device 82 operated by user 80, an IoT ecosystem 92, and a vehicle 90. In this embodiment, the smart device 82 is part of the same IoT ecosystem as the vehicle 90. System 70a may not utilize the first device 84 ( Figure 2 As illustrated, the operation may include steps 160 to 170. The sequence of steps is shown as a representative example. Other sequence of steps may be implemented to meet the standards of a particular application.

[0151] In step 160, user 80 can trigger message 86 via a command and control application executed on smart device 82. In step 162, smart device 82 can exchange data with IoT controller 130 to determine if vehicle 90 has registered with IoT controller 130. If registered, smart device 82 transmits message 86 to IoT controller 130 in step 164. If not registered, smart device 82 can utilize alternative routes to contact the vehicle, such as using cellular communication-based messaging (e.g., SMS).

[0152] In step 166, the IoT controller 130 sends a message to the vehicle 90 according to a given IoT protocol. A circuit 110 in the vehicle 90 that supports the IoT protocol can receive message 86. If a circuit 120 in the vehicle that does not support the IoT protocol loses power and message 86 is a wake-up signal, then in step 168, the IoT-enabled circuit 110 wakes up one or more circuits 120 that do not support the IoT protocol. If message 86 contains a command to be executed by one or more circuits 120 that do not support the IoT protocol but are in a sleep state, such a module is woken up by the IoT-enabled module 110. Once the command contained in message 86 is received by a circuit 120 that does not support the IoT protocol, the action requested in message 86 is executed. Registration of a circuit 120 that does not support the IoT protocol with a circuit 110 that supports the IoT protocol can be a precondition for sending messages from the IoT-enabled circuit 110 to a circuit 120 that does not support the IoT protocol.

[0153] After the command within the message is executed, in step 170, vehicle 90 can send an ACK message 138 back to IoT controller 130. IoT controller 130 can then notify smart device 82 of the completion. Smart device 82 then notifies user 80 that the message has been executed.

[0154] refer to Figure 4The diagram illustrates a schematic sequence diagram of a first example sequence 180 according to one or more exemplary embodiments. Sequence 180 utilizes a smart device 82, a first device 84 (e.g., a cloud server computer), an IoT controller 130, circuitry 110 supporting the IoT protocol, and two circuits 120 (e.g., 120a-120b) not supporting the IoT protocol. As illustrated, sequence 180 includes operations 182 to 190. Other sequences of operations may be implemented to meet the standards of a particular application.

[0155] In operation 182, smart device 82 transmits a message to first device 84. In operation 184, first device 84 sends the message to IoT controller 130, which has registered with first device 84 (e.g., via the Internet 94, initiated by smart device 82 or IoT controller 130 itself) as an entity to receive command and control messages intended for vehicle 90, which is part of IoT ecosystem 92. In operation 186, IoT controller 130 sends the message to vehicle 90 via a given IoT protocol. In operation 188, circuitry 110 supporting the IoT protocol processes the IoT message; determines whether the IoT message requests authorized operation; and identifies circuits 120a-120b that do not support the IoT protocol and are suitable for being woken up and contacted to execute the command contained in the IoT message. If the message is authorized, in operation 190, circuitry 110 supporting the IoT protocol wakes up the identified circuits 120a-120b that do not support the IoT protocol to execute the command contained in the message.

[0156] refer to Figure 5 This illustrates a schematic functional flowchart of a third example operation of system 70b according to one or more exemplary embodiments. System 70b may be system 70( Figure 1 and 2 ) and / or system 70a ( Figure 3 A variant of ), system 70b includes a smart device 82 operated by user 80, a first device 84, an IoT ecosystem 92, and a vehicle 90a. Vehicle 90a may be a variant of vehicle 90. Vehicle 90a may lack circuitry supporting IoT protocols. As illustrated, operation may include steps 200 to 214. The sequence of steps is shown as a representative example. Other step sequences may be implemented to meet the standards of a specific application.

[0157] In step 200, user 80 can trigger a message via a command and control application executed on smart device 82. In step 202, smart device 82 delivers message 86 to first device 84. First device 84 can exchange data with IoT controller 130 to determine whether vehicle 90a has registered with IoT ecosystem 92. If registered, first device 84 transmits message 86 to IoT controller 130 in step 204, where message 86 is buffered. If not registered, first device 84 can check vehicle 90a's registration with other IoT ecosystem members. In step 206, IoT controller 130 sends message 86 to a designated trusted node (e.g., 132a) that is part of ecosystem 92 and supports the IoT protocol.

[0158] In step 208, circuitry in vehicle 90 that does not support the IoT protocol (such as 120) periodically transmits check command messages 216 to the IoT ecosystem 92. Check command messages 216 may utilize non-IoT protocol compatible interfaces 218 and low-power wireless technologies such as Bluetooth or Bluetooth Low Energy (BLE), Zigbee, or other technologies. A designated trusted node 132a that supports the IoT protocol responds to the most recently received check command message 216 by checking message 86 in its local buffer 212. The designated trusted node 132a that supports the IoT protocol responds to vehicle 90 using non-IoT protocol 218. This response may indicate the presence of message 86 for vehicle 90a in buffer 212.

[0159] In step 210, circuit 120 that does not support the IoT protocol receives message 86 and, if necessary, wakes up one or more other circuits 120 that do not support the IoT protocol to execute the command contained in message 86. In step 214, vehicle 90a (i) contacts a designated trusted node 132a that supports the IoT protocol through interface 218 that does not support the IoT protocol, or (ii) contacts the first device 84 through Wi-Fi, cellular connection, or other non-IoT protocol compatible links to receive subsequent message 86 or acknowledge 138 the completion of execution of previous message 86.

[0160] refer to Figure 6 The diagram illustrates a schematic sequence of a second example sequence 240 according to one or more exemplary embodiments. Sequence 240 utilizes a smart device 82, a first device 84, an IoT controller 130, a designated trusted node 132a that supports the IoT protocol, and circuitry 120 that does not support the IoT protocol. As illustrated, sequence 240 includes operations 242 to 256. Other sequences of operations may be implemented to meet the standards of a particular application.

[0161] In operation 242, smart device 82 transmits message 86 to first device 84. In operation 244, first device 84 sends message 86 to IoT controller 130, which has been registered directly with first device 84 or by smart device 82, to identify IoT controller 130 to receive command and control messages destined for vehicle 90a when vehicle 90a is in an IoT network in which controller 130 is a part. In operation 246, IoT controller 130 concatenates (or sends) the message to a designated trusted node 132a that supports the given IoT protocol. In operation 248, the designated trusted node 132a processes the message; determines whether the request for the message is a permitted operation, and if permitted, buffers the message.

[0162] In operation 250, vehicle 90a transmits a check command message to a designated trusted node 132a that supports the IoT protocol. If the message is authorized, in step 252, the designated trusted node 132a responds to the check command message with a buffered message. In operation 254, one or more appropriate circuits 120 that do not support the IoT protocol are awakened, provided with the message, processed, and execute the command included in the message. Once message processing and command execution are complete, in operation 256, vehicle 90a sends an acknowledgment signal back to smart device 82 via the designated trusted node 132a, the IoT controller 130, and the first device 84.

[0163] Various embodiments of the system and / or method typically use IoT protocols to provide command and control (e.g., messaging) transmissions to IoT protocol-enabled modules, which in turn wake up modules that do not support the IoT protocol. Circuitry in the vehicle that supports the IoT protocol provides filtering and / or determines whether a message is among the messages allowed on an IoT protocol-compatible link. The message may be accepted if it passes the filter and rejected if it does not.

[0164] Circuits supporting IoT protocols include low-power wake-up transceivers (radios) for receiving wake-up signals / initial messages from the IoT ecosystem. Circuits / vehicles supporting IoT protocols register with the IoT controller before receiving messages.

[0165] When the message processing is complete, the vehicle can send a response signal directly to the cloud service using another interface (such as Wi-Fi with a cellular or internet connection), or send a response signal by responding to the IoT controller using a given IoT protocol.

[0166] Circuitry within a vehicle that supports IoT protocols can host IoT hubs to allow the reception of messages transmitted over various IoT-compliant technologies. For example, a Matter hub module might be able to send or receive messages from other Matter-enabled devices via Thread, Wi-Fi, Zigbee, etc. When the distance between the IoT controller and the vehicle is too long, or when significant path loss occurs due to reflectors or obstacles, multi-hop links can be configured between the IoT controller and the vehicle. Multi-hop links establish optimal paths between IoT controllers and designated IoT-enabled nodes within the IoT ecosystem to minimize message latency.

[0167] When a message is triggered from a user using a smart device, the smart device can contact the IoT controller to identify whether the vehicle is in an IoT network, and if so, direct one or more messages to the IoT controller instead of sending the message (e.g., via the Internet) to the first device, in order to reduce the waiting time.

[0168] Embodiments of this disclosure generally provide a system having a first device, an IoT ecosystem, and a vehicle. The first device is operable to transmit a message to the IoT ecosystem via a first protocol. The message may contain one or more commands. The IoT ecosystem has an IoT controller and one or more nodes supporting the IoT protocol. The IoT controller is operable to receive messages from the first device in accordance with the first protocol. One of the following is operable to wirelessly transmit messages to the vehicle in accordance with a given IoT protocol: (i) the IoT controller and (ii) one or more nodes supporting the IoT protocol. The given IoT protocol differs from the first protocol.

[0169] The vehicle may have circuitry supporting an IoT protocol and one or more additional circuits. The IoT protocol-supporting circuitry is operable to receive messages from the Internet of Things (IoT) ecosystem according to a given IoT protocol, wake up the one or more additional circuits in response to receiving the messages, and transmit the messages to the one or more additional circuits. The one or more additional circuits are operable to process the messages. The one or more additional circuits are circuitry that does not support the IoT protocol. In response to the completion of message processing, the vehicle is operable to transmit an acknowledgment signal to an external location.

[0170] In various embodiments, the electronic circuits described herein typically include at least one microcontroller and / or at least one microprocessor. The at least one microcontroller may include one or more processors, each of which may be embodied as a separate processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a dedicated electronic control unit. The at least one microcontroller may be any kind of electronic processor (implemented in hardware, software executing on hardware, or a combination of both). The at least one microcontroller may also include tangible, non-transitory memory (e.g., read-only memory in the form of optical, magnetic, and / or flash memory). For example, at least one microcontroller may include an appropriate number of random access memories, read-only memories, flash memory, and other types of electrically erasable programmable read-only memories, as well as accompanying hardware in the form of a high-speed clock or timer, analog-to-digital and digital-to-analog circuitry, input / output circuitry and devices, and appropriate signal conditioning and buffering circuitry. The term "module" as used herein can refer to hardware, software executing on hardware, or a combination of both. Various modules may or may not be located in the same location. In various embodiments, the in-vehicle module (i.e., ECU) may include one or more microprocessors that may use external memory (e.g., random access memory, read-only memory, flash memory and other types of electrically erasable programmable read-only memory) and external I / O devices (e.g., analog-to-digital, digital-to-analog, appropriate signal conditioning and buffering circuitry, etc.).

[0171] Numerical values ​​of parameters (e.g., values ​​of quantities or conditions) in this specification, including the appended claims, should be understood to be modified in each case by the term "about," regardless of whether "about" actually appears before the numerical value. "About" indicates that the numerical value allows for some slight imprecision (approximately close to the exact value; about or reasonably close to the value; approximate). If the imprecision provided by "about" is not understood in the ordinary sense in the art, then "about" as used herein at least indicates the variation that might arise from ordinary methods of measuring and using such a parameter. Furthermore, the disclosure of ranges includes values ​​throughout the range and disclosures of further subdivided ranges. Each value within a range and the endpoints of the range are disclosed herein as separate embodiments.

[0172] While the best mode of carrying out this disclosure has been described in detail, those skilled in the art will recognize various alternative designs and embodiments for carrying out this disclosure within the scope of the appended claims.

Claims

1. A system comprising: A first device, operable for transmitting messages via a first protocol; An Internet of Things (IoT) ecosystem consists of an IoT controller and one or more nodes that support IoT protocols, wherein: The IoT controller is operable to receive the message from the first device according to the first protocol; and One of the following is operable to wirelessly transmit the message according to a given Internet of Things (IoT) protocol: (i) the IoT controller and (ii) the one or more nodes supporting the IoT protocol; and The given IoT protocol is different from the first protocol; The vehicle has circuitry and one or more modules that support Internet of Things (IoT) protocols, wherein: The circuit supporting the Internet of Things protocol is operable for: Receive the message from the IoT ecosystem in accordance with the given IoT protocol; In response to receiving the message, wake up the one or more modules; and The message is sent to one or more modules; The one or more modules are operable to process the message; One or more modules do not support IoT protocols; and In response to the completion of message processing, the vehicle is operable to transmit a response signal to the outside of the vehicle.

2. The system according to claim 1, wherein the circuit supporting the Internet of Things protocol is further operable to: Filter the message among multiple permissible messages of the given Internet of Things protocol; Accept the message when passing through the filter; and The message is rejected if it fails the filter.

3. The system according to claim 2, wherein: The circuitry supporting the Internet of Things (IoT) protocol includes a vehicle transceiver operable to receive the message from the IoT ecosystem in accordance with the given IoT protocol. When in standby mode, the vehicle transceiver is a low-power transceiver; as well as The circuitry supporting the Internet of Things protocol is operable to wake up the one or more modules in further response to the receipt of the message.

4. The system according to claim 1, wherein: The IoT ecosystem is also operable to register the vehicle with the IoT controller before transmitting the message to the vehicle; and The vehicle was registered as an Internet of Things (IoT) device.

5. The system according to claim 1, wherein The vehicle also includes a vehicle transceiver; The vehicle transceiver is operable to directly wirelessly transmit the response signal to the first device using a second protocol; and The second protocol is different from the given IoT protocol.

6. The system of claim 1, wherein the vehicle further comprises: A vehicle transceiver operable to wirelessly transmit the response signal to the IoT controller in accordance with the given IoT protocol.

7. The system according to claim 1, wherein: The circuit-hosted IoT hub that supports IoT protocols; and The IoT hub is operable for communication via a variety of IoT-enabled technologies.

8. The system according to claim 1, wherein: The IoT ecosystem is also operable to establish multi-hop paths through one or more IoT nodes between the IoT controller and the vehicle.

9. The system according to claim 1, further comprising: A smart device, operable to transmit the message to the first device, wherein: The first device is a server computer operable to receive the message from the smart device; and The server computer is operable to wirelessly transmit the message to the IoT controller via the first protocol.

10. The system according to claim 1, further comprising: A smart device operable to transmit the message directly to the IoT controller via the given IoT protocol, wherein: The first device is a server computer; and The messages from the smart device to the IoT controller bypass the server computer.

Images