Vehicle control system and vehicle

Abstract

The invention relates to the technical field of automatic testing, and discloses a vehicle control system and a vehicle, the vehicle control system comprises an operating system abstraction layer OSAL, a task queue abstraction layer and a software layer, the operating system abstraction layer comprises an interface of a packaged real-time operating system, and the task queue abstraction layer comprises a task queue abstraction layer and a software layer; the task queue abstraction layer communicates with the software layer through an interface provided by the task queue abstraction layer; the OSAL is used for creating a to-be-processed task in the task queue; the task queue abstraction layer is used for determining a target task in the to-be-processed tasks of the task queue in response to a trigger operation for the scheduling interface, and scheduling the target task to the real-time operating system; and the software layer is used for controlling the execution state of the target task through the first state interface. According to the invention, decoupling between the real-time operating system RTOS and the software layer autosar is realized, the testability of the autosar is improved, and the development difficulty of the vehicle control system is further reduced.

Description

Technical Field

[0001] The present invention relates to the field of automated testing technology, and in particular to a vehicle control system and a vehicle. Background Art

[0002] In vehicle control systems, real-time operating system (RTOS) and Autosar (an open automotive software architecture standard) are two important concepts, and RTOS and Autosar are usually used in combination. RTOS is responsible for the scheduling and management of real-time tasks, while Autosar provides a standardized method to organize and manage software components, making the entire system more modular, scalable and reliable.

[0003] However, in relevant vehicle control systems, common RTOS include FreeRTOS, RT-Thread, VXWorks, OSEKOS, Tramline OS, etc. They each have their own advantages and are the best practices in different scenarios. However, except for OSEKOS and Tramline OS, the other RTOS do not support the AutoSAR standard, which limits the applicability of RTOS. In addition, although OSEKOS and Tramline OS support the AutoSAR standard, the kernel coupling between AutoSAR and RTOS is high, which results in AutoSAR not having good testability and increases the difficulty of developing vehicle control systems. Summary of the invention

[0004] In view of this, the present invention provides a vehicle control system and a vehicle to solve the problem that the high coupling between the kernel of Autosar and RTOS leads to the lack of good testability of Autosar and the high difficulty in developing the vehicle control system.

[0005] In a first aspect, the present invention provides a vehicle control system, the system comprising: an operating system abstraction layer OSAL, a task queue abstraction layer and a software layer, wherein the operating system abstraction layer includes an interface of an encapsulated real-time operating system and communicates with the software layer through an interface provided by the task queue abstraction layer;

[0006] OSAL, used to create pending tasks in the task queue;

[0007] The task queue abstraction layer is used to determine the target task from the pending tasks in the task queue in response to the trigger operation on the scheduling interface, and schedule the target task to the real-time operating system;

[0008] The software layer is used to control the execution state of the target task through the first state interface.

[0009] In an optional implementation, OSAL is further used to: encapsulate the interface of the real-time operating system based on the type of the real-time operating system, and provide a task interface, wherein the task interface is used to communicate with the task queue abstraction layer.

[0010] In the embodiment of the present invention, the real-time operating system can be abstracted through OSAL, and the task interface can be provided through OSAL to call the service in the real-time operating system through the task interface, so that the interface of the real-time operating system does not need to be coupled with the upper software layer and other units, thereby realizing the decoupling between the real-time operating system and the software layer, and realizing the self-closed loop of research and development testing when testing the software layer without relying on the real-time operating system. At the same time, the present invention can also be compatible with the real-time operating system that does not originally support the software layer standard, thereby improving the overall compatibility of the vehicle control system.

[0011] In an optional implementation, the task interface includes: a task creation interface, an acquisition interface, and a second state interface;

[0012] Task creation interface, used to create and configure pending tasks in the task queue;

[0013] The acquisition interface is used to obtain the task identifier of the target task from the task queue abstraction layer;

[0014] The second state interface is used to switch the execution state of the target task based on the task queue abstraction layer in response to the switching instruction.

[0015] In an embodiment of the present invention, OSAL can call the services of the real-time operating system by providing a unified task creation interface, acquisition interface, and second state interface, so that when developing and testing the vehicle control system, R&D personnel do not need to have too much knowledge of the relevant development knowledge of the real-time operating system, thereby reducing the difficulty of developing the vehicle control system.

[0016] In an optional implementation, the second state interface includes: a suspend interface and a prepare interface;

[0017] The abort interface is used to switch the execution state of the target task from the running state to the suspended state;

