Vehicle machine awakening method, device and equipment

Abstract

The invention relates to the technical field of Internet of Vehicles, in particular to an in-vehicle machine awakening method, device and equipment. The method comprises the following steps: monitoring network state information of a first Internet of Things card and a second Internet of Things card at a vehicle terminal in real time; when a vehicle machine wakeup instruction is received, determining a target Internet of Things card from the first Internet of Things card and the second Internet of Things card according to the network state information; and waking up the vehicle machine based on the target Internet of Things card, and determining a wakeup result. In the embodiment of the invention, the card with the better network state in the two Internet of Things cards is dynamically selected to execute awakening through a dual-card collaborative awakening mechanism in combination with a signal priority and redundant backup strategy, and the other card is automatically switched to perform retry after the awakening fails. The wake-up success rate is improved, the problem of wake-up failure caused by poor single-card signal in the prior art is solved, and the core service of the Internet of Vehicles is ensured to stably fall to the ground.

Description

Technical Field

[0001] This application relates to the field of vehicle networking technology, and in particular to a method, device and equipment for waking up a vehicle's infotainment system. Background Technology

[0002] With the widespread adoption of vehicle-to-everything (V2X) technology, remote vehicle wake-up has become a core function of intelligent connected vehicles, and its reliability directly determines the effectiveness of key services such as remote control, vehicle diagnostics, and location tracking.

[0003] Vehicle-mounted infotainment system wake-up primarily relies on SMS commands. However, different carriers support different SMS formats, with the two main ones being user-defined SMS (Universal Character Set, USC) and international standard SMS (International Organization for Standardization, ISO). To avoid wake-up failures caused by single-carrier network coverage blind spots and signal attenuation, automakers generally adopt multi-carrier IoT SIM card deployment solutions, using dual-SIM redundancy to improve the success rate of vehicle-mounted infotainment system wake-up.

[0004] Existing automotive IoT card management MNO platforms have significant technical defects when adapting to dual-carrier dual-SIM wake-up scenarios, such as a lack of dual-carrier dual-SIM collaborative wake-up capabilities and incompatibility with SMS formats. Summary of the Invention

[0005] This invention provides a vehicle-mounted system wake-up method, apparatus, and device to solve the problem of lack of collaborative wake-up capability in existing dual-operator dual-SIM systems.

[0006] In a first aspect, embodiments of the present invention provide a method for waking up a vehicle infotainment system, the method comprising: Real-time monitoring of the network status information of the first and second IoT cards on the vehicle's infotainment system; When a vehicle-mounted system wake-up command is received, the target IoT card is determined from the first IoT card and the second IoT card based on the network status information. The vehicle system is woken up based on the target IoT card, and the wake-up result is determined.

[0007] Optionally, the real-time monitoring of the network status information of the first IoT card and the second IoT card on the vehicle terminal includes: At each preset first time interval, the network status information of the first IoT card and the network status information of the second IoT card are obtained respectively. The network status information includes signal strength, SMS delivery rate, and card activation status.

[0008] Optionally, determining the target IoT card from the first IoT card and the second IoT card based on the network status information includes: IoT cards with signal strength greater than a signal strength threshold and SMS delivery rate greater than an SMS delivery rate threshold are identified as the target IoT cards. Specifically, when the network status information of both the first IoT card and the second IoT card fails to reach the signal strength threshold and the SMS delivery rate threshold, the IoT card with the higher signal strength is identified as the target IoT card.

[0009] Optionally, before waking up the vehicle system based on the target IoT card, the method includes: The format type of the wake-up SMS is determined based on the operator of the target IoT card. The format type of the wake-up SMS includes USC format wake-up SMS and ISO format wake-up SMS. The system calls a preset format engine to generate a wake-up SMS message of the corresponding format type. The step of waking up the vehicle system based on the target IoT card includes: The wake-up SMS message is sent to the vehicle's infotainment system via the SMS gateway interface corresponding to the operator of the target IoT card to wake up the system.

[0010] Optionally, the step of calling a preset format engine to generate a wake-up SMS message of the corresponding format type includes: When the wake-up SMS is in USC format, the vehicle's unique identifier, wake-up type, and timestamp are encapsulated using a user-defined protocol. When the wake-up SMS is in ISO format, the wake-up code containing the CANID mapping and the ISO check bit are encapsulated using the ISO standard protocol. After the wake-up SMS is generated, the wake-up command is validated for legality.

