Software framework configuration method and device, storage medium and electronic equipment

Abstract

The invention discloses a software framework configuration method and device, a storage medium and electronic equipment. The method comprises the steps that an operation system abstraction layer is arranged for the automobile software framework based on a portable operation system interface, the operation system abstraction layer is used for integrating service functions provided by the automobile software framework, and the automobile software framework calls all operation systems to achieve the service functions through the operation system abstraction layer; a target interface between the automobile software framework and a target operating system is determined based on a target service function provided by the automobile software framework, the service function comprises the target service function, the target interface comprises a portable operating system interface, and each operating system comprises the target operating system; communication between the automobile software framework and the target operation system is established through the target interface, and the target service function is achieved. The technical problem that the efficiency of transplanting the automobile software framework in different operating systems is low is solved.

Description

Technical Field

[0001] The present application relates to the field of computers, and in particular to a configuration method and device for a software framework, a storage medium, and an electronic device. Background Art

[0002] In the current automotive software development environment, the automotive software framework Adaptive AUTOSAR (APAUTOSAR for short) is a key component of the next-generation automotive software architecture and is mainly used in various operating systems. However, when porting AP AUTOSAR to the operating system, due to the significant differences in the calling interface, compilation language version, and dependent library version of different operating systems, the porting cost and maintenance difficulty of AP AUTOSAR on the operating system have increased significantly. In summary, there are technical problems in the related technologies that are low in efficiency in porting the automotive software framework.

[0003] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0004] The embodiments of the present application provide a method and device for configuring a software framework, a storage medium, and an electronic device to at least solve the technical problem of low efficiency in transplanting an automobile software framework between different operating systems.

[0005] According to one aspect of an embodiment of the present application, a method for configuring a software framework is provided, comprising: setting an operating system abstraction layer for an automobile software framework based on a portable operating system interface, wherein the operating system abstraction layer is used to integrate business functions provided by the automobile software framework, and the automobile software framework calls each operating system through the operating system abstraction layer to implement the business functions; determining a target interface between the automobile software framework and a target operating system based on a target business function provided by the automobile software framework, wherein the business function includes the target business function, the target interface includes the portable operating system interface, and the each operating system includes the target operating system; and establishing communication between the automobile software framework and the target operating system through the target interface to implement the target business function.

[0006] According to another aspect of an embodiment of the present application, a configuration device for a software framework is also provided, including: a setting module, used to set an operating system abstraction layer for an automobile software framework based on a portable operating system interface, wherein the operating system abstraction layer is used to integrate business functions provided by the automobile software framework, and the automobile software framework calls each operating system through the operating system abstraction layer to implement the business functions; a determination module, used to determine a target interface between the automobile software framework and a target operating system based on a target business function provided by the automobile software framework, wherein the business function includes the target business function, the target interface includes the portable operating system interface, and the each operating system includes the target operating system; an implementation module, used to establish communication between the automobile software framework and the target operating system through the target interface to implement the target business function.

[0007] Optionally, the device is used to set up an operating system abstraction layer for an automotive software framework based on a portable operating system interface in the following manner: setting a corresponding function call function for each function in the business function; and implementing the function call function in the operating system abstraction layer based on the portable operating system interface.

[0008] Optionally, the device is used to implement the function call function in the operating system abstraction layer based on the portable operating system interface in the following manner: detect whether the target operating system supports the portable operating system interface and define an interface function macro; when the interface function macro indicates that the target system supports the portable operating system interface, use the portable operating system interface to implement the function call function; when the interface function macro indicates that the target system does not support the portable operating system interface, use the interface function macro to call an equivalent interface of the target system to implement the function call function, wherein the equivalent interface is provided for the target operating system to execute the business function.

[0009] Optionally, the device is used to set an operating system abstraction layer for an automobile software framework based on a portable operating system interface in the following manner: obtain a first programming language version and a first dependent library corresponding to the automobile software framework, and a second programming language version and a second dependent library corresponding to the target system, and define a version function macro and a dependent library function macro, wherein the version function macro is used to indicate whether the target system supports the first programming language version, and the dependent library function macro is used to indicate whether the target system can call the first dependent library; when the version function macro indicates that the target system supports the first programming language version, the automobile software framework is compiled on the target system using the programming language of the first programming language version; when the target version function macro indicates that the target system does not support the first programming language version, the automobile software framework is compiled on the target system using the programming language of the second programming language version; when the dependent library function macro indicates that the target system can call the first dependent library, the first dependent library is called to implement the business function; when the dependent library function macro indicates that the target system cannot call the first dependent library, the function macro is used to call the second dependent library to implement the business function.

[0010] Optionally, the device is used to set an operating system abstraction layer for the automobile software framework based on the portable operating system interface in the following manner: respectively encapsulate the first business function and the second business function that the automobile software framework needs to implement to obtain a first business function module and a second business function module, wherein the first business function and the second business function are of different types; deploy the first business function module and the second business function module in the operating system abstraction layer; respectively encapsulate the first system function and the second system function provided by the target system to obtain a first system function module and a second system function module, wherein the first system function and the second system function are of different types; deploy the first system function module and the second system function module in the operating system abstraction layer; wherein the first business function module and at least one of the first system function module and the second system function module can work together, and the second business function module and at least one of the first system function module and the second system function module can work together.

[0011] Optionally, the device is also used to: obtain a first business version protocol and a second business version protocol corresponding to the first business function, wherein the first business version protocol and the second business version protocol are both used to implement the first business function; respectively encapsulate the first business version protocol and the second business version protocol to obtain a first business version protocol module and a second business version protocol module; and deploy the first business version protocol module and the second business version protocol module in the operating system abstraction layer.

[0012] Optionally, the device is also used to: when the second business function needs to call the first business version protocol, use the corresponding first business version protocol module; when the first system function needs to call the first business version protocol, use the corresponding first business version protocol module; when the second system function needs to call the first business version protocol, use the corresponding first business version protocol module.

[0013] Optionally, the device is also used to: when the second business function needs to call the second business version protocol, use the corresponding first business version protocol module; when the first system function needs to call the second business version protocol, use the corresponding first business version protocol module; when the second system function needs to call the second business version protocol, use the corresponding first business version protocol module.