[0018] The prepare interface is used to restore the execution state of the target task from the suspended state to the prepare state, wherein the prepare state is used to indicate that the target task is in a state of waiting for a call.

[0019] In an embodiment of the present invention, OSAL can call the services of the real-time operating system by providing a unified task creation interface, acquisition interface, and second state interface, so that when developing and testing the vehicle control system, R&D personnel do not need to have too much knowledge of the relevant development knowledge of the real-time operating system, thereby reducing the difficulty of developing the vehicle control system.

[0020] In an optional implementation, the task queue abstraction layer includes: a running state interface, a pause state interface, a suspended state interface, and a ready state interface;

[0021] The running state interface is used to switch the execution state of the target task to the running state after being triggered by OSAL;

[0022] The pause state interface is used to switch the execution state of the target task to the pause state after being triggered by OSAL, wherein the pause state is used to indicate that the target task is temporarily stopped due to interference conditions;

[0023] The suspend state interface is used to switch the execution state of the target task to the suspend state after being triggered by OSAL;

[0024] The ready state interface is used to switch the execution state of the target task to the ready state after being triggered by OSAL.

[0025] In the embodiment of the present invention, the task queue abstraction layer may include a state switching interface, so that the OSAL can control the execution state of the target task through the state switching interface, thereby realizing the state migration of the target task.

[0026] In an optional implementation, OSAL is further configured to: trigger a pause state interface when it is detected that the priority of the target task does not satisfy the execution condition.

[0027] In the embodiment of the present invention, it is considered that during the actual operation of the vehicle control system, low-priority pending tasks may be preemptively executed. Therefore, when the real-time operating system detects that there is a high-priority pending task that has not been executed, the current target task can be suspended and the high-priority pending task can be executed, thereby maximizing the utilization of system resources and ensuring the performance of key tasks, and also achieving fair and efficient task scheduling, and improving the response speed and real-time performance of the system.

[0028] In an optional implementation, the task queue abstraction layer includes: a status acquisition interface;

[0029] The status acquisition interface is used to obtain the execution status of the target task in response to the acquisition instruction, and feed the execution status back to the software layer.

[0030] In the embodiment of the present invention, the task queue abstraction layer may include a state switching interface, so that the OSAL can control the execution state of the target task through the state switching interface, thereby realizing the state migration of the target task.

[0031] In an optional implementation, the first state interface includes: an activation interface and a termination interface;

[0032] An activation interface, used to trigger the running state interface of the task queue abstraction layer in response to the activation instruction, so as to switch the execution state of the target task to the running state;

[0033] The termination interface is used to terminate the execution and remove the target task.

[0034] In the embodiment of the present invention, AUTOSAR can control the execution state of the target task through the first state interface, thereby managing and scheduling the target task, thereby improving the overall performance and stability of the vehicle control system.

[0035] In an optional implementation, the tasks to be processed include: test tasks; the system is further used to: generate test instructions according to the functions to be tested, and generate test tasks in response to the test instructions.

[0036] In the embodiment of the present invention, since there is no need to couple the interface of the real-time operating system with upper-level units such as the software layer, decoupling between the real-time operating system and the software layer is achieved, so that a self-closed loop of R&D and testing can be achieved when testing the software layer without relying on the real-time operating system, thereby ensuring that the functions and performance of each layer of software under the software layer architecture meet the standard requirements, thereby improving the reliability and stability of the entire vehicle control system.

[0037] In an optional implementation, the system is further used to: perform test operations on the software layer based on the test task.

[0038] In the embodiment of the present invention, since there is no need to couple the interface of the real-time operating system with upper-level units such as the software layer, decoupling between the real-time operating system and the software layer is achieved, so that a self-closed loop of R&D and testing can be achieved when testing the software layer without relying on the real-time operating system, thereby ensuring that the functions and performance of each layer of software under the software layer architecture meet the standard requirements, thereby improving the reliability and stability of the entire vehicle control system.

[0039] In a second aspect, the present invention provides a vehicle having the vehicle control system of any one of the first aspects.

[0040] In a third aspect, the present invention provides a task management method, which is applied to the vehicle control system of any one of the first aspects above, and the method comprises:

[0041] Generate a test instruction according to the function to be tested, and generate a test task in the task queue abstraction layer in response to the test instruction;

[0042] Based on the test tasks, test the software layer;

[0043] In response to the state control instruction, the execution state of the target task is controlled based on the first state interface of the software layer.

