Method for monitoring operation state of operation entity under AUTOSAR CP framework
By initializing the running entity monitoring module under the AUTOSAR CP framework, recording and comparing the timing relationship of the running entity, the functional delay or confusion caused by the timing disorder of the running entity in the AUTOSAR CP system is solved, and effective monitoring of the running status and problem discovery is achieved.
Patent Information
- Application Number
- CN202510144701.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-02-10
- Publication Date
- 2025-05-30
AI Technical Summary
In the AUTOSAR CP system, timing disorders of the running entity may cause delay in vehicle function response time or confusion in function actions. The existing WdgM module cannot effectively monitor the operating status of the running entity.
Provide a method under the AUTOSAR CP framework, by initializing the running entity monitoring module, setting the running entity number and test point number, recording the running timing relationship and parameter status, and comparing whether the actual measured timing is consistent with the expected timing, so as to monitor and record the running status.
Effectively monitoring the execution sequence between multiple running entities and recording the status of running entities when they do not match the expected timing, which helps to discover potential software problems in the software development stage and improves the probability of problem discovery.
Smart Images
Figure CN120066893A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of automotive software testing, and specifically refers to a method, system, device, processor and computer-readable storage medium for implementing running state monitoring for running entities under the AUTOSAR CP framework. Background Art
[0002] In vehicle-mounted controllers, high requirements are placed on real-time performance. The controller needs to ensure that all functions can operate in the expected state. With the development of automotive electronics, the functions of the controller are becoming more and more complex, and the operating system needs to schedule more and more tasks. It is very difficult to ensure that all tasks or running entities can operate in the expected state. Especially in the development stage, many potential software problems are difficult to discover.
[0003] In the AUTOSAR CP (AUTOSAR Classic Platform) system, when multiple running entities execute, the processing timing may be disrupted due to interrupts or task preemption mechanisms. The timing disorder of running entities may cause delays in vehicle function response times and even chaotic function actions. In the existing technology, the Logical Supervision mechanism of the WdgM (WatchdogManager) module in the AUTOSAR CP standard can also monitor the execution timing flow of the code logic of the monitored entity, but it is mainly used to monitor the execution order of the code logic and cannot monitor the running state of the running entity when a timing error occurs. As a standard module, it is also very difficult to expand functions, and it is impossible to monitor the state when an error occurs while detecting a timing error. It is not very convenient to debug software timing in the software development stage using the WdgM module. Summary of the Invention
[0004] The object of the present invention is to overcome the above-mentioned disadvantages of the prior art and provide a method, system, device, processor and computer-readable storage medium for implementing running state monitoring for running entities under the AUTOSAR CP framework.
[0005] In order to achieve the above object, the method, system, device, processor and computer-readable storage medium for implementing running state monitoring for running entities under the AUTOSAR CP framework of the present invention are as follows:
[0006] The method for implementing running state monitoring for running entities under the AUTOSAR CP framework is mainly characterized in that the method includes the following steps:
[0007] (1) Initialize the running entity monitoring module, set the running entity number and test point number, initialize the list of parameters to be recorded, set the expected running timing diagram, as well as the single monitoring duration and the number of measurements, and start the running entity monitoring;
[0008] (2) Call the test point recording function respectively through the C / S interface of the RTE at the beginning and end of the monitored running entity, and record the sequential relationship of the running entity during operation, the running-time values of the custom parameters to be measured, and the timestamps of the test points.
[0009] (3) Continuously monitor the running time sequence of the running entity according to the set monitoring duration.
[0010] (4) After the monitoring time ends, compare whether the measured running time sequence is consistent with the expected time sequence. If it is consistent, do not record the current state of the running entity. Otherwise, record the current running time sequence, and record the parameter status and timestamps at each test point to troubleshoot the reasons for the deviation of the time sequence.
[0011] Preferably, the step (1) is specifically as follows:
[0012] The running entity number is the unique number of the monitored running entity.
[0013] The test point number is the test number called at the very front and very end of the monitored running entity respectively.
[0014] The parameter list to be recorded is used to record the real-time state of the running entity when a time sequence error occurs according to the specific functions of the monitored entity; and
[0015] The time sequence expectation graph is stored in a tree structure.
[0016] Preferably, in step (1), when starting to monitor the running entity, it is necessary to start from the first test point to ensure that each measurement has the same starting point; after each monitoring execution is completed, it is necessary to wait until running to the first test point before starting the next monitoring.
[0017] Preferably, the step (2) is specifically as follows:
[0018] At the beginning and end positions of the running entity, call the test point recording function respectively through the C / S interface of the RTE. When each time the test point recording function is called, record the number of the monitored running entity, the test point number, the running-time values of the custom parameters to be measured, and the timestamp of the test point for this call, and store them in a linear list according to the execution order, where the measured time sequence of the running entity will be recorded in sequence.
[0019] Preferably, the step (4) specifically includes the following steps:
[0020] After the described running entity completes the monitoring process, further determine whether the current monitoring time has ended. If it has ended, proceed to step (4.2); otherwise, proceed to step (4.4).
[0021] (4.2) Compare whether the measured running time series of the current running entity is consistent with the expected running time series. If it is consistent, proceed to step (4.3); otherwise, proceed to step (4.4).
[0022] (4.3) Record the current measured running time series and the real-time status recorded at each test point.
[0023] (4.4) Determine whether the current number of monitoring times is full. If not, return to step (1) for loop monitoring; otherwise, stop monitoring.
[0024] Preferably, after the monitoring is stopped in step (4), read the stored linear list data that does not meet the expected time series, compare the difference between the order of the linear list and the expected order, and analyze the reason for the deviation of the time series based on the recorded parameter data.
[0025] Preferably, the expected time series will be adjusted in real time according to the real-time running situation of the running entity.
[0026] The system for implementing the running status monitoring of a running entity under the AUTOSAR CP framework for implementing the above-mentioned method is characterized in that the system includes:
[0027] A running entity monitoring module, which is set in the ASW layer of the AUTOSAR CP framework and is used to provide test point recording services;
[0028] Several SWCs, which are set in the ASW layer of the AUTOSAR CP framework and are used to place the running entity; and
[0029] The RTE layer and the BSW layer of the AUTOSAR CP framework.
[0030] Preferably, the test point recording service is added with the C / S interface of the RTE layer and used as the Server interface. The monitored running entity sets test points using the test point recording service of the running entity monitoring module by calling the C / S interface. At this time, the monitored entity side of the system is the Client interface.
[0031] Preferably, the following data interactions occur in the test point recording service:
[0032] Running entity number, test point number, and the parameter status that the monitored entity needs to record.
[0033] Preferably, when invoking the test point recording service, the running entity monitoring module will record the timestamp simultaneously for analyzing the execution time of the running entity. When a timing error occurs in the running entity under test, precise timing analysis will be performed based on the call time points of each recorded test point.
[0034] The device for implementing running state monitoring for a running entity under the AUTOSAR CP framework is mainly characterized in that the device includes:
[0035] A processor configured to execute computer-executable instructions;
[0036] A memory storing one or more computer-executable instructions, which, when executed by the processor, implement the steps of the method for implementing running state monitoring for a running entity under the above-mentioned AUTOSAR CP framework.
[0037] The processor for implementing running state monitoring for a running entity under the AUTOSAR CP framework is mainly characterized in that the processor is configured to execute computer-executable instructions, which, when executed by the processor, implement the steps of the method for implementing running state monitoring for a running entity under the above-mentioned AUTOSAR CP framework.
[0038] The computer-readable storage medium is mainly characterized in that a computer program is stored thereon, and the computer program can be executed by a processor to implement the steps of the method for implementing running state monitoring for a running entity under the above-mentioned AUTOSAR CP framework.
[0039] By adopting the method, system, device, processor, and computer-readable storage medium for implementing running state monitoring for a running entity under the AUTOSAR CP framework of the present invention, through real-time monitoring of the running state of the running entity, the execution order between multiple running entities can be effectively monitored, and the parameter status of each test point of the running entity that does not conform to the expected timing can be recorded, which is beneficial to discovering some potential software problems in white-box testing, thereby effectively increasing the probability of discovering problems. BRIEF DESCRIPTION OF THE DRAWINGS
[0040] Figure 1 It is a flowchart of the method for implementing running state monitoring for a running entity under the AUTOSAR CP framework of the present invention.
[0041] Figure 2 It is a schematic structural diagram of the system for implementing running state monitoring for a running entity under the AUTOSAR CP framework of the present invention.
[0042] Figure 3Schematic diagram of the storage structure of the timing expectation diagram of the present invention.
[0043] Figure 4 Schematic diagram of the present invention for comparing the measured operating timing with the expected timing.
[0044] Figure 5 Schematic diagram of the operating entity of the present invention executing in the expected order.
[0045] Figure 6 Schematic diagram of the execution of the present invention in case of timing errors. Detailed implementation manners
[0046] In order to more clearly describe the technical content of the present invention, the following will be further described in conjunction with specific embodiments.
[0047] Before detailing the embodiments according to the present invention, it should be noted that, hereinafter, the terms "comprising", "including" or any other variants are intended to cover non-exclusive inclusion, such that a process, method, article or device comprising a series of elements not only includes those elements but also includes other elements not expressly listed, or elements inherent to such process, method, article or device.
[0048] Based on the AUTOSAR CP architecture, this technical solution provides a method for monitoring the execution timing flow of each operating entity, which can monitor the execution timing of each measured operating entity in real time during software operation and record the real-time state of the operating entity when the measured operating timing is inconsistent with the expected timing.
[0049] Please refer to Figure 1 As shown, the method for implementing the running state monitoring for the operating entity under the AUTOSAR CP framework, wherein the method includes the following steps:
[0050] (1) Initialize the operating entity monitoring module, set the operating entity number and test point number, initialize the list of parameters to be recorded, set the timing expectation diagram, the single monitoring duration and the number of measurements, and start the operating entity monitoring;
[0051] (2) Call the test point recording function respectively through the C / S interface of the RTE at the start and end of the monitored operating entity, and record the sequence relationship of the operating entity during operation, the runtime values of the custom parameters to be measured, and the timestamps of the test points;
[0052] (3) Continuously monitor the operating timing of the operating entity according to the set monitoring duration;
[0053] (4) After the monitoring time ends, compare whether the measured running timing is consistent with the expected timing. If it is consistent, do not record the current state of the running entity. Otherwise, record the current running timing, and record the parameter status and timestamp at each test point to troubleshoot the reason for the timing deviation.
[0054] As a preferred embodiment of the present invention, step (1) is specifically as follows:
[0055] The running entity number is the unique number of the monitored running entity;
[0056] The test point number is the test number called at the very front and the very end of the monitored running entity respectively;
[0057] The parameter list to be recorded is used to record the real-time state of the running entity when a timing error occurs according to the specific function definition of the monitored entity; and
[0058] The timing expectation diagram is stored in a tree structure.
[0059] As a preferred embodiment of the present invention, in step (1) when starting to monitor the running entity, it is necessary to start from the first test point to ensure that each measurement has the same starting point; after each monitoring execution is completed, it is necessary to wait until running to the first test point before starting the next monitoring.
[0060] As a preferred embodiment of the present invention, step (2) is specifically as follows:
[0061] At the start and end positions of the running entity, call the test point recording function through the C / S interface of RTE. When each time the test point recording function is called, record the number of the monitored running entity, the test point number, the running time value of the custom parameter to be measured, and the timestamp of the test point, and store them in a linear list according to the execution order, where the measured timing of the running entity will be recorded in sequence.
[0062] As a preferred embodiment of the present invention, step (4) specifically includes the following steps:
[0063] (4.1) After the running entity completes the monitoring process, further determine whether the current monitoring time has ended. If it has ended, enter step (4.2); otherwise, enter step (4.4);
[0064] (4.2) Compare whether the measured running timing of the current running entity is consistent with the expected running timing. If it is consistent, enter step (4.3); otherwise, enter step (4.4);
[0065] (4.3) Record the running time of this actual test and the real-time status of each test point;
[0066] (4.4) Determine whether the current monitoring times are full. If not, return to step (1) to perform cyclic monitoring. Otherwise, stop monitoring.
[0067] As a preferred embodiment of the present invention, after the monitoring in step (4) is stopped, the stored linear table data that does not conform to the expected timing is read, the difference between the order of the linear table and the expected order is compared, and the cause of the timing deviation is analyzed based on the recorded parameter data.
[0068] As a preferred implementation mode of the present invention, the expected timing will be adjusted in real time according to the real-time operation status of the operation entity.
[0069] See also Figure 2 As shown, as a preferred embodiment of the present invention, the system for implementing running status monitoring for running entities under the AUTOSAR CP framework, wherein the system includes:
[0070] The running entity monitoring module is set in the ASW layer of the AUTOSAR CP framework to provide test point recording services;
[0071] A plurality of SWCs, arranged in the ASW layer of the AUTOSAR CP framework, for placing the operating entities; and
[0072] The RTE layer and the BSW layer of the AUTOSAR CP framework.
[0073] As a preferred embodiment of the present invention, the test point recording service adds a C / S interface of the RTE layer and uses it as the Server interface. The monitored running entity sets the test point by calling the C / S interface and using the test point recording service of the running entity monitoring module. At this time, the monitored entity of the system is the Client interface.
[0074] As a preferred embodiment of the present invention, the test point recording service undergoes the following data interaction:
[0075] The running entity number, test point number and parameter status of the monitored entity that need to be recorded.
[0076] As a preferred embodiment of the present invention, when calling the test point recording service, the running entity monitoring module will simultaneously record a timestamp for analyzing the execution time of the running entity. When a timing error occurs in the running entity under test, accurate timing analysis will be performed through the recorded calling time points of each test point.
[0077] The technical solution will be further described in detail below:
[0078] This technical solution is implemented based on the AUTOSAR CPOS architecture. Figure 1 As shown in the figure, the running entity monitoring module is defined in the ASW layer (application software layer) of AUTOSAR CP. The monitoring module provides a test point recording service, which is added to the C / S (Client / Server) interface of RTE and serves as a Server interface. The monitored running entity sets the test point by calling this C / S interface and using the test point recording service of the monitoring module. At this time, the monitored entity is the Client interface.
[0079] In the test point recording service, three main data interactions occur:
[0080] (1) Operation entity number;
[0081] (2) Test point number;
[0082] (3) The parameter status of the monitored entity that needs to be recorded;
[0083] When calling the test point recording service, the monitoring module will also record the timestamp for analyzing the execution time of the running entity. This timestamp can be implemented through the Gpt (generic timer) module in the AUTOSAR standard. It is mainly used to record the calling time points of each test point when a timing error occurs in the running entity under test, thereby more accurately analyzing the timing problem.
[0084] The monitoring sequence of the running entity running status monitoring module is as follows: Figure 2 As shown:
[0085] Step 1: Initialize the running entity monitoring module, set the running entity number, each monitored running entity has a unique number; set the test point number, each running entity has two test points, which are called at the beginning and the end of the monitored running entity respectively; initialize the parameter list to be recorded, this parameter list can be defined according to the specific functions of the monitored entity, and is used to record the real-time status of the running entity when the timing error occurs; set the running timing expectation diagram, such as Figure 3 As shown, the timing expectation diagram is stored in a tree structure; the single monitoring duration and the number of measurements are set. The single monitoring duration is determined according to the specific function. Since the storage resources in the chip are limited, the time is generally in milliseconds, and the number of measurements is also determined according to the actual storage resources;
[0086] Step 2: Start the running entity monitoring. When starting, you need to start from the first test point to ensure that each measurement starts from the same starting point. After each monitoring is completed, wait until it reaches the first test point before starting the next monitoring.
[0087] Step 3: Call the test point recording function respectively through the C / S interface of RTE at the beginning and end of the running entity. Each time the test point recording service is called, record the number of the monitored running entity, the test point number, the runtime value of the custom parameter to be measured, and the timestamp of the test point for this call, and store them in a linear list in the execution order. As Figure 4 shown, the actual measured time sequence will be recorded in order;
[0088] Step 4: Continuously monitor the running state of the running entity according to the set monitoring duration;
[0089] Step 5: After the monitoring time ends, compare whether the recorded actual measured running time sequence is consistent with the expected time sequence. Since the expected time sequence is stored in the form of a tree diagram, while the actual measured running time sequence is a linear list stored in chronological order and may not be exactly equal, only the logical execution order before and after is compared during the comparison; when the actual measured time sequence is inconsistent with the expected time sequence, store the linear list data of this monitoring. As Figure 4 shown, the execution order is recorded in the form of a linear list. For the previous test point in the logical order of test point 3, it is test point 1, while Figure 3 in the expected time sequence diagram shown, the previous test point in the logical order of test point 3 is test point 2. Since their logical orders are inconsistent, the abnormal result of this measurement will be returned at this time, and the linear list data of this measurement will be stored; when all the logical orders of the actual measured time sequence conform to the expected running time sequence, this status will not be recorded;
[0090] Step 6: When the set monitoring times have not been reached, execute the steps described in Step 2 - Step 5 again. When the set monitoring times have been reached, stop the monitoring;
[0091] Step 7: After the monitoring stops, read out the stored linear list data that does not conform to the expected time sequence through the emulator or other means, compare the difference between the order of the linear list and the expected order, and analyze the reason for the difference based on the recorded parameter data. As Figure 3 shown in the expected execution order, it can be obtained that the running entity is expected to execute in the order as Figure 5 shown. Compare the actual measured running time sequence as Figure 4 shown with the expected time sequence as Figure 3 shown, and it can be obtained that in the actual measured monitoring diagram as Figure 4 shown, there is a situation as Figure 6The execution order shown, where the monitored running entity 2 does not wait for the monitored running entity 1 to complete execution before executing, but interrupts the processing of the monitored running entity 1, waits for the monitored entity 2 to complete execution, and then resumes the processing of the monitored running entity 1. Thus, it can be easily inferred from the linear list of monitoring records the real-time running situation of the running entity, providing a more concrete reference for the analysis of software problems; since all situations may not be considered clearly when setting the expected value, at this time, the expected timing diagram can be adjusted according to the recorded data and measured again.
[0092] In practical applications, this technical solution is based on the AUTOSAR CP architecture. The test point settings for each running entity are implemented through the RTE. The running entity monitoring module belongs to the application layer component of the AUTOSAR CP architecture. The running entity monitoring module provides a test point recording service to the monitored running entity through the RTE C / S interface, and the monitored running entity realizes the setting of test points by calling this C / S interface. According to the execution order of the test points, the test data is recorded, and the data includes the running entity number where the test point is located, the test point number, the monitored custom parameters, and the timestamp.
[0093] When judging the running timing error of the running entity, it includes:
[0094] (1) Preset an expected timing diagram before monitoring, defined in the form of a tree diagram.
[0095] (2) The measured timing diagram will record the execution order and occurrence time of the test points in the form of a linear list.
[0096] (3) Judge the consistency of the comparison results by comparing the logical order of each running entity in the expected timing diagram and the measured record.
[0097] When recording the test data and troubleshooting the running timing error of the running entity, it includes:
[0098] (1) Store the measured linear data table when the expected timing diagram is inconsistent with the measured timing diagram, and discard the measurement results of this time when the expected timing diagram is consistent with the measured timing Figure 1 diagram.
[0099] (2) Infer the actual execution situation of the running entity through the recorded linear list, and analyze the reason for the timing error according to the real-time running state of the recorded parameters.
[0100] The device for realizing the running state monitoring of the running entity under the AUTOSAR CP framework, wherein the device includes:
[0101] A processor configured to execute computer-executable instructions;
[0102] A memory stores one or more computer-executable instructions, and when the computer-executable instructions are executed by the processor, the steps of the method for implementing the running state monitoring for a running entity under the above-mentioned AUTOSAR CP framework are realized.
[0103] A processor for implementing the running state monitoring for a running entity under the AUTOSAR CP framework, wherein the processor is configured to execute computer-executable instructions, and when the computer-executable instructions are executed by the processor, the steps of the method for implementing the running state monitoring for a running entity under the above-mentioned AUTOSAR CP framework are realized.
[0104] A computer-readable storage medium, on which a computer program is stored, and the computer program can be executed by a processor to realize the steps of the method for implementing the running state monitoring for a running entity under the above-mentioned AUTOSAR CP framework.
[0105] The method for monitoring the running state of a running entity according to the technical solution of the present invention is mainly used in the software white box testing stage. Since a certain vehicle function generally requires the cooperation of multiple modules in software implementation, the present invention can check whether there are abnormal timing errors when all the running entities associated with a certain function are running, and can record the running states of each running instance when an abnormal timing occurs.
[0106] Some of the function abnormalities caused by timing problems are low-probability abnormal events, which are difficult to capture through intuitive observation or by some test instruments with low accuracy, and even if captured, it is difficult to analyze the cause of the problem. Through the present invention, the probability of discovering problems can be increased to a certain extent, and the cause of the problem can be found more easily.
[0107] Any process or method description shown in the flowchart or described in other ways herein can be understood as representing a module, segment, or part of code including one or more executable instructions for implementing a specific logical function or process, and the scope of the preferred embodiments of the present invention includes additional implementations, in which the functions can be executed in a substantially simultaneous manner or in a reverse order according to the involved functions, rather than in the order shown or discussed, and this should be understood by those skilled in the technical field to which the embodiments of the present invention belong.
[0108] It should be understood that each part of the present invention can be implemented by hardware, software, firmware, or a combination thereof. In the above-mentioned embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution device.
[0109] Those of ordinary skill in the art can understand that all or part of the steps carried out in implementing the above-described embodiment methods can be completed by a program instructing relevant hardware. The program can be stored in a computer-readable storage medium, and when the program is executed, it includes one or a combination of the steps of the method embodiment.
[0110] The above-mentioned storage medium can be a read-only memory, a magnetic disk, an optical disc, or the like.
[0111] In the description of this specification, the description with reference to terms such as "one embodiment", "some embodiments", "example", "specific example", or "embodiment" means 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. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in a suitable manner in any one or more embodiments or examples.
[0112] Although the embodiments of the present invention have been shown and described above, it can be understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those of ordinary skill in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present invention.
[0113] By adopting the method, system, device, processor, and computer-readable storage medium for implementing the running state monitoring of running entities under the AUTOSAR CP framework of the present invention, by monitoring the running state of running entities in real time, the execution order between multiple running entities can be effectively monitored, and the parameter status of each test point of the running entity when it does not conform to the expected time sequence can be recorded, which is beneficial to discovering some potential software problems in white-box testing, thereby effectively increasing the probability of discovering problems.
[0114] In this specification, the present invention has been described with reference to its specific embodiments. However, it is obvious that various modifications and transformations can still be made without departing from the spirit and scope of the present invention. Therefore, the specification and the drawings should be regarded as illustrative rather than restrictive.
Claims
1. A method for implementing running status monitoring for a running entity under the AUTOSAR CP framework, characterized in that: The method comprises the following steps: (1) Initialize the running entity monitoring module, set the running entity number and test point number, initialize the list of parameters to be recorded, set the running sequence expectation diagram and the single monitoring duration and number of measurements, and start the running entity monitoring; (2) At the beginning and end of the monitored running entity, the test point recording function is called through the C / S interface of the RTE, and the sequence relationship of the running entity during operation, the running value of the custom parameter to be tested, and the timestamp of the test point are recorded; (3) continuously monitoring the operating timing of the operating entity according to a set monitoring duration; (4) After the monitoring time is over, compare the measured operating timing with the expected timing to see if they are consistent. If they are consistent, the current state of the operating entity is not recorded. Otherwise, the current operating timing is recorded, and the parameter state and timestamp at each test point are recorded to troubleshoot the cause of the timing deviation.
2. The method for implementing operation status monitoring for an operation entity under the AUTOSAR CP framework according to claim 1, characterized in that: The step (1) is specifically as follows: The operating entity number is the unique number of the monitored operating entity; The test point numbers are the test numbers called at the very beginning and the very end of the monitored running entity respectively; The list of parameters to be recorded is used to record the real-time status of the running entity when a timing error occurs according to the specific functional definition of the monitored entity; and The timing expectation graph is stored in a tree structure.
3. The method for implementing operation status monitoring for an operation entity under the AUTOSAR CP framework according to claim 1, characterized in that: When starting the entity monitoring, the step (1) needs to start from the first test point to ensure that each measurement has the same starting point; after each monitoring is completed, it is necessary to wait until the first test point is reached before starting the next monitoring.
4. The method for implementing operation status monitoring for an operation entity under the AUTOSAR CP framework according to claim 1, characterized in that: The step (2) is specifically as follows: At the beginning and end positions of the running entity, the test point recording function is called respectively through the C / S interface of the RTE. Each time the test point recording function is called, the number of the monitored running entity, the test point number, the runtime value of the customized parameter to be tested and the timestamp of the test point are recorded, and stored in a linear table in the order of execution, wherein the actual measured timing of the running entity will be recorded in sequence.
5. The method for implementing operation status monitoring for an operation entity under the AUTOSAR CP framework according to claim 1, characterized in that: The step (4) specifically comprises the following steps: After the operating entity described in (4.1) completes the monitoring process, it further determines whether the current monitoring time has ended. If so, it proceeds to step (4.2); otherwise, it proceeds to step (4.4); (4.2) Compare the measured running time of the running entity and the expected running time to see if the results are consistent. If they are consistent, proceed to step (4.3); otherwise, proceed to step (4.4); (4.3) Record the running time of this actual test and the real-time status of each test point; (4.4) Determine whether the current monitoring times are full. If not, return to step (1) to perform cyclic monitoring. Otherwise, stop monitoring.
6. The method for implementing operation status monitoring for an operation entity under the AUTOSAR CP framework according to claim 5, characterized in that: When the monitoring in step (4) is stopped, the stored linear table data that does not conform to the expected timing is read, the difference between the order of the linear table and the expected order is compared, and the reason for the timing deviation is analyzed based on the recorded parameter data.
7. The method for implementing operation status monitoring for an operation entity under the AUTOSAR CP framework according to claim 6, characterized in that: The expected timing will be adjusted in real time according to the real-time operation status of the operation entity.
8. A system for implementing the method according to any one of claims 1 to 7 and implementing operation status monitoring for an operation entity under the AUTOSAR CP framework, characterized in that: The system comprises: The running entity monitoring module is set in the ASW layer of the AUTOSAR CP framework to provide test point recording services; A plurality of SWCs, arranged in the ASW layer of the AUTOSAR CP framework, for placing the operating entities; and The RTE layer and the BSW layer of the AUTOSAR CP framework.
9. The system for implementing operation status monitoring for an operation entity under the AUTOSAR CP framework according to claim 8, characterized in that: The test point recording service adds the C / S interface of the RTE layer and uses it as the Server interface. The monitored running entity sets the test point by calling the C / S interface and using the test point recording service of the running entity monitoring module. At this time, the monitored entity of the system is the Client interface.
10. The system for implementing operation status monitoring for an operation entity under the AUTOSAR CP framework according to claim 8, characterized in that: The test point recording service described above undergoes the following data interactions: The running entity number, test point number and parameter status of the monitored entity that need to be recorded.
11. The system for implementing operation status monitoring for an operation entity under the AUTOSAR CP framework according to claim 8, characterized in that: When calling the test point recording service, the running entity monitoring module will simultaneously record the timestamp for analyzing the execution time of the running entity. When a timing error occurs in the running entity under test, accurate timing analysis will be performed through the recorded calling time points of each test point.
12. A device for implementing running status monitoring for a running entity under the AUTOSAR CP framework, characterized in that: The device comprises: a processor configured to execute computer executable instructions; A memory storing one or more computer executable instructions, wherein when the computer executable instructions are executed by the processor, the steps of the method for implementing running status monitoring for a running entity under the AUTOSAR CP framework described in any one of claims 1 to 7 are implemented.
13. A processor for implementing running status monitoring for a running entity under the AUTOSAR CP framework, characterized in that: The processor is configured to execute computer executable instructions. When the computer executable instructions are executed by the processor, the steps of the method for implementing operation status monitoring for an operation entity under the AUTOSAR CP framework described in any one of claims 1 to 7 are implemented.
14. A computer-readable storage medium, characterized in that: A computer program is stored thereon, and the computer program can be executed by a processor to implement the steps of the method for implementing operating status monitoring for an operating entity under the AUTOSAR CP framework described in any one of claims 1 to 7.