[0014] According to another aspect of the embodiments of the present application, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program is configured to execute the configuration method of the above-mentioned software framework when running.

[0015] According to another aspect of the embodiment of the present application, a computer program product or a computer program is provided, the computer program product or the computer program includes computer instructions, the computer instructions are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the configuration method of the software framework as described above.

[0016] According to another aspect of the embodiments of the present application, there is also provided an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the configuration method of the software framework through the computer program.

[0017] In an embodiment of the present application, an operating system abstraction layer is set for the automobile software framework based on a portable operating system interface, wherein the operating system abstraction layer is used to integrate business functions provided by the automobile software framework, and the automobile software framework calls each operating system through the operating system abstraction layer to implement the business functions; a target interface between the automobile software framework and the target operating system is determined based on the target business functions provided by the automobile software framework, wherein the business functions include target business functions, the target interface includes a portable operating system interface, and each operating system includes a target operating system; communication between the automobile software framework and the target operating system is established through the target interface to implement the target business functions. Through function macros and conditional compilation mechanisms, not only the correct implementation of the business functions is guaranteed, but also the execution efficiency of the business functions is improved, so as to achieve the purpose of flexibly adapting to the characteristics of different operating systems, thereby achieving the technical effect of efficient and consistent business function implementation, and further solving the technical problem of low efficiency in transplanting automobile software frameworks in different operating systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0019] Figure 1 is a schematic diagram of an application environment of an optional software framework configuration method according to an embodiment of the present application;

[0020] Figure 2 is a flowchart of an optional method for configuring a software framework according to an embodiment of the present application;

[0021] Figure 3 is a schematic diagram of an optional method for configuring a software framework according to an embodiment of the present application;

[0022] Figure 4 is a schematic diagram of another optional method for configuring a software framework according to an embodiment of the present application;

[0023] Figure 5 is a schematic diagram of another optional method for configuring a software framework according to an embodiment of the present application;

[0024] Figure 6 is a schematic diagram of a configuration device of an optional software framework according to an embodiment of the present application;

[0025] Figure 7 is a structural diagram of a configuration product of an optional software framework according to an embodiment of the present application;

[0026] Figure 8It is a schematic diagram of the structure of an optional electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0027] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0028] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0029] The present application is described below in conjunction with embodiments:

[0030] According to one aspect of an embodiment of the present application, a method for configuring a software framework is provided. Optionally, in this embodiment, the method for configuring the software framework can be applied to Figure 1 In the hardware environment composed of the server 101 and the terminal device 103 shown in FIG. Figure 1As shown, the server 101 is connected to the terminal 103 via a network, and can be used to provide services for the terminal device or the application installed on the terminal device. The application can be a video application, an instant messaging application, a browser application, an educational application, a game application, etc. A database 105 may be set up on the server or independently of the server to provide data storage services for the server 101, for example, a game data storage server. The above-mentioned network may include, but is not limited to, a wired network and a wireless network, wherein the wired network includes, a local area network, a metropolitan area network and a wide area network; the wireless network includes, Bluetooth, WIFI and other networks that implement wireless communication; the terminal device 103 may be a terminal configured with an application, and may include, but is not limited to, at least one of the following: a mobile phone (such as an Android phone, an iOS phone, etc.), a laptop computer, a tablet computer, a PDA, a MID (Mobile Internet Devices), a PAD, a desktop computer, a smart TV, an intelligent voice interaction device, a smart home appliance, a vehicle-mounted terminal, an aircraft, a virtual reality (VR) terminal, an augmented reality (AR) terminal, a mixed reality (MR) terminal and other computer devices; the above-mentioned server may be a single server, a server cluster consisting of multiple servers, or a cloud server.

[0031] Combination Figure 1 As shown, the configuration method of the above software framework can be executed by an electronic device, which can be a terminal device or a server. The configuration method of the above software framework can be implemented by the terminal device or the server respectively, or by the terminal device and the server together.

[0032] The above is only an example and is not specifically limited in this embodiment.

[0033] Optionally, as an optional implementation, as Figure 2 As shown, the configuration method of the above software framework includes:

[0034] S202, setting an operating system abstraction layer for the automobile software framework based on the portable operating system interface, wherein the operating system abstraction layer is used to integrate business functions provided by the automobile software framework, and the automobile software framework calls each operating system through the operating system abstraction layer to implement the business functions;

[0035] Optionally, in an embodiment of the present application, the above-mentioned operating system abstraction layer refers to an intermediate layer (OSAL layer) designed for interaction between the automotive software framework and the underlying operating system, including but not limited to abstracting and encapsulating the business functions of automotive software frameworks such as Adaptive AUTOSAR, so that they can run on different types of real-time operating systems (RTOS) or other operating systems without modifying the business logic code.

[0036] For example, a unified set of APIs is first defined based on the portable operating system interface (such as POSIX). These APIs can cover the basic operations required by the business functions in the automotive software framework, such as thread management, file system access, memory operations, etc. By implementing these APIs in the operating system abstraction layer, the business function modules provided by the automotive software framework are decoupled from the specific underlying operating system. At this point, the business function modules only need to call the APIs in the OSAL layer without directly calling the system calls of a specific operating system.

[0037] Furthermore, within the OSAL layer, according to the target operating system's support for the POSIX interface and C++ standard features, the corresponding system functions are selectively called through function macros and conditional compilation mechanisms to ensure the correct implementation of business functions.

[0038] S204, determining a target interface between the automobile software framework and the target operating system based on a target business function provided by the automobile software framework, wherein the business function includes a target business function, the target interface includes a portable operating system interface, and each operating system includes a target operating system;

[0039] Optionally, in an embodiment of the present application, the above-mentioned target business functions refer to specific functions or services in the automobile software framework that need to be implemented on the target operating system, including but not limited to highly automated driving, vehicle communication (V2X), remote software updates (OTA) and other functions; the above-mentioned target interface refers to the bridge connecting the automobile software framework and the target operating system, which is designed based on a portable operating system interface (such as POSIX) to ensure that business functions can consistently call system services across different operating system platforms.