[0044] In a fourth aspect, the present invention provides a computer device, comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the system testing method of the third aspect or any corresponding embodiment thereof by executing the computer instructions.

[0045] In a fifth aspect, the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute the system testing method of the third aspect or any corresponding embodiment thereof.

[0046] In a sixth aspect, the present invention provides a computer program product, comprising computer instructions for causing a computer to execute the system testing method of the third aspect or any corresponding embodiment thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0048] Figure 1 is an architecture diagram of a vehicle control system according to an embodiment of the present invention;

[0049] Figure 2 is an architecture diagram of another vehicle control system according to an embodiment of the present invention;

[0050] Figure 3 is a flow chart of a system testing method according to an embodiment of the present invention;

[0051] Figure 4 is a structural block diagram of a system testing device according to an embodiment of the present invention;

[0052] Figure 5 It is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0053] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0054] In conjunction with the application scenarios on which the execution of the vehicle control system depends, the application scenarios are described here.

[0055] In vehicle control systems, real-time operating system (RTOS) and Autosar (an open automotive software architecture standard) are two important concepts, and RTOS and Autosar are usually used in combination. RTOS is responsible for the scheduling and management of real-time tasks, while Autosar provides a standardized method to organize and manage software components, making the entire system more modular, scalable and reliable.

[0056] However, in relevant vehicle control systems, common RTOS include FreeRTOS, RT-Thread, VXWorks, OSEKOS, Tramline OS, etc. They each have their own advantages and are the best practices in different scenarios. However, except for OSEKOS and Tramline OS, the other RTOS do not support the AutoSAR standard, which limits the applicability of RTOS. In addition, although OSEKOS and Tramline OS support the AutoSAR standard, the kernel coupling between AutoSAR and RTOS is high, which results in AutoSAR not having good testability and increases the difficulty of developing vehicle control systems.

[0057] Based on this, an embodiment of the present invention provides a vehicle control system, which includes: an operating system abstraction layer OSAL, a software layer and a task queue abstraction layer, wherein the operating system abstraction layer includes an interface of an encapsulated real-time operating system, and communicates with the software layer through an interface provided by the task queue abstraction layer. Here, OSAL is used to create pending tasks in the task queue, the task queue abstraction layer is used to determine a target task among the pending tasks in the task queue in response to a trigger operation on a scheduling interface, and schedule the target task to the real-time operating system, and the software layer is used to control the execution state of the target task through a first state interface, thereby achieving decoupling between the real-time operating system RTOS and the software layer Autosar, improving the testability of Autosar, and thereby reducing the difficulty of developing the vehicle control system.

[0058] In this embodiment, a vehicle control system is provided, which can be used for the above-mentioned vehicle. Figure 1 is an architecture diagram of a vehicle control system according to an embodiment of the present invention, such as Figure 1 As shown, the system includes: an operating system abstraction layer OSAL10, a task queue abstraction layer 20 and a software layer 30, wherein the operating system abstraction layer includes an interface of a packaged real-time operating system and communicates with the software layer through an interface provided by the task queue abstraction layer;

[0059] OSAL10, used to create pending tasks in the task queue.

[0060] In an embodiment of the present invention, the above-mentioned OSAL (Operating System Abstraction Layer) is used to encapsulate the RTOS and provide the task interface of the RTOS to the upper-level unit to provide RTOS services to the upper-level unit, thereby reducing the development difficulty when developing the vehicle control system.

[0061] Here, the OSAL may initialize pending tasks in a task queue to wait for a call, wherein the pending tasks may be test tasks for the vehicle control system, for example, test tasks for the software layer.

[0062] The task queue abstraction layer 20 is used to determine a target task among the tasks to be processed in response to a trigger operation on the scheduling interface, and schedule the target task to the real-time operating system.

[0063] In the embodiment of the present invention, the task queue abstraction layer refers to a conceptual model for managing and implementing various scheduling algorithms and scheduling strategies for task queues. The OSAL can implement task scheduling through a scheduler.

[0064] In specific implementation, the task queue abstraction layer provides a scheduling interface task_schedule() for communicating with other hierarchical units in the operating system, and the OSAL can call the target task by triggering the scheduling interface.

[0065] When the task queue includes multiple pending tasks, the target task can be determined based on the priority of the pending tasks, wherein the target task can be the pending task with the highest priority. Specifically, the task queue can be implemented using a priority queue to ensure that the scheduler can find the target task with the highest priority in an O(1) complexity manner.

