WO2023143020A1

WO2023143020A1 - Generation method and apparatus for real-time operating system, use method and apparatus for real-time operating system, electronic device, and medium

Info

Publication number: WO2023143020A1
Application number: PCT/CN2023/071367
Authority: WO
Inventors: 王春锦
Original assignee: 宁德时代新能源科技股份有限公司
Priority date: 2022-01-29
Filing date: 2023-01-09
Publication date: 2023-08-03
Also published as: CN115826938B; CN115826938A

Abstract

A generation method and apparatus for a real-time operating system (RTOS), a use method and apparatus for an RTOS, an electronic device, and a medium. The generation method comprises: generating an operating system abstraction layer (OSAL) kernel on the basis of an automotive open system architecture (AUTOSAR) standard, the OSAL kernel being used for enabling an RTOS to run under the AUTOSAR standard (S1); encapsulating a corresponding application programming interface (API) of the RTOS on the basis of the OSAL kernel (S2); obtaining an OSAL code generation tool, the OSAL code generation tool being used for generating a code file consistent with the OSAL kernel according to the configuration in the OSAL kernel by a user and a calling process of the RTOS by the user (S3); and generating an AUTOSAR-based RTOS on the basis of the OSAL kernel, the RTOS having the encapsulated API, and the OSAL code generation tool (S4). The development cost in a BMS project can be reduced, and rapid development of the project can also be implemented.

Description

Generating and using method and device of real-time operating system, electronic equipment, medium

Cross References to Related Applications

This application claims the priority of the Chinese patent application 202210111217.4 entitled "Real-time operating system generation, use method and device, electronic equipment, medium" filed on January 29, 2022, the entire content of which is incorporated by reference In this article.

technical field

The present application relates to the technical field of battery management, and in particular to a method for generating a real-time operating system, a method for using it, a device for generating it, a device for using it, electronic equipment, and a computer-readable storage medium.

Background technique

Vehicles use MICROSAR OS as a preemptive real-time multi-tasking operating system, which has been widely used in the field of automotive electronics. However, MICROSAR OS needs to purchase the Davinci series tools and the static code package provided by Vector in the development of automotive electronics, resulting in very high development costs. Moreover, once the Davinci series tools and the static code package provided by Vector are not updated in time, it will seriously affect the development progress of projects such as the Battery Management System (BMS).

Contents of the invention

In view of the above problems, the present application provides a real-time operating system generation method, use method, generation device, use device, electronic equipment and computer-readable storage medium, which can not only reduce the development cost of BMS projects, but also realize rapid development of projects .

In the first aspect, the embodiment of the present application provides a method for generating a real-time operating system, and the generating method includes: generating an operating system abstraction layer (Operating System Abstraction Layer, OSAL) kernel based on the Automobile Open System Architecture (AUTomotive Open System Architecture, AUTOSAR) standard , the OSAL kernel is used to make a real-time operating system (Real Time Operating System, RTOS) run under the AUTOSAR standard; based on the OSAL kernel, the corresponding application program interface (Application Programming Interface, API) of the RTOS is encapsulated; obtain OSAL code generation tool, the OSAL code generation tool is used to generate a code file consistent with the OSAL kernel for the user's configuration in the OSAL kernel and the call process to the RTOS; based on the OSAL kernel, encapsulation After the RTOS API and the OSAL code generation tool, generate an AUTOSAR-based real-time operating system.

The AUTOSAR-based real-time operating system obtained at this time can run according to the AUTOSAR standard, that is, realize all or part of the functions in MICROSAR OS. In this way, it is not necessary to purchase MICROSAR OS, the Davinci series tools in MICROSAR OS and the static code package provided by Vector, and the development of BMS projects can also be realized, which saves the development cost of BMS projects. Moreover, since the OSAL kernel and OSAL code generation tools are configured in the AUTOSAR-based real-time operating system, there is no need to rebuild the software architecture or manually write a large number of codes during the development of the BMS project, so as to realize the rapid development of the BMS project.

In some embodiments, the generating the operating system abstraction layer OSAL kernel based on the automotive open system architecture AUTOSAR standard includes: generating the OSAL kernel including multiple objects in the automotive open system architecture operating system AUTOSAR OS based on the AUTOSAR standard.

Through multiple objects in the AUTOSAR OS, the OSAL kernel is generated based on the AUTOSAR standard, which can reduce the workload when generating the OSAL kernel based on the AUTOSAR standard, and then based on the OSAL kernel, it can more conveniently and comprehensively simulate various functions in the MICROSAR OS.

In some embodiments, the generation of the OSAL kernel containing multiple objects in the automotive open system architecture operating system AUTOSAR OS based on the AUTOSAR standard includes: generating an operating system abstraction layer OSAL scheduler, and the OSAL scheduler is used for Manage kernel parameter initialization, kernel start and stop, current core acquisition, application initialization, interrupt initialization, clock initialization, and external interface calls; generate data structures of multiple objects in the AUTOSAR OS based on the AUTOSAR standard; based on the OSAL scheduler and the data structures generated by the OSAL kernel.

In the process of generating the OSAL kernel, the OSAL scheduler is generated to realize the management of multiple objects, and the data structure of multiple objects in the AUTOSAR OS is generated, and then combined with the OSAL scheduler to generate the OSAL kernel, the OSAL kernel can be scheduled by OSAL The controller implements unified management of its various functions and strengthens the OSAL kernel.

In some embodiments, the generating the data structures of multiple objects in the AUTOSAR OS based on the AUTOSAR standard includes: when the multiple objects include applications, generating application stacks and task associations based on the AUTOSAR standard Property table, task handle table, clock-related property table, clock handle table, signal-related property table, event-related property table, event handle table, ISRs nested flags, computed property table, source property table, application static code and configuration Code architecture; when the multiple objects include a clock, generate an identifier, a clock name, a cycle running time, a timeout time, and a clock implementation interface based on the AUTOSAR standard.

According to the types of different objects in AUTOSAR OS, different data structures can be configured to enable OSAL kernel to manage and configure related objects of AUTOSAR OS in RTOS, so as to ensure that RTOS can realize various functions based on AUTOSAR.

In some embodiments, the acquisition of the OSAL code generation tool includes: generating a variety of link file generation templates, and different link file generation templates correspond to different compilers; based on the link file generation templates, static variables defined according to the code The OSAL code generation tool is generated according to the rules consistent with the data structures in the OSAL kernel.

Generate OSAL code generation tools through link file generation templates corresponding to different compilers. No matter what RTOS the developer chooses, the OSAL code generation tools can generate RTOS-compliant codes, which can improve the applicability of OSAL code generation tools for different RTOSs. sex.

In the second aspect, the embodiment of the present application provides a method for using a real-time operating system, which is applied to the real-time operating system generated by the above-mentioned generation method, and the method for using includes: from the real-time operating system based on AUTOSAR Download the OSAL kernel, and download the target real-time operating system that matches the vehicle battery management development project from an open source website; obtain the user's configuration in the OSAL kernel based on the vehicle battery management development project; The operating result in the target real-time operating system uses the OSAL code generation tool to generate the code files required by the vehicle battery management development project.

