An embedded software system across hardware platforms based on a gateway domain controller

Abstract

The application provides a gateway domain controller-based embedded software system across hardware platforms, comprising an ARM processor and an MCU microcontroller configured on an SVN server; a plurality of library files of hardware modules are integrated in the form of folders in the driving layer of the ARM processor; a plurality of hardware directories are included in the application layer of the ARM processor, each hardware directory stores function codes, and the function codes stored in the same hardware directory have the same function; a plurality of chip kernels are integrated in the form of folders in the driving layer of the MCU microcontroller, and each chip kernel corresponds to a hardware module; a plurality of chip directories are included in the application layer of the MCU microcontroller, each chip directory stores function codes of chip modules corresponding to a plurality of chip kernels, and the plurality of function codes stored in any chip directory have the same function, so that the effect of developing a plurality of hardware platform projects on a single hardware platform is achieved.

Description

Technical Field

[0001] This invention relates to the field of automotive electronic intelligence, and in particular to an embedded software system based on a gateway domain controller across hardware platforms. Background Technology

[0002] With the development of intelligent and connected vehicles, centralized electronic and electrical architectures are gradually replacing traditional distributed architectures. The gateway domain controller, as the vehicle's communication hub, is responsible for core functions such as vehicle-to-cloud data interaction, vehicle protocol conversion, and OTA (Over-the-Air) upgrades. However, the hardware and requirements vary significantly between different vehicle models, and there are now numerous domestic chip alternatives available. Current software development faces a series of challenges, including high development and maintenance costs and low software reusability.

[0003] Traditional embedded software design architectures, whether on the MCU (Microcontroller Unit) or ARM (Advanced RISC Machine) side, tightly couple the hardware driver layer with the application code. For example, the MCU application layer has interfaces that directly manipulate GPIO (General-purpose input / output). Modifications to hardware details are linked upwards from the driver layer to the application layer, meaning any hardware change can trigger a change in the entire software architecture. The decentralization of functional modules, with the same function on different hardware platforms, often leads to independent development by different developers, resulting in non-reusable code due to hardware coupling. Furthermore, each hardware platform requires a separate software architecture, with dedicated compilation scripts and toolchain configurations. Switching platforms necessitates manually modifying multiple compilation options and even changing the entire development environment.

[0004] Each hardware platform requires the creation and maintenance of an independent code repository or branch. With the explosive growth in product diversification and the accelerated pace of hardware iteration, the increase in hardware platform combinations leads to a rapid expansion of the codebase. Furthermore, bug fixes and feature updates require manual synchronization across branches. Each new hardware platform necessitates repetitive environment configuration, significantly increasing the complexity of building and releasing. Therefore, the current technical solution involves building an independent software architecture for each hardware platform to meet the functional requirements of different projects. The development of each software architecture's features requires separate maintenance, and software modifications with the same functional requirements must be maintained synchronously on each hardware platform. Consequently, existing technologies suffer from high maintenance costs, low development efficiency, and low code reusability. Summary of the Invention

[0005] To address the aforementioned technical problems, the technical solution adopted by this invention is as follows:

[0006] According to one aspect of this application, an embedded software system based on a gateway domain controller across hardware platforms is provided, including an ARM processor and an MCU microcontroller configured on an SVN server;

[0007] The driver layer of the ARM processor integrates library files for several types of hardware modules in the form of folders;

[0008] The application layer of the ARM processor includes several hardware directories. Each hardware directory stores the function codes of several types of hardware modules, and the functions corresponding to the function codes stored in any hardware directory are the same.

[0009] The driver layer of the MCU microcontroller integrates several chip cores in the form of folders, and each chip core corresponds to a hardware module.

[0010] The application layer of an MCU microcontroller includes several chip directories. Each chip directory stores the function codes of several chip modules corresponding to several chip cores, and the functions corresponding to the several function codes stored in any chip directory are the same.

[0011] In one exemplary embodiment of this application, the hardware catalog includes driver implementation code, interface definition code, and supporting resource code for the hardware module.

[0012] In one exemplary embodiment of this application, the hardware directory is configured with corresponding compiled code, and the library files of the hardware module corresponding to the compiled code are adjusted through the compiled code.