[0066] The software layer 30 is used to control the execution state of the target task through the first state interface.

[0067] In an embodiment of the present invention, the software layer may be the AUTOSAR layer, wherein the AUTOSAR layer may include AUTOSAR Task, which is a core unit in AUTOSAR for executing tasks. For example, when testing AUTOSAR, a test task may be created based on the OSAL, and the test task may be scheduled to AUTOSARTask for execution through the task queue abstraction layer.

[0068] In addition, the software layer includes a first state interface, through which the execution state of the target task can be controlled, and the task queue abstraction layer can be communicated with to obtain and update the execution state of the target task, thereby realizing the state migration of the target task in Autosar. Here, the execution state can include running state (Running), waiting state (Waiting), suspended state (Suspended) and ready state (Ready), and the state migration is used to indicate the conversion of the execution state.

[0069] It can be known from the above description that in an embodiment of the present invention, the vehicle control system includes: an operating system abstraction layer OSAL, a software layer and a task queue abstraction layer, wherein the operating system abstraction layer contains an interface of an encapsulated real-time operating system and communicates with the software layer through an interface provided by the task queue abstraction layer. Here, OSAL is used to create pending tasks in the task queue, the task queue abstraction layer is used to determine the target task in the pending tasks in the task queue in response to a trigger operation on the scheduling interface, and schedule the target task to the real-time operating system, and the software layer is used to control the execution state of the target task through the first state interface, thereby realizing the decoupling between the real-time operating system RTOS and the software layer Autosar, improving the testability of Autosar, and thus reducing the difficulty of developing the vehicle control system.

[0070] In some optional implementations, the OSAL 10 is further used to: encapsulate the interface of the real-time operating system based on the type of the real-time operating system, and provide a task interface, wherein the task interface is used to communicate with the task queue abstraction layer.

[0071] In the embodiment of the present invention, it can be seen from the above that the above RTOS includes freertos, rt-thread, vxworks, osekos, tramline os and other types, and the interface, real-time performance, community support and service calling method contained in different types of RTOS may be different.

[0072] Therefore, when encapsulating the RTOS through the above-mentioned OSAL, the interfaces contained in the RTOS can be encapsulated according to the type of the RTOS, and a task interface can be provided to the upper-level units of the OSAL in the vehicle control system so that the upper-level units can call the services in the RTOS based on the task interface.

[0073] In the embodiment of the present invention, the RTOS can be abstracted through OSAL, and the task interface can be provided through OSAL to call the service in the RTOS through the task interface, so that the interface of the RTOS does not need to be coupled with the upper-layer units such as Autosar, and the decoupling between the RTOS and Autosar is realized. When testing Autosar, the self-closed loop of R&D and testing can be realized without relying on RTOS. At the same time, the present invention can also be compatible with RTOS that does not originally support the Autosar standard, thereby improving the overall compatibility of the vehicle control system.

[0074] In some optional implementations, the task interface in the above OSAL 10 includes: a task creation interface 11, an acquisition interface 12, and a second state interface 13;

[0075] The task creation interface 11 is used to create and configure tasks to be processed in the task queue.

[0076] The acquisition interface 12 is used to obtain the task identifier of the target task from the task queue abstraction layer.

[0077] The second state interface 13 is used to switch the execution state of the target task based on the task queue abstraction layer in response to the switching instruction.

[0078] In the embodiment of the present invention, the task creation interface can be expressed as: thread_creat_with_no_resume(), which is used to create a pending task and initialize the pending task after receiving a task creation instruction, and the initialization process includes steps such as configuration loading, resource allocation, and connection establishment. Then, the target task can be scheduled through the scheduling interface thread_shedule(), and the task identifier of the currently executed target task, i.e., the task id, can be obtained through the above acquisition interface thread_get_id().

[0079] When the vehicle control system executes the target task, the second state interface in the OSAL can be triggered by a switching instruction to switch the execution state of the target task. Here, the second state interface can include a stop interface and a preparation interface.

[0080] Specifically, the above-mentioned suspension interface thread_suspend(thread_id) can be used to suspend the target task, that is, to switch the execution state of the above-mentioned target task from the running state to the suspended state. In addition, the above-mentioned preparation interface thread_resume(thread_id) can be used to activate the target task, that is, to switch the execution state of the above-mentioned target task from the suspended state to the ready state. It should be understood that the running state is used to indicate the state of normal operation of the task, the suspend state is used to indicate the state of the task being suspended and suspended during the execution process, and the ready state is used to indicate the state of the task waiting to be called and executed.