[0011] Optionally, determining the wake-up result includes: Upon receiving a confirmation SMS from the vehicle's infotainment system within the first instance, the system is confirmed to have successfully woken up. If a confirmation SMS is not received from the vehicle system within the first time, or if a failure SMS is received from the vehicle system, the wake-up process is deemed to have failed. After confirming a successful wake-up, the success result is recorded and a notification message is pushed to the client. If the wake-up fails, switch to another IoT card and try to wake up the vehicle system again. If it still fails, obtain the reason for the failure and push a prompt message to the client.

[0012] Secondly, embodiments of the present invention provide a vehicle-mounted system wake-up device, the device comprising: The dual-SIM status monitoring module monitors the network status information of the first and second IoT SIM cards on the vehicle's infotainment system in real time. The dual-SIM wake-up strategy decision module, when receiving a vehicle-mounted wake-up command, determines the target IoT card from the first IoT card and the second IoT card based on the network status information; The wake-up command execution module wakes up the vehicle system based on the target IoT card and determines the wake-up result.

[0013] Optionally, the device further includes: a dual-format SMS adaptation module; The dual-format SMS adaptation module is used to determine the format type of the wake-up SMS according to the operator of the target IoT card. The format types of the wake-up SMS include USC format wake-up SMS and ISO format wake-up SMS. The system calls a preset format engine to generate a wake-up SMS message of the corresponding format type.

[0014] Thirdly, embodiments of the present invention provide an electronic device, comprising: At least one processor; and At least one memory communicatively connected to the processor, wherein: The memory stores program instructions that can be executed by the processor, which can invoke the program instructions to perform the method as described in any of the first aspects.

[0015] Fourthly, embodiments of the present invention provide a storage medium including a stored program, wherein, when the program is executed, it controls the device where the storage medium is located to perform the method described in any of the first aspects.

[0016] In this embodiment of the invention, a dual-SIM collaborative wake-up mechanism, combining signal priority and redundancy backup strategies, dynamically selects the IoT SIM card with the better network status to perform wake-up, and automatically switches to the other card for retry if the wake-up fails. This improves the wake-up success rate, solves the problem of wake-up failure caused by poor signal from a single SIM card in existing technologies, and ensures the stable deployment of core vehicle networking services.

[0017] In cases where one IoT SIM card fails, a fast retry mechanism switches to another IoT SIM card for a second wake-up attempt, reducing the number of manual operations required by the user. Simultaneously, a clear wake-up result is pushed to the user, allowing them to track the progress in real time. This reduces the average waiting time for wake-up operations by 60%, lowers the user complaint rate after wake-up failures, and significantly improves user satisfaction and brand reputation for automakers' connected car services.

[0018] Meanwhile, through a closed-loop feedback mechanism, the system records command sending, response status, and failure reasons (such as format errors or network timeouts) in real time. Operations personnel can quickly locate the root cause of problems through platform logs, reducing troubleshooting time to within 5 minutes. Furthermore, automated dual-card management and format adaptation reduce manual intervention, lowering the average annual operation and maintenance costs for a single automaker by more than 30%.

[0019] In this embodiment of the invention, by performing dual-format SMS adaptation, corresponding format instructions are automatically generated based on the card operator attributes, and a built-in verification mechanism ensures legality, resulting in a 100% accuracy rate for wake-up SMS format matching. This not only reduces the configuration time for a single vehicle to within 30 seconds, but also eliminates wake-up failures caused by format incompatibility, improving operational configuration efficiency by over 90%. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 The diagram shown is a structural schematic of a vehicle-mounted wake-up system provided in an embodiment of this application. Figure 2 The diagram shown is a structural schematic of a vehicle-mounted wake-up device provided in an embodiment of this application. Figure 3 The diagram shown is a flowchart of a vehicle system wake-up method provided in an embodiment of this application; Figure 4 The diagram shown is a structural schematic of an electronic device provided in an embodiment of this application. Detailed Implementation

[0022] To better understand the technical solution of this application, the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0023] It should be understood that the described embodiments are merely some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0024] like Figure 1 The diagram shown is a structural schematic of a vehicle-mounted system wake-up system provided in an embodiment of the present invention. (See also...) Figure 1 The vehicle wake-up system includes a client 110, a vehicle wake-up device 120, and a vehicle unit 130.