[0040] For example, the target business functions in the automotive software framework are first analyzed to identify the underlying system services required by these functions at runtime, such as thread management, memory allocation, file system access, etc. Then, a target interface is defined based on the portable operating system interface (such as POSIX), which includes a series of unified APIs for encapsulating and providing the above system services; the operating system abstraction layer (OSAL) adapts the APIs in the target interface to corresponding system calls according to the specific implementation details of the target operating system. Finally, the automotive software framework calls the APIs provided by the OSAL layer through the target interface to implement the target business functions on the target operating system without directly relying on the characteristics of the operating system.

[0041] S206, establishing communication between the automobile software framework and the target operating system through the target interface to realize the target business function.

[0042] In an exemplary embodiment, Figure 3 is a schematic diagram of an optional software framework configuration method according to an embodiment of the present application, wherein the operating system abstraction layer framework is as follows Figure 3 As shown in the figure, if the target operating system is FreeRTOS, the OSAL layer will translate the thread management API in the target interface into the thread management function call of FreeRTOS; if it is RT-Thread, the RT-Thread function can be used accordingly; finally, the business function module of the automotive software framework calls the services provided by the OSAL layer through the target interface, thereby realizing its functions on the target operating system, ensuring that the business function module always interacts with the target operating system through a unified, operating system-independent interface, thereby simplifying the complexity of cross-operating system porting and improving the portability and operating efficiency of the software framework.

[0043] Through the embodiments of the present application, an operating system abstraction layer is set for the automobile software framework based on a portable operating system interface, wherein the operating system abstraction layer is used to integrate the business functions provided by the automobile software framework, and the automobile software framework calls each operating system through the operating system abstraction layer to implement the business functions; based on the target business functions provided by the automobile software framework, a target interface between the automobile software framework and the target operating system is determined, wherein the business functions include target business functions, the target interface includes a portable operating system interface, and each operating system includes a target operating system; communication between the automobile software framework and the target operating system is established through the target interface to implement the target business functions. Through function macros and conditional compilation mechanisms, not only the correct implementation of the business functions is guaranteed, but also the execution efficiency of the business functions is improved, so as to achieve the purpose of flexibly adapting to the characteristics of different operating systems, thereby achieving the technical effect of efficient and consistent business function implementation, and thus solving the technical problem of low efficiency in transplanting automobile software frameworks in different operating systems.

[0044] As an optional solution, the above-mentioned setting of an operating system abstraction layer for the automobile software framework based on the portable operating system interface includes: setting a corresponding function call function for each function in the above-mentioned business function; and implementing the above-mentioned function call function in the above-mentioned operating system abstraction layer based on the above-mentioned portable operating system interface.

[0045] In an exemplary embodiment, taking the application scenario of realizing the vehicle remote software update (OTA) function as an example, the automotive software framework AP AUTOSAR needs to communicate with the target operating system to complete the software update process; for this purpose, firstly, corresponding function call functions are set for key steps such as file download, file storage, and system restart in the OTA function. These functions are defined as standard interfaces within AP AUTOSAR for interacting with the operating system abstraction layer (OSAL). Next, these function call functions are specifically implemented in the OSAL layer based on the POSIX portable operating system interface. For example, the file download function call function is implemented in the OSAL layer as a network communication function that calls the POSIX standard; the file storage function is implemented through the POSIX file system function; and the system restart function corresponds to the POSIX system control function.

[0046] It should be noted that in actual applications, the types of target operating systems may include but are not limited to RTOS such as FreeRTOS, RT-Thread, RtosFreeRTOS, RTX, ThreadX, and UNIX-like systems such as Linux. In addition, the target business functions may involve various software modules of the vehicle, such as driver assistance systems, infotainment systems, vehicle diagnostic systems, etc. The technical solution of the present application can be widely used in these diverse situations, not only limited to the OTA functions in the above examples, but any automotive software functions that need to interact with the underlying operating system can be defined and implemented in the OSAL layer. The corresponding function call function can be based on POSIX or other portable operating system interfaces to achieve rapid porting and efficient operation on different operating systems.

[0047] Through the embodiments of the present application, AP AUTOSAR does not need to care whether the target operating system directly supports the POSIX interface. It only needs to call through the standard API of the OSAL layer. The OSAL layer will be responsible for converting the API into a system call that matches the target operating system to ensure the consistency of OTA functions on different operating systems.

[0048] As an optional scheme, the above-mentioned function call function is implemented in the above-mentioned operating system abstraction layer based on the above-mentioned portable operating system interface, including: detecting whether the above-mentioned target operating system supports the above-mentioned portable operating system interface, and defining an interface function macro; when the above-mentioned interface function macro indicates that the above-mentioned target system supports the above-mentioned portable operating system interface, using the above-mentioned portable operating system interface to implement the above-mentioned function call function; when the above-mentioned interface function macro indicates that the target system does not support the above-mentioned portable operating system interface, using the above-mentioned interface function macro to call the equivalent interface of the above-mentioned target system to implement the above-mentioned function call function, wherein the above-mentioned equivalent interface is provided for the above-mentioned target operating system to execute the above-mentioned business function.

[0049] In an exemplary embodiment, Figure 4 is a schematic diagram of another optional software framework configuration method according to an embodiment of the present application, the POSIX interface is implemented as follows Figure 4 As shown in the figure, taking the transplantation of AP AUTOSAR on the target operating system FreeRTOS as an example, in the initialization phase, it will detect whether FreeRTOS supports the POSIX portable operating system interface. Since FreeRTOS itself does not directly support the POSIX interface, the target operating system will define specific interface function macros, such as POSIX_PSE51; in the subsequent code implementation, the business function module of AP AUTOSAR is operated through the function call function, such as file reading and writing. When encountering a function that needs to call the POSIX interface, the target operating system will check the POSIX_PSE51 macro and find that FreeRTOS does not directly support the POSIX interface. Therefore, the function call function will call the equivalent interface of FreeRTOS through the macro, such as using the file system function of FreeRTOS to replace the file reading and writing operation of POSIX to realize the business function. That is, even if the target operating system does not support the POSIX interface, it can call its own interface by defining and using the function macro to ensure the execution of the function call function.