Run the user's configuration in the OSAL kernel in the target RTOS, and then use the OSAL code generation tool to convert the running results into corresponding code files, so that the BMS project can be developed based on the code files. In the process of BMS project development, there is no need to purchase MICROSAR OS, the Davinci series tools in MICROSAR OS and the static code package provided by Vector, which reduces the development cost of BMS projects. Moreover, since the OSAL kernel and OSAL code generation tools are configured in the AUTOSAR-based real-time operating system, there is no need to rebuild the software architecture or manually write a large number of codes during the development of the BMS project, so as to realize the rapid development of the BMS project.

In some embodiments, based on the running result of the configuration in the target real-time operating system, using the OSAL code generation tool to generate the code files required by the vehicle battery management development project includes: for different According to the configuration of the OSAL code generation tool, the macro loads the interface corresponding to the different configuration in the target real-time operating system; when loading the interface, the OSAL code generation tool is used to generate the vehicle Code files required for battery management development projects.

The macro generated by the OSAL code generation tool determines the interface of the current user's configuration in the RTOS, and then loads the interface to run the user's configuration, and then uses the OSAL code generation tool to process the running results to obtain the code files required by the current BMS project. Since the interface loaded in the RTOS is based on the configuration of the user, the generated code files can meet the needs of the BMS project development, thereby ensuring the normal and smooth development of the BMS project.

In some embodiments, for different configurations, loading the interface corresponding to the different configurations in the target real-time operating system according to the macro generated by the OSAL code generation tool includes: when the configuration is a clock setting , determine whether the target real-time operating system is FreeRTOS according to the macro generated by the OSAL code generation tool; if so, load Clock_setTimeout, Clock_setPeriod, Clock_start in the FreeRTOS, and call xTimerStart; when the configuration is an application setting , determine whether the target real-time operating system is FreeRTOS according to the macro generated by the OSAL code generation tool; if so, load the vTaskStartScheduler in the FreeRTOS, and call xSemaphoreCreateMutex, xSemaphoreCreateMutex, Semaphore_post; and generate The macro determines whether the target real-time operating system is SYSbios; if so, loads BIOS_start() in the SYSbios.

For Alarm configuration and Application configuration, according to the macro generated by the OSAL code generation tool, it is determined whether the target RTOS is FreeRTOS, and then when the target RTOS is determined to be FreeRTOS, the specific call interface is given to avoid interface call errors, thereby improving the efficiency of code file generation Accuracy further ensures the normal and smooth development of BMS projects.

In a third aspect, the embodiment of the present application provides a real-time operating system generating device, the generating device includes: a design module for generating an operating system abstraction layer OSAL kernel based on the automotive open system architecture AUTOSAR standard, and the OSAL kernel uses To make the real-time operating system RTOS run under the AUTOSAR standard; the encapsulation module is used to encapsulate the corresponding application program interface API of the RTOS based on the OSAL kernel; the acquisition module is used to obtain an OSAL code generation tool, and the OSAL code The generation tool is used to generate a code file consistent with the OSAL kernel for the user's configuration in the OSAL kernel and the calling process of the RTOS; the generation module is used for the RTOS based on the OSAL kernel and encapsulated API And the OSAL code generation tool generates an AUTOSAR-based real-time operating system.

In a fourth aspect, an embodiment of the present application provides a device for using a real-time operating system, the device for using is applied to the real-time operating system generated by the above-mentioned generating device, and the device for using includes: a download module for downloading from the Download the OSAL kernel based on the AUTOSAR real-time operating system, and download the target real-time operating system that matches the vehicle battery management development project from the open source website; the configuration module is used to obtain the user based on the vehicle battery management development project. The configuration in the OSAL kernel; the generation module is used to adopt the OSAL code generation tool to generate the required code files for the vehicle battery management development project based on the operation result of the configuration in the target real-time operating system.

In the fifth aspect, the embodiment of the present application provides an electronic device, including: a processor, a memory, and a bus; wherein, the processor and the memory complete mutual communication through the bus; the processor is used to call The program instructions in the memory are used to execute the generation method in the first aspect or the use method in the second aspect.

In a sixth aspect, an embodiment of the present application provides a computer-readable storage medium, including: a stored program; wherein, when the program is running, the device where the storage medium is located is controlled to execute the generation method in the first aspect or the second method used in the aspect.

The above description is only an overview of the technical solution of the present application. In order to better understand the technical means of the present application, it can be implemented according to the contents of the description, and in order to make the above and other purposes, features and advantages of the present application more obvious and understandable , the following specifically cites the specific implementation manner of the present application.

Description of drawings

Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiment. The drawings are only for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the application. Also, the same reference numerals are used to denote the same components throughout the drawings. In the attached picture:

FIG. 1 is a schematic flow diagram of a method for generating a real-time operating system in an embodiment of the present application;

Fig. 2 is the structural representation of the real-time operating system based on AUTOSAR in the embodiment of the present application;

FIG. 3 is a schematic flowchart of a method for using a real-time operating system in an embodiment of the present application;

Fig. 4 is a schematic diagram of the core processing flow of the OSAL scheduler in the embodiment of the present application;

FIG. 5 is a schematic structural diagram of a device for generating a real-time operating system in an embodiment of the present application;

FIG. 6 is a schematic structural diagram of a device for using a real-time operating system in an embodiment of the present application;

FIG. 7 is a schematic structural diagram of an electronic device in an embodiment of the present application.

Detailed ways

Embodiments of the technical solutions of the present application will be described in detail below in conjunction with the accompanying drawings. The following examples are only used to illustrate the technical solution of the present application more clearly, and therefore are only examples, rather than limiting the protection scope of the present application.

Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the technical field of the application; the terms used herein are only for the purpose of describing specific embodiments, and are not intended to To limit this application; the terms "comprising" and "having" and any variations thereof in the specification and claims of this application and the description of the above drawings are intended to cover a non-exclusive inclusion.

In the description of the embodiments of the present application, technical terms such as "first" and "second" are only used to distinguish different objects, and should not be understood as indicating or implying relative importance or implicitly indicating the number, specificity, or specificity of the indicated technical features. Sequence or primary-secondary relationship. In the description of the embodiments of the present application, "plurality" means two or more, unless otherwise specifically defined.

Reference herein to "an embodiment" means that a particular feature or characteristic described in connection with the embodiment can be included in at least one embodiment of the present application. The occurrences of this phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. It is understood explicitly and implicitly by those skilled in the art that the embodiments described herein can be combined with other embodiments.

In the description of the embodiment of the present application, the term "and/or" is only an association relationship describing associated objects, which means that there may be three relationships, such as A and/or B, which may mean: there is A, and there are A and B, there are three situations of B. In addition, the character "/" in this article generally indicates that the contextual objects are an "or" relationship.

In the description of the embodiments of the present application, the term "multiple" refers to more than two (including two), similarly, "multiple groups" refers to more than two groups (including two), and "multiple pieces" refers to More than two pieces (including two pieces).

In the description of the embodiments of the present application, the technical terms "center", "longitudinal", "lateral", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical" "Horizontal", "Top", "Bottom", "Inner", "Outer", "Clockwise", "Counterclockwise", "Axial", "Radial", "Circumferential", etc. indicate the orientation or positional relationship based on the drawings Orientation or positional relationship is only for the convenience of describing the embodiment of the present application and simplifying the description, and does not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as an implementation of the present application. Example limitations.