[0081] Here, for example, during the execution of the target task, when encountering interference situations such as delay, waiting for reading semaphore, etc., the target task can be suspended by triggering the above-mentioned abort interface to suspend the execution of the target task. Then, after the interference situation ends, the execution state of the target task can be switched to the ready state by triggering the above-mentioned preparation interface, thereby waiting for the call of the vehicle control system.

[0082] In an embodiment of the present invention, OSAL can call the services of RTOS by providing a unified task creation interface, acquisition interface, and second state interface, so that when developing and testing the vehicle control system, R&D personnel do not need to know too much about the relevant development knowledge of RTOS, thereby reducing the difficulty of developing the vehicle control system.

[0083] In some optional implementations, the task queue abstraction layer 20 includes: a running state interface 21, a pause state interface 22, a suspended state interface 23, and a ready state interface 24;

[0084] The running state interface 21 is used to switch the execution state of the target task to the running state after being triggered by OSAL.

[0085] The pause state interface 22 is used to switch the execution state of the target task to the pause state after being triggered by OSAL, wherein the pause state is used to indicate that the target task is in a state of temporarily stopping execution due to interference conditions.

[0086] The suspend state interface 23 is used to switch the execution state of the target task to the suspend state after being triggered by OSAL.

[0087] The ready state interface 24 is used to switch the execution state of the target task to the ready state after being triggered by OSAL.

[0088] In an embodiment of the present invention, the task queue abstraction layer 20 may include two types of interfaces, one type of scheduling interface task_schedule(), which can be provided to OSAL so that the OSAL calls the target task through the scheduling interface. Another type of interface may be a state switching interface, and OSAL may switch the execution state of the target task by triggering the state switching interface. The state switching interface may include the above-mentioned running state interface task_set_status_running(task_id), the suspended state interface task_set_status_watting(task_id), the suspended state interface task_set_status_suspend(task_id), and the ready state interface task_set_status_ready(task_id).

[0089] Specifically, triggering the running state interface can switch the state of the target task from the ready state (i.e. the above-mentioned ready state) to the running state (i.e. the above-mentioned running state), triggering the pause state interface can switch the state of the target task from the running state (i.e. the above-mentioned running state) to the waiting state (i.e. the above-mentioned pause state), triggering the suspend state interface can switch the state of the target task from the running state (i.e. the above-mentioned running state) to the suspend state (i.e. the above-mentioned suspended state), and triggering the suspend state interface can switch the state of the target task from the suspend state (i.e. the above-mentioned suspended state) to the ready state.

[0090] It should be understood that, considering that during the execution of the target task, it is often necessary to obtain the execution status of the target task through the above-mentioned Autosar to adjust the scheduling strategy and ensure the real-time performance of the real RTOS. Therefore, the above-mentioned task queue abstraction layer may also include a status acquisition interface task_get_current_status(task_id), through which Autosar can obtain the execution status of the target task in real time.

[0091] In the embodiment of the present invention, the task queue abstraction layer may include a state switching interface, so that the OSAL can control the execution state of the target task through the state switching interface, thereby realizing the state migration of the target task.

[0092] In some optional implementations, the OSAL 10 is further configured to: trigger a pause state interface when it is detected that the priority of the target task does not satisfy the execution condition.

[0093] In the embodiment of the present invention, it can be seen from the above that when a plurality of pending tasks are included in the above-mentioned task queue, the target task can be determined based on the priority of the pending task, so as to realize the priority execution of the high-priority task. However, considering that in the actual operation process of the vehicle control system, the low-priority pending task may be preemptively executed. Therefore, when the RTOS detects that there is a high-priority pending task that has not been executed, the execution of the currently executed target task can be suspended, and the high-priority pending task can be executed.

[0094] In specific implementation, when the above OSAL detects that there is a high-priority pending task that has not been executed, it determines that the priority of the target task does not meet the execution condition. At this time, the pause state interface in the above task queue abstraction layer can be triggered to switch the execution state of the target task from the running state to the waiting state, and execute the high-priority pending task. It should be understood that after the high-priority pending task is executed, the execution state of the target task can be automatically switched to the running state.