[0050] Through the embodiments of the present application, a method is adopted to detect the degree of support of the target operating system for the portable operating system interface and define the interface function macro, thereby achieving the technical effect of unifying API interface calls in different operating system environments, and achieving the purpose of quickly porting and efficiently running automotive software frameworks such as AP AUTOSAR on multiple RTOS.

[0051] As an optional solution, the above-mentioned setting of an operating system abstraction layer for an automobile software framework based on a portable operating system interface includes: obtaining a first programming language version and a first dependent library corresponding to the above-mentioned automobile software framework, and a second programming language version and a second dependent library corresponding to the above-mentioned target system, and defining a version function macro and a dependent library function macro, wherein the above-mentioned version function macro is used to indicate whether the above-mentioned target system supports the above-mentioned first programming language version, and the above-mentioned dependent library function macro is used to indicate whether the above-mentioned target system can call the above-mentioned first dependent library; when the above-mentioned version function macro indicates that the above-mentioned target system supports the above-mentioned first programming language version, the above-mentioned automobile software framework is compiled on the above-mentioned target system using the programming language of the above-mentioned first programming language version; when the above-mentioned target version function macro indicates that the above-mentioned target system does not support the above-mentioned first programming language version, the above-mentioned automobile software framework is compiled on the above-mentioned target system using the programming language of the above-mentioned second programming language version; when the above-mentioned dependent library function macro indicates that the above-mentioned target system can call the above-mentioned first dependent library, the above-mentioned first dependent library is called to implement the above-mentioned business function; when the above-mentioned dependent library function macro indicates that the above-mentioned target system cannot call the above-mentioned first dependent library, the function macro is used to call the above-mentioned second dependent library to implement the above-mentioned business function.

[0052] In an exemplary embodiment, taking the transplantation of AP AUTOSAR on RtosFreeRTOS as an example, first obtain the first programming language version (such as C++17) and the first dependent library (such as Boost library) used by AP AUTOSAR. Then, detect whether RtosFreeRTOS supports C++17 and whether it can call the Boost library, and define the corresponding version function macro (such as CPP17_SUPPORT) and dependent library function macro (such as BOOST_SUPPORT).

[0053] Specifically, if the macro CPP17_SUPPORT indicates that RtosFreeRTOS supports C++17, it will be compiled with C++17. Conversely, if RtosFreeRTOS does not support C++17, the system will compile with the second programming language version it supports (such as C++11).

[0054] Similarly, if the macro BOOST_SUPPORT indicates that RtosFreeRTOS can call the Boost library, the business function will directly call the Boost library to implement; if the Boost library cannot be called, the system will use the second dependent library supported by RtosFreeRTOS (such as mbed TLS) to implement the same or similar business functions.

[0055] Through the embodiments of the present application, a method is adopted to detect the degree of support of the target operating system for programming languages ​​and dependent libraries, and to selectively use programming language versions and dependent libraries based on function macros, thereby achieving the technical effect of unifying programming environments and dependent library calls under different operating system environments, achieving the purpose of quickly porting and efficiently running automotive software frameworks on multiple RTOSs, and being compatible with different programming languages ​​and dependent library versions.

[0056] As an optional solution, the above-mentioned setting of an operating system abstraction layer for the automobile software framework based on the portable operating system interface includes: respectively encapsulating the first business function and the second business function that the above-mentioned automobile software framework needs to implement to obtain a first business function module and a second business function module, wherein the types of the above-mentioned first business function and the above-mentioned second business function are different; deploying the above-mentioned first business function module and the above-mentioned second business function module in the above-mentioned operating system abstraction layer; respectively encapsulating the first system function and the second system function provided by the above-mentioned target system to obtain a first system function module and a second system function module, wherein the types of the above-mentioned first system function and the above-mentioned second system function are different; deploying the above-mentioned first system function module and the above-mentioned second system function module in the above-mentioned operating system abstraction layer; wherein the above-mentioned first business function module and at least one of the above-mentioned first system function module and the above-mentioned second system function module can work in coordination, and the above-mentioned second business function module and at least one of the above-mentioned first system function module and the above-mentioned second system function module can work in coordination.

[0057] In an exemplary embodiment, Figure 5 is a schematic diagram of another optional software framework configuration method according to an embodiment of the present application, such as Figure 5 As shown, for each functional module of the automobile software framework, independent functional sub-modules (the above-mentioned first business functional module and the second business functional module) are abstracted and integrated and matched. For example, the communication management (CM) module in the automobile software framework AP is responsible for processing the communication between applications in a distributed, real-time, embedded environment. Different customers have different implementations of the communication protocols supported by the CM module, such as DDS (Data Distribution Service) and SOME / IP (Scalable service-Oriented MiddlewarE over IP). Some business requirements also use the Iceoryx protocol. When developing the operating system abstraction layer, the supported protocols are made into independent functional sub-modules, and users can load one or more functional sub-modules as needed.

[0058] In another exemplary embodiment, taking the application scenario of AP AUTOSAR in the integration of vehicle infotainment system and vehicle diagnostic system as an example, first, the first business function module for implementing infotainment function (such as audio playback, map navigation) and the second business function module for implementing vehicle diagnostic function (such as fault detection, performance monitoring) in AP AUTOSAR are encapsulated respectively.

[0059] Next, the first business function module and the second business function module are deployed in the operating system abstraction layer (OSAL) to ensure that they can interact with the underlying operating system. At the same time, the first system function module (such as network communication function) and the second system function module (such as hardware access function) provided by the target operating system are encapsulated. These system function modules are also deployed in OSAL so that they can be called by the above business function modules.

[0060] At runtime, the first business function module (infotainment module) works in conjunction with the first system function module (network communication module) to achieve online audio playback or real-time map updates. Similarly, the second business function module (diagnostic module) works in conjunction with the second system function module (hardware access module) to perform hardware status detection and fault diagnosis. Through the adaptation of OSAL, these modules can run simply and conveniently across different types of operating systems without directly relying on the underlying operating system.

