Method and device for sending diagnostic data
By using the first parameter and the second parameter to control the transmission of diagnostic data in a heterogeneous multi-core processor, and retransmitting it when a transmission failure is detected, the problem of data transmission failure caused by different real-time characteristics between cores is solved, and the reliability of data transmission is improved.
Patent Information
- Application Number
- CN202510286221.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-11
- Publication Date
- 2025-06-27
AI Technical Summary
In heterogeneous multi-core processors, due to the different real-time characteristics between cores, the diagnostic data transmission fails.
When the diagnostic data is sent to the second core (low real-time) (low real-time) the first parameter and the second parameter control data transmission are used. The second parameter is periodically checked, and when a pending state is detected, the first parameter is further checked. If the first parameter indicates that the data transmission fails, the data is resent and the timeout mechanism is activated on the first resend to control the maximum resend duration.
It effectively solves the problem of data transmission failure caused by different real-time between cores, and improves the reliability of diagnostic data transmission and system resource utilization.
Smart Images

Figure CN120216239A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to automotive diagnostic technologies, and in particular, to a method and device for sending diagnostic data. Background Art
[0002] In automotive electronics, heterogeneous multi-core processors are being widely used. For heterogeneous multi-core processors, inter-core communication is a key technology for realizing multi-core collaborative work. Especially in scenarios involving real-time diagnosis, different processor cores (such as control core M with high real-time requirements and functional core A responsible for application processing) need to complete data interaction through an efficient communication mechanism (such as IPCF, Inter-Processor Communication Framework, inter-core communication framework). However, when core M sends a large amount of diagnostic data to core A, due to the single-transmission capacity limit, the data needs to be split into multiple data packets for batch transmission. During this process, the real-time requirement of core M is significantly higher than that of core A, and its sending rate may far exceed the processing capacity of core A, resulting in the state of the IPCF communication thread instance being unable to switch back from the "occupied (use)" state to the "ready" state in a timely manner, thus causing frequent sending failures of the Ipcf_send interface.
[0003] One solution is to set a timeout to control the data sending. Usually, the size of the timeout is related to the payload of the data packet and is generally set based on experience. However, if the timeout threshold is set too long, the communication thread needs to wait for a long time for the state to switch, resulting in the ineffective occupation of communication link resources (such as buffers, thread instances), and reducing the overall resource utilization rate of the system; if the timeout threshold is set too short, it may trigger misjudgment due to the failure of core A to complete processing in time, resulting in data packet discarding and information loss, affecting diagnostic integrity and system reliability.
[0004] Therefore, there is a need for improvement in the prior art. Summary of the Invention
[0005] A method and device for sending diagnostic data according to an embodiment of the present invention can solve the problem of data sending failure caused by different inter-core real-time requirements.
[0006] A method for sending diagnostic data according to this embodiment includes: when a first core sends diagnostic data to a second core through an inter-core communication mechanism, controlling the sending of the diagnostic data based on a first parameter and a second parameter; wherein, the real-time requirement of the first core is higher than that of the second core; wherein, the first parameter is used to indicate whether the diagnostic data is sent successfully; wherein, the second parameter is periodically checked, when it is checked that the second parameter is a first value, the first parameter is further checked, and when the first parameter indicates that the diagnostic data sending fails, the diagnostic data is resent.
[0007] In some embodiments, when the diagnostic data is resent for the first time, a timeout mechanism is started, and the timeout mechanism is used to control the maximum resending duration of the diagnostic data, and the maximum resending duration is greater than the period for checking the second parameter.
[0008] In some embodiments, when the first parameter indicates that the transmission of the diagnostic data fails and the timeout mechanism has not timed out, the second parameter is maintained as the first value.
[0009] In some embodiments, when the first parameter indicates that the transmission of the diagnostic data is successful or the timeout mechanism times out, the second parameter is set to the second value.
[0010] In some embodiments, when the diagnostic data is sent for the first time, the second parameter is set to the first value.
[0011] In some embodiments, when the size of the diagnostic data is greater than the threshold of a single data packet supported by the inter-core communication mechanism, the diagnostic data is split into multiple data packets for transmission.
[0012] In some embodiments, the first core uses a diagnostic communication manager to send the diagnostic data, and the second parameter is the diagnostic operation status in the diagnostic communication manager. When the second parameter is the first value, it indicates that the diagnostic operation status is pending.
[0013] A multi-core device according to an embodiment of the present invention includes: a first core and a second core. The first core sends diagnostic data to the second core through an inter-core communication mechanism, and the real-time performance of the first core is higher than that of the second core. The first core includes: a diagnostic communication manager, configured to: when sending the diagnostic data to the second core through the inter-core communication mechanism, control the transmission of the diagnostic data based on a first parameter and a second parameter; wherein, the first parameter is used to indicate whether the transmission of the diagnostic data is successful; wherein, the diagnostic communication manager periodically checks the second parameter, and when it is checked that the second parameter is the first value, further checks the first parameter, and when the first parameter indicates that the transmission of the diagnostic data fails, resends the diagnostic data.
[0014] A computer device / apparatus / system according to an embodiment of the present invention includes a memory, a processor, and a computer program stored on the memory. The processor executes the computer program to implement the steps of the method according to an embodiment of the present invention.
[0015] A computer-readable storage medium according to an embodiment of the present invention has a computer program / instructions stored thereon. When the computer program / instructions are executed by a processor, the steps of the method according to an embodiment of the present invention are implemented.
[0016] Advantageous effects of the embodiments of the present invention:
[0017] Control the transmission of diagnostic data according to a first parameter for indicating whether the diagnostic data is successfully transmitted and a second parameter that will be periodically checked. When it is detected that the second parameter is a first value, further detect the first parameter. If the first parameter indicates that the diagnostic data transmission fails, retransmit the diagnostic data, thus solving the problem of data transmission failure caused by different inter-core real-time performances. BRIEF DESCRIPTION OF THE DRAWINGS
[0018] In the drawings, unless otherwise specified, the same reference numerals throughout the several views represent the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments provided in accordance with the present invention and should not be regarded as limiting the scope of the present invention.
[0019] Figure 1 is a schematic structural diagram of an embodiment of the diagnostic system of the present invention;
[0020] Figure 2 is Figure 1 a schematic diagram of the operation flow of the processing interface 2011 in
[0021] Figure 3 is Figure 1 a schematic diagram of the operation flow of the sending interface 2012 in
[0022] Figure 4 a schematic structural diagram of an embodiment of the computer device / equipment / system of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS
[0023] The present invention will be further described in detail below with reference to the drawings. The same reference numerals in the drawings represent elements with the same or similar functions. Although various aspects of the embodiments are shown in the drawings, the drawings do not necessarily need to be drawn to scale unless otherwise specified.
[0024] In addition, for better explaining the present invention, numerous specific details are given in the following detailed description of the embodiments. Those skilled in the art should understand that the present invention can be implemented without some of these specific details. In some instances, methods, means, elements, and circuits well known to those skilled in the art are not described in detail to highlight the gist of the present invention.
[0025] As Figure 1 shown, it is a schematic structural diagram of an embodiment of the diagnostic system of the present invention. The diagnostic system includes: a diagnostic instrument 1 and a multi-core device 2.
[0026] Among them, the diagnostic instrument 1 can be, for example, an external device such as a host computer or a laptop computer, or can be a remote diagnostic device. The multi-core device 2 can be a heterogeneous multi-core processor and can be implemented as various types of ECUs (Electronic Control Units) in a vehicle, including but not limited to: domain controllers (DCUs), zone controllers (ZCUs), and central processing units, etc. The diagnostic instrument 1 can control the multi-core device 2 to execute specific programs or codes, that is, routine control, or read and return the values of specific registers, etc., so as to realize the diagnosis of the multi-core device 2.
[0027] Specifically, the multi-core device 2 can include: a first core 20 and a second core 21. Among them, the real-time performance of the first core 20 is higher than that of the second core 21. For example, the first core 20 is an M core and the second core 21 is an A core. In the figure, the first core 20 and the second core 21 implement data interaction based on the IPCF (Inter-core Communication Framework). Of course, the first core 20 and the second core 21 can also perform data interaction through other inter-core communication mechanisms.
[0028] In the first core 20, it includes: a DCM (Diagnostic Communication Manager) 201 for providing diagnostic communication functions. The diagnostic instrument 1 sends diagnostic data to the DCM 201, and then the DCM 201 sends the diagnostic data to the second core 21 through the IPCF 22, and the second core 21 performs specific diagnostic operations based on the diagnostic data. That is to say, the management function of diagnostic communication is deployed in the first core 20, while the diagnostic operation is deployed in the second core 21. In addition, the diagnostic instrument 1 receives diagnostic result data through the DCM 201. Among them, the above-mentioned diagnostic data includes but is not limited to: routine control data or data read / write instructions, etc. That is to say, routine control or data reading and writing in the multi-core device 2 can be realized by means of diagnosis.
[0029] Specifically, in the DCM 201, it includes: a processing interface 2011 and a sending interface 2012, and both the processing interface 2011 and the sending interface 2012 can be function interfaces. Among them, the processing interface 2011 is used to control the sending of diagnostic data, including the implementation of the retransmission mechanism when the sending fails. The sending interface 2012 is used to perform the specific sending operation of diagnostic data. For example, when the sending interface 2012 is called by the processing interface 2011, it sends the diagnostic data to the second core 21 by calling the IPCF 22 and returns the first parameter to the processing interface 2011 based on the sending result. Among them, the first parameter is used to indicate whether the diagnostic data is sent successfully, which is represented by the send status in the figure.
[0030] In this embodiment, a second parameter is set in the processing interface 2011, and the first parameter (sendstatus) and the second parameter are used to control the sending of diagnostic data, such as retransmission when the sending of diagnostic data fails. Specifically, when sending diagnostic data, the second parameter is set to a first value, and the main program in the DCM201 periodically checks the value of the second parameter. When it is detected that the value of the second parameter is the first value, the main program enters and executes the logic in the processing interface 2011, including: detecting the value of the first parameter, and when it is detected that the first parameter indicates a sending failure, retransmitting the diagnostic data. Therefore, in this embodiment, instead of setting a timeout based on the payload of the data, the main program checks whether the diagnostic data is successfully sent based on the polling period of the second parameter, and triggers retransmission when the sending fails, thereby achieving an effect similar to a dynamic timeout.
[0031] The following combines Figure 2 and 3 to illustrate the specific operation processes of the processing interface 2011 and the sending interface 2012.
[0032] As Figure 2 shown, it is a schematic flow diagram of the operation process of the processing interface 2011, which includes:
[0033] Step S201: Receive diagnostic data from the diagnostic instrument.
[0034] Step S202: Send the diagnostic data.
[0035] In this step, the diagnostic data is sent by calling the sending interface 2012, and the first parameter returned by the sending interface 2012 is obtained.
[0036] Step S203: Set the second parameter to the first value.
[0037] Step S204: Periodically check whether the second parameter is the first value. When it is the first value, execute Step S205.
[0038] Among them, the second parameter can be the diagnostic operation status in the DCM. Setting the second parameter to the first value may mean setting the diagnostic operation status to the pending status. In the DCM, the main function (or main program) periodically polls the function in the pending status. Therefore, when the second parameter is set to the diagnostic operation status, Step S204 will be periodically executed, thereby guiding the program into the subsequent process of this embodiment.
[0039] In addition, before step S202, it is possible to first check whether the diagnostic operation status is the initial state. Only when it is in the initial state, steps S202 and S203 are executed. Because, if the diagnostic operation status is the pending state or other states, it indicates that there is another diagnostic operation currently being executed by the DCM or there are other events. Therefore, the diagnostic data received in step S201 can be added to the processing queue and wait to be processed.
[0040] Step S205: Check the first parameter. When the first parameter indicates that the diagnostic data has been successfully sent, execute step S206. When the first parameter indicates that the diagnostic data sending has failed, execute step S207.
[0041] Step S206: Feed back an indication of successful sending of the diagnostic data to the diagnostic instrument and reset the second parameter. For example, reset the diagnostic operation status to the initial state.
[0042] Step S207: Resend the diagnostic data and start a timer when resending for the first time.
[0043] Among them, the sending interface 2012 can be called again to execute the resending of the diagnostic data. And, it is possible to resend based on the failed data without resending the data that has already been successfully sent.
[0044] Among them, the timer is used to control the maximum resending duration of the diagnostic data.
[0045] Step S208: Determine whether the timer has timed out. If it has timed out, execute step S209. If it has not timed out, execute step S203. At this time, step S203 is to maintain the second parameter as the first value.
[0046] Step S209: Feed back an indication of sending failure to the diagnostic instrument and reset the second parameter.
[0047] In the operation process of this embodiment, when the diagnostic data sending fails, the processing interface 2011 controls the sending of the diagnostic data based on the first parameter and the second parameter. And, the mechanism of this embodiment can make the timeout duration of the diagnostic data dynamically change within the maximum resending duration, so there is no need to set a fixed timeout duration.
[0048] As Figure 3 shown, it is a schematic flow diagram of the operation process of the sending interface 2012, which includes:
[0049] Step S301: Obtain the diagnostic data.
[0050] Step S302: Determine whether the diagnostic data is greater than the size threshold of a single data packet.
[0051] Step S303: When the size of the diagnostic data is greater than the size threshold of a single IPCF data packet, split the diagnostic data into multiple data packets and send them sequentially one by one.
[0052] Step S304: When the size of the diagnostic data is less than the size threshold of a single IPCF data packet, directly call IPCF to send the diagnostic data.
[0053] Step S305: According to the sending result of Step S303 or S304, set the value of the first parameter and return it to the processing interface 2012 (Step S306 or S307).
[0054] In this embodiment, when sending diagnostic data for the first time or re - sending diagnostic data, the Figure 3 process can be adopted. When re - sending diagnostic data, the above - mentioned process can be executed only for the data that failed to be sent.
[0055] The following takes routine control as an example to illustrate the solution of the embodiment of the present invention.
[0056] Taking routine control as an example, two parameters are introduced in DCM:
[0057] Send_status, that is, the first parameter, which is used to indicate whether the diagnostic data is sent successfully.
[0058] Dcm_Op_status, that is, the second parameter, which is used to describe the status of the diagnostic operation. In this embodiment, it involves the initial state (initial) and the pending state (Pending).
[0059] Then the process of this embodiment can include:
[0060] The first step: The diagnostic instrument calls DCM in the M core (such as Figure 1 the processing interface 2011 in
[0061] ) to start the process of sending the routine control data to the A core.
[0062] The second step: Operations involved in the processing interface 2011.
[0063] 2.1, When receiving the diagnostic data, call Dcm_Op_status, where Dcm_Op_status defaults to the initial state.
[0064] 2.2, Judge whether Dcm_Op_status is in the initial state. If so, execute 2.3; if not, execute 2.5.
[0065] 2.3, Call the sending interface 2012 to send the diagnostic data to the A core and receive the Send_status returned by the sending interface 2012.
[0065] 2.4, Set Dcm_Op_status to Pending, and return to step 2.2
[0066] 2.5, Check if the status of Dcm_Op_status is pending. If it is, execute 2.6
[0067] 2.6, Check Send_status. If it is failed, execute 2.7. If it is successful, execute 2.9
[0068] 2.7, Start a countdown timer. When it is executed for the first time, start it and call the sending interface 2012 to resend the diagnostic data. It can be resent from the broken point and obtain Send_status
[0069] 2.8, Check if the countdown timer is greater than 0. If it is, maintain the Dcm_Op_status as pending and return to 2.2 / 2.5. If it is not (i.e., the countdown reaches), return a failure indication to the diagnostic instrument
[0070] 2.9, Return a sending success indication to the diagnostic instrument
[0071] Step 3: Operations involved in the sending interface 2012
[0072] 3.1, When called, check if the length of the diagnostic data to be sent is greater than the length of a single IPCF packet. If it is less, execute 3.2. If it is greater, execute 3.3
[0073] 3.2, Send the diagnostic data to Core A through IPCF. If the sending is successful, return an indication that Send_status = success. Otherwise, return an indication that Send_status = failure
[0074] 3.3, Unpack the diagnostic data and send each data packet to Core A through IPCF in sequence. When all sendings are successful, return an indication that Send_status = success. When any data packet sending fails, return an indication that Send_status = failure, and save the failure point for continued sending from the failure point when it is called again
[0075] In this embodiment, the Dcm_Op_status parameter existing in DCM is used to control the sending of diagnostic data, such as resending. That is, the standard interface and parameters of DCM in AUTOSAR are used to implement the sending of diagnostic data, which can improve the software reuse efficiency. And the method of this embodiment reduces the technical standard for IPCF and does not require implementing a complex timeout retransmission mechanism after sending fails
[0076] Such as Figure 4As shown, it is a schematic structural diagram of an embodiment of the computer device / apparatus / system 4 of the present invention, which includes: a memory 40, a processor 42, and a computer program or instruction stored on the memory 40, and the processor 42 executes the computer program to implement the method of the embodiment of the present invention.
[0077] In addition, an embodiment of the present invention also provides a computer-readable storage medium, on which a computer program / instruction is stored, and when the computer program / instruction is executed by a processor, the steps of the method of the embodiment of the present invention are implemented.
[0078] In addition, an embodiment of the present invention also provides a computer program product, including a computer program / instruction, and when the computer program / instruction is executed by a processor, the steps of the method of the embodiment of the present invention are implemented.
[0079] In an embodiment of the present invention, if the memory and the processor are implemented independently, the memory and the processor can be interconnected through a bus and communicate with each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc.
[0080] Optionally, in specific implementation, if the memory and the processor are integrated on a chip, the memory and the processor can communicate with each other through an internal interface.
[0081] It should be understood that the above-mentioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc. It is worth noting that the processor can be a processor supporting the Advanced RISC Machines (ARM) architecture.
[0082] Further, optionally, the above-mentioned memory may include a read-only memory and a random access memory, and may further include a non-volatile random access memory. The memory may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may include a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may include a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available. For example, static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchlink dynamic random access memory (SLDRAM), and direct rambus random access memory (DR RAM).
[0083] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present invention are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, computer, server, or data center to another website, computer, server, or data center in a wired manner (such as coaxial cable, optical fiber, Digital Subscriber Line (DSL)) or wirelessly (such as infrared, Bluetooth, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer, or a data storage device such as a server or data center that includes one or more integrated available media. The available medium can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a Digital Versatile Disc (DVD)), or a semiconductor medium (such as a Solid State Disk (SSD)), etc. It should be noted that the computer-readable storage medium mentioned in the present invention can be a non-volatile storage medium, in other words, it can be a non-transitory storage medium.
[0084] Those of ordinary skill in the art can understand that all or part of the steps for implementing the above embodiments can be completed by hardware, or can be completed by a program instructing relevant hardware. The program can be stored in a computer-readable storage medium, and the storage medium mentioned above can be a read-only memory, a magnetic disk, or an optical disc, etc.
[0085] In the description of the embodiments of the present invention, the descriptions referring to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples", etc., mean that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present invention. Moreover, the specific features, structures, materials, or characteristics described can be combined in a suitable manner in any one or more embodiments or examples. In addition, without contradiction, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples.
[0086] In the description of the embodiments of the present invention, unless otherwise specified, " / " means "or". For example, A / B may mean A or B. "And / or" herein is merely a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B may mean: A exists alone, A and B exist simultaneously, and B exists alone.
[0087] In the description of the embodiments of the present invention, the terms "first" and "second" are only used for descriptive purposes and cannot be construed as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of such features. In the description of the embodiments of the present invention, unless otherwise specified, "a plurality of" means two or more.
[0088] The above are only exemplary embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention shall be included within the protection scope of the present invention.
Claims
1. A method for sending diagnostic data, characterized in that: include: When the first core sends diagnostic data to the second core through the inter-core communication mechanism, based on the first parameter and the second parameter, controlling the sending of the diagnostic data; Among them, the real-time performance of the first core is higher than that of the second core; Wherein, the first parameter is used to indicate whether the diagnostic data is sent successfully; The second parameter is periodically checked, and when it is checked that the second parameter is the first value, the first parameter is further checked, and when the first parameter indicates that the diagnostic data has failed to be sent, the diagnostic data is resent.
2. The method for sending diagnostic data according to claim 1, characterized in that: When the diagnostic data is retransmitted for the first time, a timeout mechanism is started, and the timeout mechanism is used to control the maximum retransmission time length of the diagnostic data, and the maximum retransmission time length is greater than the period of checking the second parameter.
3. The method for sending diagnostic data according to claim 2, characterized in that: When the first parameter indicates that the diagnostic data fails to be sent and the timeout mechanism has not timed out, the second parameter is maintained at the first value.
4. The method for sending diagnostic data according to claim 2, characterized in that: When the first parameter indicates that the diagnostic data is sent successfully or the timeout mechanism times out, the second parameter is set to a second value.
5. The method for sending diagnostic data according to claim 1, characterized in that: When the diagnostic data is sent for the first time, the second parameter is set to the first value.
6. The method for sending diagnostic data according to claim 1, characterized in that: When the size of the diagnostic data is greater than a threshold of a single data packet supported by the inter-core communication mechanism, the diagnostic data is split into multiple data packets for transmission.
7. The method for sending diagnostic data according to claim 1, characterized in that: The first core uses the diagnostic communication manager to send the diagnostic data, and the second parameter is the diagnostic operation state in the diagnostic communication manager. When the second parameter is a first value, it indicates that the diagnostic operation state is in a pending state.
8. A multi-core device, comprising: The first core and the second core, the first core sends the diagnostic data to the second core through an inter-core communication mechanism, and the real-time performance of the first core is higher than that of the second core, and the first core includes: a diagnostic communication manager, configured to: when sending the diagnostic data to the second core through the inter-core communication mechanism, control the sending of the diagnostic data based on the first parameter and the second parameter; Wherein, the first parameter is used to indicate whether the diagnostic data is sent successfully; The diagnostic communication manager periodically checks the second parameter, and when it is checked that the second parameter is the first value, further checks the first parameter, and when the first parameter indicates that the diagnostic data transmission fails, resends the diagnostic data.
9. A computer device / equipment / system comprising a memory, a processor and a computer program stored in the memory, characterized in that: The processor executes the computer program to implement the steps of the method according to any one of claims 1 to 7.
10. A computer-readable storage medium having a computer program / instruction stored thereon, characterized in that: When the computer program / instructions are executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.