Platform instrument sound alarm method, system, equipment and medium

Abstract

The invention relates to the technical field of automobile electronic control, in particular to a platform instrument sound alarm method, system, equipment and medium, an external multi-source alarm sound signal is received through a sound alarm signal processing module, and the received external multi-source alarm sound signal is subjected to escape processing to form a uniform interface signal; analyzing the unified interface signal through a sound alarm management module, synthesizing the analyzed signal information into a standard alarm sound signal, and generating an arbitration event; an arbitration event is executed through a sound alarm arbitration module according to a preset priority rule, and a playing instruction is generated; and the sound alarm playing module plays alarm sound according to the playing instruction. Therefore, the signal processing, management, arbitration and playing function modules of the instrument sound alarm are platformized, the development period is greatly shortened, the timeliness and the accuracy of alarm sound playing are realized, the vehicle state is stably fed back, and the driving safety is guaranteed through a clear arbitration rule and accurate playing control.

Description

Technical Field

[0001] This application relates to the field of automotive electronic control technology, and in particular to a platform-based instrument sound alarm method, system, device and medium. Background Technology

[0002] Instrument panel audible alarms are an indispensable status alert mechanism in vehicles. They provide real-time feedback on abnormal events or potential risks in multiple areas such as the vehicle's power system, battery system, electrical system, and safety system through specific audio signals (such as sounds of different pitches, rhythms, and durations). This auditory stimulation quickly attracts the driver's attention and prompts the driver to take timely action.

[0003] With the development of the automotive market, various automakers have designed diverse instrument panel audible alarm solutions based on their own product needs. In existing technologies, instrument panel audible alarms are typically triggered by signals and buttons, and transmitted to the instrument panel software layer via a specific communication protocol to realize the alarm notification function. However, different manufacturers have different audible alarm notification rules, requiring the instrument panel software layer to develop corresponding audible alarm strategies separately for each manufacturer. Furthermore, when changing vehicle models, differences in hardware configuration and alarm logic necessitate redeveloping the audible alarm function. This "one manufacturer, one policy; one vehicle, one development" approach not only significantly reduces the development efficiency of instrument panel audible alarm functions but also increases subsequent maintenance costs, making it difficult to meet the automotive industry's demands for product universality and economical development. Summary of the Invention

[0004] To overcome the shortcomings of existing technologies, this application provides a platform-based instrument sound alarm method, system, device, and medium. By constructing a multi-module collaborative system architecture, it can achieve unified processing of alarm signals, classified management of playback rules, intelligent arbitration of playback timing, and stable playback output, thereby improving development efficiency and versatility.

[0005] In a first aspect, this application provides a platform-based instrument sound alarm method, applied to a platform-based instrument sound alarm system, wherein the platform-based instrument sound alarm system includes a sound alarm signal processing module, a sound alarm management module, a sound alarm arbitration module, and a sound alarm playback module; the method includes the following steps: The sound alarm signal processing module receives external multi-source alarm sound signals and processes them into a unified interface signal, which is then sent to the sound alarm management module. The sound alarm management module parses the received unified interface signal and starts / stops the alarm based on the parsed signal information. If the alarm is started, the parsed signal information is synthesized into a standard alarm tone signal, and an arbitration event is generated and sent to the sound alarm arbitration module. Based on the sound alarm arbitration module, the arbitration event is executed according to the preset priority rules, and a playback command is generated; The sound alarm playback module plays an alarm sound according to the playback command.

[0006] In one possible implementation, the received external multi-source alarm tone signals include alarm tone signals from various vehicle systems. By configuring a dedicated adapter, the alarm tone signals of each system are converted into a unified interface signal; the unified interface signal includes alarm event type, operation command, priority base value, playback requirements, and adaptation conditions.

[0007] In one possible implementation, the step of synthesizing the parsed signal information into a standard alarm tone signal and generating an arbitration event includes the following steps: The parsed signal information is then filled into each byte of the standard alarm tone signal; the standard alarm tone signal includes the priority byte, type byte, audio source file sequence number byte, attribute byte, playback count byte, playback frequency byte, and reserved byte of the alarm event; The parsed operation instructions and the filled standard alarm tone signal are encapsulated into an arbitration event.

