Call management method and vehicle
By working together with state machines and state objects, call conflicts are handled based on the priority of call events and node judgments, thus solving the problem of chaotic call states in T-BOX and achieving orderly and reliable call processing.
Patent Information
- Application Number
- CN202511606592.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-05
- Publication Date
- 2026-03-10
AI Technical Summary
When T-BOX experiences call conflicts, the call status becomes chaotic, making normal calls impossible. Existing technology cannot handle call conflicts in a timely and effective manner, affecting user experience and life safety.
After receiving a pending call event, the state machine sends it to the state object for priority determination. If the priority of the pending call event is higher than that of the currently processing call event, the currently processing call event is terminated and a new state object is created to handle the pending call event. If the priorities are equal or lower, the pending call event is either responded to or ignored based on the call node, thus achieving orderly processing of calls.
By using state objects as arbitrators to handle call conflicts, call state chaos can be avoided, the order and reliability of calls can be improved, and the normal operation of calls can be ensured.
Smart Images
Figure CN121645158A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of vehicle communication technology, and in particular to a call management method and a vehicle. Background Technology
[0002] The vehicle-mounted telematics box (T-BOX, responsible for data communication and remote control between the vehicle and the outside world) integrates a variety of call types, such as emergency calls, internet calls, and satellite calls. If there is a call conflict, it may cause call status confusion and affect the normal calling of the T-BOX. Summary of the Invention
[0003] In view of this, the purpose of this application is to propose a call management method and vehicle to solve the problem of chaotic call status and inability to make calls normally when there is a call conflict in the T-BOX.
[0004] To achieve the above objectives, this application provides a call management method applied to a T-BOX. The T-BOX includes a state machine and state objects, wherein the link pointer of the state machine points to the state object. The method includes: After receiving a pending call event, the state machine sends the pending call event to the state object pointed to by the link pointer, so that the state object can determine the priority between the pending call event and the call event in process, wherein the call event in process is the call event that the state object is currently processing; If the state object determines that the priority of the pending call event is higher than the priority of the call event in process, then it terminates the call event in process and sends a state object switching instruction to the state machine so that the state machine creates a new state object. After the state machine creates a new state object, it switches the link pointer to point to the new state object so that the new state object can handle the pending call event.
[0005] Furthermore, the method also includes: If the state object determines that the priority of the pending call event is lower than the priority of the processing call event, it continues to execute the processing call event and sends an ignore instruction to the state machine so that the state machine ignores the pending call event.
[0006] Furthermore, the method also includes: If the state object determines that the priority of the pending call event is equal to the priority of the processing call event, it determines the first call node corresponding to the pending call event and the second call node corresponding to the processing call event, and determines whether to respond to the pending call event based on the first call node and the second call node.
[0007] Furthermore, determining whether to respond to the pending call event based on the first and second calling nodes includes: If the state object determines that the first calling node is no later than the second calling node in the call process, it continues to execute the call event in process and sends an ignore instruction to the state machine so that the state machine ignores the call event to be processed. If the state object determines that the first calling node is later than the second calling node in the call process, it responds to the pending call event to update the second calling node to the first calling node. The call process is the process by which the server responds to the pending call event, and the call process includes multiple call nodes set in a sequential order.
[0008] Furthermore, the method also includes: If the state object determines that the priority of the pending call event is higher than the priority of the call event being processed, then the state object is destroyed.
[0009] Furthermore, the termination of the call event during processing includes: Send a hang-up command to the server to cause the server to terminate the call event in process.
[0010] Furthermore, the method also includes: If the state object determines that the priority of the pending call event is higher than the priority of the call event being processed, then the state object releases the occupied call resources. If the state machine completes the creation of the new state object, then the new state object occupies the call resource.
[0011] Furthermore, after switching the link pointer to point to the new state object, the process includes: The state machine sends the pending call event to the new state object; The new state object processes the pending call events.
[0012] Furthermore, the new state object processes the pending call event, including: The new state object sends the pending call event to the server, so that the server responds to the pending call event.
[0013] Based on the same inventive concept, this application also provides a vehicle including a T-BOX for performing the methods described above.
[0014] As can be seen from the above, this application provides a call management method and vehicle, wherein the method includes: when a state machine receives a call event to be processed, it sends the call event to be processed to a state object pointed to by its link pointer, so that the state object determines the priority of the call event being processed and the call event to be processed, and when the priority of the call event to be processed is higher than the priority of the call event being processed, it ends the call event being processed and sends a state object switching instruction; when the state machine receives the state object switching instruction sent by the state object, it creates a new state object and switches the link pointer to connect to the new state object, so as to send the call event to be processed to the new state object, and the new state object is used to process the call event to be processed. This application sends pending call events to a state object for processing. The call event being processed by the state object is called a "processing call event." By processing pending call events through the state object, the state object acts as the sole arbitrator to handle call conflicts between pending and processing call events. This allows the state object to independently handle various call conflicts, avoiding the problem of call status confusion caused by the mismatch between preset call conflicts and actual call conflicts. Furthermore, when it is determined that the priority of the pending call event is higher than that of the processing call event, a new state object is created to handle the pending call event, realizing the situation where one state object handles one call. This avoids the problem of one state object handling multiple calls, which can cause call status confusion and the inability to make calls normally, thus promoting the orderliness and effectiveness of calls. Attached Figure Description
[0015] To more clearly illustrate the technical solutions in this application or related technologies, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0016] Figure 1 This is a flowchart illustrating a call management method according to an embodiment of this application. Figure 1 ; Figure 2 This is a flowchart illustrating a call management method according to an embodiment of this application. Figure 2 ; Figure 3 This is a schematic diagram of the structure of a T-BOX according to an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation
[0017] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.
[0018] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this application should have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," and similar terms used in the embodiments of this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are only used to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.
[0019] Vehicles communicate with the outside world through the T-BOX, that is, they make calls through the T-BOX. With the rapid development of vehicles, the types of calls integrated into the T-BOX are increasing, such as emergency calls (eCall), internet-based calls (IbCall), satellite calls (Satellite Call), etc., and in the future, it will also expand to include various call types such as Meow Call and VIP Call. There are strict priority principles (such as eCall > IbCall > Satellite Call) and mutual exclusion (i.e., they cannot be executed simultaneously) between the various calls. Currently, for various call conflicts in T-BOX (e.g., when Ibcall is being executed, ecall is triggered; both calls require corresponding resources and send call requests to the server, thus causing a call conflict), a procedural linear approach is typically used. This approach encapsulates all possible call conflict scenarios into one or a few large functions to handle them. However, this approach can only handle pre-defined call conflicts. When a call conflict arises that is not pre-defined, it leads to problems such as state confusion, resource contention, and business logic errors. This makes it impossible to handle call conflicts in a timely and effective manner, seriously affecting user experience and safety. Furthermore, when adding call types, existing functions must be patched, increasing workload and increasing the risk of new logical errors that affect the normal operation of T-BOX.
[0020] Based on this, this application proposes a call management method and vehicle. When the state machine receives a call event to be processed, it sends it to the state object for judgment. When the state object sends a state object switching instruction, a new state object is created so that the new state object can handle the call event to be processed. This achieves clear handling of the call event to be processed, avoids call conflicts, and helps improve the call experience.
[0021] The embodiments of this application will be described in detail below with reference to the accompanying drawings.
[0022] In some embodiments, a call management method is applied to a T-BOX, wherein the T-BOX includes a state machine and state objects, and the link pointers of the state machine point to the state objects, such as... Figure 1 and Figure 2 As shown, the method includes: Step S101: After receiving a call event to be processed, the state machine sends the call event to be processed to the state object pointed to by the link pointer, so that the state object determines the priority of the call event to be processed and the call event in process, wherein the call event in process is the call event that the state object is currently processing. Specifically, the state machine is a vector structure that can receive and forward the pending call events, and manage the state objects through link pointers. The state objects are used to process the pending call events and represent the status of the call events being processed.
[0023] There is only one link pointer, and this link pointer can only point to one state object. When the link pointer points to a state object, only that state object can receive the pending call event. The state object is used to send a call request based on the pending call event to the server to complete the call. Only the state object can send a call request to the server. When the link pointer points to a state object, it can be in a state of processing a call event or in a state of not processing any call events.
[0024] The state machine is connected to the call event generation source, and is thus able to receive the call event to be processed. The call event generation source includes structures connected to the T-BOX that can generate call events, including but not limited to the ecall button, Ibcall button and server on the vehicle. During the execution of the call event, the server needs to provide feedback on the call node related to the ongoing call. Therefore, the server is also a type of call event generation source when executing the call event.
[0025] The pending call events include call types and call nodes. Call types include ecall, Ibcall, and Satellite Call, etc. The call nodes are the call nodes in the call process, including dialing, ringing, connecting, and hanging up, etc. The pending call events can be newly triggered or sent by a server that is currently executing a call task. When determining the priority of the processing call event and the pending call event, the state object determines the priority according to its embedded priority principles. The embedded priority principles of the state object include priority principles determined by call type and priority principles determined by call node. For example, the priority principle determined by call type is eCall > IbCall > Satellite Call, and the priority principle determined by call node is dialing < ringing < connecting < hanging up. When determining the priority of the processing call event and the pending call event, the priority of the processing call event and the pending call event is first determined according to the priority principle determined by call type. If the processing call event and the pending call event have the same call type, that is, the same priority, the priority is determined according to the call node. For example, if the pending call event is eCall and the call node is dialing, and the processing call event is eCall and the call node is ringing, then the priority of the pending call event is determined to be lower than that of the processing call event.
[0026] More specifically, the state machine receives the pending call event and sends it to the state object pointed to by the link pointer for processing. The state object determines the processing result for the pending call event based on its currently processed call event (i.e., the call event in progress) and the pending call event. The processing result includes ignoring, priority preemption, and acceptance. When the processing result is ignoring, it is determined that the priority of the pending call event is lower than the priority of the call event being processed by the state object (for example, if the pending call event is Ibcall and the call event being processed by the state object is ecall, and ecall has a higher priority than Ibcall, then the state object's processing result is ignoring). The state object sends an ignore instruction to the state machine so that the state machine ignores the pending call event. When the processing result is priority preemption, it is determined that the pending call event... If a call event has a higher priority (e.g., the pending call event is ecall, and the call event being processed by the state object is Ibcall, and ecall has a higher priority than Ibcall, then the state object's processing result is that the priority is preempted), the state object sends a state object switching instruction to the state machine, so that the state machine creates a new state object and switches the link pointer to connect with the new state object. The new state object processes the pending call event. When the processing result is reception (e.g., the call event being processed by the state object is ecall, and the pending call event is ecall sent by the server, which is used by the server to respond to the calling node of ecall, then the state object's processing result is to receive the pending call event), the state object sends a reception instruction to the state machine, so that the state machine determines that the pending event has been processed by the state object.
[0027] It should be noted that the state object has an embedded priority principle (for example, eCall > IbCall > Satellite Call). Therefore, the state object can automatically determine the priority of the pending call events and the call events in process. Furthermore, when the call type is increased, only the priority principle of the state object needs to be changed (for example, currently supported call types include eCall, IbCall, and Satellite Call, with the priority principle being eCall > IbCall > Satellite Call. If VIPcall is added, there is no need to change the connection status and operation method of the state machine, server, and state object; only the priority principle of the state object needs to be changed to achieve arbitration for the four call types). That is, when the state object receives a new priority principle, it overrides the existing priority principle to process the received pending call events according to the new priority principle. When the priority principle changes or the supported call types are increased, only the priority principle of the state object needs to be changed to achieve management of multiple call types, avoid call conflicts, greatly reduce workload, and not affect the call order.
[0028] For example, if the call event being processed by the state object is ecall, and its priority principle is eCall > IbCall > Satellite Call, then the state object will ignore the processing results of the received call event.
[0029] For another example, if the call event being processed by the state object is Ibcall, and its priority principle is eCall > IbCall > Satellite Call, then when the call event to be processed is ecall, the state object's processing result for the call event to be processed is that the priority is preempted, and a state object switching instruction is sent to the state machine; when the call event to be processed is Satellite Call, the state object's processing result for the call event to be processed is to ignore it.
[0030] For another example, if the call event being processed by the state object is IbCall, and its priority principle is eCall > IbCall > Satellite Call, then only when the call event to be processed is eCall will the state object's processing result for the call event to be processed be priority preemption, and a state object switching instruction be sent to the state machine. If a call type VIPcall is added, the priority principle becomes eCall > VIPcall > IbCall > Satellite Call. Then, when the call event to be processed is either eCall or VIPcall, the state object's processing result for the call event to be processed will be priority preemption, and a state object switching instruction be sent to the state machine. When adding call types, it is not necessary to preset multiple call conflict situations or make extensive modifications to the functions. Only by changing the priority principle can the problem of increased call conflict situations be avoided when call types are added.
[0031] In step S102, if the state object determines that the priority of the pending call event is higher than the priority of the call event in process, then the call event in process is terminated, and a state object switching instruction is sent to the state machine so that the state machine creates a new state object. Specifically, when the state object determines that the priority of the pending call event is higher than the priority of the processing call event, that is, when the priority is preempted, the processing call event needs to end, give way to the pending call event, and sends a state object switching instruction to the state machine, so that the state machine creates a new state object, which is used to process the pending call event.
[0032] It should be noted that the new state object, upon creation, inherently incorporates a priority principle and is in a state where no call events have been processed.
[0033] In step S103, after the state machine creates a new state object, it switches the link pointer to point to the new state object so that the new state object can process the pending call event.
[0034] Specifically, after creating a new state object, the state machine switches the link pointer to point to the new state object, sending the pending call event to the new state object so that the new state object can handle the event. Creating a new state object to handle the event avoids call confusion caused by the same state object handling multiple events. Furthermore, the state machine sends a resource release command to the state object, causing it to release its occupied audio, microphone, and other resources. Simultaneously, the state machine sends a resource acquisition command to the new state object, enabling it to acquire audio, microphone, and other resources to meet call needs.
[0035] It should be noted that when the state object sends the state object switching instruction to the state machine, it performs a cleanup step. The cleanup step includes ending the call event being processed (i.e. hanging up the current call), releasing the occupied resources, and self-destruction. The cleanup step can ensure a smooth switching process between different calls, realize atomic state transitions of calls, and prevent situations where the corresponding audio or microphone resources cannot be occupied when executing another call. The self-destruction of the state object can ensure that there is only one state object used to execute the current call, which can avoid the space occupied by too many state objects.
[0036] For example, if the call type corresponding to the pending call event is ecall and the call node is dialing, then the pending call event is a newly triggered ecall. The new state object sends the pending call event to the server, and the server executes the dialing of the ecall, thus completing the processing of the pending call event.
[0037] It should be noted that the new state object will only be created if the pending call event is a newly triggered call and has a higher priority than the call being processed by the state object. Therefore, after the new state object is created, it will trigger a call that matches the pending call event. The triggering of the call is achieved through the server, that is, the server is a relay station for the call service.
[0038] In this embodiment, when the state machine receives a pending call event, it sends the pending call event to the state object pointed to by its link pointer, so that the state object determines the priority of the processing call event and the pending call event. When the priority of the pending call event is higher than the priority of the processing call event, the processing call event ends and a state object switching instruction is sent. When the state machine receives the state object switching instruction sent by the state object, it creates a new state object and switches the link pointer to connect to the new state object, so that the pending call event is sent to the new state object. The new state object is used to process the pending call event. This application sends pending call events to a state object for processing. The call event being processed by the state object is called a "processing call event." By processing pending call events through the state object, the state object acts as the sole arbitrator to handle call conflicts between pending and processing call events. This allows the state object to independently handle various call conflicts, avoiding the problem of call status confusion caused by the mismatch between preset call conflicts and actual call conflicts. Furthermore, when it is determined that the priority of the pending call event is higher than that of the processing call event, a new state object is created to handle the pending call event, realizing the situation where one state object handles one call. This avoids the problem of one state object handling multiple calls, which can cause call status confusion and the inability to make calls normally, thus promoting the orderliness and effectiveness of calls.
[0039] In some embodiments, the method further includes: In step S201, if the state object determines that the priority of the pending call event is lower than the priority of the processing call event, it continues to execute the processing call event and sends an ignore instruction to the state machine so that the state machine ignores the pending call event.
[0040] Specifically, when the state object determines that the priority of the pending call event is lower than the priority of the processing call event, it indicates that the pending call event needs to give way to the processing call event. In order to avoid the pending call event affecting the normal progress of the processing call event, the pending call event is ignored, and an ignore instruction is sent to the state machine, so that the state machine ignores the pending call event.
[0041] In this embodiment, when the state object determines that the priority of the pending call event is lower than the priority of the processing call event, it ignores the pending call event and prioritizes the processing call event with higher priority. This can avoid call conflicts based on the priority principle, achieve orderly processing of the pending call events, avoid chaos, and improve call reliability.
[0042] In some embodiments, the method includes: Step S301: If the state object determines that the priority of the pending call event is equal to the priority of the processing call event, it determines the first call node corresponding to the pending call event and the second call node corresponding to the processing call event, and determines whether to respond to the pending call event based on the first call node and the second call node.
[0043] Specifically, when the state object determines that the priority of the pending call event is equal to the priority of the processing call event, it determines that the priority needs to be determined based on the calling nodes of the pending call event and the processing call event. Therefore, it confirms the first calling node corresponding to the pending call event and the second calling node corresponding to the processing call event, so as to determine the processing result of the pending call event, i.e., whether to respond to the pending call event, based on the first calling node and the second calling node.
[0044] It should be noted that when the priority of the pending call event and the processing call event is equal, it means that the two call events have the same call type. The pending call event may be a newly triggered call of this type, or it may be a call event fed back by the server in response to a change in the call node of the processing call event. Therefore, it is necessary to determine the call nodes of the two call events and determine the processing result of the pending call event by comparing the order of the call nodes of the two call events.
[0045] For example, the call event in the process is ecall, and the corresponding call node is ringing. The call event to be processed is ecall, and the corresponding call node is dialing. The two events have the same call type, that is, the same priority, but different call nodes. Moreover, the ringing order is later than the dialing order, indicating that the progress of the call event in the process is greater than the progress of the call event to be processed. The call event to be processed is newly triggered. The state object ignores the call event to be processed to avoid the newly triggered call from affecting the ongoing call and causing call chaos.
[0046] More specifically, the first calling node and the second calling node are compared to determine their order in the call flow. Based on the obtained order, the priority of the pending call event and the processing call event is determined, and then it is determined whether to receive the pending call event. If the pending call event is received, the second calling node of the processing call event is updated to the second calling node to realize the processing of the pending call event. If the pending call event is ignored, the second calling node of the processing call event is kept, that is, the second calling node is not updated to the first calling node.
[0047] In this embodiment, when the priority of the pending call event is determined to be the same as the priority of the processing call event, a first call node corresponding to the pending call event and a second call node corresponding to the processing call event are determined respectively. The first call node and the second call node are used to determine whether to receive the pending call event. If the pending call event is received, the second call node is updated to the first call node. If the pending call event is not received, it is ignored, and the processing of the pending call event is completed. The processing result of the pending call event is determined based on the call nodes of the pending call event and the processing call event, avoiding the situation where the call node of the processing call event cannot be updated in time. This achieves orderly processing of the pending call events, avoids chaos, and improves the reliability of the call.
[0048] In some embodiments, step S301: determining whether to respond to the pending call event based on the first calling node and the second calling node includes: Step S401: If the state object determines that the first calling node is no later than the second calling node in the call process, it continues to execute the call event in process and sends an ignore instruction to the state machine so that the state machine ignores the call event to be processed. Specifically, the state object has a call flow, which includes multiple call nodes in a sequential order (e.g., dialing → ringing → connecting → hanging up). The state object determines the order of the first call node and the second call node according to the call flow. If the first call node is not later than the second call node, it means that the pending call event is a newly triggered call with the same call event as the one being processed. Therefore, in order to avoid frequent triggering of the same type of call, the state object ignores the pending call event, which can improve call order.
[0049] For example, the call event in the process is ecall, and the corresponding second call node is connected. The call event to be processed is ecall, and the corresponding first call node is dialing. The call events in the process are already in progress and are in the connected node. If the call event to be processed is received, the ecall must be ended, that is, the current call is hung up and the ecall is redialed, that is, the dialing node is executed. This will cause the ecall to be triggered repeatedly, resulting in call confusion. Therefore, the call event to be processed is ignored.
[0050] Step S402: If the state object determines that the first calling node is later than the second calling node in the call process, it responds to the pending call event to update the second calling node to the first calling node. The call process is the process by which the server responds to the pending call event, and the call process includes multiple call nodes set in a sequential order.
[0051] Specifically, when the state object determines that the first calling node is later than the second calling node, it determines that this is the calling node fed back by the server for the call event in process. In order to ensure the normal implementation of the call, the state object receives the call event to be processed, that is, updates the second calling node to the first calling node.
[0052] It should be noted that the state object is used to interact with the user. When the state object is processing a call event, it sends corresponding information to the vehicle system to remind the user which call is being executed (such as ecall). When the call node of the call event changes, the state object also sends response information to the vehicle system so that the user knows the node where the call is located and can take corresponding actions (such as speaking) according to the node to achieve the purpose of the call.
[0053] In this embodiment, when the state object determines that the first calling node is no later than the second calling node in the call flow, i.e., it determines that the progress of the pending call event is behind the progress of the processing call event, it ignores the pending call event to ensure the normal progress of the processing call event. When it determines that the first calling node is later than the second calling node in the call flow, it determines that the progress of the pending call event is faster than the progress of the processing call event, indicating that the server is updating the progress of the processing call event. In this case, the second calling node is updated to the second calling node, so that the calling node of the state object is consistent with the calling node of the server, which is beneficial to the normal progress of the processing call event. The state object judges the priority of the pending call event and the processing call event through the calling node, realizes arbitration of the call event at the calling node, effectively avoids the problem of ineffective arbitration when the priority of the call events is the same, effectively avoids the situation of call conflict, and improves the practicality of the method. In some embodiments, the method further includes: In step S501, if the state object determines that the priority of the pending call event is higher than the priority of the call event being processed, then the state object is destroyed.
[0054] Specifically, when a state object determines that the priority of the pending call event is higher than the priority of the call event in progress, it determines that it is currently processing a call event. This means the call event in progress needs to end to avoid simultaneous occurrence of the call event in progress and the pending call event, which could lead to call confusion. Furthermore, after ending the call event in progress, the state object self-destructs. Upon self-destruction, the call resources occupied by the state object are automatically released. Therefore, the self-destruction of the state object avoids memory consumption and ensures the complete release of call resources, which is beneficial for the normal operation of subsequent calls. In addition, the self-destruction of the state object also ensures the accuracy of the link pointer switching. If each state object does not self-destruct after sending the state object switching instruction, the state machine needs to identify multiple state objects when switching the link pointer to connect with a new state object, complicating the process and increasing the risk of switching errors.
[0055] In addition, the state object can send the pending call event to the server so that the server responds to the pending call event, that is, completes the call corresponding to the pending call event. The self-destruction of the state object can ensure that only one state object exists, thereby avoiding the situation where multiple state objects send call events to the server at the same time, which would cause server call chaos and help improve the order of calls.
[0056] In some embodiments, terminating the call event during processing includes: Step S601: Send a hang-up call command to the server so that the server terminates the call event in process.
[0057] Specifically, when the state object ends the in-process call event, it sends the hang-up call instruction to the server. The hang-up call instruction is an instruction to update the call node to hang-up. When the server receives the hang-up call instruction, it actively hangs up the currently ongoing call, thereby ending the in-process call event. The call event being executed by the server ends, which can seamlessly connect to the next call event, realize the atomic transfer of call events, and is conducive to the orderliness of calls.
[0058] In this embodiment, the state object sends a hang-up command to the server, causing the server to terminate the call event in progress. This allows the server to free up space for processing the next call event and effectively avoids call chaos and call anomalies.
[0059] In some embodiments, the method further includes: Step S701: If the state object determines that the priority of the pending call event is higher than the priority of the call event being processed, then the state object releases the occupied call resources. Specifically, when the state object determines that the priority of the pending call event is higher than the priority of the call event being processed, it sends a state object switching instruction to the state machine. The state machine then sends a call resource release instruction to the state object, causing it to release the call resources it occupies, thus preventing the new state object from using those resources to make a call. The state object's release of its occupied call resources proactively yields to the new state object, facilitating the atomic conversion of call resources between the current state object and the new state object.
[0060] It should be noted that the call resources are hardware resources related to the call, including hardware devices such as microphones and speakers. When the state object occupies the call resources, it can control the opening and closing of the call resources, and can play the audio sent by the server, and receive and send the audio content of the user's in-vehicle conversation to the server, so as to realize the normal operation of the call.
[0061] In step S702, if the state machine completes the creation of the new state object, then the new state object occupies the call resource.
[0062] Specifically, after receiving the state object switching instruction from the state object, the state machine sends a call resource release instruction to the state object and creates the new state object. Therefore, when the state machine completes the creation of the new state object, the state object has already released the call resource, and the new state object's occupation of the call resource is effective. Thus, the new state object can make a call and ensure that the call proceeds normally.
[0063] In this embodiment, when the state object determines that the priority of the pending call event is higher than the priority of the call event being processed, it releases the occupied call resources. Furthermore, after the state machine completes the creation of the new state object, the new state object occupies the call resources to ensure that the call runs normally when the new state object processes the pending call event, avoids call chaos, and improves call reliability.
[0064] In some embodiments, after step S103: switching the link pointer to point to the new state object, the following is included: Step S801: The state machine sends the pending call event to the new state object; Specifically, after the link pointer is switched to point to the new state object, it is determined that the pending call event will be processed by the new state object. Therefore, the state machine sends the pending call event to the new state object so that the new state object can process the pending call event.
[0065] Step S802: The new state object processes the pending call event.
[0066] Specifically, when the new state object receives the pending call event, it responds to the pending call event by processing the pending call event, that is, by executing the pending call event and realizing the call corresponding to the pending call event.
[0067] It should be noted that when the new state object processes the pending call event, it feeds back the call type corresponding to the pending call event to the vehicle controller, so that the vehicle controller controls the corresponding indicator light to light up based on the call type, so as to prompt the user about the type of call being executed.
[0068] In this embodiment, when the new state object is pointed to by the link pointer, it can receive the pending call event sent by the state machine and directly process the pending call event. This can improve the singularity of the call event processed by the new state object. That is, when the new state object is created and has not processed any call event, it can directly process the pending call event, thereby improving the processing efficiency of the pending call event.
[0069] In some embodiments, the new state object processes the pending call event, including: In step S901, the new state object sends the pending call event to the server so that the server responds to the pending call event.
[0070] Specifically, the server is a component used to implement the call. Therefore, when the new state object receives the pending call event, it sends the pending call event to the server so that the server can complete the call type corresponding to the pending call event.
[0071] After receiving the pending call event, the server responds to it (for example, if the pending call event is ecall, the server responds by dialing ecall). During this response, the call node changes. Upon determining this change, the server identifies a new pending call event and feeds back the changed call node and the call type from the pending call event to the state machine. Upon receiving this new pending call event, the state machine sends it to the new state object connected to the link pointer. The new state object then processes the new pending call event. The new state object prioritizes the call events based on their call types. Since the new pending call event reported by the server has the same call type as the pending call event being processed by the new state object, they have the same priority. The new state object then determines the order of the call nodes for the new pending call event. Because the new pending call event is an update of the call node for the server's call, and the call node for the new pending call event is later than the call node for the pending call event being processed by the new state object, the new state object receives the new pending call event and updates the call node of its currently processed call event to be the same as the call node corresponding to the new pending call event.
[0072] For example, the link pointer of the state machine points to a state object. The state object receives a pending call event of type ecall, and the calling node is dialing. It then sends the pending call event to the server. The server dials ecall, and at this time, the server receives a calling node of type dialing and a call type of ecall. Afterward, the server receives a calling node of type ringing, that is, the calling node changes. The server then sends the call type "ecall" and the calling node "ringing" as the new pending call event to the state machine, so that the state machine sends it to the state object for the state object to determine the processing result. Since the new pending call event has the same call type as the pending call event, and the calling node of the new pending call event is later than the pending call event, the state object receives the new pending call event and updates the calling node of the currently processed call event to "ringing".
[0073] In this embodiment, the server is used to receive and respond to pending call events sent by the new state object, and monitor the call node during the response to the pending call events. When the call node changes, the server feeds back the changed call node and the call type of the responded pending call event as a new pending call event, so that the call type and call node of the call event being processed by the new state object can be matched with the server, which can ensure the effective execution of the call and improve the reliability of the call.
[0074] It should be noted that the method in this embodiment can be executed by a single device, such as a computer or server. The method can also be applied in a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method in this embodiment, and the multiple devices will interact with each other to complete the method described.
[0075] It should be noted that the above description describes some embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the above embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
[0076] Based on the same inventive concept, and corresponding to any of the above embodiments, this application also provides a T-BOX.
[0077] refer to Figure 3 The T-BOX100 includes a state machine 110 and a state object 120, wherein the link pointer 111 of the state machine 110 points to the state object 120; The T-BOX100 is configured such that: after the state machine receives a call event to be processed, it sends the call event to be processed to the state object pointed to by the link pointer, so that the state object determines the priority of the call event to be processed and the call event in process, wherein the call event in process is the call event that the state object is currently processing; If the state object determines that the priority of the pending call event is higher than the priority of the call event in process, then it terminates the call event in process and sends a state object switching instruction to the state machine so that the state machine creates a new state object. After the state machine creates a new state object, it switches the link pointer to point to the new state object so that the new state object can handle the pending call event.
[0078] Furthermore, the T-BOX100 is also configured as follows: If the state object determines that the priority of the pending call event is lower than the priority of the processing call event, it continues to execute the processing call event and sends an ignore instruction to the state machine so that the state machine ignores the pending call event.
[0079] Furthermore, the T-BOX100 is also configured as follows: If the state object determines that the priority of the pending call event is equal to the priority of the processing call event, it determines the first call node corresponding to the pending call event and the second call node corresponding to the processing call event, and determines whether to respond to the pending call event based on the first call node and the second call node.
[0080] Furthermore, the T-BOX100 is also configured as follows: If the state object determines that the first calling node is no later than the second calling node in the call process, it continues to execute the call event in process and sends an ignore instruction to the state machine so that the state machine ignores the call event to be processed. If the state object determines that the first calling node is later than the second calling node in the call process, it responds to the pending call event to update the second calling node to the first calling node. The call process is the process by which the server responds to the pending call event, and the call process includes multiple call nodes set in a sequential order.
[0081] Furthermore, the T-BOX100 is also configured as follows: If the state object determines that the priority of the pending call event is higher than the priority of the call event being processed, then the state object is destroyed.
[0082] Furthermore, the T-BOX100 is also configured as follows: Send a hang-up command to the server to cause the server to terminate the call event in process.
[0083] Furthermore, the T-BOX100 is also configured such that: if the state object determines that the priority of the pending call event is higher than the priority of the call event being processed, then the state object releases the occupied call resources. If the state machine completes the creation of the new state object, then the new state object occupies the call resource.
[0084] Furthermore, the T-BOX100 is also configured such that the state machine sends the pending call event to the new state object; The new state object processes the pending call events.
[0085] Furthermore, the T-BOX100 is also configured such that the new state object sends the pending call event to the server, so that the server responds to the pending call event.
[0086] The T-BOX in the above embodiments is used to implement the corresponding call management method in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.
[0087] Based on the same inventive concept, this application also provides a vehicle including a T-BOX as described above, the beneficial effects of which are the same as those of the T-BOX described above, and will not be repeated here.
[0088] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, in implementing this application, the functions of each module can be implemented in one or more software and / or hardware.
[0089] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the call management method described in any of the above embodiments.
[0090] Figure 4 This embodiment illustrates a more specific hardware structure of an electronic device. The device may include a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, memory 1020, input / output interface 1030, and communication interface 1040 are interconnected internally via the bus 1050.
[0091] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.
[0092] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.
[0093] The input / output interface 1030 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.
[0094] The communication interface 1040 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).
[0095] Bus 1050 includes a pathway for transmitting information between various components of the device, such as processor 1010, memory 1020, input / output interface 1030, and communication interface 1040.
[0096] It should be noted that although the above-described device only shows the processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050, in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the embodiments of this specification, and not necessarily all the components shown in the figures.
[0097] The electronic devices described above are used to implement the corresponding call management methods in any of the foregoing embodiments and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.
[0098] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides a non-transitory computer-readable storage medium that stores computer instructions for causing the computer to execute the call management method as described in any of the above embodiments.
[0099] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.
[0100] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the call management method as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.
[0101] Based on the same concept, corresponding to any of the above embodiments, this application also provides a computer program product, including computer program instructions, which, when run on a computer, cause the computer to perform the method described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.
[0102] It is understood that before using the technical solutions of the various embodiments in this disclosure, users will be informed of the type, scope of use, and usage scenarios of the personal information involved in an appropriate manner, and user authorization will be obtained.
[0103] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose, based on the prompt message, whether to provide personal information to the software or hardware such as electronic devices, applications, servers, or storage media performing the operations of this disclosed technical solution.
[0104] As an optional but not limited implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.
[0105] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.
[0106] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this application is limited to these examples; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this application as described above, which are not provided in detail for the sake of brevity.
[0107] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this application, the well-known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the provided drawings. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this application, and this also takes into account the fact that the details of the implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this application will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuits) have been set forth to describe exemplary embodiments of this application, it will be apparent to those skilled in the art that the embodiments of this application can be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.
[0108] Although this application has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.
[0109] The embodiments of this application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the claims of this application. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the embodiments of this application should be included within the protection scope of this application.
Claims
1. A call management method characterized by, The method is applied to a T-BOX, the T-BOX comprises a state machine and a state object, a link pointer of the state machine points to the state object, and the method comprises the following steps: After the state machine receives a to-be-processed call event, the state machine sends the to-be-processed call event to the state object pointed to by the link pointer, so that the state object determines the priority of the to-be-processed call event and a processing call event, wherein the processing call event is a call event being processed by the state object; If the state object determines that the priority of the to-be-processed call event is higher than the priority of the processing call event, the state object ends the processing call event and sends a state object switching instruction to the state machine, so that the state machine creates a new state object; After the state machine creates the new state object, the state machine switches the link pointer to point to the new state object, so that the new state object processes the to-be-processed call event.
2. The method of claim 1, wherein, Further comprising: If the state object determines that the priority of the to-be-processed call event is lower than the priority of the processing call event, the state object continues to execute the processing call event and sends an ignore instruction to the state machine, so that the state machine ignores the to-be-processed call event.
3. The method of claim 1, wherein, Further comprising: If the state object determines that the priority of the to-be-processed call event is equal to the priority of the processing call event, the state object determines a first call node corresponding to the to-be-processed call event and a second call node corresponding to the processing call event, and determines whether to respond to the to-be-processed call event based on the first call node and the second call node.
4. The method of claim 3, wherein, The determination of whether to respond to the to-be-processed call event based on the first call node and the second call node comprises: If the state object determines that the first call node is not later than the second call node in a call flow, the state object continues to execute the processing call event and sends an ignore instruction to the state machine, so that the state machine ignores the to-be-processed call event; If the state object determines that the first call node is later than the second call node in the call flow, the state object responds to the to-be-processed call event to update the second call node as the first call node; The call flow is a flow of a server responding to the to-be-processed call event, and the call flow comprises a plurality of call nodes arranged in a sequence.
5. The method of claim 1, wherein, Further comprising: If the state object determines that the priority of the to-be-processed call event is higher than the priority of the processing call event, the state object destroys the state object.
6. The method of claim 1, wherein, The ending of the processing call event comprises: Sending a hang-up call instruction to a server, so that the server ends the processing call event.
7. The method of claim 1, wherein, Further comprising: If the state object determines that the priority of the to-be-processed call event is higher than the priority of the processing call event, the state object releases the occupied call resource; If the state machine creates the new state object, the new state object occupies the call resource.
8. The method of claim 1, wherein, After the link pointer is switched to point to the new state object, the following steps are further included: The state machine sends the pending call event to the new state object; The new state object processes the pending call event.
9. The method of claim 8, wherein, The new state object processes the pending call event, comprising: The new state object sends the pending call event to a server, so that the server responds to the pending call event.
10. A vehicle characterized by comprising: A T-BOX for performing the method of any one of claims 1-9.