In the description of the embodiments of this application, unless otherwise clearly specified and limited, technical terms such as "installation", "connection", "connection" and "fixation" should be interpreted in a broad sense, for example, it can be a fixed connection or a fixed connection. Disassembled connection, or integration; it can also be a mechanical connection, or an electrical connection; it can be a direct connection, or an indirect connection through an intermediary, and it can be the internal communication of two components or the interaction relationship between two components. Those of ordinary skill in the art can understand the specific meanings of the above terms in the embodiments of the present application according to specific situations.

At present, in order to realize the rapid development of BMS, it is mainly through the purchase of MICROSAR OS, and then realize the rapid development of BMS through MICROSAR OS. MICROSAR OS is a preemptive real-time multitasking operating system developed by Vector, which fully complies with the AUTOSAR standard. Its main idea is to make the software designer easier to manage, the software system easier to transplant, tailor, and better maintain and quality assurance. MICROSAR OS has been widely used in the field of automotive electronics. It has many advantages such as static operating system, complete preemption, event triggering, and configurable functions and sizes.

However, MICROSAR OS needs to purchase the Davinci series tools and the static code package provided by Vector in the development of automotive electronics. Additional purchases of system tools and code packages require a certain amount of money, resulting in very high BMS development costs. Moreover, the resources of the Micro Control Unit (MCU) of the existing technology platform are constantly changing, and the development of Vector is limited (for example: Vector has not yet developed a new generation of chip code packages and configuration tools), which leads to the development of new BMS projects. The MICROSAR OS provided by Vector cannot continue to be used in the middle, which seriously affects the development of the MBS project.

However, if a BMS project is developed using an open source or commercial RTOS on the market, a large amount of handwritten code is required, and a new software architecture needs to be redeveloped, which simply cannot meet the needs of rapid development of current BMS projects.

The inventor found through research that the BMS project development cost caused by MICROSAR OS is high. And the root cause of the limited conditions and the inability to meet the rapid development needs of BMS projects is that when using MICROSAR OS for BMS project development, it is necessary to use Davinci series tools and static code packages. The prices and updates of Davinci series tools and static code packages are not under the control of BMS project developers. The fundamental reason why RTOS cannot meet the rapid development needs of BMS projects is that BMS project developers need to rebuild the software architecture and write a lot of codes by hand.

In view of this, based on the research findings of the inventors, the embodiments of the present application provide a real-time operating system generation method, use method, generation device, use device, electronic equipment, and computer-readable storage medium. On the basis of RTOS, based on The AUTOSAR standard generates the OSAL kernel that can simulate various functions in AUTOSAR, and then configures the OSAL kernel in the RTOS, combined with the corresponding code generation tools, can automatically generate the corresponding configuration file, and then simulates a real-time operating system similar to AUTOSAR. Because it avoids the need to purchase Davinci series tools and static code packages when using MICROSAR OS, it can save the development cost of BMS projects, and realize the rapid development of BMS projects in the structure of RTOS without rebuilding the software architecture and writing a lot of codes by hand. Therefore, using the real-time operating system generation method, use method, generation device, use device, electronic equipment, and computer-readable storage medium provided by the embodiment of the present application can reduce the development cost of the BMS project while still realizing the implementation of the BMS project. Rapid development.

First, the method for generating the real-time operating system provided by the embodiment of the present application will be described in detail.

Fig. 1 is a schematic flow chart of a method for generating a real-time operating system in an embodiment of the present application, as shown in Fig. 1, the method may include:

S1: Generate the operating system abstraction layer OSAL kernel based on the AUTOSAR standard of the automotive open system architecture.

Among them, the OSAL kernel is used to make the real-time operating system RTOS run under the AUTOSAR standard.

When developing BMS projects, it is necessary to follow the AUTOSAR standard. If you want to realize the rapid development of BMS projects on the basis of RTOS without rebuilding the software architecture and without a lot of handwritten code, you can configure an OSAL kernel in the RTOS so that the OSAL kernel can simulate MICROSAR under the AUTOSAR standard All or part of the functions in the OS. In this way, the RTOS with the OSAL kernel can realize all or part of the functions in MICROSAR OS without rebuilding the software architecture and without a lot of handwriting codes.

The specific method of generating the OSAL kernel based on the AUTOSAR standard can use any existing method of generating the OSAL kernel, as long as the generated OSAL kernel can make the RTOS run under the AUTOSAR standard. That is to say, RTOS configured with OSAL kernel can simulate all or part of the functions in MICROSAR OS. The specific generation method of the OSAL kernel is not limited here.

S2: Encapsulate the corresponding application program interface API of the RTOS based on the OSAL kernel.

Since the OSAL kernel needs to be configured in the RTOS, the RTOS can simulate all or part of the functions in the MICROSAR OS through the OSAL kernel. Therefore, it is necessary to encapsulate the OSAL kernel and the corresponding API in the RTOS.

In general, there will be multiple APIs in an RTOS. As for which API is used to encapsulate the OSAL kernel, it can be determined according to the actual situation during configuration, and no specific limitation is made here. As well as the specific encapsulation method adopted during the encapsulation, it may be any existing encapsulation method, which is not specifically limited here.

S3: Get the OSAL code generation tool.

Among them, the OSAL code generation tool is used to generate a code file consistent with the OSAL kernel from the user's configuration in the OSAL kernel and the call process to the RTOS.

After configuring the OSAL kernel in the RTOS, if you want the RTOS to run normally according to the AUTOSAR standard, you need to configure the RTOS related content with the OSAL kernel. The user's configuration is generally different from the code used by the OSAL kernel. Therefore, a code generation tool is needed to convert the user's configuration and the calling process generated in the RTOS based on the user's configuration into a code file consistent with the OSAL kernel. , this code generation tool is the OSAL code generation tool.

In practical application, the existing code generation tool can be improved so that it can generate a code file consistent with the OSAL kernel for the user's configuration in the OSAL kernel and the calling process of the RTOS. It is also possible to custom generate an OSAL code generation tool. The generation process of the OSAL code generation tool is similar to that of other code generation tools, as long as its final function can generate a code file consistent with the OSAL kernel for the user's configuration in the OSAL kernel and the calling process of the RTOS. The design methods adopted are the design methods of existing commonly used code generation tools. The specific method of obtaining the OSAL code generation tool is not limited here.

S4: Generate an AUTOSAR-based real-time operating system based on the OSAL kernel, the RTOS after encapsulating the API, and the OSAL code generation tool.

After obtaining the OSAL kernel, encapsulating the API of the OSAL kernel in the RTOS, and loading the OSAL code generation tool into the RTOS, the RTOS has the OSAL kernel and the OSAL code generation tool. At this time, the RTOS can run according to the AUTOSAR standard, that is, all or part of the functions in the MICROSAR OS are realized.