[0008] In one possible implementation, the alarm is started / stopped based on the parsed operation command; Based on the pre-set mapping table between alarm event types and audio source file numbers, determine the audio source file number byte of the standard alarm tone signal; The attribute bytes of the standard alarm tone signal are determined based on the parsed adaptation conditions; Based on the parsed playback demand information, the target playback rule is matched from multiple pre-set playback rules, and the playback count and frequency bytes of the standard alarm tone signal are determined according to the matched target playback rule.

[0009] In one possible implementation, the attribute bytes include power status attributes, interruption attributes, recovery attributes, periodic attributes, self-interruption attributes, and adaptation attributes.

[0010] In one possible implementation, the preset priority rule is: Arbitration events are sorted according to an ascending priority strategy, with the priority obtained from the priority byte in the standard alarm tone signal; Specifically, arbitration events with the same priority are further sorted according to their reception time; and the alarm sound played for the corresponding arbitration event is interrupted or resumed based on the attribute bytes in the standard alarm sound signal.

[0011] In one possible implementation, the corresponding audio source file is played through multiple parallel players according to the number of playbacks and the playback frequency in the playback instruction; The audio source file is obtained by the data provider that the supply manager requests to adapt according to the playback command, and the data provider triggers the loading of the file container.

[0012] Secondly, this application provides a platform-based instrument sound alarm system, including a sound alarm signal processing module, a sound alarm management module, a sound alarm arbitration module, and a sound alarm playback module, for performing the steps of the platform-based instrument sound alarm method as described in any of the first aspects.

[0013] Thirdly, this application provides an electronic device, including: a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory via the bus, and when the machine-readable instructions are executed by the processor, the steps of the platform-based instrument sound alarm method as described in any of the first aspects are performed.

[0014] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the platform-based instrument sound alarm method as described in any of the first aspects.

[0015] This embodiment provides a platform-based instrument panel sound alarm method, system, device, and medium. The system receives external multi-source alarm sound signals through a sound alarm signal processing module, processes these signals into a unified interface signal, and sends it to a sound alarm management module. The sound alarm management module parses the received unified interface signal and activates / deactivates the alarm based on the parsed signal information. If an alarm is activated, the parsed signal information is synthesized into a standard alarm sound signal, and an arbitration event is generated and sent to a sound alarm arbitration module. The sound alarm arbitration module executes the arbitration event according to preset priority rules, generating a playback command. The sound alarm playback module plays the alarm sound according to the playback command. This abstracts and platformizes the core functional modules of instrument panel sound alarms, including signal processing, management, arbitration, and playback. Based on this platform architecture, when adapting to new vehicle models or brands, there is no need to reconstruct the core alarm logic, significantly shortening the development cycle and improving development efficiency. Furthermore, through clear arbitration rules and precise playback control, the system achieves timely and accurate alarm sound playback, stably reflecting vehicle status and ensuring driving safety. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A schematic diagram of the structure of a platform-based instrument sound alarm system according to an embodiment of this application is shown; Figure 2 A flowchart of a platform-based instrument sound alarm method according to an embodiment of this application is shown; Figure 3 A schematic diagram of the structure of the sound alarm signal processing module according to an embodiment of this application is shown; Figure 4 A structural block diagram of an electronic device according to an embodiment of this application is shown. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0019] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0020] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0021] In view of the technical problems raised in the background art, this application provides a platform-based instrument sound alarm method, system, device and medium, which can realize unified processing of alarm signals, classified management of playback rules, intelligent arbitration of playback timing and stable playback output by constructing a multi-module collaborative system architecture, thereby improving development efficiency and versatility.

[0022] In one embodiment, see the appendix to the specification. Figure 1 Included with instruction manual Figure 2 This application provides a platform-based instrument sound alarm method, applied to a platform-based instrument sound alarm system. The platform-based instrument sound alarm system includes a sound alarm signal processing module, a sound alarm management module, a sound alarm arbitration module, and a sound alarm playback module. The method includes the following steps: S1. The sound alarm signal processing module receives external multi-source alarm sound signals and processes the received external multi-source alarm sound signals into a unified interface signal, which is then sent to the sound alarm management module. S2. The sound alarm management module parses the received unified interface signal and starts / stops the alarm according to the parsed signal information; wherein, if the alarm is started, the parsed signal information is synthesized into a standard alarm sound signal, and an arbitration event is generated and sent to the sound alarm arbitration module. S3. Based on the sound alarm arbitration module, the arbitration event is executed according to the preset priority rules, and a playback command is generated; S4. The sound alarm playback module plays an alarm sound according to the playback command.