[0095] In the embodiment of the present invention, it is considered that during the actual operation of the vehicle control system, low-priority pending tasks may be preemptively executed. Therefore, when the RTOS detects that there is a high-priority pending task that has not been executed, the currently executed target task can be suspended and the high-priority pending task can be executed, thereby maximizing the utilization of system resources and ensuring the performance of key tasks, and also achieving fair and efficient task scheduling, and improving the response speed and real-time performance of the system.

[0096] In some optional implementations, the first state interface in the software layer 30 includes: an activation interface 31 and a termination interface 32 .

[0097] The activation interface 31 is used to trigger the running state interface of the task queue abstraction layer in response to the activation instruction to switch the execution state of the target task to the running state.

[0098] The termination interface 32 is used to terminate the execution and remove the target task.

[0099] In an embodiment of the present invention, the above-mentioned activation interface ActivateTask can respond to the activation instruction and switch the execution state of the target task to the running state by calling the osalthread_resume interface. The above-mentioned termination interface can terminate the execution of the target task by calling the osalthread_suspend interface and remove the target task to release system resources.

[0100] In addition, the above software layer autosar can also include interfaces Schedule, ChainTask, GetTaskState and GetTaskID. Here, Schedule can trigger RTOS to execute task scheduling by calling osalthread_schedule interface, ChainTask can realize task chain activation through ActivateTask and TerminateTask, GetTaskState can obtain the execution status of the target task by calling task_get_current_status interface provided by task queue, and GetTaskID can obtain the execution status of the target task being executed by calling osalthread_get_id.

[0101] In the embodiment of the present invention, AUTOSAR can control the execution state of the target task through the first state interface, thereby managing and scheduling the target task, thereby improving the overall performance and stability of the vehicle control system.

[0102] In some optional implementations, the above-mentioned tasks to be processed include: test tasks, and the above-mentioned vehicle testing system is further used to: generate test instructions according to the function to be tested, and generate test tasks in response to the test instructions.

[0103] In the embodiment of the present invention, during the development of the vehicle control system, the developed functions to be tested can be tested to achieve a closed loop of implementation and verification during the development process. Here, considering that the above software layer adopts the Autosar architecture, it is very necessary to test Autosar separately to ensure that the functions and performance of each layer of software meet the standard requirements, thereby improving the reliability and stability of the entire system.

[0104] Specifically, a test instruction can be generated based on the above-mentioned function to be tested, and a test task for AUTOSAR can be generated in response to the test instruction, so as to perform a test operation on the software layer based on the test task.

[0105] In the embodiment of the present invention, since there is no need to couple the interface of the RTOS with upper-level units such as AUTOSAR, decoupling between the RTOS and AUTOSAR is achieved, so that when testing AUTOSAR, a self-closed loop of R&D and testing can be achieved without relying on the RTOS, thereby ensuring that the functions and performance of each layer of software under the AUTOSAR architecture meet the standard requirements, thereby improving the reliability and stability of the entire vehicle control system.

[0106] In this embodiment, another vehicle control system is provided, which can be used for the above-mentioned vehicle. Figure 2is an architecture diagram of another vehicle control system according to an embodiment of the present invention, such as Figure 2 As shown, the system includes: RTOS, OSAL, task queue abstraction layer and autosar.

[0107] Specifically, OSAL is used to encapsulate the interface of the above RTOS and provide the RTOS with a task interface for communicating with the upper unit. The task queue abstraction layer includes two types of interfaces, one of which is the scheduling interface task_schedule(), which can be provided to OSAL so that the OSAL calls the target task through the scheduling interface. The other type of interface can be the above state switching interface, and OSAL can switch the execution state of the target task by triggering the state switching interface. Autosar is the above software layer, which includes the above first state interface and other interfaces for communicating with RTOS.

[0108] In summary, in an embodiment of the present invention, the vehicle control system includes: an operating system abstraction layer OSAL, a software layer and a task queue abstraction layer, wherein the operating system abstraction layer includes an interface of an encapsulated real-time operating system, and communicates with the software layer through an interface provided by the task queue abstraction layer. Here, OSAL is used to create pending tasks in the task queue, the task queue abstraction layer is used to determine the target task among the pending tasks in the task queue in response to a trigger operation on the scheduling interface, and schedule the target task to the real-time operating system, and the software layer is used to control the execution state of the target task through the first state interface, thereby achieving decoupling between the real-time operating system RTOS and the software layer Autosar, improving the testability of Autosar, and thus reducing the difficulty of developing the vehicle control system.