[0061] Through the embodiments of the present application, a method is adopted in which different business function modules in the automobile software framework and different system function modules in the target operating system are encapsulated separately and uniformly deployed in the operating system abstraction layer, thereby achieving decoupling and collaborative work between business function modules and system function modules, improving interoperability and portability between modules, and achieving the purpose of quickly integrating and running diversified automobile software business functions on different RTOS.

[0062] As an optional scheme, the above method also includes: obtaining the first business version protocol and the second business version protocol corresponding to the above-mentioned first business function, wherein the above-mentioned first business version protocol and the above-mentioned second business version protocol are both used to implement the above-mentioned first business function; respectively encapsulating the above-mentioned first business version protocol and the above-mentioned second business version protocol to obtain the first business version protocol module and the second business version protocol module; deploying the above-mentioned first business version protocol module and the above-mentioned second business version protocol module in the above-mentioned operating system abstraction layer.

[0063] In an exemplary embodiment, taking the vehicle remote software update (OTA) function in AP AUTOSAR as an example, first obtain the first service version protocol corresponding to the OTA function, such as the R20-11 version protocol of AUTOSAR Classic Platform, and the second service version protocol, such as the R22-11 version protocol of AP AUTOSAR. Both versions of the protocol can implement the OTA function, but there are differences in details, such as data transmission mechanism, system call interface, etc.

[0064] Next, the R20-11 protocol and the R22-11 protocol are encapsulated respectively to obtain the first service version protocol module and the second service version protocol module. The first service version protocol module and the second service version protocol module are deployed in the operating system abstraction layer (OSAL), so that when AP AUTOSAR runs on different RTOS, it can call the corresponding function module according to the protocol version supported by the system to implement the OTA function.

[0065] Through the embodiments of the present application, a solution is adopted for obtaining and encapsulating different service version protocols and then uniformly deploying them in the operating system abstraction layer, thereby realizing flexible switching of service functions between different version protocols, improving the adaptability and compatibility of service functions, and achieving the purpose of quickly porting and deploying automotive software frameworks such as AP AUTOSAR on different operating systems while maintaining the integrity and advancement of service functions.

[0066] As an optional scheme, the above method also includes: when the above-mentioned second business function needs to call the above-mentioned first business version protocol, using the corresponding above-mentioned first business version protocol module; when the above-mentioned first system function needs to call the above-mentioned first business version protocol, using the corresponding above-mentioned first business version protocol module; when the above-mentioned second system function needs to call the above-mentioned first business version protocol, using the corresponding above-mentioned first business version protocol module.

[0067] As an optional scheme, the above method also includes: when the above-mentioned second business function needs to call the above-mentioned second business version protocol, using the corresponding above-mentioned first business version protocol module; when the above-mentioned first system function needs to call the above-mentioned second business version protocol, using the corresponding above-mentioned first business version protocol module; when the above-mentioned second system function needs to call the above-mentioned second business version protocol, using the corresponding above-mentioned first business version protocol module.

[0068] In an exemplary embodiment, when the second business function needs to call at least one of the first business version protocol and the second business version protocol, the corresponding first business version protocol module and / or the second business version protocol module is used; when the first system function needs to call at least one of the first business version protocol and the second business version protocol, the corresponding first business version protocol module and / or the second business version protocol module is used; when the second system function needs to call at least one of the first business version protocol and the second business version protocol, the corresponding first business version protocol module and / or the second business version protocol module is used.

[0069] For example, when the second business function module needs to use a function of the first business version protocol or the second business version protocol, it will dynamically call the first business version protocol module or the second business version protocol module deployed in the operating system abstraction layer to ensure that the implementation of the business function is not limited to a specific protocol version. Similarly, when the first system function module or the second system function module needs to interact with the business function, it will also be implemented by calling the corresponding business version protocol module. This mechanism ensures that the system function module can effectively cooperate with different versions of business protocols, improving the overall compatibility and flexibility of the system.

[0070] Through the embodiments of the present application, a technical solution is adopted to dynamically call different business version protocol modules according to needs in the operating system abstraction layer, thereby achieving seamless connection between business function modules and system function modules between different protocol versions, improving the portability and adaptability of the automotive software framework, and achieving the purpose of quickly deploying and running automotive software on multiple operating systems while maintaining the integrity and advancement of business functions.

[0071] In an exemplary embodiment, the present application can implement an RTOS-based OSAL (operating system abstraction layer) extension system, which provides a unified API interface. Through the unified API, automotive software frameworks such as Adaptive AUTOSA (AP AUTOSAR for short) can be quickly ported to different RTOS.

[0072] It should be noted that Adaptive AUTOSAR (AP AUTOSAR for short) is a new automotive software framework. In the context of the intelligent networking environment of new energy vehicles, AP AUTOSAR provides support for new applications (such as highly automated driving, V2X, OTA software updates, or vehicles as part of the Internet of Things). Based on achieving autonomous control of software, reducing costs and risks, etc., automakers often choose to develop AP AUTOSAR in-house to meet the needs of future software-defined cars.

[0073] Considering that the current mature AP AUTOSAR solution is based on a UNIX-like kernel, although it comes with the concept of OSAL operating system abstraction layer, it mainly shields the differences of UNIX-like operating systems. The RTOS kernels of various manufacturers are different and cannot meet the requirements of different RTOS operating systems. For example: MOS, UCOS, FreeRTOS, RT-Thread, LiteOS, AliOS, etc. The functions and system call interfaces of different operating systems are often different, and there is no unified standard at present, which makes the porting and maintenance costs of AP AUTOSAR on RTOS too high; secondly, AP AUTOSAR is developed using the object-oriented language C++, and the current different RTOS do not fully support the C++ standard features (C++14, C++17); and the AP AUTOSAR versions used by different users are also inconsistent. At the same time, the versions of open source libraries such as C++ are used in the specific implementation process, which makes the porting and maintenance costs of AP AUTOSAR on RTOS too high.