[0023] In step S1, the sound alarm signal processing module is mainly responsible for receiving, distinguishing, and translating external multi-source alarm sound signals; for details, please refer to the attached instruction manual. Figure 3The received external multi-source alarm tone signals cover alarm tone signals linked to vehicle warning systems, telltale systems, TC (traction control system), CAN (vehicle network), and other components; alarm tone source switching signals for European and non-European standards learned by the Adas (Advanced Driver Assistance System); brand / standard alarm tone source switching signals set by the Monitor (sound type monitoring system); and alarm tone on / off signals for the power supply component's STR (sleep / wake-up system) during sleep and wake-up. Furthermore, by configuring their respective dedicated adapters, such as WarningAdapter (warning system adapter), TTAdapter (telltale system adapter), TCAdapter (charging system adapter), CANAdapter (vehicle network adapter), and AdasAdapter (advanced driver assistance system adapter), these external multi-source alarm tone signals are interfaced and differentiated. The differentiated signals are processed into unified interface signals and sent to the sound alarm management module to trigger the start or stop of the alarm tone.

[0024] The unified interface signals processed by the escape sequence include alarm event types (such as battery failure, collision warning, abnormal lighting, etc.), operation commands (start alarm or stop alarm), priority base values ​​(0-7, 7 being the highest), playback requirements (number of times, interval, whether to loop), adaptation conditions (power status, brand / standard, whether it can be interrupted), and identification information (signal source identifier, trigger timestamp), etc. Through standardized escape sequences using a dedicated adapter, signals with varying formats, meanings, and sources are transformed into a unified structure. This preserves the core information of the alarm event while eliminating the impact of differences on downstream modules, laying the foundation for centralized control of the subsequent sound alarm management module.

[0025] In step S2, the sound alarm management module is mainly responsible for controlling the start and stop of alarm sounds, signal synthesis, rule matching, and arbitration event generation. Specifically, after the sound alarm signal processing module sends the escaped unified interface signal to the sound alarm management module, the sound alarm management module will parse the unified interface signal and start / stop the alarm according to the parsed operation instructions. Specifically, when stopping the alarm, the currently playing alarm sound will be stopped by using the signal source identifier. When starting the alarm, the contact information is integrated and transformed into an alarm sound signal format that better meets the playback requirements.

[0026] In one embodiment, the parsed information is mapped to a standard alarm tone signal, which includes 64-bit alarm tone ID data and 8-bit attribute data. The 64-bit alarm tone ID data is defined as typedef unsigned long long chime_id_t, divided into eight bytes, and the data description is shown in Table 1 below.

[0027]

[0028] Table 1 The attribute bytes include power status attributes, interruption attributes, recovery attributes, periodic attributes, self-interruption attributes, and adaptation attributes. The data descriptions are shown in Table 2 below.

[0029]

[0030] Table 2 Specifically, the attribute bytes of the standard alarm tone signal are determined based on the parsed adaptation information and mapped to the corresponding attribute bits. For example, depending on the urgency of the alarm event and the system design, if interruption by a high-priority alarm tone is permissible, `interrupt` is set to 1; non-emergency alarms such as an unclosed door are typically set to 1, while emergency alarms such as airbag malfunctions are set to 0 to prevent interruption; if the alarm tone needs to resume playback after being interrupted, `recover` is set to 1. For instance, if an unclosed door alarm is interrupted by a high-priority collision warning, the unclosed door alarm should resume playback after the collision warning ends; in this case, `recover` is set to 1.

[0031] Based on the parsed playback demand information, a target playback rule is matched from multiple pre-set playback rules, and the playback count (times) and playback frequency (rate) of the standard alarm tone signal are determined according to the matched target playback rule. In one embodiment, the pre-set playback rules include: playing only once (e.g., playing once and then automatically stopping after button feedback); playing a limited number of times at certain time intervals (e.g., playing 5 times at 3-second intervals for an open door); playing an unlimited number of times at certain time intervals (e.g., playing until the stop signal is triggered when the handbrake is not released); and a long beep with no time interval (e.g., playing until the engine overheats).