[0025] The client 110 is typically a user-owned terminal device with the corresponding vehicle manufacturer's application installed on it. When a user attempts to remotely wake up the vehicle's infotainment system, they issue a wake-up command on the client, which then sends the command to the vehicle's wake-up device, thereby waking up the vehicle.

[0026] The vehicle-mounted unit wake-up device 120 is deployed on a multi-carrier IoT card management platform (Mobile Network Operator, MNO). After receiving a wake-up command from the client, the vehicle-mounted unit wakes up the vehicle-mounted unit by sending a wake-up SMS message based on the activated carrier.

[0027] Generally, in order to avoid wake-up failures caused by blind spots in the network coverage of a single operator or signal attenuation, car manufacturers usually adopt a deployment solution of IoT cards from multiple operators.

[0028] The vehicle-mounted infotainment system 130 is deployed in vehicles that need to be woken up by the user. The system contains two IoT SIM cards, each from a different operator: a first IoT SIM card and a second IoT SIM card. This dual-SIM redundancy mechanism improves the system's wake-up success rate. The system wakes up by receiving SMS messages from the wake-up device via the IoT SIM cards.

[0029] like Figure 2 The diagram shown is a structural schematic of a vehicle-mounted system wake-up device provided in an embodiment of the present invention. (See also...) Figure 2 The vehicle-mounted wake-up device includes: a dual-SIM status monitoring module 121, a dual-SIM wake-up strategy decision module 122, and a wake-up command execution module 123.

[0030] The dual-SIM status monitoring module 121 is used to monitor the network status information of the first IoT SIM card and the second IoT SIM card on the vehicle terminal in real time.

[0031] Specifically, at preset first time intervals, the network status information of the first IoT card and the second IoT card are acquired respectively. The network status information includes signal strength, SMS delivery rate, and card activation status.

[0032] The dual-SIM wake-up strategy decision module 122 is used to determine the target IoT card based on the network status information of the first IoT card and the second IoT card when a vehicle wake-up command is received.

[0033] Specifically, IoT cards with signal strength greater than a strength threshold and SMS delivery rate greater than an SMS delivery rate threshold are identified as target IoT cards. Optionally, if the network status information of two IoT cards does not meet the requirements, the IoT card with the higher signal strength is identified as the target IoT card.

[0034] The wake-up command execution module 123 is used to wake up the vehicle system based on the target IoT card and determine the wake-up result.

[0035] Specifically, the operator of the identified target IoT SIM card sends a confirmation SMS to the vehicle's infotainment system. The system receives a confirmation SMS from the system within the first instance. If a confirmation SMS is received within the first instance, the vehicle wake-up is considered successful; if no confirmation SMS is received within the first instance, the vehicle wake-up is considered failed. If the wake-up is successful, the result is recorded, and a notification is pushed to the user's client. If the wake-up fails, another IoT SIM card is used to resend an SMS to the vehicle's infotainment system to attempt wake-up. If this also fails, the reason for the failure is obtained, and a notification is pushed to the client.

[0036] Optionally, in this embodiment of the invention, the vehicle wake-up device further includes a dual-format SMS adaptation module 124.

[0037] After the target IoT card is identified by the dual-SIM wake-up strategy decision module, the dual-format SMS adaptation module determines the format type of the wake-up SMS based on the target IoT card's operator, and calls the preset format engine to generate the corresponding format type of wake-up SMS for the wake-up command execution module to send the SMS.

[0038] The wake-up SMS formats include USC format wake-up SMS and ISO format wake-up SMS.

[0039] like Figure 3 The diagram shown is a flowchart of a vehicle infotainment system wake-up method provided by an embodiment of the present invention. This method is applied to applications such as... Figure 1 or Figure 2 The vehicle's infotainment system wake-up device is shown. See also... Figure 3 The specific steps of this method include: S301 monitors the network status information of the first and second IoT cards on the vehicle's infotainment system in real time.

[0040] Specifically, at preset intervals of a first preset time, the network status information of the first IoT SIM card and the network status information of the second IoT SIM card are acquired respectively. The first preset time interval could be, for example, 30 seconds.

[0041] The network status information includes the signal strength of the IoT card, SMS delivery rate (e.g., the success rate of the last 10 SMS messages), and card activation status (e.g., whether the IoT card is online or offline).