As can be seen from the above, the method for generating a real-time operating system provided by the embodiment of the present application firstly generates an OSAL kernel based on the AUTOSAR standard; then, encapsulates the corresponding API of the RTOS based on the OSAL kernel; then obtains an OSAL code generation tool; finally, Generate an AUTOSAR-based real-time operating system based on the OSAL kernel, RTOS after encapsulating the API, and OSAL code generation tools. The AUTOSAR-based real-time operating system obtained at this time can run according to the AUTOSAR standard, that is, realize all or part of the functions in MICROSAR OS. In this way, it is not necessary to purchase MICROSAR OS, the Davinci series tools in MICROSAR OS, and the static code package provided by Vector, and the development of BMS projects can also be realized, saving the development cost of BMS projects. Moreover, since the OSAL kernel and OSAL code generation tools are configured in the AUTOSAR-based real-time operating system, there is no need to rebuild the software architecture or manually write a large number of codes during the development of the BMS project, so as to realize the rapid development of the BMS project.

Further, as a refinement and extension of step S1 in the method shown in Figure 1, in the process of generating the OSAL kernel based on the AUTOSAR standard, multiple objects in the AUTOSAR OS can also be referred to, thereby enabling more convenient and comprehensive generation of the OSAL kernel. OSAL kernel for simulating various functions in MICROSAR OS.

Specifically, the above step S1 may specifically include:

S11: Generate an OSAL kernel containing multiple objects in the automotive open system architecture operating system AUTOSAR OS based on the AUTOSAR standard.

Each object in AUTOSAR OS can realize corresponding functions, and then, refer to each object in AUTOSAR OS to generate an OSAL kernel based on AUTOSAR standard, which can more conveniently and comprehensively simulate various functions in MICROSAR OS.

Specifically, the objects in AUTOSAR OS can at least include: Core, Application, Task, Interrupt Service, Alarm, Counter, Resource, IOC, etc. That is to say, in the design of the OSAL kernel, the output targets are to realize Core, Application, Task, Interrupt Service, Alarm, Counter, Resource, and IOC.

Of course, if there are other objects in the AUTOSAR OS, in the design of the OSAL kernel, it can also take the realization of other objects as the output goal. For the specific content of the object in AUTOSAR OS, there is no limitation here.

From the above content, we can see that through multiple objects in AUTOSAR OS, the OSAL kernel is generated based on the AUTOSAR standard, which can reduce the workload when generating the OSAL kernel based on the AUTOSAR standard, and then based on the OSAL kernel, it can more conveniently and comprehensively simulate various objects in MICROSAR OS. item function.

Furthermore, as a refinement and extension of the above step S11, the OSAL kernel needs a general control capable of scheduling its various functions during the running process, and this general control can be the operating system abstraction layer OSAL scheduler. Then combined with the data structure of multiple objects in AUTOSAR OS, an OSAL kernel that can run based on the AUTOSAR standard is obtained.

Specifically, the above step S11 may specifically include:

S111: Generate an operating system abstraction layer OSAL scheduler.

Among them, the OSAL scheduler is used to manage kernel parameter initialization, kernel startup and shutdown, current kernel acquisition, application initialization, interrupt initialization, clock initialization, and external interface calls.

The OSAL scheduler designed in the OSAL kernel is actually used to manage OS kernel (Core) parameter initialization, kernel (Core) start and stop, current core (Core) acquisition, Application initialization, interrupt initialization, Alarm initialization, etc. At the same time, it can also manage OS services, provide an external call interface, and is compatible with the RTE module in AUTOSAR. In fact, the OSAL scheduler is similar to the trap in AUTOSAR OS, but the processing process is completely different. The key core processing lies in the judgment of different RTOS types, which will be explained in detail in the usage method of the real-time operating system later.

S112: Generate data structures of multiple objects in the AUTOSAR OS based on the AUTOSAR standard.

In the process of generating an OSAL kernel that meets the AUTOSAR standard with reference to multiple objects in the AUTOSAR OS, the multiple objects in the AUTOSAR OS are not directly moved into the OSAL kernel, but the data of multiple objects in the AUTOSAR OS is constructed in the OSAL kernel structure, therefore, it is necessary to generate the data structure of multiple objects in AUTOSAR OS based on the AUTOSAR standard.

S113: Generate an OSAL kernel based on the OSAL scheduler and data structure.

After obtaining the OSAL scheduler and the data structures of multiple objects in AUTOSAR OS, combine the OSAL scheduler and the data structures of multiple objects in AUTOSAR OS to obtain the OSAL kernel. Furthermore, in the OSAL kernel, through the OSAL scheduler, various functions conforming to the AUTOSAR standard can be realized.

It can be seen from the above that in the process of generating the OSAL kernel, the OSAL scheduler is generated to realize the management of multiple objects, and the data structure of multiple objects in the AUTOSAR OS is generated, and then combined with the OSAL scheduler to generate the OSAL kernel, it can make The OSAL kernel implements unified management of its various functions through the OSAL scheduler, which strengthens the OSAL kernel.

Further, as a refinement and extension of the above step S112, in order to enable the OSAL kernel to manage and configure the related objects of the AUTOSAR OS in the RTOS, and to adapt to the requirements of the OSAL code generation tool, according to the requirements of the AUTOSAR standard, it is necessary to Design the Application, Alarm, Interrupt, Counter, and Task data structures.

When generating data structures of multiple objects in AUTOSAR OS, different object types have different corresponding data structures. Therefore, it is necessary to generate corresponding data structures for specific types of different objects.

Specifically, the above step S112 may specifically include:

S1121: When multiple objects include applications, generate an application stack, a task-related attribute table, a task handle table, a clock-related attribute table, a clock handle table, a signal-related attribute table, an event-related attribute table, an event handle table, based on the AUTOSAR standard, ISRs nest flags, computed property sheets, source property sheets, application static code, and configuration code architectures.

That is to say, when configuring the Application, the Application structure needs to have the Application stack (dynamic state identification when creating the Application), task association attribute table, task handle table, Alarm association attribute table, Alarm handle table, signal association Attribute table, event association attribute table, event handle table, ISRs nested flag, Counters attribute table, Resources attribute table, etc.

At the same time, it is also necessary to design the application's static code and configuration code architecture. According to the AUTOSAR standard, the static code of Application is responsible for the initialization of the corresponding resources in AUTOSAR, and completes the task list, alarm list, event list, and resource initialization of all rights according to the Applications configuration list.

The key to the design is to be able to judge different types of RTOS by reading the macro of the code generation tool to realize the function of RTE task activation in AUTOSAR OS. The specific implementation manner will be described in detail later in the method of using the real-time operating system.

S1122: When multiple objects include a clock, generate an identifier, a clock name, a cycle running time, a timeout time, and a clock implementation interface based on the AUTOSAR standard.

Specifically, when configuring the Alarm, the Alarm structure needs to have ID, Alarm name, cycle running time, timeout time, and Alarm implementation interface.

That is to say, define the Alarm structure according to the requirements of the AUTOSAR standard. The key to the design is to be able to judge different types of RTOS by reading the macro of the code generation tool to realize the start and stop function of RTE Alarm in AUTOSAR OS. The specific implementation manner will be described in detail later in the method of using the real-time operating system.

What needs to be explained here is that the above steps S1121 and S1122 do not have a sequence of execution, but are two situations when configuring the data structure.