[0032] The sequence number byte of the audio source file for the standard alarm tone signal is determined based on a pre-set mapping table between alarm event types and audio source file numbers. For example, in one embodiment, the mapping table is consulted based on the alarm event type (door not closed) to obtain the corresponding WAV audio source file with sequence number 21.

[0033] Finally, the parsed operation command information and the filled standard alarm tone signal are encapsulated in the system's preset binary / structured format to form the final arbitration event sent to the sound alarm arbitration module.

[0034] In step S3, the sound alarm arbitration module is mainly used to receive arbitration events sent by the sound alarm management module and arbitrate the timing of alarm sound playback based on preset priority rules.

[0035] Specifically, when the sound alarm management module generates an arbitration event (containing a standard alarm tone signal, which defines priority and other information) and sends it to the sound alarm arbitration module, the sound alarm arbitration module adds the new alarm tone event to the arbitration queue according to certain rules. In one embodiment, the maximum capacity of the arbitration queue is limited to 20, minimizing system load while meeting functional requirements. The sound alarm arbitration module sorts the alarm tone events to be processed according to the rule of ascending priority and descending sequence number. The priority information is stored in the priority byte of the alarm tone ID. By comparing the priority byte values ​​of different alarm IDs, the priority is determined. The sequence number can be generated based on the alarm tone event reception time; the earlier the reception time, the larger the sequence number. For example, suppose there are three alarm tone events A, B, and C in the current arbitration queue. A has a priority of 3 and a sequence number of 10; B has a priority of 2 and a sequence number of 8; and C has a priority of 3 and a sequence number of 12. After sorting, the queue order will become B, A, C (because A and C have the same priority, C has a larger sequence number and is placed after A).

[0036] When deciding which alarm tone to play, the sound alarm arbitration module retrieves the highest-priority alarm tone event from the head of the arbitration queue and sends it to the sound alarm playback module for playback. Simultaneously, if a new high-priority alarm tone event is received during playback, the sound alarm arbitration module determines whether to interrupt the current playback (based on the attribute bytes in the standard alarm tone signal). If interruption is supported, the sound alarm arbitration module sends an interrupt playback command to the sound alarm playback module, simultaneously recording the interruption position and recovery flag of the currently playing alarm tone (recorded only when the recover bit in the 8-bit attribute is 1). The sound alarm playback module pauses the current alarm tone, releases audio resources, and starts playing the high-priority alarm tone to ensure that important alarm tones are heard by the driver promptly. The interrupted alarm tone is then re-added to the processing queue (if recovery is supported) and reordered according to the sorting rules. For example, if the currently playing alarm tone for "door not closed" (priority 3) is followed by a newly received collision warning (priority 7), the "door not closed" alarm tone is immediately interrupted, the collision warning alarm tone is played first, and the "door not closed" alarm tone is re-added to the queue. This ultimately achieves orderly scheduling of instrument panel sound alarm events across multiple scenarios.

[0037] Furthermore, the sound alarm arbitration module maintains a status record for each received alarm tone event. For example, when an alarm tone event enters the arbitration queue to wait for playback, its status is marked as "waiting." Once the sound alarm arbitration module sends it to the sound alarm playback module and starts playback, the status is immediately updated to "playing." During playback, the sound alarm arbitration module and the sound alarm playback module maintain information exchange. If the sound alarm playback module causes a change in the alarm tone playback status due to some reason (such as receiving an interruption command, playback completion, etc.), it will promptly feed back the status change information to the sound alarm arbitration module, which then updates the status record of the corresponding alarm tone based on the feedback information.

[0038] In step S4, the sound alarm playback module consists of multiple parallel players, each player being an independent slot. These independent slots can support the simultaneous playback of multiple alarm sounds, achieving parallel processing of alarm sound playback. For example, when the vehicle simultaneously detects a forward collision warning (ADAS alarm sound) and a trunk not properly closed (TAILDOOR alarm sound), different players can be responsible for playing the corresponding alarm sounds separately without interfering with each other.