[0042] Optionally, when a poor network status is detected for an IoT card, such as an IoT card with a signal strength of less than -110dBm or an SMS delivery rate of less than 70%, the IoT card is marked as a low-priority card and an alert is issued.

[0043] In this embodiment of the invention, when obtaining the network status information of the first IoT card and the second IoT card for the first time, it is necessary to enter the basic information of the two IoT cards and configure the basic parameters of the wake-up command.

[0044] Basic information includes the IoT card's ICCID, carrier type, and supported SMS formats. Basic parameters for the wake-up command include the vehicle's VIN code and wake-up type encoding.

[0045] S302, when a vehicle-mounted system wake-up command is received, the target IoT card is determined from the first IoT card and the second IoT card based on the network status information.

[0046] Specifically, the vehicle-mounted system wake-up command can be issued by the user through a client, or it can be automatically triggered by the system based on a fixed time. Upon receiving the wake-up command, IoT cards with signal strength greater than a signal strength threshold and SMS delivery rate greater than an SMS delivery rate threshold are identified as target IoT cards.

[0047] For example, a signal strength threshold of -90dBm can be set, and an SMS delivery rate of 90% can be set. That is, IoT cards with a signal strength greater than -90dBm and an SMS delivery rate greater than 90% can be identified as target IoT cards.

[0048] If the network status information of both IoT cards meets the signal strength threshold and the SMS delivery rate threshold, or if the network status information of both IoT cards does not meet the signal strength threshold and the SMS delivery rate threshold, then the IoT card with the higher signal strength will be selected as the target IoT card.

[0049] Optionally, in this embodiment of the invention, for high-frequency wake-up scenarios, such as when 5 or more wake-ups are performed per hour, two IoT cards are used alternately for wake-up to avoid network congestion on the operator's network.

[0050] S303, wake up the vehicle system based on the target IoT card and determine the wake-up result.

[0051] Specifically, a wake-up SMS message is sent to the vehicle's infotainment system via the SMS gateway interface corresponding to the target IoT card's operator to wake up the system.

[0052] Wait for the vehicle's infotainment system to respond immediately after sending the wake-up SMS. Once a confirmation SMS containing a wake-up success indicator is received from the vehicle's infotainment system within the first instance, the wake-up is confirmed as successful, the success result is recorded, and a notification message is pushed to the client.

[0053] If no confirmation SMS is received from the vehicle's infotainment system within the first instance, or if a failure SMS containing a wake-up failure indicator is received, the wake-up process is confirmed to have failed, and another IoT SIM card is used to re-execute the wake-up. If it still fails, the reason for the failure is obtained, such as an incorrect SMS format or network problem, and a notification message is pushed to the client.

[0054] In this embodiment of the invention, a dual-SIM collaborative wake-up mechanism, combining signal priority and redundancy backup strategies, dynamically selects the IoT SIM card with the better network status to perform wake-up, and automatically switches to the other card for retry if the wake-up fails. This improves the wake-up success rate, solves the problem of wake-up failure caused by poor signal from a single SIM card in existing technologies, and ensures the stable deployment of core vehicle networking services.

[0055] In cases where one IoT SIM card fails, a fast retry mechanism switches to another IoT SIM card for a second wake-up attempt, reducing the number of manual operations required by the user. Simultaneously, a clear wake-up result is pushed to the user, allowing them to track the progress in real time. This reduces the average waiting time for wake-up operations by 60%, lowers the user complaint rate after wake-up failures, and significantly improves user satisfaction and brand reputation for automakers' connected car services.

[0056] Meanwhile, through a closed-loop feedback mechanism, the system records command sending, response status, and failure reasons (such as format errors or network timeouts) in real time. Operations personnel can quickly locate the root cause of problems through platform logs, reducing troubleshooting time to within 5 minutes. Furthermore, automated dual-card management and format adaptation reduce manual intervention, lowering annual operating and maintenance costs for individual automakers by more than 30%.

[0057] Optionally, in this embodiment of the invention, after determining the target IoT card by executing S302, it is necessary to generate a wake-up SMS message of the corresponding format type.

[0058] Specifically, the format type of the wake-up SMS is determined based on the target IoT card's carrier. This includes USC format wake-up SMS and ISO format wake-up SMS. A preset format engine is then used to generate the wake-up SMS of the corresponding format type.