[0109] In this embodiment, a system testing method is also provided, which can be used for the above vehicle control system. Figure 3 is a flow chart of a system testing method according to an embodiment of the present invention. Figure 3 As shown, the process includes the following steps:

[0110] Step S301 : generating a test instruction according to the function to be tested, and generating a test task in the task queue abstraction layer in response to the test instruction.

[0111] Step S302: Perform a test operation on the software layer based on the test task.

[0112] Step S303 , in response to the state control instruction, controlling the execution state of the target task based on the first state interface of the software layer.

[0113] In an embodiment of the present invention, the method for testing the vehicle control system by executing the target task is as described above. Figure 1The corresponding embodiments will not be described in detail here.

[0114] In this embodiment, a system testing device is also provided, which is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made will not be repeated. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0115] This embodiment provides a system testing device, such as Figure 4 As shown, including:

[0116] The generating module 401 generates a test instruction according to the function to be tested, and generates a test task in the task queue abstraction layer in response to the test instruction.

[0117] The testing module 402 performs testing operations on the software layer based on the testing tasks.

[0118] The control module 403 controls the execution state of the target task based on the first state interface of the software layer in response to the state control instruction.

[0119] In some optional implementations, the device is further used to: encapsulate the interface of the real-time operating system based on the type of the real-time operating system, and provide a task interface, wherein the task interface is used to communicate with the task queue abstraction layer.

[0120] In some optional implementations, the control module 403 is further configured to:

[0121] Create and configure pending tasks in the task queue;

[0122] Get the task ID of the target task from the task queue abstraction layer;

[0123] In response to the switch instruction, the execution state of the target task is switched based on the task queue abstraction layer.

[0124] In some optional implementations, the control module 403 is further configured to:

[0125] Switch the execution state of the target task from the running state to the suspended state;

[0126] The execution state of the target task is restored from the suspended state to the ready state, wherein the ready state is used to indicate that the target task is in a state of waiting for a call.

[0127] In some optional implementations, the control module 403 is further configured to:

[0128] After being triggered by OSAL, the execution state of the target task is switched to the running state;

[0129] After being triggered by OSAL, the execution state of the target task is switched to a pause state, wherein the pause state is used to indicate that the target task is temporarily stopped due to interference conditions;

[0130] After being triggered by OSAL, the execution state of the target task is switched to the suspended state;

[0131] After being triggered by OSAL, the execution state of the target task is switched to the ready state.

[0132] In some optional implementations, the control module 403 is configured to trigger a pause state interface when it is detected that the priority of the target task does not satisfy the execution condition.

[0133] In some optional embodiments, the device is also used for:

[0134] In response to the acquisition instruction, the execution status of the target task is acquired, and the execution status is fed back to the software layer.

[0135] In some optional embodiments, the device is also used for:

[0136] In response to the activation instruction, triggering the running state interface of the task queue abstraction layer to switch the execution state of the target task to the running state;

[0137] Terminates execution and removes the target task.

[0138] In some optional implementations, the task to be processed includes: a test task; the device is further used for:

[0139] A test instruction is generated according to the function to be tested, and a test task is generated in response to the test instruction.

[0140] In some optional embodiments, the device is also used for:

[0141] Based on the test tasks, test operations are performed on the software layer.

[0142] The further functional description of each of the above modules and units is the same as that of the above corresponding embodiments and will not be repeated here.

[0143] The system testing device in this embodiment is presented in the form of a functional unit, where the unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that executes one or more software or fixed programs, and / or other devices that can provide the above functions.

[0144] The embodiment of the present invention also provides a computer device having the above Figure 4 System test setup shown.

[0145] See also Figure 5 , Figure 5 is a schematic diagram of the structure of a computer device provided by an optional embodiment of the present invention, such as Figure 5 As shown, the computer device includes: one or more processors 100, a memory 200, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Various components are connected to each other using different buses for communication, and can be installed on a common mainboard or installed in other ways as needed. The processor can process the instructions executed in the computer device, including instructions stored in or on the memory to display the graphical information of the GUI on an external input / output device (such as, a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Figure 5 A processor 100 is taken as an example.

[0146] The processor 100 may be a central processing unit, a network processor or a combination thereof. The processor 100 may further include a hardware chip. The hardware chip may be a dedicated integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable logic gate array, a general purpose array logic or any combination thereof.

[0147] The memory 200 stores instructions executable by at least one processor 100, so that the at least one processor 100 executes the method shown in the above embodiment.

[0148] The memory 200 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required by at least one function; the data storage area may store data created according to the use of the computer device, etc. In addition, the memory 200 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 200 may optionally include a memory remotely arranged relative to the processor 100, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0149] The memory 200 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid state drive; the memory 200 may also include a combination of the above types of memory.