[0039] When the sound alarm playback module receives a playback command from the sound alarm arbitration module, it loads the corresponding audio source file through the file container. Specifically, the file container reads the corresponding WAV format audio source file and obtains relevant PCM data information, including the PCM data size, PCM data address, and the starting address of the WAV file in memory. With this information, the file container can accurately locate and manage the audio data, preparing for subsequent data provision. For example, when a specific alarm tone needs to be played, the file container loads the corresponding WAV file from the pre-stored audio source file library based on the audio source file number provided by the sound alarm management module and parses out the relevant PCM data information. The data provider then obtains the audio data from the file container and provides the PCM data to the sound alarm playback module according to certain formats and requirements. Furthermore, different types of alarm tones may require different data processing methods and supply strategies. The sound alarm playback module selects an appropriate data provider through the provider manager to provide PCM data to the sound alarm playback module.

[0040] The sound alarm playback module then executes playback cycle / interval logic locally. For alarm sounds set to loop or interval playback, the module controls the playback rhythm based on information such as the number of plays (times byte), playback frequency (rate byte), and cycle attribute (cyclebit) in the alarm sound ID. For example, if the alarm sound ID is set to play 5 times and the playback frequency is 1 time per second, the module will play the alarm sound once per second until it has played 5 times.

[0041] In addition to local logic control, the sound alarm playback module also integrates with the global scheduling of the sound alarm arbitration module. The sound alarm arbitration module intervenes and adjusts the loop / interval playback of the sound alarm playback module based on factors such as the priority of the alarm tone and the current system status. For example, when a high-priority alarm tone occurs, the sound alarm arbitration module may pause the currently looping / interval playback of a low-priority alarm tone, prioritizing the high-priority alarm tone. After the high-priority alarm tone finishes playing, the loop / interval playback of the low-priority alarm tone resumes, ensuring that important alarm information is promptly conveyed to the driver.

[0042] In other embodiments, the sound alarm playback module transmits data through a sound alarm adapter module (chime wrapper). This chime wrapper encapsulates the Audio Client interface, isolating the sound alarm system from external components and ensuring compatibility with different external components. The sound alarm playback module sends the processed PCM audio data to the chime wrapper. The chime wrapper, according to the requirements of the Audio Client interface, performs format conversion, timing adjustment, and other processing on the data to make it conform to the receiving standards of the external hardware. The data processed by the chime wrapper is finally transmitted to the audio client module. This module is bound to a specific audio hardware platform. It sends the received PCM data to the audio hardware device, driving amplifiers and other sound-producing components to convert the digital audio signal into a sound signal, thereby achieving the final output of the alarm tone, allowing the driver to hear the corresponding alarm prompt.

[0043] As can be seen, the platform-based instrument panel audible alarm method provided in this application abstracts and platformizes the core functional modules of instrument panel audible alarms, such as signal processing, management, arbitration, and playback. Based on this platform architecture, when adapting to new vehicle models or brands, only hardware binding and interface adaptation need to be adjusted, without reconstructing the core alarm logic. This significantly shortens the development cycle and improves development efficiency. Furthermore, the core modules are uniformly designed and maintained, so subsequent troubleshooting or function upgrades only require targeting specific modules, reducing the maintenance workload and costs across multiple versions and vehicle models. In addition, through clear arbitration rules, precise playback control, and isolated adaptation design, the timeliness and accuracy of alarm sound playback are ensured, providing stable feedback on vehicle status and guaranteeing driving safety.

[0044] Based on the same inventive concept, this application also provides a platform-based instrument sound alarm system. Since the principle of the system in this application is similar to the above-mentioned platform-based instrument sound alarm method in this application, the implementation of the system can refer to the implementation of the method, and the repeated parts will not be described again.

[0045] Based on the same concept of the present invention, the specification is attached. Figure 4 As shown in the figure, an embodiment of this application provides the structure of an electronic device 400, which includes: at least one processor 401, at least one network interface 404 or other user interface 403, memory 405, and at least one communication bus 402. The communication bus 402 is used to realize the connection and communication between these components. The electronic device 400 may optionally include a user interface 403, including a display (e.g., touch screen, LCD, CRT, holographic imaging, or projector, etc.), a keyboard, or a clicking device (e.g., mouse, trackball, touchpad, or touch screen, etc.).

[0046] Memory 405 may include read-only memory and random access memory, and provides instructions and data to processor 401. A portion of memory 405 may also include non-volatile random access memory (NVRAM).

[0047] In some implementations, memory 405 stores executable modules or data structures, or subsets thereof, or extended sets thereof: The 4051 operating system contains various system programs used to implement various basic business functions and handle hardware-based tasks. Application module 4052 contains various applications, such as desktop (launcher), media player (MediaPlayer), browser (Browser), etc., to implement various application services.