[0013] In one exemplary embodiment of this application, when a new library file for a hardware module is added to the driver layer of the ARM processor, a new hardware directory corresponding to the hardware module is created in the application layer of the ARM processor, and the compilation options of the newly created hardware directory are set.

[0014] In one exemplary embodiment of this application, several hardware directories included in the application layer of the ARM processor are distinguished by corresponding project configuration macro definitions.

[0015] In one exemplary embodiment of this application, the project configuration macro definition includes data format processing rules for different hardware modules and implementation rules for the vehicle-to-cloud communication protocol.

[0016] In one exemplary embodiment of this application, several hardware modules interact with each other through a standardized interface.

[0017] In one exemplary embodiment of this application, the chip core stores the startup code, real-time clock configuration information, peripheral input / output driver information, and interrupt handling information of the chip module corresponding to the chip core.

[0018] In one exemplary embodiment of this application, the SDK version file and platform version file of each type of hardware module are stored in the release directory of the SVN server.

[0019] In one exemplary embodiment of this application, the SDK version file and the platform version file under the same release directory correspond to the same project.

[0020] The present invention has at least the following beneficial effects:

[0021] The present invention relates to an embedded software system based on a gateway domain controller across hardware platforms, comprising an ARM processor and an MCU microcontroller configured on an SVN server. The ARM processor's driver layer integrates library files for several types of hardware modules in a folder-based manner. The ARM processor's application layer includes several hardware directories, each storing functional codes for several types of hardware modules, with the functional codes in any hardware directory corresponding to the same function. The MCU microcontroller's driver layer integrates several chip cores in a folder-based manner, each chip core corresponding to one hardware module. The MCU microcontroller's application layer includes several... Each chip directory stores the functional codes of several chip modules corresponding to several chip cores. The functional codes stored in any chip directory correspond to the same functions. By building an embedded software system based on a gateway domain controller across hardware platforms, hardware drivers and business logic are separated, functional components are highly reused, and the software reuse rate is greatly improved. While maintaining the independence of each hardware module, it can flexibly adapt to the differentiated customization needs of different hardware platform projects. The development of new projects only requires the integration of new driver layer code and the addition of requirements through configuration options. This enables the development of multi-hardware platform projects on a single hardware platform, which can significantly improve development efficiency and reduce maintenance costs. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 A block diagram of an embedded software system based on a gateway domain controller across hardware platforms, provided in an embodiment of the present invention;

[0024] Figure 2 A flowchart illustrating the software construction process of an SVN server provided in an embodiment of the present invention. Detailed Implementation

[0025] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] This application proposes an embedded software system based on a gateway domain controller across hardware platforms, such as... Figure 1 As shown, it includes an ARM processor and an MCU microcontroller configured on the SVN server.

[0027] The driver layer of the ARM processor is designed according to the principle of hardware abstraction, and integrates library files of several types of hardware modules in the form of folders.

[0028] Several hardware modules interact with each other through standardized interfaces to reduce coupling, which ensures the stability of the core code and meets the customization needs of different hardware platforms.

[0029] The application layer of an ARM processor includes several hardware directories. Each hardware directory stores the function codes of several types of hardware modules, and the functions corresponding to the function codes stored in any hardware directory are the same.

[0030] The application layer design of ARM processors adopts the concept of maximizing the reuse of functional components, organizing functional code with similar functions in the same hardware directory.

[0031] Specifically, the hardware directory includes the driver implementation code, interface definition code, and supporting resource code for the hardware modules. The hardware directory also contains corresponding compilation code, which is used to adjust the library files of the hardware modules corresponding to the compilation code.

[0032] The application layer of the ARM processor includes several hardware catalogs that are distinguished by corresponding project configuration macros. For the inevitable differences in requirements among various hardware modules, internal distinctions are made through project configuration macros. These macros include platform-related feature adaptation and personalized customization of business logic, thereby achieving minor differences in details. For example, project configuration macros include data format processing rules for different hardware modules and implementation rules for vehicle-to-cloud communication protocols.

[0033] When a new library file for a hardware module is added to the driver layer of the ARM processor, a new hardware directory corresponding to that hardware module is created in the application layer of the ARM processor, and the compilation options for the newly created hardware directory are set.