It can be seen from the above that, according to the types of different objects in AUTOSAR OS, different data structures can be configured to enable OSAL kernel to manage and configure related objects of AUTOSAR OS in RTOS, so as to ensure that RTOS can realize various functions based on AUTOSAR.

Further, as a refinement and extension of step S3 in the method shown in Figure 1, when generating OSAL code generation tools by itself, OSAL code generation tools can be generated based on different compilers, thereby improving the OSAL code generation tools for different RTOSs. applicability.

Specifically, the above step S3 may specifically include:

S31: Generate various link file generation templates.

Wherein, different link file generation templates correspond to different compilers.

According to the AUTOSAR standard, software modularization and configurability in RTOS are required. Therefore, a set of OSAL code generation tools needs to be designed, and its code can be generated according to the RTOS selected by the developer. At the same time, it is also necessary to generate link files and build files associated with the compiler, which are used for engineering development and construction. Therefore, it is required to have a set of link file generation templates for different compilers in the OSAL code generation tool design. Furthermore, different compilers are connected to generate templates through different link files, and then code compilation is realized.

S32: Generate a template based on the link file, and generate an OSAL code generation tool according to the rule that the static variable defined by the code is consistent with the data structure in the OSAL kernel.

After obtaining the link file generation templates corresponding to different compilers, since the static variables defined by the code generated by the OSAL code generation tool need to be consistent with the structure designed in the OSAL kernel, therefore, to generate templates based on the link files, it is necessary to follow the static variables defined by the code Rules for variables to be consistent with data structures in the OSAL kernel, generated by OSAL code generation tools.

From the above content, we can see that the OSAL code generation tool is generated through the link file generation template corresponding to different compilers. No matter which RTOS the developer chooses, the OSAL code generation tool can generate RTOS-compliant code, which can improve the OSAL code generation tool. Applicability of different RTOS.

After adopting the generation method of the above real-time operating system, the real-time operating system based on AUTOSAR can be obtained.

FIG. 2 is a schematic diagram of the architecture of the AUTOSAR-based real-time operating system in the embodiment of the present application. Referring to FIG. 2 , the AUTOSAR-based real-time operating system includes: OSAL and EOS. The EOS here is actually RTOS.

BMS APP/RTE is a BMS project, which does not belong to the AUTOSAR-based real-time operating system, but it is connected with the AUTOSAR-based real-time operating system to select and process each module in the AUTOSAR-based real-time operating system according to the specific content of the BMS project. Configuration, so that the rapid development of BMS projects is carried out based on the selected and configured AUTOSAR-based real-time operating system.

In EOS, it includes: Semaphore, Event, Queue, Task, Timer, IPC, Interupt, Clock. These are all existing modules in EOS. Different EOSs have slightly different modules, but they are generally the same. Which EOS the user chooses, which EOS is configured here.

In OSAL, include: OSAL kernel, OS code generation tool, OS manager and system service. Among them, OSAL is compatible with the Autoosar runtime environment. OSAL kernel includes: APP management, Alarm management, OSAL scheduler, Memony management. Users can configure through APP management and Alarm management. Through the OSAL scheduler, Memony management can be realized, the clock in EOS can be controlled, and the information interface can be interacted with EOS through OS manager and OS API to realize system services. During the scheduling process of the OSAL scheduler, the OS code generation tool can also generate configuration codes during its operation, so as to realize the automatic configuration of the real-time operating system based on AUTOSAR.

After obtaining the real-time operating system based on AUTOSAR, the real-time operating system can be used to realize the rapid development of the BMS project at a low development cost.

Next, the usage method of the real-time operating system provided by the embodiment of the present application will be described in detail. The real-time operating system is an AUTOSAR-based real-time operating system generated by using the method for generating a real-time operating system in the foregoing embodiments.

FIG. 3 is a schematic flowchart of a method for using a real-time operating system in an embodiment of the present application. Referring to FIG. 3, the method may include:

S5: Download the OSAL kernel from the AUTOSAR-based real-time operating system, and download the target real-time operating system that matches the vehicle battery management development project from the open source website.

In the real-time operating system based on AUTOSAR, there is a pre-designed OSAL kernel. The OSAL kernel is capable of simulation according to the AUTOSAR standard. Therefore, when using the AUTOSAR-based real-time operating system for rapid development of the BMS project, the OSAL kernel needs to be downloaded first.

Different BMS development projects have different applicable RTOS. Therefore, it is necessary to select the required RTOS according to the currently developed BMS project. In general, RTOS can be directly downloaded from open source websites.

S6: Obtain the user's configuration in the OSAL kernel based on the vehicle battery management development project.

After the OSAL kernel is downloaded, since the OSAL kernel contains various functional modules and configuration functions of various functional modules, the user can perform corresponding configuration through the OSAL kernel, so that the real-time operating system based on AUTOSAR can meet the current BMS project development needs.

After the user completes the configuration in the OSAL kernel, the user's configuration can be obtained, so as to run the user's configuration in the target RTOS, and then use the OSAL code generation tool in the AUTOSAR-based real-time operating system to generate the corresponding code file, and then based on the code The file realizes the rapid development of BMS projects.

S7: Based on the running results configured in the target real-time operating system, use the OSAL code generation tool to generate the code files required for the vehicle battery management development project.

After the user's configuration in the OSAL kernel is run in the target RTOS, the target RTOS will generate a running result after the running process is completed, and then convert the running result into code through the OSAL code generation tool in the AUTOSAR-based real-time operating system file, the code file is what the BMS project needs to achieve rapid development. Therefore, the rapid development of the BMS project can be realized based on the code file.

It can be seen from the above content that the user's configuration in the OSAL kernel is run in the target RTOS, and then the OSAL code generation tool is used to convert the running result into the corresponding code file, so that the BMS project can be developed based on the code file. In the process of BMS project development, there is no need to purchase MICROSAR OS, the Davinci series tools in MICROSAR OS and the static code package provided by Vector, which reduces the development cost of BMS projects. Moreover, since the OSAL kernel and OSAL code generation tools are configured in the AUTOSAR-based real-time operating system, there is no need to rebuild the software architecture or manually write a large number of codes during the development of the BMS project, so as to realize the rapid development of the BMS project.

Further, as a refinement and extension of step S7 in the method shown in Figure 3, when generating the corresponding code file, different configurations and different interfaces are called, and the corresponding interface needs to be loaded to generate the code file, which can ensure that the code file is generated The accuracy, thus ensuring the normal and smooth development of the BMS project.

Specifically, the above step S7 may specifically include:

S71: For different configurations, load interfaces corresponding to different configurations in the target real-time operating system according to the macro generated by the OSAL code generation tool.

In order to determine the interfaces corresponding to different configurations, the corresponding interfaces can be loaded according to the macro generated by the OSAL code generation tool. The macro generated by the OSAL code generation tool can determine the specific type of the target RTOS, and then load the corresponding interface according to the different types of RTOS.

S72: When loading the interface, use the OSAL code generation tool to generate the code file required by the vehicle battery management development project.

After determining the interface corresponding to the current configuration based on the macro generated by the OSAL code generation tool, you can continue to load the interface, and then run the configuration in the RTOS, and then use the OSAL code generation tool to process the running results to obtain the current BMS project required code files.