[0059] When the wake-up SMS message is in USC format, the vehicle's unique identifier, wake-up type, and timestamp are encapsulated using a user-defined protocol to generate the wake-up SMS message. In one specific embodiment, the VIN code, wake-up type "01", and timestamp are encapsulated into a USC format wake-up SMS message.

[0060] When the wake-up SMS is in ISO format, the wake-up code containing the CAN ID mapping and the ISO checksum are encapsulated using the ISO standard protocol to generate the wake-up SMS. In one specific embodiment, the wake-up code "0x18DB33F1" mapping the CAN ID and the checksum are encapsulated into an ISO format wake-up SMS.

[0061] After generating the wake-up SMS, the wake-up command is validated for validity, and the SMS is sent to the vehicle's infotainment system upon successful validation. Specifically, the field lengths of the USC format wake-up SMS and the checksums of the ISO format wake-up SMS are validated to prevent command loss due to format errors.

[0062] In this embodiment of the invention, by performing dual-format SMS adaptation, corresponding format instructions are automatically generated based on the card operator attributes, and a built-in verification mechanism ensures legality, resulting in a 100% accuracy rate for wake-up SMS format matching. This not only reduces the configuration time for a single vehicle to within 30 seconds, but also eliminates wake-up failures caused by format incompatibility, improving operational configuration efficiency by over 90%.

[0063] Figure 4 This is a schematic diagram illustrating the structure of one embodiment of the electronic device described in this specification. Specifically, the electronic device can be implemented as an MNO platform, that is, an electronic device equipped with the vehicle-mounted wake-up device provided in this embodiment of the invention, used to execute the vehicle-mounted wake-up method provided in this embodiment. Figure 4 As shown, the above-mentioned electronic device may include at least one processor; and at least one memory communicatively connected to the processing unit, wherein: the memory stores program instructions that can be executed by the processing unit, and the processor can execute the vehicle wake-up method provided in this embodiment by calling the program instructions.

[0064] The aforementioned electronic device can be a device capable of intelligent dialogue with the user, such as a cloud server. This specification does not limit the specific form of the electronic device in the embodiments. It is understood that the electronic device here refers to the machine mentioned in the method embodiments.

[0065] Figure 4 A block diagram of an exemplary electronic device suitable for implementing embodiments of this specification is shown. Figure 4 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments described in this specification.

[0066] like Figure 4As shown, the electronic device is represented in the form of a general-purpose computing device. The components of the electronic device may include, but are not limited to: one or more processors 410, communication interface 420, memory 430, and communication bus 440 connecting different system components (including memory 430, communication interface 420 and processor 410).

[0067] Communication bus 440 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, Industry Standard Architecture (ISA) buses, Micro Channel Architecture (MAC) buses, Enhanced ISA buses, Video Electronics Standards Association (VESA) local buses, and Peripheral Component Interconnect (PCI) buses.

[0068] Electronic devices typically include a variety of computer-readable media. These media can be any available media that can be accessed by the electronic device, including volatile and non-volatile media, and removable and non-removable media.

[0069] Memory 430 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory. The electronic device may further include other removable / non-removable, volatile / non-volatile computer system storage media. Memory 430 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments described herein.

[0070] A program / utility having a set (at least one) of program modules may be stored in memory 430. Such program modules include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. The program modules typically perform the functions and / or methods described in the embodiments of this specification.

[0071] The processor 410 executes various functional applications and data processing by running programs stored in the memory 430, such as implementing the vehicle wake-up method provided in the embodiments shown in this specification.

[0072] This specification provides a non-transitory computer-readable storage medium that stores computer instructions that cause the computer to execute the vehicle system wake-up method provided in the embodiments shown in this specification.

[0073] The aforementioned non-transitory computer-readable storage medium may be any combination of one or more computer-readable media. A computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium may be any tangible medium containing or storing a program that may be used by or in connection with an instruction execution system, apparatus, or device.

[0074] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0075] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0076] Computer program code for performing the operations described herein can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0077] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0078] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this specification, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0079] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this specification includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which the embodiments of this specification pertain.

[0080] Depending on the context, the word "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection." Similarly, depending on the context, the phrase "if determination" or "if detection (of the stated condition or event)" can be interpreted as "when determination," "in response to determination," "when detection (of the stated condition or event)," or "in response to detection (of the stated condition or event)."