[0048] In this embodiment of the application, by calling the program or instructions stored in the memory 405, the processor 401 is used to execute the steps in a platform-based instrument sound alarm method. By constructing a multi-module collaborative system architecture, it can realize unified processing of alarm signals, classified management of playback rules, intelligent arbitration of playback timing, and stable playback output, thereby improving development efficiency and versatility.

[0049] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs steps such as those in a platform-based instrument audible alarm method.

[0050] Specifically, the storage medium can be a general-purpose storage medium, such as a removable disk or hard disk. When the computer program on the storage medium is run, it can execute the aforementioned platform-based instrument sound alarm method.

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

[0052] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0053] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0054] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0055] Finally, it should be noted that the above embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A platform-based instrument audible alarm method, characterized in that, The method is applied to a platform-based instrument sound alarm system, which includes a sound alarm signal processing module, a sound alarm management module, a sound alarm arbitration module, and a sound alarm playback module; the method includes the following steps: The sound alarm signal processing module receives external multi-source alarm sound signals and processes them into a unified interface signal, which is then sent to the sound alarm management module. The sound alarm management module parses the received unified interface signal and starts / stops the alarm based on the parsed signal information. If the alarm is started, the parsed signal information is synthesized into a standard alarm tone signal, and an arbitration event is generated and sent to the sound alarm arbitration module. Based on the sound alarm arbitration module, the arbitration event is executed according to the preset priority rules, and a playback command is generated; The sound alarm playback module plays an alarm sound according to the playback command.

2. The platform-based instrument sound alarm method according to claim 1, characterized in that, in, The received external multi-source alarm tone signals include alarm tone signals from various vehicle systems; By configuring a dedicated adapter, the alarm tone signals of each system are converted into a unified interface signal; the unified interface signal includes alarm event type, operation command, priority base value, playback requirements, and adaptation conditions.

3. The platform-based instrument sound alarm method according to claim 2, characterized in that, The process of synthesizing the parsed signal information into a standard alarm tone signal and generating an arbitration event includes the following steps: The parsed signal information is then filled into each byte of the standard alarm tone signal; the standard alarm tone signal includes the priority byte, type byte, audio source file sequence number byte, attribute byte, playback count byte, playback frequency byte, and reserved byte of the alarm event; The parsed operation instructions and the filled standard alarm tone signal are encapsulated into an arbitration event.

4. The platform-based instrument sound alarm method according to claim 3, characterized in that, in, Start / stop the alarm based on the parsed operation instructions; Based on the pre-set mapping table between alarm event types and audio source file numbers, determine the audio source file number byte of the standard alarm tone signal; The attribute bytes of the standard alarm tone signal are determined based on the parsed adaptation conditions; Based on the parsed playback demand information, the target playback rule is matched from multiple pre-set playback rules, and the playback count and frequency bytes of the standard alarm tone signal are determined according to the matched target playback rule.

5. The platform-based instrument sound alarm method according to claim 4, characterized in that, in, The attribute bytes include power status attributes, interruption attributes, recovery attributes, periodic attributes, self-interruption attributes, and adaptation attributes.

6. The platform-based instrument sound alarm method according to claim 5, characterized in that, The default priority rules are: Arbitration events are sorted according to an ascending priority strategy, with the priority obtained from the priority byte in the standard alarm tone signal; Specifically, arbitration events with the same priority are further sorted according to their reception time; and the alarm sound played for the corresponding arbitration event is interrupted or resumed according to the attribute bytes in the standard alarm sound signal.

7. The platform-based instrument sound alarm method according to claim 6, characterized in that, in, The corresponding audio source file is played through multiple parallel players according to the number of times and frequency of playback in the playback instruction; The audio source file is obtained by the data provider that the supply manager requests to adapt according to the playback command, and the data provider triggers the loading of the file container.

8. A platform-based instrument sound alarm system, characterized in that, It includes a sound alarm signal processing module, a sound alarm management module, a sound alarm arbitration module, and a sound alarm playback module, used to execute the steps of the platform-based instrument sound alarm method as described in any one of claims 1 to 7.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of the platform-based instrument sound alarm method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the platform-based instrument sound alarm method as described in any one of claims 1 to 7.

Images