[0034] Each hardware directory is configured with a dedicated Makefile build script (i.e., build code). The build options variables control whether the hardware module is included in the build. Switching between different hardware platforms can be accomplished simply by modifying the top-level configuration. When a new hardware platform needs to be supported, simply add the corresponding hardware directory and set the corresponding build options, without changing the overall build architecture.

[0035] The driver layer of the MCU microcontroller integrates several chip cores in the form of folders. Each chip core corresponds to a hardware module. The chip core stores the startup code, real-time clock configuration information, peripheral input / output driver information and interrupt handling information of the chip module corresponding to that chip core.

[0036] The application layer of an MCU microcontroller includes several chip directories. Each chip directory stores the function codes of several chip modules corresponding to several chip cores, and the functions corresponding to the several function codes stored in any chip directory are the same.

[0037] The target hardware module can be specified by using compiler option variables to ensure that only the chip support code required by the current project is included during compilation.

[0038] The SDK version file and platform version file for each type of hardware module are stored in the release directory of the SVN server. The SDK version file and platform version file in the same release directory correspond to the same project. This is used to distinguish the differences in module platform versions between different hardware platforms of each project. The publisher can select the corresponding release directory through the project configuration options to build software release packages for different projects.

[0039] In the application layer design of the MCU microcontroller, a component-based approach similar to that of ARM processors is adopted. Business logic and functional implementations are categorized by modules and stored uniformly in a common directory, with all projects sharing the same application code base. Project-specific configurations, such as logistics information, version numbers, and default operating parameters, are managed using independent C files. Each project's configuration file is identified by project-specific macro definitions, and the compilation system automatically selects the correct configuration file for compilation based on the currently active project's macros.

[0040] like Figure 2As shown, the final software build and release utilizes a combination of an SVN server and Jenkins automated deployment tools. This extracts all compilation options and project macros required for different hardware modules, functionalities, and project configurations for both ARM processors and MCU microcontrollers. Through visual selection boxes, dropdown menus, and parameter input boxes, release personnel can easily specify the target hardware platform, functional module combinations, and project-specific configurations. These selections are translated into environment variables in real time and injected into the build process via the variable passing mechanism of Jenkins automated deployment tools. The build script reads all environment variables set by Jenkins automated deployment tools, generating dynamic compilation effects. For ARM processors, it selects the specific architecture cross-compilation toolchain; for MCU microcontrollers, it automatically associates the corresponding chip's driver library. After the build is complete, the system automatically packages the generated flashing files, upgrade packages, and related version information documents into a standardized release package and stores them in a unified release directory.

[0041] This invention establishes a software architecture integrating compilation chains for multiple hardware platforms. It features a dynamic compilation architecture with modular hardware abstraction layers and application components. Through hierarchical directory isolation, compiler script control, and environment variable injection, it achieves cross-hardware platform architecture design. The driver layer for MCU microcontrollers and ARM processors integrates multiple chip cores matching their respective hardware. The application layer modularizes and reuses common code sections, resulting in high code reusability, reducing development costs and solving the problem of low code reuse. Simultaneously, an automated compilation chain tool is built using Jenkins' automated deployment tool and an SVN server. Environment variable configurations (hardware options, project options, etc.) on the Jenkins automated deployment tool determine the server's code build for the corresponding project, enabling cross-hardware platform project version output based on a single software architecture, significantly reducing software maintenance costs.

[0042] The present invention relates to an embedded software system based on a gateway domain controller across hardware platforms, comprising an ARM processor and an MCU microcontroller configured on an SVN server. The ARM processor's driver layer integrates library files for several types of hardware modules in a folder-based manner. The ARM processor's application layer includes several hardware directories, each storing functional codes for several types of hardware modules, with the functional codes in any hardware directory corresponding to the same function. The MCU microcontroller's driver layer integrates several chip cores in a folder-based manner, each chip core corresponding to one hardware module. The MCU microcontroller's application layer includes several... Each chip directory stores the functional codes of several chip modules corresponding to several chip cores. The functional codes stored in any chip directory correspond to the same functions. By building an embedded software system based on a gateway domain controller across hardware platforms, hardware drivers and business logic are separated, functional components are highly reused, and the software reuse rate is greatly improved. While maintaining the independence of each hardware module, it can flexibly adapt to the differentiated customization needs of different hardware platform projects. The development of new projects only requires the integration of new driver layer code and the addition of requirements through configuration options. This enables the development of multi-hardware platform projects on a single hardware platform, which can significantly improve development efficiency and reduce maintenance costs.