[0074] Therefore, the embodiment of the present application is based on the standard POSIX interface, through the OSAL extension layer, to quickly transplant and adapt AP AUTOSAR on different RTOS, solving the version differences of different AP AUTOSAR (R20-11, R22-11, etc.); different support differences (POSIX support levels are different); different C++ standard version feature differences (different RTOS may only support C++11, C++14, C++17, etc.); different versions of C++ dependency library differences (boost, sqlite3, etc.), specifically, by abstracting the adaptation layer (the above operating system abstraction layer) to solve the above technical problems:

[0075] S1, based on the AP AUTOSAR specification, abstracts a unified OS system interface as a standard API provided by the adaptation layer;

[0076] S2, within the adaptation layer, implements API functions based on standard interfaces (POSIX interfaces and standard library interfaces);

[0077] S3, in view of the differences between different OS, such as differences in POSIX interface support and C++ support, is controlled through function macros to achieve compatibility and expansion on different RTOS;

[0078] S4 is controlled by function macros and is compatible with different versions of C++ dependency libraries.

[0079] It is understandable that AP AUTOSAR is a standard specification, and different OS / RTOS bottom layers also provide system functions based on standard interfaces (POSIX interfaces and standard library interfaces). Therefore, technically, it is entirely possible to use an OSAL extension system to be compatible with different versions of AP AUTOSAR, different RTOS, different C++ standard library features and different versions of C++ dependent libraries. Based on the OSAL extension system, automotive software such as AP AUTOSAR can be quickly ported and implemented on different RTOS. Its layered design can decouple the upper-level automotive software from the RTOS system layer, making development and maintenance easier. And by continuously improving the OSAL extension system, a mature solution for quickly porting and implementing automotive software such as AP AUTOSAR on RTOS can be formed.

[0080] S1, for each functional module of AP, abstract independent functional sub-modules and make overall adaptation, for example: the communication management (CM) module in AP is responsible for processing the communication between applications in a distributed, real-time, embedded environment. Different customers have different communication protocols supported by the CM module, such as DDS (Data Distribution Service) and SOME / IP (Scalable service-Oriented MiddlewarE over IP), and some customers use the Iceoryx protocol. When we develop the adaptation layer, we make the supported protocols into independent functional sub-modules, and users can load one or more functional sub-modules as needed.

[0081] S2, according to the use of AP modules and various C++ function libraries, corresponding processing is performed, for example: boost library, after cross-compilation under Ubuntu, boost-1.72.0 has a total of the following 40 sub-libraries and related header file libraries (hpp files). When actually adapting AP, only one or several sub-libraries in boost are needed, such as PER, PHM, and CM modules, as shown in Table 1:

[0082] Table 1

[0083]

[0084]

[0085] S3, when developing the adaptation layer, the independent functional sub-modules are abstracted and loaded and used as independent modules. Users can load one or more functional sub-modules as needed;

[0086] S4, POSIX interface implementation, among which IEEE 1003.13 is the standard [real-time profiles] developed by POSIX for the embedded field. In order to provide different levels of RTOS capabilities, IEEE Std.1003.13 defines four subsets: Minimal: the minimum embedded subset specification is PSE51; Controller: the industrial controller subset specification is PSE52; Dedicated: the larger embedded system subset specification is PSE53; Multi-Purpose: the large-scale general system subset specification with real-time requirements is PSE54; by defining different function macros (POSIX_PSE51, POSIX_PSE52, POSIX_PSE53), it is compatible with the system support of different RTOS.

[0087] It is understandable that in the specific implementation of this application, related data such as user information is involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of relevant data need to comply with relevant laws, regulations and standards of relevant countries and regions.

[0088] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0089] According to another aspect of the embodiment of the present application, a software framework configuration device for implementing the above-mentioned software framework configuration method is also provided. Figure 6 As shown, the device comprises:

[0090] A setting module 602 is used to set an operating system abstraction layer for the automobile software framework based on the portable operating system interface, wherein the operating system abstraction layer is used to integrate the business functions provided by the automobile software framework, and the automobile software framework calls each operating system through the operating system abstraction layer to implement the business functions;

[0091] A determination module 604 is used to determine a target interface between the automobile software framework and the target operating system based on a target business function provided by the automobile software framework, wherein the business function includes a target business function, the target interface includes a portable operating system interface, and each operating system includes a target operating system;

[0092] The implementation module 606 is used to establish communication between the automobile software framework and the target operating system through the target interface to implement the target business function.

[0093] As an optional solution, the above-mentioned device is used to set up an operating system abstraction layer for the automobile software framework based on the portable operating system interface in the following manner: setting a corresponding function call function for each function in the above-mentioned business function; and implementing the above-mentioned function call function in the above-mentioned operating system abstraction layer based on the above-mentioned portable operating system interface.

[0094] As an optional scheme, the above-mentioned device is used to implement the above-mentioned function call function in the above-mentioned operating system abstraction layer based on the above-mentioned portable operating system interface in the following manner: detect whether the above-mentioned target operating system supports the above-mentioned portable operating system interface, and define an interface function macro; when the above-mentioned interface function macro indicates that the above-mentioned target system supports the above-mentioned portable operating system interface, use the above-mentioned portable operating system interface to implement the above-mentioned function call function; when the above-mentioned interface function macro indicates that the target system does not support the above-mentioned portable operating system interface, use the above-mentioned interface function macro to call the equivalent interface of the above-mentioned target system to implement the above-mentioned function call function, wherein the above-mentioned equivalent interface is provided for the above-mentioned target operating system to execute the above-mentioned business function.

[0095] As an optional solution, the above-mentioned device is used to set an operating system abstraction layer for the automobile software framework based on the portable operating system interface in the following manner: obtain the first programming language version and the first dependent library corresponding to the above-mentioned automobile software framework, and the second programming language version and the second dependent library corresponding to the above-mentioned target system, and define version function macros and dependent library function macros, wherein the above-mentioned version function macros are used to indicate whether the above-mentioned target system supports the above-mentioned first programming language version, and the above-mentioned dependent library function macros are used to indicate whether the above-mentioned target system can call the above-mentioned first dependent library; when the above-mentioned version function macro indicates that the above-mentioned target system supports the above-mentioned first programming language version, the above-mentioned automobile software framework is compiled on the above-mentioned target system using the programming language of the above-mentioned first programming language version; when the above-mentioned target version function macro indicates that the above-mentioned target system does not support the above-mentioned first programming language version, the above-mentioned automobile software framework is compiled on the above-mentioned target system using the programming language of the above-mentioned second programming language version; when the above-mentioned dependent library function macro indicates that the above-mentioned target system can call the above-mentioned first dependent library, the above-mentioned first dependent library is called to implement the above-mentioned business function; when the above-mentioned dependent library function macro indicates that the above-mentioned target system cannot call the above-mentioned first dependent library, the function macro is used to call the above-mentioned second dependent library to implement the above-mentioned business function.