[0081] It should be noted that the terminals involved in the embodiments of this specification may include, but are not limited to, personal computers (PCs), personal digital assistants (PDAs), wireless handheld devices, tablet computers, mobile phones, MP3 players, MP4 players, etc.

[0082] In the embodiments provided in this specification, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0083] Furthermore, the functional units in the various embodiments of this specification can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units.

[0084] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of this specification.

[0085] The above description is merely a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of protection of this specification.

Claims

1. A method for waking up a vehicle's infotainment system, characterized in that, The method includes: Real-time monitoring of the network status information of the first and second IoT cards on the vehicle's infotainment system; When a vehicle-mounted system wake-up command is received, the target IoT card is determined from the first IoT card and the second IoT card based on the network status information. The vehicle system is woken up based on the target IoT card, and the wake-up result is determined.

2. The method according to claim 1, characterized in that, The real-time monitoring of network status information of the first and second IoT cards on the vehicle's infotainment system includes: At each preset first time interval, the network status information of the first IoT card and the network status information of the second IoT card are obtained respectively. The network status information includes signal strength, SMS delivery rate, and card activation status.

3. The method according to claim 1, characterized in that, The step of determining the target IoT card from the first IoT card and the second IoT card based on the network status information includes: IoT cards with signal strength greater than a signal strength threshold and SMS delivery rate greater than an SMS delivery rate threshold are identified as the target IoT cards. Specifically, when the network status information of both the first IoT card and the second IoT card fails to reach the signal strength threshold and the SMS delivery rate threshold, the IoT card with the higher signal strength is identified as the target IoT card.

4. The method according to claim 1, characterized in that, Before waking up the vehicle system based on the target IoT card, the method includes: The format type of the wake-up SMS is determined based on the operator of the target IoT card. The format type of the wake-up SMS includes USC format wake-up SMS and ISO format wake-up SMS. The system calls a preset format engine to generate a wake-up SMS message of the corresponding format type. The step of waking up the vehicle system based on the target IoT card includes: The wake-up SMS message is sent to the vehicle's infotainment system via the SMS gateway interface corresponding to the operator of the target IoT card to wake up the system.

5. The method according to claim 4, characterized in that, The step of calling a preset format engine to generate a wake-up SMS message of the corresponding format type includes: When the wake-up SMS is in USC format, the vehicle's unique identifier, wake-up type, and timestamp are encapsulated using a user-defined protocol. When the wake-up SMS is in ISO format, the wake-up code containing the CAN ID mapping and the ISO check bit are encapsulated using the ISO standard protocol. After the wake-up SMS is generated, the wake-up command is validated for legality.

6. The method according to claim 1, characterized in that, The determination of the wake-up result includes: Upon receiving a confirmation SMS from the vehicle's infotainment system within the first instance, the system is confirmed to have successfully woken up. If a confirmation SMS is not received from the vehicle system within the first time, or if a failure SMS is received from the vehicle system, the wake-up process is deemed to have failed. After confirming a successful wake-up, the success result is recorded and a notification message is pushed to the client. If the wake-up fails, switch to another IoT card and try to wake up the vehicle system again. If it still fails, obtain the reason for the failure and push a prompt message to the client.

7. A vehicle-mounted system wake-up device, characterized in that, The device includes: The dual-SIM status monitoring module monitors the network status information of the first and second IoT SIM cards on the vehicle's infotainment system in real time. The dual-SIM wake-up strategy decision module, when receiving a vehicle-mounted wake-up command, determines the target IoT card from the first IoT card and the second IoT card based on the network status information; The wake-up command execution module wakes up the vehicle system based on the target IoT card and determines the wake-up result.

8. The apparatus according to claim 7, characterized in that, The device further includes: a dual-format SMS adaptation module; The dual-format SMS adaptation module is used to determine the format type of the wake-up SMS according to the operator of the target IoT card. The format types of the wake-up SMS include USC format wake-up SMS and ISO format wake-up SMS. The preset format engine is invoked to generate a wake-up SMS message of the corresponding format type.

9. An electronic device, characterized in that, include: At least one processor; as well as At least one memory communicatively connected to the processor, wherein: The memory stores program instructions that can be executed by the processor, and the processor can execute the method as described in any one of claims 1 to 6 by calling the program instructions.

10. A storage medium, characterized in that, The storage medium includes a stored program, wherein, when the program is executed, it controls the device on which the storage medium is located to perform the method according to any one of claims 1 to 6.

Images