[0150] The computer device further includes a communication interface 300 for the computer device to communicate with other devices or a communication network.

[0151] The embodiment of the present invention also provides a computer-readable storage medium. The method according to the embodiment of the present invention can be implemented in hardware, firmware, or can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium through a network download, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state hard disk, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor, or hardware, the method shown in the above embodiment is implemented.

[0152] A part of the present invention may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present invention through the operation of the computer. Those skilled in the art should understand that the existence of the computer program instruction in a computer-readable medium includes, but is not limited to, a source file, an executable file, an installation package file, etc., and accordingly, the way in which the computer program instruction is executed by the computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium may be any available computer-readable storage medium or communication medium accessible to the computer.

[0153] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations are all within the scope defined by the accompanying description.

Claims

1. A vehicle control system, characterized in that: The system comprises: an operating system abstraction layer OSAL, a task queue abstraction layer and a software layer, wherein the operating system abstraction layer contains an interface of an encapsulated real-time operating system and communicates with the software layer through an interface provided by the task queue abstraction layer; The OSAL is used to create a task to be processed in the task queue; The task queue abstraction layer is used to determine a target task from the pending tasks in the task queue in response to a trigger operation on the scheduling interface, and schedule the target task to the real-time operating system; The software layer is used to control the execution state of the target task through a first state interface.

2. The system according to claim 1, characterized in that The OSAL is further used to: encapsulate the interface of the real-time operating system based on the type of the real-time operating system, and provide a task interface, wherein the task interface is used to communicate with the task queue abstraction layer.

3. The system according to claim 2, characterized in that The task interface includes: a task creation interface, an acquisition interface and a second status interface; The task creation interface is used to create and configure the pending tasks in the task queue; An acquisition interface is used to obtain the task identifier of the target task from the task queue abstraction layer; The second state interface is used to switch the execution state of the target task based on the task queue abstraction layer in response to a switching instruction.

4. The system according to claim 3, characterized in that The second state interface includes: a stop interface and a prepare interface; The abort interface is used to switch the execution state of the target task from a running state to a suspended state; The preparation interface is used to restore the execution state of the target task from the suspended state to the preparation state, wherein the preparation state is used to indicate that the target task is in a state of waiting for invocation.

5. The system according to claim 1, characterized in that The task queue abstraction layer includes: a running state interface, a pause state interface, a suspended state interface, and a ready state interface; The running state interface is used to switch the execution state of the target task to the running state after being triggered by the OSAL; The pause state interface is used to switch the execution state of the target task to a pause state after being triggered by the OSAL, wherein the pause state is used to indicate that the target task is in a state of temporarily stopping execution due to interference conditions; The suspended state interface is used to switch the execution state of the target task to a suspended state after being triggered by the OSAL; The ready state interface is used to switch the execution state of the target task to the ready state after being triggered by the OSAL.

6. The system according to claim 5, characterized in that The OSAL is further configured to trigger the pause state interface when it is detected that the priority of the target task does not satisfy the execution condition.

7. The system according to claim 1, characterized in that The task queue abstraction layer includes: a status acquisition interface; The state acquisition interface is used to acquire the execution state of the target task in response to an acquisition instruction, and feed back the execution state to the software layer.

8. The system according to claim 1, characterized in that The first state interface includes: an activation interface and a termination interface; The activation interface is used to trigger the running state interface of the task queue abstraction layer in response to the activation instruction to switch the execution state of the target task to the running state; The termination interface is used to terminate the execution and remove the target task.

9. The system according to claim 1, characterized in that The tasks to be processed include test tasks. The system is further used to generate test instructions according to the functions to be tested, and generate test tasks in response to the test instructions.

10. The system according to claim 9, characterized in that The system is also used to: perform a test operation on the software layer based on the test task.

11. A vehicle, characterized in that: A vehicle control system according to any one of claims 1 to 10.

12. A task management method, characterized in that: Applied to the vehicle control system according to any one of claims 1 to 10, the method comprising: Generate a test instruction according to the function to be tested, and generate a test task in the task queue abstraction layer in response to the test instruction; Based on the test task, perform a test operation on the software layer; In response to the state control instruction, the execution state of the target task is controlled based on the first state interface of the software layer.

Images