[0096] As an optional solution, the above-mentioned device is used to set an operating system abstraction layer for the automobile software framework based on the portable operating system interface in the following manner: respectively encapsulating the first business function and the second business function that the above-mentioned automobile software framework needs to implement to obtain the first business function module and the second business function module, wherein the types of the above-mentioned first business function and the above-mentioned second business function are different; deploying the above-mentioned first business function module and the above-mentioned second business function module in the above-mentioned operating system abstraction layer; respectively encapsulating the first system function and the second system function provided by the above-mentioned target system to obtain the first system function module and the second system function module, wherein the types of the above-mentioned first system function and the above-mentioned second system function are different; deploying the above-mentioned first system function module and the above-mentioned second system function module in the above-mentioned operating system abstraction layer; wherein the above-mentioned first business function module and at least one of the above-mentioned first system function module and the above-mentioned second system function module can work in coordination, and the above-mentioned second business function module and at least one of the above-mentioned first system function module and the above-mentioned second system function module can work in coordination.

[0097] As an optional scheme, the above-mentioned device is also used to: obtain the first business version protocol and the second business version protocol corresponding to the above-mentioned first business function, wherein the above-mentioned first business version protocol and the above-mentioned second business version protocol are both used to implement the above-mentioned first business function; respectively encapsulate the above-mentioned first business version protocol and the above-mentioned second business version protocol to obtain the first business version protocol module and the second business version protocol module; deploy the above-mentioned first business version protocol module and the above-mentioned second business version protocol module in the above-mentioned operating system abstraction layer.

[0098] As an optional solution, the above-mentioned device is also used for: when the above-mentioned second business function needs to call the above-mentioned first business version protocol, using the corresponding above-mentioned first business version protocol module; when the above-mentioned first system function needs to call the above-mentioned first business version protocol, using the corresponding above-mentioned first business version protocol module; when the above-mentioned second system function needs to call the above-mentioned first business version protocol, using the corresponding above-mentioned first business version protocol module.

[0099] As an optional solution, the above-mentioned device is also used to: when the above-mentioned second business function needs to call the above-mentioned second business version protocol, use the corresponding above-mentioned first business version protocol module; when the above-mentioned first system function needs to call the above-mentioned second business version protocol, use the corresponding above-mentioned first business version protocol module; when the above-mentioned second system function needs to call the above-mentioned second business version protocol, use the corresponding above-mentioned first business version protocol module.

[0100] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program with a predetermined function, and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

[0101] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0102] According to one aspect of the present application, a computer program product is provided. The computer program product includes a computer program.

[0103] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0104] Figure 7 The structure block diagram of a computer system for implementing an electronic device according to an embodiment of the present application is schematically shown.

[0105] It should be noted that Figure 7 The computer system 700 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0106] like Figure 7 As shown, the computer system 700 includes a central processing unit 701 (CPU), which can perform various appropriate actions and processes according to the program stored in the read-only memory 702 (ROM) or the program loaded from the storage part 708 to the random access memory 703 (RAM). Various programs and data required for system operation are also stored in the random access memory 703. The central processing unit 701, the read-only memory 702 and the random access memory 703 are connected to each other through a bus 704. An input / output interface 705 (Input / Output interface, i.e., I / O interface) is also connected to the bus 704.

[0107] The following components are connected to the input / output interface 705: an input section 706 including a keyboard, a mouse, etc.; an output section 707 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN card, a modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the input / output interface 705 as needed. A removable medium 711, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 710 as needed so that a computer program read therefrom is installed into the storage section 708 as needed.

[0108] In particular, according to an embodiment of the present application, the process described in each method flow chart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer readable medium, and the computer program contains a program code for executing the method shown in the flow chart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 709, and / or installed from the removable medium 711. When the computer program is executed by the central processor 701, various functions defined in the system of the present application are executed.

[0109] In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 709, and / or installed from the removable medium 711. When the computer program is executed by the central processor 701, various functions provided by the embodiment of the present application are performed.

[0110] According to another aspect of the embodiment of the present application, an electronic device for implementing the configuration method of the above software framework is also provided. The electronic device may be Figure 1 The terminal device or server shown in the figure. This embodiment is described by taking the electronic device as a terminal device as an example. Figure 8 As shown, the electronic device includes a memory 802 and a processor 804. The memory 802 stores a computer program, and the processor 804 is configured to execute the steps in any of the above method embodiments through the computer program.

[0111] Optionally, in this embodiment, the electronic device may be located in at least one network device among a plurality of network devices of a computer network.

[0112] Optionally, in this embodiment, the above-mentioned processor can be configured to execute the methods in each embodiment of the present application through a computer program.

[0113] Alternatively, a person skilled in the art may understand that: Figure 8 The structure shown is for illustration only. Figure 8 The structure of the electronic device is not limited. Figure 8 More or fewer components (such as network interfaces, etc.) as shown in, or with Figure 8 Different configurations are shown.

[0114] Among them, the memory 802 can be used to store software programs and modules, such as the program instructions / modules corresponding to the configuration method and device of the software framework in the embodiment of the present application. The processor 804 executes various functional applications and data processing by running the software programs and modules stored in the memory 802, that is, realizing the above-mentioned configuration method of the software framework. The memory 802 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 802 may further include a memory remotely located relative to the processor 804, and these remote memories may be connected to the terminal via a network. Examples of the above-mentioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. Among them, the memory 802 can be specifically, but not limited to, used to store information about target business functions. As an example, such as Figure 8 As shown, the memory 802 may include but is not limited to the setting module 602, the determining module 604 and the implementing module 606 in the configuration device of the software framework. In addition, other module units in the configuration device of the software framework may also be included but are not limited to, which will not be repeated in this example.