It can be known from the above that the macro generated by the OSAL code generation tool determines the interface of the current user's configuration in the RTOS, and then loads the interface to run the user's configuration, and then uses the OSAL code generation tool to process the running results to obtain the current BMS project. required code files. Since the interface loaded in the RTOS is based on the configuration of the user, the generated code files can meet the needs of the BMS project development, thereby ensuring the normal and smooth development of the BMS project.

Further, as a refinement and extension of the above step S71, different configurations have different interfaces for specific calls. The specific interfaces for calls are described below from the two aspects of Alarm configuration and Application configuration.

Specifically, the above step S71 may specifically include:

S711: When configured as the clock Alarm setting, determine whether the target RTOS is FreeRTOS according to the macro generated by the OSAL code generation tool; if so, load Clock_setTimeout, Clock_setPeriod, Clock_start in FreeRTOS, and call xTimerStart.

The function of Alarm can be realized by calling Clock_setTimeout, Clock_setPeriod, and Clock_start. And if you want to implement the SetRelAlarm function in AUTOSAR OS, then you need to call the xTimerStart interface API of FreeRTOS through the corresponding interface of the OSAL scheduler.

S712: When configured to apply Application settings, determine whether the target RTOS is FreeRTOS according to the macro generated by the OSAL code generation tool; if so, load the vTaskStartScheduler in FreeRTOS, and call xSemaphoreCreateMutex, xSemaphoreCreateMutex, Semaphore_post; and generate according to the OSAL code generation tool The macro determines whether the target RTOS is SYSbios; if so, loads BIOS_start() in SYSbios.

The OSAL scheduler also has most of the functions of the Core module in AUTOSAR OS. For example: Os_Api_StartOS of the Core module in AUTOSAR OS. The OSAL scheduler calls the internal Application module, which first determines whether the current macro is FreeRTOS, and if so, calls the FreeRTOS API interface vTaskStartScheduler to start the OS. If it is TI's SYSbios, call the API interface BIOS_start() of SYSbios to start the OS. Finally, the OSAL scheduler can also implement the related interfaces called by the RTE module in AUTOSAR. For example: task activation (ActivateTask), alarm setting (SetRelAlarm), etc.

So far, the core processing flow of the OSAL scheduler will be described.

Fig. 4 is a schematic diagram of the core processing flow of the OSAL scheduler in the embodiment of the present application, as shown in Fig. 4, the flow may include:

First, the OS start-stop and OS kernel initialization in the OSAL kernel are controlled by the ECUM module, and the OS task activation and ALARM settings in the OSAL kernel are controlled by the RTE module.

Then, in the OSAL kernel, it is judged whether the supported RTOS type is satisfied. If the type of RTOS supports it, OSAL loads the corresponding RTOS-related API interface. If the type of RTOS does not support it, the process ends.

Then, call the RTOS interface for processing, that is, run the user's configuration, and then generate the corresponding code file.

Finally, end the whole process.

If the RTOS currently configured by the code generation tool is FreeRTOS, you need to call xSemaphoreCreateMutex to create a signal flag for task activation, call the xSemaphoreCreateMutex interface to implement the startup task activation interface (ActivateTask) of the runtime environment RTE, and call the Semaphore_post semaphore interface of FreeRTOS to accomplish.

Before RTE starts, because the OS has been initialized, the startup scheduling in FreeRTOS is called, that is, the tasks are all running, which obviously does not conform to the AUTOSAR specification. Therefore, it is necessary to introduce the semaphore of FreeRTOS, so that the task is suspended before RTE starts, and then activate the task by submitting the semaphore according to the configuration requirements of RTE.

It can be seen from the above that for the Alarm configuration and Application configuration, according to the macro generated by the OSAL code generation tool, it is determined whether the target RTOS is FreeRTOS, and then when the target RTOS is determined to be FreeRTOS, the specific call interface is given to avoid interface call errors, and then Improve the accuracy of code file generation to further ensure the normal and smooth development of BMS projects.

Based on the same inventive concept, as an implementation of the above generation method, an embodiment of the present application further provides a real-time operating system generation device. FIG. 5 is a schematic structural diagram of a device for generating a real-time operating system in an embodiment of the present application. Referring to FIG. 5, the device may include:

The design module 51 is used to generate the operating system abstraction layer OSAL kernel based on the automotive open system architecture AUTOSAR standard, and the OSAL kernel is used to make the real-time operating system RTOS run under the AUTOSAR standard;

An encapsulation module 52, configured to encapsulate the corresponding application program interface API of the RTOS based on the OSAL kernel;

The obtaining module 53 is used to obtain an OSAL code generation tool, and the OSAL code generation tool is used to generate a code file consistent with the OSAL kernel for the user's configuration in the OSAL kernel and the call process to the RTOS;

The generating module 54 is configured to generate an AUTOSAR-based real-time operating system based on the OSAL kernel, the RTOS after encapsulating the API, and the OSAL code generation tool.

Further, the design module is specifically used to generate the OSAL kernel including multiple objects in the automotive open system architecture operating system AUTOSAR OS based on the AUTOSAR standard.

Further, the design module is specifically used to generate an operating system abstraction layer OSAL scheduler, and the OSAL scheduler is used to manage kernel parameter initialization, kernel startup and shutdown, current kernel acquisition, application initialization, interrupt initialization, clock initialization, and external interfaces Call; Generate the data structure of multiple objects in the AUTOSAR OS based on the AUTOSAR standard; Generate the OSAL kernel based on the OSAL scheduler and the data structure.

Further, the design module is specifically configured to generate an application stack, task-associated attribute table, task handle table, clock-associated attribute table, clock handle table, signal Association attribute table, event association attribute table, event handle table, ISRs nested flag, calculation attribute table, source attribute table, application static code and configuration code architecture; when the multiple objects include a clock, based on the AUTOSAR standard generates identification, clock name, cycle running time, timeout time, and clock implementation interface.

Further, the acquisition module is specifically used to generate multiple link file generation templates, and different link file generation templates correspond to different compilers; based on the link file generation templates, the static variables defined according to the code and the OSAL kernel Consistent rules in the data structure are generated by the OSAL code generation tool.

It should be pointed out here that the description of the above embodiment of the generation device is similar to the description of the above embodiment of the generation method, and has similar beneficial effects as the embodiment of the generation method. For the technical details not disclosed in the embodiment of the generation device of this application, please refer to the description of the embodiment of the generation method of this application for understanding.

Based on the same inventive concept, as an implementation of the above using method, an embodiment of the present application also provides a device for using a real-time operating system. The using device is applied to the real-time operating system generated by the above-mentioned generating device. FIG. 6 is a schematic structural diagram of a device for using a real-time operating system in an embodiment of the present application. Referring to FIG. 6, the device may include:

The download module 61 is used for downloading the OSAL kernel from the real-time operating system based on AUTOSAR, and downloading the target real-time operating system matching the vehicle battery management development project from an open source website;

The configuration module 62 is used to obtain the user's configuration in the OSAL kernel based on the vehicle battery management development project;

The generation module 63 is configured to use the OSAL code generation tool to generate code files required by the vehicle battery management development project based on the running results of the configuration in the target real-time operating system.