[0043] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, mobile terminal, or network device, etc.) to execute the architecture according to the embodiments of this disclosure.

[0044] Those skilled in the art will understand that various aspects of the present invention can be implemented as systems or program products. Therefore, various aspects of the present invention can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software aspects, collectively referred to herein as a "circuit," "module," or "system."

[0045] An electronic device according to this embodiment of the invention. The electronic device is merely an example and should not be construed as limiting the functionality or scope of the embodiments of the invention.

[0046] Electronic devices are manifested in the form of general-purpose computing devices. Components of an electronic device may include, but are not limited to: at least one processor, at least one memory, and buses connecting different system components (including memory and processor).

[0047] The storage may include readable media in the form of volatile storage, such as random access memory (RAM) and / or cache memory, and may further include read-only memory (ROM).

[0048] The storage may also include programs / utilities having a set (at least one) of program modules, including but not limited to: an operating system, one or more applications, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0049] A bus can represent one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus that uses any of the various bus architectures.

[0050] Electronic devices can also communicate with one or more external devices (such as keyboards, pointing devices, Bluetooth devices, etc.), one or more devices that enable users to interact with the electronic device, and / or any device that enables the electronic device to communicate with one or more other computing devices (such as routers, modems, etc.). This communication can be performed through input / output (I / O) interfaces. Furthermore, electronic devices can also communicate with one or more networks (such as local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via network adapters.

[0051] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0052] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0053] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0054] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0055] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0056] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. An embedded software system based on a gateway domain controller across hardware platforms, characterized in that, This includes the ARM processor and MCU microcontroller configured on the SVN server; The driver layer of the ARM processor integrates library files for several types of hardware modules in the form of folders. The application layer of the ARM processor includes several hardware directories. Each hardware directory stores the function codes of several types of hardware modules, and the functions corresponding to the function codes stored in any hardware directory are the same. When a new library file for a hardware module is added to the driver layer of the ARM processor, a new hardware directory corresponding to the hardware module is created in the application layer of the ARM processor, and the compilation options for the new hardware directory are set. The driver layer of the MCU microcontroller integrates several chip cores in the form of folders, and each chip core corresponds to a hardware module. The hardware modules interact with each other through a standardized interface. The SDK version file and platform version file of each type of hardware module are stored in the release directory of the SVN server. The SDK version file and platform version file in the same release directory correspond to the same project, which is used to distinguish the module platform version differences between different hardware platforms of each project. The corresponding release directory is selected through the project configuration options to build software release packages for different projects. The application layer of the MCU microcontroller includes several chip directories. Each chip directory stores the functional code of the chip module corresponding to several chip cores. The functional codes stored in any chip directory have the same function. The target hardware module is specified by the compilation option variable to ensure that only the chip support code required by the current project is included during compilation. The application layer of the MCU microcontroller has project-specific differentiated configurations, including logistics information, version number, and default operating parameters. These are managed using independent C files. Each project's configuration file is identified by a project-specific macro definition. The compilation system automatically selects the correct configuration file for compilation based on the currently active project macro.

2. The embedded software system based on a gateway domain controller across hardware platforms according to claim 1, characterized in that, The hardware catalog includes the driver implementation code, interface definition code, and supporting resource code for the hardware module.

3. The embedded software system based on a gateway domain controller across hardware platforms according to claim 2, characterized in that, The hardware directory contains corresponding compilation code, which is used to adjust the library files of the hardware module corresponding to the compilation code.

4. The embedded software system based on a gateway domain controller across hardware platforms according to claim 1, characterized in that, The application layer of the ARM processor includes several hardware directories that are distinguished by corresponding project configuration macro definitions.

5. The embedded software system based on a gateway domain controller across hardware platforms according to claim 4, characterized in that, The project configuration macro definitions include data format processing rules for different hardware modules and implementation rules for the vehicle-to-cloud communication protocol.

6. The embedded software system based on a gateway domain controller across hardware platforms according to claim 1, characterized in that, The chip core stores the startup code, real-time clock configuration information, peripheral input / output driver information, and interrupt handling information of the chip module corresponding to the chip core.

Images