[0115] Optionally, the transmission device 806 is used to receive or send data via a network. Specific examples of the network may include wired networks and wireless networks. In one example, the transmission device 806 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices and routers via a network cable so as to communicate with the Internet or a local area network. In one example, the transmission device 806 is a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0116] In addition, the electronic device further includes: a display 808 for displaying information of the target service function; and a connection bus 810 for connecting various module components in the electronic device.

[0117] In other embodiments, the terminal device or server may be a node in a distributed system, wherein the distributed system may be a blockchain system, and the blockchain system may be a distributed system formed by connecting the multiple nodes through network communication. The nodes may form a peer-to-peer network, and any form of computing device, such as a server, terminal or other electronic device, may become a node in the blockchain system by joining the peer-to-peer network.

[0118] According to one aspect of the present application, a computer-readable storage medium is provided, and a processor of an electronic device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the electronic device executes the software framework configuration method provided in various optional implementations of the above-mentioned software framework configuration aspects.

[0119] Optionally, in this embodiment, the above-mentioned computer-readable storage medium can be configured to store data for executing the methods in various embodiments of the present application.

[0120] Optionally, in this embodiment, a person of ordinary skill in the art may understand that all or part of the steps in the various methods of the above embodiments may be completed by instructing hardware related to the terminal device through a program, and the program may be stored in a computer-readable storage medium, and the storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, etc.

[0121] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0122] If the integrated units in the above embodiments are implemented in the form of software functional units and sold or used as independent products, they can be stored in the above computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for one or more electronic devices to execute all or part of the steps of the methods described in each embodiment of the present application.

[0123] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0124] In the several embodiments provided in the present application, it should be understood that the disclosed application can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

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

[0126] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0127] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for configuring a software framework, characterized in that: include: An operating system abstraction layer is set for the automobile software framework based on the portable operating system interface, wherein the operating system abstraction layer is used to integrate the business functions provided by the automobile software framework, and the automobile software framework calls each operating system through the operating system abstraction layer to implement the business functions; Determining a target interface between the automobile software framework and a target operating system based on a target business function provided by the automobile software framework, wherein the business function includes the target business function, the target interface includes the portable operating system interface, and the respective operating systems include the target operating system; The communication between the automobile software framework and the target operating system is established through the target interface to realize the target business function.

2. The method according to claim 1, characterized in that The step of setting an operating system abstraction layer for the automobile software framework based on the portable operating system interface includes: Setting a corresponding function call function for each function in the business function; The function call function is implemented in the operating system abstraction layer based on the portable operating system interface.

3. The method according to claim 2, characterized in that The method of implementing the function call function in the operating system abstraction layer based on the portable operating system interface includes: Detecting whether the target operating system supports the portable operating system interface and defining interface function macros; In the case where the interface function macro indicates that the target system supports the portable operating system interface, using the portable operating system interface to implement the function call function; In the case where the interface function macro indicates that the target system does not support the portable operating system interface, the interface function macro is used to call an equivalent interface of the target system to implement the function call function, wherein the equivalent interface is provided for the target operating system to execute the business function.

4. The method according to claim 1, characterized in that: The step of setting an operating system abstraction layer for the automobile software framework based on the portable operating system interface includes: Obtaining a first programming language version and a first dependent library corresponding to the automotive software framework, and a second programming language version and a second dependent library corresponding to the target system, and defining a version function macro and a dependent library function macro, wherein the version function macro is used to indicate whether the target system supports the first programming language version, and the dependent library function macro is used to indicate whether the target system can call the first dependent library; When the version function macro indicates that the target system supports the first programming language version, the automotive software framework is compiled on the target system using a programming language of the first programming language version; when the target version function macro indicates that the target system does not support the first programming language version, the automotive software framework is compiled on the target system using a programming language of the second programming language version; When the dependency library function macro indicates that the target system can call the first dependency library, the first dependency library is called to implement the business function; when the dependency library function macro indicates that the target system cannot call the first dependency library, the function macro is used to call the second dependency library to implement the business function.

5. The method according to claim 1, characterized in that The step of setting an operating system abstraction layer for the automobile software framework based on the portable operating system interface includes: respectively encapsulating a first business function and a second business function to be implemented by the automobile software framework to obtain a first business function module and a second business function module, wherein the first business function and the second business function are of different types; and deploying the first business function module and the second business function module in the operating system abstraction layer; respectively encapsulating a first system function and a second system function provided by the target system to obtain a first system function module and a second system function module, wherein the first system function and the second system function are of different types; and deploying the first system function module and the second system function module in the operating system abstraction layer; The first business function module and at least one of the first system function module and the second system function module can work together, and the second business function module and at least one of the first system function module and the second system function module can work together.

6. The method according to claim 5, characterized in that The method further comprises: Obtaining a first service version protocol and a second service version protocol corresponding to the first service function, wherein the first service version protocol and the second service version protocol are both used to implement the first service function; Encapsulating the first service version protocol and the second service version protocol respectively to obtain a first service version protocol module and a second service version protocol module; The first service version protocol module and the second service version protocol module are deployed in the operating system abstraction layer.

7. A configuration device for a software framework, characterized in that: include: A setting module, used for setting an operating system abstraction layer for the automobile software framework based on a portable operating system interface, wherein the operating system abstraction layer is used for integrating business functions provided by the automobile software framework, and the automobile software framework calls each operating system through the operating system abstraction layer to implement the business functions; a determination module, configured to determine a target interface between the automobile software framework and a target operating system based on a target business function provided by the automobile software framework, wherein the business function includes the target business function, the target interface includes the portable operating system interface, and the respective operating systems include the target operating system; An implementation module is used to establish communication between the automobile software framework and the target operating system through the target interface to implement the target business function.

8. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored computer program, wherein the computer program can be executed by an electronic device to perform the method described in any one of claims 1 to 6.

9. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method described in any one of claims 1 to 6 are implemented.

10. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to execute the method according to any one of claims 1 to 6 through the computer program.

Images