Further, the generation module is specifically configured to load the interface corresponding to the different configuration in the target real-time operating system according to the macro generated by the OSAL code generation tool for different configurations; when loading the interface , using the OSAL code generation tool to generate the code files required by the vehicle battery management development project.

Further, the generation module is specifically used to determine whether the target real-time operating system is FreeRTOS according to the macro generated by the OSAL code generation tool when the configuration is clock setting; if so, load the Clock_setTimeout, Clock_setPeriod, Clock_start, and call xTimerStart; when the configuration is an application setting, determine whether the target real-time operating system is FreeRTOS according to the macro generated by the OSAL code generation tool; if so, load the vTaskStartScheduler in the FreeRTOS , and call xSemaphoreCreateMutex, xSemaphoreCreateMutex, Semaphore_post; and determine whether the target real-time operating system is SYSbios according to the macro generated by the OSAL code generation tool; if so, load BIOS_start() in the SYSbios.

It should be pointed out here that the description of the above embodiment of the use device is similar to the description of the above embodiment of the use method, and has similar beneficial effects as the embodiment of the use method. For the technical details not disclosed in the embodiment of the device used in this application, please refer to the description of the embodiment of the method used in this application for understanding.

Based on the same inventive concept, as an implementation of the above generating method and using method, an embodiment of the present application also provides an electronic device. Fig. 7 is a schematic structural diagram of an electronic device in an embodiment of the present application. Referring to Fig. 7, the electronic device may include: a processor 71, a memory 72, and a bus 73; communication; the processor 71 is used to call the program instructions in the memory 72, so as to execute the generation method or the use method in one or more embodiments above.

It should be pointed out here that the description of the above electronic device embodiment is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. For technical details not disclosed in the electronic device embodiments of the present application, please refer to the description of the method embodiments of the present application for understanding.

Based on the same inventive concept, as an implementation of the above generating method and using method, the embodiment of the present application also provides a computer-readable storage medium, which may include: a stored program; wherein, when the program is running, the storage medium is controlled The device where it is located executes the generating method or using method in one or more of the above embodiments.

It should be pointed out here that the description of the above storage medium embodiment is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. For technical details not disclosed in the storage medium embodiments of the present application, please refer to the description of the method embodiments of the present application for understanding.

Finally, the process of real-time operating system design based on AUTOSAR simulation in the embodiment of the present application is described again.

By designing the core of AUTOSAR simulation (OSAL), mainstream real-time operating systems have to quickly develop vehicle application software with AUTOSAR standards. And the developed software has a complete kernel standard and a unified program interface, and the reusability of the software has been greatly improved.

The design of the real-time operating system based on AUTOSAR simulation, according to the requirements of the AUTOSAR OS standard, through the design of the OSAL kernel (encapsulating and calling the RTOS) and OS code generation tools, so that the current popular real-time operating system (RTOS) meets the requirements of the AUTOSAR OS.

The OSAL kernel is designed to realize related objects in AUTOSAR OS (Core, Application, Task, Interrupt Service, Alarm, Counter, Resource, IOC) as the output target, and the module API interface provided by RTOS as the input object (such as TI's SYSbios, related Interfaces include Semaphores, MailBoxes, Queues, Clock, HWI/SWI, etc.), the OSAL kernel encapsulates and designs the corresponding API interfaces of the RTOS, and the designed OSAL kernel is compatible with the AUTOSAR runtime environment, and can be generated by combining the designed OS code The configuration code generated by the tool makes the RTOS completely consistent with the AUTOSAR OS in function.

The OS code generation tool can select the required RTOS (such as FreeRTOS) according to the needs of the chip, and then implement the relevant configuration of the AUTOSAR OS objects Core, Application, Task, Interrupt Service, Alarm, Counter, Resource, and IOC for the selected RTOS to generate and OSAL Kernel matching configuration code, project construction configuration files and link files.

The detailed design is as follows:

According to the AUTOSAR standard, the traditional RTOS needs to implement the AUTOSAR OS, and the OSAL kernel design needs to do the following steps:

1. The OSAL kernel needs to design an OSAL scheduler to manage OS kernel (Core) parameter initialization, kernel (Core) start and stop, current core (Core) acquisition, Application initialization, interrupt initialization, Alarm initialization, etc. At the same time, it can manage OS services, provide an external call interface, and is compatible with the RTE module in AUTOSAR. The OSAL scheduler is similar to the trap in AUTOSAR OS, but the processing process is completely different. The key core processing lies in the judgment of different RTOS types, such as the setting of the Alarm. In the OSAL kernel, the macro generated by the OS code tool must first be used to determine the current Whether the RTOS is FreeRTOS, if so, the OSAL kernel will load FreeRTOS related Clock_setTimeout, Clock_setPeriod, Clock_start to realize the function of Alarm. At the same time, the OSAL scheduler has most of the functions of the Core module in AUTOSAR OS. For example, in the Os_Api_StartOS of the Core module in AUTOSAR OS, the OSAL scheduler calls the internal Application module. This module first judges whether the current macro is FreeRTOS, and if so, calls the FreeRTOS API interface vTaskStartScheduler to start the OS. If it is TI's SYSbios, call the API interface BIOS_start() of SYSbios to start the OS. Preferably, the OSAL scheduler implements the relevant interfaces called by the RTE module in AUTOSAR, such as task activation (ActivateTask), alarm setting (SetRelAlarm), etc.

2. In order to enable the OSAL kernel to manage and configure AUTOSAR OS-related objects in the RTOS, and at the same time adapt to the requirements of the OSAL code generation tool, in accordance with the requirements of the AUTOSAR standard, it is necessary to design the Application, Alarm, Interrupt, Counter, and Task data structures in the OSAL kernel .

a) If the application configuration is required, the Application structure needs to have the Application stack (dynamic state identification when creating the Application), task association attribute table, task handle table, Alarm association attribute table, Alarm handle table, signal association attribute table , event association attribute table, event handle table, ISRs nested flags, Counters attribute table, Resources attribute table, etc., at the same time, it is necessary to design the static code and configurable code architecture of Application. According to the AUTOSAR standard, the static code of Application is responsible for the initialization of corresponding resources in AUTOSAR, and completes the task list, alarm list, event list, and resource initialization of all rights according to the Applications configuration list. The key to its design is that it can judge different types of RTOS by reading the macro of the code generation tool to realize the function of RTE task activation in AUTOSAR OS. For example, when the RTOS currently configured by the code generation tool is FreeRTOS, it is necessary to call xSemaphoreCreateMutex to create the task activation Signal flag, call the xSemaphoreCreateMutex interface to implement the startup task activation interface (ActivateTask) of the runtime environment RTE, which needs to be implemented by calling the Semaphore_post semaphore interface of FreeRTOS. Because the OS has been initialized before the RTE startup, the startup in FreeRTOS is called. Scheduling, that is, tasks are running, obviously does not comply with the AUTOSAR specification, so it is necessary to introduce FreeRTOS semaphores, so that tasks are suspended before RTE starts, and then activate tasks by submitting semaphores according to RTE configuration requirements.

