A method, device and equipment for managing the state of a vehicle-mounted emergency call system
Patent Information
- Application Number
- CN202610866895.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-06-16
- Publication Date
- 2026-09-22
AI Technical Summary
[0011]为了弥补上述不足，本发明提出一种车载紧急呼叫系统的状态管理方法、装置及设备，系统性地解决了现有技术中平台兼容性差、状态流转混乱、状态不一致及模块耦合度高等技术问题，实现了清晰、安全、可扩展的车载紧急呼叫状态管理
[0033]本发明消除了不同车辆平台信号格式差异对上层业务逻辑的影响，使上层状态管理模块无需关注底层信号的具体定义，从而显著提升了系统的平台兼容性和可移植性。
Smart Images
Figure CN122802877A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of vehicle communication technology, and specifically to a status management method, apparatus, and equipment for an in-vehicle emergency call system. Background Technology
[0002] With the rapid development of intelligent connected vehicles, in-vehicle emergency call systems have become an important feature for ensuring the safety of vehicle occupants. These systems can be automatically or manually triggered by occupants in emergency situations such as traffic accidents or vehicle malfunctions to establish a voice call with the rescue service center and upload key information such as vehicle location, time, and model to support timely rescue efforts.
[0003] Currently, existing vehicle-mounted emergency call systems mainly adopt relatively simple functional implementation methods, and their technical architecture and status management have the following shortcomings:
[0004] First, in terms of system architecture, existing solutions often highly couple functional modules such as call control, user interface, and underlying communication, lacking a clear layered architecture design. This high degree of coupling makes code maintenance difficult; when a function needs to be modified, it often affects other modules, increasing the complexity of development and testing. At the same time, functional scalability is also limited, making it difficult to adapt to the customized needs of different car models or different markets.
[0005] Secondly, in terms of state management, existing systems generally lack a unified state management mechanism. The flow logic of call states (such as standby, dialing, in call, hung up, etc.) is scattered across various business modules, which can easily lead to inconsistencies in states. For example, the "in call" state displayed on the user interface may not match the actual call state at the underlying level, or state loss or incorrect state transitions may occur during rapid operations, seriously affecting user experience and system reliability.
[0006] Third, the existing solutions are not robust enough in terms of anomaly handling. There is a lack of effective detection and recovery mechanisms for common anomalies such as abnormal system service disconnections, interruptions in connections to in-vehicle communication services, and heartbeat signal timeouts. When anomalies occur, the system may remain unresponsive for an extended period or fail to recover automatically, requiring the user to restart the vehicle or related systems to restore normal operation.
[0007] Fourth, regarding platform compatibility, there are significant differences in the communication interfaces and signal definitions provided by different vehicle platforms. The signal processing logic of existing systems is often tightly bound to specific platforms, which requires extensive code modifications when porting the system to other vehicle platforms. This results in high cross-platform porting costs and hinders rapid product iteration and large-scale application.
[0008] Fifth, in terms of data collection, existing solutions lack a complete mechanism for collecting and reporting behavioral data. Key data such as user actions (e.g., clicks, voice triggers), call status changes, and system anomalies are often not systematically recorded and reported, leading to difficulties in problem localization and a lack of data support for system optimization.
[0009] Sixth, in terms of resource management, the existing system does not manage system resources (such as audio focus and window display focus) during a call in a granular manner. When an emergency call runs simultaneously with other applications (such as multimedia playback and navigation voice), resource conflicts are likely to occur, leading to call abnormalities or affecting other application functions.
[0010] Therefore, developing a vehicle-mounted emergency call system with a clear architecture, sound state management, robust exception handling, and good platform compatibility, as well as its state management method, is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention
[0011] To overcome the above shortcomings, this invention proposes a state management method, device, and equipment for a vehicle-mounted emergency call system, which systematically solves the technical problems of poor platform compatibility, chaotic state transitions, inconsistent states, and high module coupling in the prior art, and realizes clear, safe, and scalable state management for vehicle-mounted emergency calls.
[0012] To achieve the above objectives, the present invention adopts the following technical solution:
[0013] In a first aspect, the present invention provides a status management method for an in-vehicle emergency call system, the method comprising:
[0014] Receive raw signals from the vehicle service and parse the raw signals into standardized state inputs;
[0015] Based on the standardized status input and the current call status, a predefined status transition verification strategy is invoked to determine whether the transition from the current call status to the target call status is legal.
[0016] If the call is deemed valid, update the call status object to overwrite the current call status with the target call status.
[0017] Based on the updated call status object, generate a status change notification and distribute the status change notification.
[0018] Optionally, the call status object includes: status code, call type, and return code fields.
[0019] Optionally, parsing the original signal into a standardized state input includes: identifying the data format of the original signal and converting it into a standardized data format that the state transition verification strategy can recognize.
[0020] Optionally, the step of invoking a predefined state transition verification strategy to determine whether the transition from the current call state to the target call state is legal includes: extracting the status code of the current call state and matching the corresponding status verification strategy from the strategy set based on the status code;
[0021] The status verification strategy predefines a list of legal target statuses that are allowed to transition. By querying whether the target call status exists in the list of legal target statuses, a legality judgment result is generated.
[0022] Optionally, updating the call status object includes: determining whether the target call status is the same as the current call status; if they are the same, maintaining the call status object unchanged; if they are different, updating the status code, call type, and return code fields in the call status object.
[0023] Optionally, generating a status change notification based on the updated call status object and distributing the status change notification includes: triggering a corresponding preset callback interface based on the status code in the updated call status object, and providing behavioral record data containing the status code and call type to the data collection.
[0024] Optionally, the method further includes: monitoring the periodic signal heartbeat with the vehicle service; if the periodic signal is not received within a preset timeout period, generating a service disconnection anomaly signal, and using the service disconnection anomaly signal as the standardized status input.
[0025] Optionally, the monitoring of the periodic signal heartbeat of the vehicle service includes: resetting the heartbeat timer when the periodic signal is received, and determining whether the current call status is dialing, hanging up, or ended; if so, pausing the heartbeat timer.
[0026] In a second aspect, the present invention provides a status management device for a vehicle-mounted emergency call system, for implementing the method described in any one of the first aspects, comprising:
[0027] A signal receiving unit is used to receive raw signals from the vehicle service and parse the raw signals into standardized state inputs.
[0028] A status verification unit, connected to the signal receiving unit, is used to call a predefined status transition verification strategy based on the standardized status input and the current call status to determine whether the transition from the current call status to the target call status is legal.
[0029] A status update unit, connected to the status verification unit, is used to update the call status object when the status verification unit determines that it is valid, so that the target call status overwrites the current call status;
[0030] The notification distribution unit, connected to the status update unit, is used to generate a status change notification based on the updated call status object and distribute the status change notification.
[0031] A third aspect of the present invention provides an electronic device including a memory and a processor, wherein the memory stores a computer program that, when executed by the processor, causes the processor to perform the steps of the method as described in any one of the first aspects.
[0032] Compared with the closest prior art, the present invention has the following beneficial effects:
[0033] This invention eliminates the impact of signal format differences between different vehicle platforms on upper-layer business logic, so that the upper-layer state management module does not need to pay attention to the specific definition of the underlying signals, thereby significantly improving the system's platform compatibility and portability.
[0034] Secondly, by invoking a predefined state transition verification strategy based on standardized state inputs and the current call state, the legality of state transitions is determined, overcoming the shortcomings of existing technologies where state transition logic is scattered and lacks unified verification. This ensures that only state changes that conform to the system's predefined transition rules can be executed, thus preventing system anomalies caused by illegal state transitions and improving the security and reliability of state management.
[0035] Secondly, if the call status is deemed valid, the call status object is updated to overwrite the current call status with the target call status. This ensures that the system always maintains an accurate and consistent current call status, avoiding inconsistencies caused by multiple modules maintaining their own statuses, and providing a reliable data foundation for subsequent business logic judgments and interface displays.
[0036] Finally, a state change notification is generated and distributed based on the updated call state object, achieving unified and timely propagation of state change events. This enables state-dependent modules such as view management and data acquisition to synchronously learn of state changes without needing to poll or repeatedly parse the original signals, thereby reducing coupling between modules and ensuring a high degree of synchronization between the user interface display and the actual system state, improving user experience and system observability. Attached Figure Description
[0037] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.
[0038] Figure 1 A flowchart illustrating the status management method of an in-vehicle emergency call system provided in this embodiment of the invention;
[0039] Figure 2 This is a schematic diagram of the structure of a vehicle-mounted emergency call system provided in an embodiment of the present invention;
[0040] Figure 3 A structural block diagram of a status management device for a vehicle-mounted emergency call system provided in an embodiment of the present invention;
[0041] Figure 4 This is an internal structure diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation
[0042] The embodiments of the technical solution of the present invention will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of the present invention and are therefore merely examples, and should not be construed as limiting the scope of protection of the present invention.
[0043] It should be noted that, unless otherwise stated, the technical or scientific terms used in this application should have the ordinary meaning as understood by one of ordinary skill in the art to which this invention pertains.
[0044] This invention provides a status management method, apparatus, and device for an in-vehicle emergency call system, and particularly relates to an in-vehicle emergency call device and its status management method for intelligent connected vehicles. Embodiments of the invention are described below with reference to the accompanying drawings.
[0045] Example 1: This example details the specific execution flow of the status management method for an in-vehicle emergency call system. The overall flow can be found by referring to... Figure 1 .
[0046] Embodiment 1 of the present invention provides a status management method for an in-vehicle emergency call system, the method specifically including the following steps:
[0047] S101 receives raw signals from the vehicle service and parses the raw signals into standardized state inputs;
[0048] S102, based on the standardized status input and the current call status, invokes a predefined status transition verification strategy to determine whether the transition from the current call status to the target call status is legal;
[0049] S103 If the call is deemed valid, update the call status object and overwrite the current call status with the target call status;
[0050] S104 generates a status change notification based on the updated call status object and distributes the status change notification.
[0051] In step S101 above, receiving the raw signal from the vehicle service includes: providing a unified signal receiving interface for different vehicle platforms, and binding the signal source of the vehicle service through the unified signal receiving interface.
[0052] Furthermore, parsing the original signal into a standardized state input includes: identifying the data format of the original signal and converting it into a standardized data format that the state transition verification strategy can recognize.
[0053] Specifically, during system operation, when a call-related event (such as a network call, call connection, or call termination) is detected, a callback method in the signal interface is triggered. For example, the "callback" method of the "vehicle service signal interface implementation" is called, passing in a key and value representing a change in call status. After parsing the value, the interface calls the "call status change callback" method, which passes this standardized status code to the "call state machine".
[0054] In step S102 above, calling a predefined state transition verification strategy to determine whether the transition from the current call state to the target call state is legal includes: extracting the status code of the current call state, and matching the corresponding status verification strategy from the strategy set according to the status code;
[0055] The status verification strategy predefines a list of legal target statuses that are allowed to transition. By querying whether the target call status exists in the list of legal target statuses, a legality judgment result is generated.
[0056] In one embodiment, after the "call state machine" receives a new state ("target state"), it first obtains the currently maintained "current state". Then, it calls a validation function, such as "whether call status feedback is required".
[0057] The core of this validation function is the determination of the legality of state transitions. It calls a policy selector, which, based on the status code of the "current state," finds the corresponding policy object from a predefined policy mapping table. Each policy object contains a list of legal target status codes that are allowed to be transitioned from the current state. The validation function checks whether the status code of the "target state" is in this legal list.
[0058] In step S103 above, the call status object includes: status code, call type, and return code fields.
[0059] The update of the call status object includes: determining whether the target call status is the same as the current call status; if they are the same, the call status object is kept unchanged; if they are different, the status code, call type and return code fields in the call status object are updated.
[0060] Specifically, if the verification in step 120 passes, the "call state machine" will update its internal "call state object." The update process includes:
[0061] Check if the old and new status codes are the same. If they are the same, return directly without any further processing.
[0062] If they are different, create a new "Call Status Object" and fill in the call type, the new status code, and the possible return code.
[0063] Replace the old object with this new object.
[0064] In step S104 above, generating a status change notification based on the updated call status object and distributing the status change notification includes: triggering a corresponding preset callback interface based on the status code in the updated call status object, and providing behavioral record data containing the status code and call type to the data collection.
[0065] In one embodiment, after the state update is complete, the "call state machine" will trigger the corresponding callback based on the specific type of the new state. For example:
[0066] If the new status is "Information service call dialing", then the "Call dialing" method of the "listener" will be called back.
[0067] If the new state is "Call connected", then the "Call connected" method of the "listener" will be called back.
[0068] If the new state is "Call Ended", then the "Call Ended" method of the "Listener" is called back, and the state is reset.
[0069] These callbacks will notify the "Call Application View Model". In the corresponding callback method, the "View Model" will update its internal "real-time data", such as "call duration" and "connection status". Simultaneously, the "View Model" will call the corresponding methods of the "Data Acquisition Wrapper Class" to record the current state change. For example, in the "Call Connected" callback, the call start time will be recorded, and the "Call Connected" event will be reported.
[0070] In addition, the method also includes: monitoring the periodic signal heartbeat with the vehicle service; if the periodic signal is not received within a preset timeout period, generating a service disconnection anomaly signal, and using the service disconnection anomaly signal as the standardized status input.
[0071] The monitoring of the periodic signal heartbeat of the vehicle service includes: resetting the heartbeat timer when the periodic signal is received, and determining whether the current call status is dialing, hanging up, or ended. If so, the heartbeat timer is paused.
[0072] This embodiment describes in detail a periodic signal heartbeat detection method to ensure system stability; its process can be found in [reference needed]. Figure 3 .
[0073] When the vehicle is operating normally and there are no emergency calls, the in-vehicle service sends a periodic signal at a fixed frequency (e.g., every 5 seconds) to indicate that the service is in normal working order. This invention utilizes this signal to achieve heartbeat detection.
[0074] A dedicated inner class, "Periodic Signal Heartbeat Auxiliary Class," handles this functionality. At its core is a countdown timer, initialized to a preset threshold duration, such as a preset timeout duration.
[0075] Heartbeat reset process:
[0076] When the "Call State Machine" or signal jack receives a periodic signal, it will call the "Count or Reset" method of the "Periodic Signal Heartbeat Auxiliary Class".
[0077] In this method, the countdown timer is first "canceled" to stop any currently running countdown.
[0078] Next, the current status of the "call status object" is determined. If a call is currently being dialed, is being disconnected, or has ended, the process returns directly without restarting the countdown. This is because in these states, the impact of service disconnection is minimal, or the system is in a sensitive period of state change, thus avoiding invalid checks.
[0079] If the current state is not in the exemption state described above, a coroutine is used to delay for a short period of time (e.g., 500 milliseconds) before restarting the countdown timer. The purpose of the delay is to avoid operating the timer too frequently.
[0080] Timeout handling process: If the countdown timer successfully completes the set threshold duration without being reset during the period, the countdown timer's "end action" will be executed.
[0081] The "End Action" will call the "Heartbeat Disconnect" method.
[0082] The "heartbeat disconnection" method first determines whether the service is already in a disconnection process to avoid duplicate processing. If this is the first timeout detected, it will:
[0083] Create an abnormal state representing "heartbeat timeout".
[0084] Report this exception by calling the "Tracking Heartbeat Timeout" method of the "Data Acquisition Wrapper Class".
[0085] The "state machine listener" notifies the "view model layer," which in turn allows the user interface layer to display a "communication service error" message to the user.
[0086] Invoke the internal method for resetting the state to restore the "call state object" to a safe base state (such as "no call").
[0087] Example 2: This example describes a specific implementation of an in-vehicle emergency call system. For example... Figure 2 As shown, the system adopts a layered architecture design, which includes, from bottom to top, a bottom service layer 11, a signal interface layer 12, a state machine layer 13, a view model layer 14, and a user interface layer 15. In addition, it also includes a data acquisition layer 16; the data acquisition layer 16 is a cross-cutting concern and interacts with both the state machine layer 13 and the view model layer 14.
[0088] 1. Underlying Service Layer 11
[0089] This layer encapsulates the interaction logic with the vehicle hardware and operating system at the lower level. In this embodiment, it is implemented through a singleton class called "Vehicle Service Wrapper Class". This class is responsible for managing all connections to vehicle services (such as vehicle services), registering listeners, and sending and receiving raw data. For example, it registers listeners with vehicle services for attributes such as call status, system status, and power status.
[0090] 2. Signal jack layer 12
[0091] This layer is crucial for resolving platform compatibility issues. At its core is an abstract base class, "Basic Signal Socket Abstract Class," which defines a unified interface that all signal sockets must implement, such as "Call Status Change Callback" and "System Fault Callback."
[0092] Based on this, different specific subclasses can be implemented for different vehicle platforms or service protocols. For example, "vehicle service signal interface implementation" is a specific implementation of the standard vehicle service interface.
[0093] The working process of this connector is as follows:
[0094] Initialization: In the "Execute Initialization" method, the required signal attributes are registered with the underlying system through the "Vehicle Service Wrapper Class".
[0095] Receiving: When a signal arrives at the underlying layer (e.g., via a callback function), the specific socket implementation will receive the data in the original "key-value pair" format.
[0096] Analysis: Determine the signal type based on the predefined "key" (e.g., "call status attribute") and parse the value into the corresponding data object (e.g., "call status information").
[0097] Reporting: Call the callback method implemented by the base class or itself to pass the parsed and standardized state information to the upper layer (state machine layer).
[0098] This plug-in design means that when a new vehicle platform needs to be supported, only an implementation class that inherits from the "basic signal socket abstract class" needs to be added and its specific signal parsing logic needs to be completed. The upper-level code does not need to be modified at all.
[0099] 3. State Machine Layer 13
[0100] This layer is the core of the system, responsible for the unified management of all call states. Its main control class is the "Call State Machine," which is typically designed using the singleton pattern to ensure that there is only one state management instance globally.
[0101] The "call state machine" internally maintains a "call state object." The "call state object" is a data class used to encapsulate the core attributes of the current call, including at least:
[0102] "Call type": For example, emergency call or information service call.
[0103] "Status code": Used to uniquely identify the current specific status, such as dialing, connecting, connected, terminated, etc.
[0104] "Return Code": Used to record the specific reason when a call ends or fails.
[0105] The "call state machine" receives standardized state inputs from the signal jack layer and performs a series of processes, the core logic of which will be detailed in the method implementation.
[0106] 4. View Model Layer 14
[0107] This layer serves as a bridge between the state machine layer and the user interface layer. The "Call Application View Model" is the primary implementation class, inheriting from the "View Model" component in the Android architecture. It can hold and manage user interface-related data, and is lifecycle-aware, preventing memory leaks.
[0108] The "Call Application View Model" holds observable data of type "Real-time Data". When the state machine layer changes, it notifies the "View Model" via a listener callback, and the "View Model" then updates the value of the "Real-time Data". By observing this "Real-time Data", the user interface layer can automatically receive update notifications and refresh the interface.
[0109] 5. User Interface Layer 15
[0110] This layer is responsible for the specific interface display and user interaction. It mainly includes the "Emergency Call Window" and the "Information Service Call Window," both of which inherit from a base window class, "Basic Call Window." The "Basic Call Window" provides common functions such as window display, hiding, and focus management, avoiding code duplication.
[0111] 6. Data Acquisition Layer 16
[0112] This layer is implemented through a utility class called "Data Acquisition Wrapper." It provides a series of static methods for conveniently acquiring data throughout the system. For example, when a user clicks the emergency call button, the user interface layer calls the "Acquire Real-Time Data" method of the "Data Acquisition Wrapper"; when the state machine transitions, it calls the "Tracking Call Status" method of the "Data Acquisition Wrapper." The "Data Acquisition Wrapper" formats this data (e.g., encapsulates it into Jason format) and sends it to the cloud server via the underlying reporting interface.
[0113] Example 3: Based on the same inventive concept, Example 3 of this application also provides a state management device for a vehicle emergency call system, which is a state management method for a vehicle emergency call system. The solution provided by this device is similar to the solution described in the method of Example 1 above. Therefore, the specific limitations of one or more state management device embodiments of a vehicle emergency call system provided below can be found in the limitations of the state management method for a vehicle emergency call system above, and will not be repeated here.
[0114] In one embodiment, Embodiment 3 of the present invention provides a status management device for a vehicle-mounted emergency call system, the device as follows: Figure 3 As shown, it includes: a signal receiving unit 21, a status verification unit 22, a status update unit 23, and a notification distribution unit 24, wherein:
[0115] Signal receiving unit 21 is used to receive raw signals from vehicle service and parse the raw signals into standardized state inputs;
[0116] The status verification unit 22 is connected to the signal receiving unit and is used to call a predefined status transition verification strategy based on the standardized status input and the current call status to determine whether the transition from the current call status to the target call status is legal.
[0117] The status update unit 23 is connected to the status verification unit and is used to update the call status object when the status verification unit determines that it is valid, so that the target call status overwrites the current call status.
[0118] Notification distribution unit 24, connected to the status update unit, is used to generate a status change notification based on the updated call status object and distribute the status change notification.
[0119] Example 4: In one embodiment, Example 4 of the present invention also provides an electronic device; the electronic device may be a terminal, and its internal structure diagram may be as follows. Figure 4 As shown. The electronic device includes a processor, memory, communication interface, display screen, and input device connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements the status management method of the vehicle-mounted emergency call system described in any one of steps S101 to S104. The display screen can be a liquid crystal display (LCD) or an e-ink display. The input device can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the device's casing, or an external keyboard, touchpad, or mouse.
[0120] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0121] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0122] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0123] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0124] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0125] The above are merely embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention are included within the scope of the claims of the present invention pending approval.
Claims
1. A status management method for a vehicle-mounted emergency call system, characterized in that, The method includes: Receive raw signals from the vehicle service and parse the raw signals into standardized state inputs; Based on the standardized status input and the current call status, a predefined status transition verification strategy is invoked to determine whether the transition from the current call status to the target call status is legal. If the call is deemed valid, update the call status object to overwrite the current call status with the target call status. Based on the updated call status object, generate a status change notification and distribute the status change notification.
2. The method according to claim 1, characterized in that, The call status object includes: status code, call type, and return code fields.
3. The method according to claim 1, characterized in that, The step of parsing the original signal into a standardized state input includes: identifying the data format of the original signal and converting it into a standardized data format that the state transition verification strategy can recognize.
4. The method according to claim 2, characterized in that, The step of invoking a predefined state transition verification strategy to determine whether the transition from the current call state to the target call state is legal includes: extracting the status code of the current call state, and matching the corresponding status verification strategy from the strategy set based on the status code; The status verification strategy predefines a list of legal target statuses that are allowed to transition. By querying whether the target call status exists in the list of legal target statuses, a legality judgment result is generated.
5. The method according to claim 2, characterized in that, The update of the call status object includes: determining whether the target call status is the same as the current call status; if they are the same, the call status object is kept unchanged; if they are different, the status code, call type and return code fields in the call status object are updated.
6. The method according to claim 2, characterized in that, The step of generating a status change notification based on the updated call status object and distributing the status change notification includes: triggering a corresponding preset callback interface based on the status code in the updated call status object, and providing behavioral record data containing the status code and call type to the data collection.
7. The method according to claim 1, characterized in that, The method further includes: monitoring the periodic signal heartbeat of the vehicle service; if the periodic signal is not received within a preset timeout period, generating a service disconnection anomaly signal, and using the service disconnection anomaly signal as the standardized status input.
8. The method according to claim 7, characterized in that, The monitoring of the periodic signal heartbeat of the vehicle service includes: resetting the heartbeat timer when the periodic signal is received, and determining whether the current call status is dialing, hanging up, or ended. If so, the heartbeat timer is paused.
9. A status management device for a vehicle-mounted emergency call system, characterized in that, include: A signal receiving unit is used to receive raw signals from the vehicle service and parse the raw signals into standardized state inputs. A status verification unit, connected to the signal receiving unit, is used to call a predefined status transition verification strategy based on the standardized status input and the current call status to determine whether the transition from the current call status to the target call status is legal. A status update unit, connected to the status verification unit, is used to update the call status object when the status verification unit determines that it is valid, so that the target call status overwrites the current call status; The notification distribution unit, connected to the status update unit, is used to generate a status change notification based on the updated call status object and distribute the status change notification.
10. An electronic device, comprising a memory and a processor, characterized in that, The memory stores a computer program that, when executed by the processor, causes the processor to perform the steps of the method as described in any one of claims 1 to 8.