b) If the Alarm configuration is required, the Alarm structure needs to have ID, Alarm name, cycle running time, timeout time, and Alarm implementation interface. According to the requirements of the AUTOSAR standard, the Alarm structure is defined. According to the AUTOSAR standard, the key to its design is to be able to judge different types of RTOS by reading the macros of the code generation tool to realize the start and stop function of the RTE Alarm in the AUTOSAR OS. For example, when the RTOS currently configured by the code generation tool is FreeRTOS, the The SetRelAlarm function in AUTOSAR OS requires the corresponding interface of the OSAL scheduler to call the xTimerStart interface API of FreeRTOS.

3. According to the AUTOSAR standard, software modularization and configurability are required. By designing a set of OSAL code generation tools, the code can be generated according to the RTOS selected by the developer, and the link file and build file associated with the compiler will be generated at the same time. This file is used for engineering development and construction. Therefore, it is required to have a set of link file generation templates for different compilers in the design of the OSAL code generation tool. In addition, the static variables defined by the code generated by the OSAL code generation tool are consistent with the structure designed in the OSAL kernel.

Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than limiting them; although the application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: It is still possible to modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the technical solutions of the various embodiments of the present application. All of them should be covered by the scope of the claims and description of the present application. In particular, as long as there is no structural conflict, the technical features mentioned in the various embodiments can be combined in any manner. The present application is not limited to the specific embodiments disclosed herein, but includes all technical solutions falling within the scope of the claims.

Claims

A method for generating a real-time operating system, characterized in that the method for generating includes:

Generate an operating system abstraction layer OSAL kernel based on the automotive open system architecture AUTOSAR standard, and the OSAL kernel is used to make the real-time operating system RTOS run under the AUTOSAR standard;

Encapsulate the corresponding application program interface API of the RTOS based on the OSAL kernel;

Obtain an OSAL code generation tool, and the OSAL code generation tool is used to generate a code file consistent with the OSAL kernel for the user's configuration in the OSAL kernel and the call process to the RTOS;

A real-time operating system based on AUTOSAR is generated based on the OSAL kernel, the RTOS after encapsulating the API, and the OSAL code generation tool.
The generating method according to claim 1, wherein the operating system abstraction layer OSAL kernel is generated based on the Automobile Open System Architecture AUTOSAR standard, comprising:

Generate the OSAL kernel including multiple objects in the automotive open system architecture operating system AUTOSAR OS based on the AUTOSAR standard.
The generation method according to claim 2, wherein, the described OSAL kernel comprising multiple objects in the automotive open system architecture operating system AUTOSAR OS is generated based on the AUTOSAR standard, comprising:

Generate an operating system abstraction layer OSAL scheduler, the OSAL scheduler is used to manage kernel parameter initialization, kernel start and stop, current core acquisition, application initialization, interrupt initialization, clock initialization and external interface calls;

Generate data structures of multiple objects in the AUTOSAR OS based on the AUTOSAR standard;

The OSAL kernel is generated based on the OSAL scheduler and the data structure.
The generation method according to claim 3, wherein the data structure of generating multiple objects in the AUTOSAR OS based on the AUTOSAR standard includes:

When the multiple objects include an application, generate an application stack, a task-related attribute table, a task handle table, a clock-related attribute table, a clock handle table, a signal-related attribute table, an event-related attribute table, and an event handle based on the AUTOSAR standard Tables, nested flags for ISRs, computed property tables, source property tables, application static code and configurable code architecture;

When the plurality of objects includes a clock, an identifier, a clock name, a cycle running time, a timeout time, and a clock implementation interface are generated based on the AUTOSAR standard.
The generation method according to claim 1, wherein said obtaining the OSAL code generation tool comprises:

Generate a variety of link file generation templates, and different link file generation templates correspond to different compilers;

Generate the template based on the link file, and generate the OSAL code generation tool according to the rule that the static variable defined by the code is consistent with the data structure in the OSAL kernel.
A method for using a real-time operating system, characterized in that the method for using is applied to a real-time operating system generated by the generating method according to any one of claims 1 to 5, and the method for using includes:

Download the OSAL kernel from the AUTOSAR-based real-time operating system, and download the target real-time operating system that matches the vehicle battery management development project from an open source website;

Obtain the user's configuration in the OSAL kernel based on the vehicle battery management development project;

Based on the operation result configured in the target real-time operating system, the OSAL code generation tool is used to generate the code files required by the vehicle battery management development project.
The method according to claim 6, characterized in that, based on the operation result configured in the target real-time operating system, the OSAL code generation tool is used to generate the required code for the vehicle battery management development project. code files, including:

For different configurations, load the interface corresponding to the different configurations in the target real-time operating system according to the macro generated by the OSAL code generation tool;

When loading the interface, the OSAL code generation tool is used to generate the code files required by the vehicle battery management development project.
The method according to claim 7, characterized in that, for different configurations, according to the macros generated by the OSAL code generation tool, the interfaces corresponding to the different configurations in the target real-time operating system are loaded, including :

When the configuration is clock setting, determine whether the target real-time operating system is FreeRTOS according to the macro generated by the OSAL code generation tool; if so, load Clock_setTimeout, Clock_setPeriod, Clock_start in the FreeRTOS, and call xTimerStart;

When the configuration is an application setting, determine whether the target real-time operating system is FreeRTOS according to the macro generated by the OSAL code generation tool; if so, load the vTaskStartScheduler in the FreeRTOS, and call xSemaphoreCreateMutex, xSemaphoreCreateMutex, Semaphore_post; and Determine whether the target real-time operating system is SYSbios according to the macro generated by the OSAL code generation tool; if so, load BIOS_start() in the SYSbios.
A generating device for a real-time operating system, characterized in that the generating device includes:

A design module for generating an operating system abstraction layer OSAL kernel based on the automotive open system architecture AUTOSAR standard, and the OSAL kernel is used to make the real-time operating system RTOS run under the AUTOSAR standard;

An encapsulation module, configured to encapsulate the corresponding application program interface API of the RTOS based on the OSAL kernel;

The obtaining module is used to obtain an OSAL code generation tool, and the OSAL code generation tool is used to generate a code file consistent with the OSAL kernel for the user's configuration in the OSAL kernel and the call process to the RTOS;

The generation module is used to generate an AUTOSAR-based real-time operating system based on the OSAL kernel, the RTOS after encapsulating the API, and the OSAL code generation tool.
A device for using a real-time operating system, characterized in that the device for using is applied to a real-time operating system generated by the generating device according to claim 9, and the device for using includes:

A download module, used to download the OSAL kernel from the AUTOSAR-based real-time operating system, and download the target real-time operating system that matches the vehicle battery management development project from an open source website;

The configuration module is used to obtain the user's configuration in the OSAL kernel based on the vehicle battery management development project;

A generating module, configured to generate code files required by the vehicle battery management development project by using the OSAL code generation tool based on the running result of the configuration in the target real-time operating system.
An electronic device, characterized in that it includes: a processor, a memory, and a bus;

Wherein, the processor and the memory complete mutual communication through the bus; the processor is used to invoke program instructions in the memory to execute the generating method described in any one of claims 1 to 5 method or the method of use described in any one of claims 6 to 8.
A computer-readable storage medium, characterized by comprising: a stored program;

Wherein, when the program is running, the device where the storage medium is located is controlled to execute the generation method described in any one of claims 1 to 5 or the use method described in any one of claims 6 to 8.