Architecture construction method and device of embedded system, equipment and storage medium

Abstract

The invention discloses an architecture construction method and device of an embedded system, equipment and a storage medium, and the method comprises the steps: building a layered architecture which comprises a working space layer, a product component layer and a platform component layer; creating a plurality of function components for independently performing version management for the product component layer and the platform component layer respectively; creating a workspace layer for a specific target device, and linking functional components required in the product component layer and the platform component layer to the workspace layer; and executing a construction process in the workspace layer, and generating a software upgrade package for the target equipment by taking the functional component as input. According to the invention, by introducing a layered architecture of the workspace layer, the product component layer and the platform component layer, the reusability of codes is improved, the workspace layer is created for specific target equipment, and required functional components from the product component layer and the platform component layer are dynamically integrated in a link mode, so that high flexibility of configuration is realized.

Description

Technical Field

[0001] This application relates to the field of system architecture technology, and more specifically, to a method, apparatus, device and storage medium for constructing the architecture of an embedded system. Background Technology

[0002] As embedded devices become increasingly complex and their software systems grow in scale, they often require multiple developers or teams to collaborate in parallel. In this context, effectively organizing code, managing versions, controlling the compilation process, and ultimately generating reliable deployment packages have become core challenges in embedded software development. A clear, efficient, and maintainable software architecture is crucial for improving development efficiency and ensuring software quality.

[0003] Currently, the common practice in the industry is to adopt a modular design, dividing the system into several modules according to their functions, and compiling and linking them using a unified build script (such as Makefile). For version management, most projects use a single code repository (Monorepo) or a distributed multi-repository approach for code hosting. During the build process, the compilation environment is configured manually or via scripts, specifying the target platform and module dependencies, ultimately outputting a deployable software image or upgrade package. Some solutions introduce basic directory structure conventions or compilation templates to achieve a certain degree of standardization.

[0004] However, existing technologies have significant drawbacks: First, the modules and platform code are often highly coupled and lack clear hierarchical isolation, resulting in poor code reusability and requiring extensive repetitive modifications when adapting to new hardware platforms or product models; second, the build process is tightly bound to the project structure, lacking flexibility and making it difficult to support parallel builds and differentiated packaging for multi-device and multi-processor architectures; in addition, the version management method is crude and cannot finely control the independent evolution and integration of each component, which can easily lead to version conflicts and management chaos in team collaboration. Summary of the Invention

[0005] To address at least one deficiency or improvement need in the prior art, the present invention provides an embedded system architecture construction method, apparatus, device, and storage medium, which solves the problems in the prior art where the coupling between modules and platform code is high, there is a lack of clear hierarchical isolation, resulting in poor code reusability, lack of flexibility, difficulty in supporting parallel construction and differentiated packaging of multi-device and multi-processor architectures, and inability to finely control the independent evolution and integration of each component.

[0006] To achieve the above objectives, according to a first aspect of the present invention, a method for constructing the architecture of an embedded system is provided, comprising: Establish a layered architecture, which includes a workspace layer, a product component layer, and a platform component layer; Create multiple independent functional components for version management in both the product component layer and the platform component layer; Create a workspace layer for a specific target device and link the required functional components from the product component layer and platform component layer to the workspace layer; The build process is executed in the workspace layer, taking functional components as input to generate a software upgrade package for the target device.

[0007] In one possible implementation, the build process is executed in the workspace layer, taking functional components as input to generate a software upgrade package for the target device, and also includes: Parse the device configuration file to obtain the target device's attribute information; Based on the attribute information, for each of the target device's several processor types, the corresponding processor rule files are constructed by calling the corresponding processor. For each processor type, the module build rule file corresponding to each functional component in the predefined module list is called. Based on the module construction rule file, compile the corresponding functional components; The compiled functional components are linked and packaged to generate a software upgrade package.

[0008] In one possible implementation, the functional components include an executable file, a configuration file, and device firmware; linking and packaging the compiled functional components to generate a software upgrade package also includes: The executable files, configuration files, and device firmware are categorized and packaged into multiple independent sub-compressed packages; Generate an upgrade script to control the upgrade process and merge it with the sub-compressed package into an upgrade compressed package; The pre-compiled target device unpacker, the header containing verification information, and the upgrade compressed package are merged in a predetermined order to output a software upgrade package.

[0009] One possible implementation also includes a type control step for the software upgrade package: Respond to the received build type instruction and select the corresponding packaging strategy; When the build type directive indicates a full upgrade package, the packaging strategy includes all sub-packages in the upgrade package; When the build type instruction indicates an incremental upgrade package, the packaging strategy uses a binary differential algorithm to include files and their metadata that differ from the base version into the upgrade package; When the build type directive indicates a module upgrade package, the packaging strategy will include the sub-packages corresponding to the specific functional components that have changed into the upgrade package.

[0010] One possible implementation also includes steps for preparing and verifying the build environment: An environment check routine is executed before the processor is invoked to build the rule file; The environment check routine should include at least the following: verifying the existence and version compatibility of the cross-compilation toolchain, checking the validity of the header file paths of the system kernel components, and confirming whether the library files provided by the platform component layer meet the dependencies. Once the environment check routine passes, the subsequent compilation steps are executed.

[0011] One possible implementation also includes a version-differentiated build step: When compiling functional components, different sets of configuration parameters are loaded based on the input version type option; When the version type option is specified as debug version, the loaded configuration parameter set causes the compilation process to introduce debug symbols, enable assertion checks, and enable core dump functionality. When the version type option is set to release, the loaded set of configuration parameters optimizes the compilation process for code size and execution speed, removes debugging symbols, and disables assertion checks and core dump functionality.

[0012] In one possible implementation, the version differentiation build steps also include: For the debug version, the upgrade script includes detailed log output instructions and logic for saving exception scenarios; For release versions, the upgrade script removes the log output command and the logic for saving the exception state, and adds a command to execute the upgrade process silently.

[0013] According to a second aspect of the present invention, an embedded system architecture construction apparatus is also provided, comprising: The architecture layering module is configured to establish a layered architecture, which includes a workspace layer, a product component layer, and a platform component layer. The functional component module is configured to create multiple independent functional components for version management in both the product component layer and the platform component layer. The component linking module is configured to create a workspace layer for a specific target device, linking the required functional components from the product component layer and platform component layer to the workspace layer; The architecture building module is configured to execute a build process in the workspace layer, taking functional components as input, to generate a software upgrade package for the target device.

[0014] According to a third aspect of the present invention, an embedded system architecture construction device is also provided, comprising at least one processing unit and at least one storage unit, wherein the storage unit stores a computer program that, when executed by the processing unit, causes the processing unit to perform the steps of any of the above methods.

[0015] According to a fourth aspect of the invention, a storage medium is also provided that stores a computer program executable by an embedded system architecture building device, which, when run on the embedded system architecture building device, causes the embedded system architecture building device to perform the steps of any of the above methods.

[0016] In summary, compared with the prior art, the above-described technical solutions conceived by this invention can achieve the following beneficial effects: This invention provides an embedded system architecture construction method. By introducing a layered architecture of workspace layer—product component layer—platform component layer, product component layer, and platform component layer, product components and platform components are separated and made into independently version-managed functional components. This decouples business logic from hardware infrastructure services, allowing platform components to be reused by devices from different product lines, improving code reusability and avoiding repeated development of common underlying functions when developing new devices. By creating a workspace layer for a specific target device and dynamically integrating the required functional components from the product component layer and platform component layer through a linking method, a high degree of configuration flexibility is achieved. This makes the build environment for each target device lightweight and customized, enabling the selection and combination of necessary components according to the specific device model, processor architecture, and functional requirements. It supports parallel construction of multiple devices and multi-processor architectures, and can call corresponding compilation rules and toolchains according to their respective device configurations to execute differentiated build processes, ultimately generating a software upgrade package specific to that device. In addition, each functional component is managed independently, enabling refined management and efficient team collaboration. Product components and platform components can evolve, test, and release versions independently, and then integrate specified versions through the workspace layer. This solves the common version conflicts and dependency management problems in traditional single code repository or loose multi-repository models, making the system have good maintainability and scalability. Attached Figure Description

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

[0018] Figure 1A flowchart illustrating an embodiment of the embedded system architecture construction method provided by the present invention; Figure 2 Provided by the present invention Figure 1 A flowchart illustrating an embodiment of step S104; Figure 3 Provided by the present invention Figure 2 A schematic flowchart of an embodiment of step S205; Figure 4 A schematic diagram of a structural embodiment of the embedded system architecture device provided by the present invention; Figure 5 This is a schematic diagram of the architecture of an embedded system provided in an embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other.

[0020] The terms "first," "second," "third," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0021] This invention provides a method, apparatus, device, and storage medium for constructing the architecture of an embedded system, which will be described below.

[0022] Please see Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the embedded system architecture construction method provided by the present invention. In a specific embodiment of the present invention, an embedded system architecture construction method is disclosed, including: S101. Establish a layered architecture, which includes a workspace layer, a product component layer, and a platform component layer. S102. Create multiple independent functional components for version management for the product component layer and the platform component layer respectively; S103. Create a workspace layer for a specific target device and link the required functional components in the product component layer and platform component layer to the workspace layer. S104. Execute the build process in the workspace layer, taking functional components as input, to generate a software upgrade package for the target device.

[0023] In the above embodiment, the workspace layer, as the top layer of the entire architecture, undertakes the core tasks of compilation management, code integration, and package generation, providing a customized development and build environment for specific devices. The product component layer focuses on implementing device-specific business functions, such as communication protocol parsing and device status monitoring; these components are directly related to the core value of the device. The platform component layer extracts common requirements across different devices, such as user interface display and general peripheral drivers, forming a series of reusable library files through abstraction and encapsulation, promoting code sharing and reuse. This layered architecture effectively isolates dependencies between different layers, improving flexibility and scalability.

[0024] Within the product and platform component layers, functional modules are further refined. Each module is designed as an independent functional component and implements a strict version control strategy. Each component has its own independent repository, recording every change from creation to iteration, including but not limited to code modifications, feature enhancements, and bug fixes. Through the sub-module functionality of version control tools like Git, these components can be linked to different workspaces, enabling flexible combination and reuse at the component level. This not only simplifies the code maintenance process but also accelerates the integration of new features, providing strong support for collaborative team development.

[0025] For each specific target device, a dedicated workspace layer is created. This layer serves as a virtual environment for device development and construction, integrating all necessary resources and tools. During the construction of the workspace layer, the required functional components are selected from the product component layer and platform component layer based on the actual needs of the device. These components are then seamlessly integrated into the workspace through the linking mechanism of version control tools. This ensures that each workspace obtains the most suitable set of components for its device, thereby achieving personalized customization and efficient utilization of the development environment.

[0026] Within the workspace layer, a complete build process is defined. This process takes linked functional components as input and, through the automated execution of build scripts such as Makefiles, completes a series of operations including code compilation, linking, compression, and packaging. During the compilation phase, based on information such as device model and CPU type, a suitable compilation toolchain and compilation options are selected to ensure that the generated executable file can run efficiently on the target device. Finally, the packaged software upgrade package will contain key components such as the target unpacker, package header information, and the upgrade compressed package. The upgrade compressed package is further subdivided into various types based on actual needs, including full software packages, software upgrade packages, and incremental software upgrade packages, to meet upgrade requirements in different scenarios. This flexible and diverse upgrade package design improves the efficiency and reliability of software upgrades, providing strong support for continuous device optimization and functional expansion.

[0027] Compared with existing technologies, the embedded system architecture construction method provided in this embodiment introduces a layered architecture of workspace layer—product component layer—platform component layer. This separates product components from platform components, making them independent functional components with version management. This decouples business logic from hardware infrastructure services, allowing platform components to be reused by devices across different product lines, improving code reusability and avoiding redundant development of common underlying functions when developing new devices. By creating a workspace layer for a specific target device and dynamically integrating the required functional components from the product component layer and platform component layer via links, high configuration flexibility is achieved. This makes the build environment for each target device lightweight and customized, enabling the selection and combination of necessary components based on the specific device model, processor architecture, and functional requirements. It supports parallel construction of multiple devices and multi-processor architectures, and can call corresponding compilation rules and toolchains according to their respective device configurations to execute differentiated build processes, ultimately generating a software upgrade package specific to that device. In addition, each functional component is managed independently, enabling refined management and efficient team collaboration. Product components and platform components can evolve, test, and release versions independently, and then integrate specified versions through the workspace layer. This solves the common version conflicts and dependency management problems in traditional single code repository or loose multi-repository models, making the system have good maintainability and scalability.

[0028] Please see Figure 2 , Figure 2 Provided by the present invention Figure 1 A flowchart illustrating an embodiment of step S104. In some embodiments of the present invention, a build process is executed in the workspace layer, taking functional components as input to generate a software upgrade package for the target device, and further includes: S201. Parse the device configuration file to obtain the target device's attribute information; S202. Based on the attribute information, for each of the several processor types of the target device, call the corresponding processor to build the rule file; S203. For each processor type, based on the predefined module list, call the module construction rule file corresponding to each functional component in the list; S204. Compile the corresponding functional components based on the module construction rule file; S205. Link and package the compiled functional components to generate a software upgrade package.

[0029] In the above embodiments, an intelligent parsing engine is used to process device configuration files. This engine can automatically identify and parse various non-standard configuration file formats. During the parsing process, the engine constructs a device attribute tree structure, organizing key information such as device model, processor architecture (e.g., different variants of the ARM Cortex-A series), memory layout, and peripheral interfaces in a hierarchical manner. This structure not only supports fast lookup but also completes missing attributes through a built-in default value inference mechanism, ensuring that the construction process can continue even with incomplete configuration information.

[0030] To support multi-processor architectures, a dynamic rule matching system was implemented. This system maintains a processor feature library, which records the compilation characteristics of various processor architectures (such as instruction set extensions and cache hierarchy). Upon obtaining the target device's processor information, the system selects the most suitable set of build rules from the rule library using a feature matching algorithm, rather than simply relying on the processor model. This allows different variants of the same processor family to obtain optimized compilation parameters; for example, it automatically adjusts the compilation optimization level for different cache configurations of ARM Cortex-A53 and A72.

[0031] During the module building phase, a dependency graph-driven compilation strategy was introduced. First, a dependency graph was built for each functional component, containing not only code-level dependencies but also recording interface compatibility information between components. During compilation, a topological sorting algorithm was used to determine the compilation order, and dynamic link library (DLL) preloading technology was used to resolve symbolic dependencies between components in advance. This avoids the repeated compilation problems caused by dependency cycles in traditional compilation methods. Combined with incremental compilation technology, when a lower-level component is modified, only the affected upper-level components need to be recompiled, improving compilation efficiency by over 40%.

[0032] After acquiring processor characteristics, corresponding optimization strategies are invoked from the optimization rule base. These strategies include, but are not limited to: vectorization optimization for the NEON instruction set, parallel compilation options for multi-core processors, and instruction scheduling optimization for low-power processors. In particular, processor microarchitecture-level optimizations are also supported, such as generating specific memory access instruction sequences for different versions of the Cortex-A series processors. These optimizations are implemented through compiler plugins, improving runtime efficiency without modifying the source code.

[0033] During the linking and packaging phases, a three-layer packaging structure was adopted: the core layer contains the system components necessary for the device, the business layer contains device-specific functional modules, and the extension layer contains optional functional packages. This layered packaging method supports differentiated upgrades, such as updating only the business layer modules without affecting system stability. During the packaging process, dependency checks are performed to ensure that all linked library file versions are compatible. In particular, considering the limited storage space of embedded devices, an intelligent compression algorithm was implemented. This algorithm can identify repetitive patterns in the code and uses context-based adaptive compression to compress the upgrade package size by 30%-50% while maintaining decompression speed.

[0034] The generated software upgrade package includes a metadata verification mechanism. During unpacking on the device, the package's integrity, source legitimacy, and compatibility with the current device version are verified. After successful verification, a two-stage upgrade strategy is employed: first, basic system components are upgraded, and then business components are upgraded after a system restart. This reduces the risk of device failure and subsequent device malfunction. The entire upgrade process supports resume download; if the network is interrupted, downloads can resume from the point of interruption, making it particularly suitable for remote upgrade scenarios over low-bandwidth networks.

[0035] Please see Figure 3 , Figure 3 Provided by the present invention Figure 2 A flowchart illustrating an embodiment of step S205. In some embodiments of the present invention, the functional components include an executable file, a configuration file, and device firmware; linking and packaging the compiled functional components to generate a software upgrade package further includes: S301. Classify the executable files, configuration files, and device firmware, and package them into multiple independent sub-compressed packages; S302. Generate an upgrade script to control the upgrade process and merge it with the sub-compressed package into an upgrade compressed package; S303. Merge the pre-compiled target device unpacking program, the header containing verification information, and the upgrade compressed package in a predetermined order to output the software upgrade package.

[0036] In the above embodiments, a file feature recognition engine automatically classifies three types of components: executable files extract segment information through ELF / PE header parsing, configuration files verify structural integrity through JSON / XML syntax tree analysis, and device firmware identifies the hardware manufacturer through binary pattern matching. After classification, differentiated compression strategies are adopted for different file types: executable files use the LZMA2 algorithm (balancing compression ratio and decompression speed), configuration files use the DEFLATE algorithm (optimizing text data), and device firmware uses the Brotli algorithm (for binary repetitive patterns). Each sub-compressed package embeds dynamically generated compression metadata, recording the file's original hash value, compression algorithm version, and decompression buffer size. In particular, for cross-platform devices, the compression block alignment is automatically adjusted according to the target device's storage characteristics (such as NAND flash page size) to avoid generating additional fragmentation during decompression.

[0037] The upgrade script generator dynamically constructs the control flow based on the device state machine model: First, it reads the device's current version information and calculates the list of components that need to be updated using a differential algorithm. Then, it generates a phased upgrade strategy based on hardware resources (such as memory size)—memory-constrained devices use an atomic operation of "decompress first, then replace," while high-performance devices support parallel decompression. A multi-level rollback mechanism is embedded in the script: if the first-stage upgrade fails, it automatically rolls back to a preset golden image; if the second stage fails, it retains the updated components and marks them as "partially upgraded." The generated script is obfuscated and then encrypted and merged with the sub-compressed package using the AES-GCM algorithm. The encryption key is dynamically derived from the device's unique ID, ensuring that each upgrade package can only be used on a specific device. The merged upgrade package also contains a timestamp signature chain to prevent man-in-the-middle attacks from tampering with the upgrade order.

[0038] The final package builder employs an "onion-like" encapsulation structure. The outermost layer is a pre-compiled unpacker (providing multiple versions for different operating systems, including Windows, Linux, and RTOS). Its built-in Hardware Abstraction Layer (HAL) automatically adapts to the target device's storage interface (such as SPI / eMMC / UFS). The unpacker reads the verification information in the packet header (including RSA-2048 signature and CRC32 checksum). After successful verification, it decompresses the contents in a predetermined order: first verifying the integrity of the upgrade script, then decompressing each sub-package and verifying the file hash value in real time. In particular, for the device firmware sub-package, the unpacker calls the Hardware Security Module (HSM) for secondary signature verification to ensure the firmware's trustworthiness. The final generated software upgrade package uses the UEFI standard format, includes a bootable image header, and supports multi-channel transmission via USB / network / OTA.

[0039] In some embodiments of the present invention, a software upgrade package type control step is also included: Respond to the received build type instruction and select the corresponding packaging strategy; When the build type directive indicates a full upgrade package, the packaging strategy includes all sub-packages in the upgrade package; When the build type instruction indicates an incremental upgrade package, the packaging strategy uses a binary differential algorithm to include files and their metadata that differ from the base version into the upgrade package; When the build type directive indicates a module upgrade package, the packaging strategy will include the sub-packages corresponding to the specific functional components that have changed into the upgrade package.

[0040] In the above embodiments, the software upgrade package type control process achieves full-scenario coverage through a policy engine. This engine integrates instruction parsing, version comparison, and dynamic encapsulation, and can automatically generate the optimal upgrade scheme according to different build requirements. When a build type instruction is received, the semantic parsing module performs in-depth analysis of the instruction, not only extracting the explicitly specified package type (full / incremental / module), but also combining contextual information such as device model, current version number, and network environment to match the most suitable packaging rule set in the policy knowledge base (e.g., automatically enabling high compression mode for incremental packages for low-bandwidth devices).

[0041] In the scenario of building a full upgrade package, a two-tiered strategy of intelligent merging and dependency optimization is adopted. First, a global file hash table is used to identify duplicate files (such as basic libraries shared by multiple functional modules) in all sub-compressed packages, retaining only one copy and generating a cross-module symbolic link table, which can reduce the package size by 20%-35%. Then, based on the module dependency graph (including metadata such as call relationships and startup order) generated in the pre-compilation stage, the sub-compressed packages are topologically sorted to ensure that files are overwritten in the correct order during device decompression, avoiding startup failures due to dependency conflicts. In particular, for embedded devices, the file alignment is automatically adjusted according to the characteristics of its storage medium (such as the page size of NAND flash memory and bad block management mechanism) to improve write efficiency.

[0042] The incremental upgrade package construction process incorporates advanced binary differential technology. First, a block alignment algorithm (granular at device storage page sizes, such as 4KB) is used to preprocess the base and target versions, eliminating pseudo-changes caused by alignment differences. Then, an improved BSDiff algorithm is employed, introducing a semantic awareness module on top of byte-level difference analysis. For ELF executables, its segment table information is parsed, comparing only the actual code segment (.text) and data segment (.data), ignoring non-critical content such as debug information (.debug). For JSON / XML configuration files, a tree edit distance algorithm is used to identify structural changes rather than textual differences, avoiding unnecessary upgrades triggered by comment modifications or format adjustments. The generated differential patch includes a three-level verification mechanism: block-level CRC32 checksum to ensure data integrity, file-level SHA-256 signature to verify source authenticity, and global HMAC-SHA1 checksum to prevent tampering. Simultaneously, a dynamic decompression script is embedded in the patch header, guiding the device to allocate an appropriate buffer based on its memory size to avoid decompression failure.

[0043] A dual change detection mechanism (version number comparison + content entropy analysis) identifies components that have actually changed. For files with the same version number but modified content (such as fixing vulnerabilities through binary patches), the SHA-3 algorithm is used to calculate the file entropy value. When the entropy value changes beyond a threshold, an upgrade is triggered. Simultaneously, the module dependency tree is analyzed to automatically identify all affected components (for example, when upgrading a network module, if an incompatible version of its dependent encryption library is detected, a new version of the encryption library is packaged simultaneously). Each module sub-package uses an independent encryption channel, with the key derived from the device's unique ID, module identifier, and timestamp, ensuring that even if a single module is compromised, it will not affect the security of other components. During the upgrade, the device first verifies the module signature and decompresses it to a temporary isolation area. After all modules have passed verification, the bootloader writes them to the system partition in dependency order and updates the version metadata. The entire process supports atomic operations, and any failure at any stage can result in automatic rollback.

[0044] The strategy engine also possesses self-optimization capabilities. After each build, it analyzes metrics such as packaging efficiency (e.g., differential algorithm time consumption, compression ratio) and upgrade success rate (device feedback), and dynamically adjusts strategy parameters (e.g., block size of the differential algorithm, dictionary size of the compression algorithm) through machine learning models. For example, when an increase in the incremental upgrade failure rate of a certain type of device (e.g., a specific model of smart meter) is detected, the differential granularity is automatically reduced (from 4KB to 2KB) and the verification level is increased. Furthermore, it supports extending new packaging types through a plugin mechanism, such as hot-fix packages for security patches (containing only the memory page data to be patched, which is directly written to the specified address on the device without decompression), or debug packages for developers (containing symbol tables, log modules, and other auxiliary information). All packaging processes generate visual reports, recording in detail the processing of each file (reasons for algorithm selection, compression ratio statistics, verification results, etc.), providing data support for problem troubleshooting and strategy optimization.

[0045] In some embodiments of the present invention, the preparation and verification steps of the construction environment are also included: An environment check routine is executed before the processor is invoked to build the rule file; The environment check routine should include at least the following: verifying the existence and version compatibility of the cross-compilation toolchain, checking the validity of the header file paths of the system kernel components, and confirming whether the library files provided by the platform component layer meet the dependencies. Once the environment check routine passes, the subsequent compilation steps are executed.

[0046] In the above embodiments, a predefined build configuration file (usually in YAML / JSON format) is loaded, describing target platform parameters (such as CPU architecture, operating system version, device model), toolchain requirements (compiler version, linker parameters, debugger type), and dependency library specifications (name, version range, ABI compatibility). Based on these configurations, a build sandbox environment is initialized, creating an isolated space through Docker containers or virtualization technology, pre-installing basic development tools (such as make, cmake, ninja, etc.), and setting environment variables (PATH, LD_LIBRARY_PATH, etc.) to point to specified paths to avoid conflicts with the host system environment. For cross-platform build scenarios, the corresponding cross-compilation toolchain (such as gcc-arm-linux-gnueabihf for ARM architecture and riscv64-unknown-elf-gcc for RISC-V architecture) is dynamically loaded according to the target device type, and the corresponding multi-architecture support libraries (such as a multi-version coexistence scheme for glibc) are configured.

[0047] After the environment check routine starts, it performs toolchain integrity verification. It locates the compiler binary file path using the `which` command, resolves the version number using the `--version` parameter, and performs a semantic comparison with the version range required in the configuration file (supporting operators such as >=, <=, and ~>). If the versions do not match, it triggers an upgrade suggestion or terminates the build. For example, when a gcc version lower than 7.3 is detected, it prompts "The current gcc 6.5.0 does not meet the project requirement of >= 7.3.0. It is recommended to upgrade via aptinstall gcc-7".

[0048] Next, a header file path validity check is performed. Based on the kernel header file directory specified in the configuration file (such as / usr / include / linux or / lib / modules / $(uname -r) / build / include), critical header files (such as stdint.h, errno.h, and target platform-specific ones) are recursively scanned.<arch / xxx.h> The process verifies the existence and permissions of files (they must be readable and not have circular symbolic links). For dependency library checks, a two-step verification method is used. First, the library version information is queried using the pkg-config tool (e.g., pkg-config --modversion libssl). Then, the SONAME of the library file is parsed (using objdump -plibxxx.so | grep SONAME) to ensure ABI compatibility. If a library version is found to be too low or there are unresolved symbolic dependencies (detected using ldd -r), it is marked as failing and a dependency tree report is generated.

[0049] After the static checks pass, the dynamic verification phase begins. First, a minimal test compilation task is started, using pre-defined test cases (usually a C / C++ source file containing key feature calls) to compile the target toolchain. The return value indicates successful compilation, and standard output / error streams are captured to analyze specific errors (such as undefined symbols or incompatible instruction sets). For example, when verifying an ARM cross-compilation environment, test cases may include inline assembly code (e.g., asmvolatile("mrs x0, mpidr_el1" ::: "x0")). If the compiler reports an "invalid instruction" error, it indicates that the toolchain is not correctly configured to support the ARMv8 architecture.

[0050] Next, header file content verification is performed. Key header files included in the test cases are parsed to check if the defined macros and structures meet expectations (e.g., whether the value of __LINUX_ARM_ARCH__ matches the target device architecture), avoiding differences in compilation behavior due to inconsistent header file versions. For dependent libraries, the test program is dynamically linked and run (or simulated using QEMU if the target platform is an embedded device) to verify whether library functions can be called correctly (e.g., whether OpenSSL encryption functions return the expected results). Simultaneously, memory leaks (using the Valgrind tool) and thread safety (using the TSan tool) are monitored.

[0051] If any check fails, the build process is immediately terminated and a diagnostic report is generated. The report uses a hierarchical structure: the first level displays the failed check items (e.g., "Cross-compilation toolchain version mismatch"); the second level displays specific error information (e.g., "Current gcc 8.4.0, requires >= 9.3.0"); and the third level provides repair suggestions (e.g., "Execute sudo apt install gcc-9" or "Modify the toolchain_version field in the build configuration file"). For critical environment issues (e.g., missing kernel header files), an automatic repair is attempted by installing the missing components through the package manager (apt / yum / dnf) or downloading a pre-compiled toolchain from a specified repository. If automatic repair fails, the issue is escalated to the developers, and relevant personnel are notified via email / Slack. All check logs are recorded in persistent storage (e.g., the ELK stack), supporting multi-dimensional queries by time, build task, error type, etc.

[0052] This environment verification mechanism supports the extension of new inspection items through plugins. For example, for AI projects, CUDA toolkit version checks can be added; for safety-critical systems, static analysis tools (such as Coverity) can be integrated for code style scanning. For continuous integration (CI) scenarios, environment check results can be cached (e.g., stored as Docker image tags). Subsequent builds can reuse cached results if the environment configuration remains unchanged, shortening preparation time. Furthermore, a built-in environment drift detection function can be implemented, automatically running environment checks periodically (e.g., daily) to compare the current environment with the baseline configuration. When a toolchain is manually upgraded or dependencies are replaced, an alert is triggered and a change impact analysis report is generated, preventing unreproducible build results due to environment inconsistencies.

[0053] In some embodiments of the present invention, a version differentiation construction step is also included: When compiling functional components, different sets of configuration parameters are loaded based on the input version type option; When the version type option is specified as debug version, the loaded configuration parameter set causes the compilation process to introduce debug symbols, enable assertion checks, and enable core dump functionality. When the version type option is set to release, the loaded set of configuration parameters optimizes the compilation process for code size and execution speed, removes debugging symbols, and disables assertion checks and core dump functionality.

[0054] In the above embodiments, compilation configuration is managed through a two-tier architecture of basic parameters and version parameters. Basic parameters (such as target platform and compiler type) are globally applicable, while version parameters (such as optimization strategies and debugging options) are loaded on demand. When the user specifies a version type (such as "debug version" or "release version"), the corresponding parameter package is retrieved from a preset repository.

[0055] The debug version parameters include generating complete debug information (facilitating code problem localization), enabling assertion checks (quickly identifying logical errors), and allowing core dumps (generating memory snapshots in case of crashes). It also retains intermediate artifacts (such as preprocessed files) for developers to analyze the compilation process. The release version parameters include extreme code size optimization (reducing the installation package size), disabling debug symbols (lowering the risk of reverse engineering), and disabling assertions (preventing service interruptions). Link-time optimization (LTO) is enabled, and cross-module code structure is adjusted to improve performance.

[0056] When loading parameters, version-specific parameters are used first. If there is a conflict with the basic parameters (e.g., the basic requirement is moderate optimization, while the release version requires extreme optimization), the version parameters shall prevail, and the adjustment explanation shall be recorded (e.g., the release version upgrades the optimization level, which may increase compilation time).

[0057] The behavior of the compilation tool is dynamically adjusted based on the loaded parameters, as follows: Debug compilation: Debugging symbol generation: The compiler embeds information such as source code line numbers and variable names, making it easier to locate problems using a debugger (such as GDB). For example, if a variable value is abnormal, its definition location in the code can be directly viewed.

[0058] Assertion checking enabled: All predefined assertions (such as assert(x>0)) participate in compilation. If the condition is not met, the program terminates immediately and outputs an error message (such as "Assertion failed: x should be positive"), helping to quickly detect logical errors.

[0059] Core dump support: When a program crashes, a core file is generated, recording information such as memory state and call stack. Developers can use tools to analyze the dump file to pinpoint the cause of the crash (such as null pointer dereferencing).

[0060] Release version compilation: Code optimization and minification: The compiler enables advanced optimizations (such as loop unrolling and function inlining) to reduce code size and improve speed. For example, frequently called short functions are directly embedded at the call site to avoid function call overhead.

[0061] Debug symbol stripping: Removes all debugging information, retaining only necessary symbol tables (such as function names) for error logging, which can reduce file size (usually by 30%-70%) and reduce the risk of being reverse engineered.

[0062] Assertions and dumps disabled: Removes all assertion checks, allowing the program to continue running even if it encounters errors (possibly in an abnormal state), thus avoiding service interruptions. It also disables core dumps to prevent the generation of large files that could affect system stability during a crash.

[0063] Perform multi-dimensional verification on the generated version artifacts and apply optimization strategies according to the version type. Debug version verification: Check the integrity of debug information (such as whether it contains a line number table in DWARF format), run unit tests, confirm that all assertions can be triggered and output the expected errors, actively trigger a crash (such as division by zero), verify whether a valid core file can be generated, and analyze the call stack information.

[0064] Release verification: Use standard test suites (such as SPEC CPU) to measure execution speed. If it does not meet expectations, adjust the optimization strategy (such as upgrading the compiler optimization level). Check whether the file size meets the limit (such as mobile applications need to be less than 100MB). If it exceeds the limit, it is recommended to remove unnecessary functions or enable more aggressive compression (such as UPX packing). Run the program under high load scenarios (such as multi-threaded concurrency) to monitor memory leaks, deadlocks and other issues, and generate crash logs to locate code locations.

[0065] In some embodiments of the present invention, the version differentiation construction step further includes: For the debug version, the upgrade script includes detailed log output instructions and logic for saving exception scenarios; For release versions, the upgrade script removes the log output command and the logic for saving the exception state, and adds a command to execute the upgrade process silently.

[0066] In the above embodiments, the core design of the debug version upgrade script is to provide developers with comprehensive problem traceability support, ensuring that any anomalies that occur during the upgrade process can be quickly located and fixed. Its key logic is as follows: 1. The debug script generates detailed logs for each critical step (such as file decompression, configuration replacement, and service restart), recording the operation time, execution content, and result status. For example, when decompressing the upgrade package, the log will indicate whether decompression started, was successful, or failed (error code: X). These logs are arranged chronologically to form a complete timeline, allowing developers to quickly pinpoint the stage where the problem occurred. If the upgrade fails, the error codes in the logs (such as insufficient file permissions or insufficient disk space) can directly point to the specific cause, avoiding blind troubleshooting.

[0067] 2. When an error occurs during the upgrade process, the script automatically saves the complete state of the current environment, including system environment variables, a list of running processes, and error stacks of related services. For example, if a service fails to start, the script will capture the service's log file, recording the parameter configuration at startup and the error information at the time of the crash. The on-site data will be packaged into a compressed file and timestamped for developers to download and analyze. By reconstructing the environment at the time of the anomaly, developers can accurately reproduce the problem and even simulate repair solutions, shortening the debugging cycle.

[0068] 3. Debug scripts typically offer a debug mode, allowing developers to pause execution at critical steps and manually check intermediate states. For example, after decompressing files, the script may prompt whether to continue configuring the replacement [Y / n]. If the developer chooses to pause, they can manually check whether the decompressed file content is complete and whether permissions are correct. This step-by-step verification mechanism prevents automated execution from masking potential problems, making it particularly suitable for complex upgrade scenarios.

[0069] The core design principle of the release upgrade script is to minimize the impact on users, ensuring a seamless and uninterrupted upgrade process while maintaining high reliability. Its key logic is as follows: 1. The released version of the script removes all unnecessary log output, retaining only key operation results (such as upgrade complete or upgrade failed). For example, when decompressing files, the script will not output a progress bar or detailed steps, but will complete the operation directly in the background. If users view the upgrade process through the terminal, they will only see concise prompts, avoiding log clutter that could negatively impact the user experience. Furthermore, the script supports a silent mode parameter (such as --quiet), which completely hides all output when enabled, only providing feedback through exit codes (0 for success, non-zero for failure).

[0070] 2. The release version of the script strictly controls resource consumption during the upgrade process to avoid system lag due to excessive CPU, memory, or disk usage. For example, if the upgrade involves restarting multiple services, the script will execute them sequentially rather than in parallel to prevent sudden resource spikes. For time-consuming operations such as copying large files or migrating databases, the script will hide the progress display to prevent terminal output from consuming bandwidth or causing interface lag.

[0071] 3. The release script has built-in rollback logic. If the upgrade fails (e.g., service startup timeout, missing critical files), it will automatically revert to the old version of the files and record a simplified error log. For example, if the new version of the service does not respond to a health check within 30 seconds of startup, the script will immediately terminate the new service and restore the old version of the configuration and binary files from the backup directory, while also recording the upgrade failure and rollback logs. This ensures that users can always access available services and avoids prolonged service unavailability due to upgrades.

[0072] The differentiated design of the upgrade scripts for debug and release versions is essentially a balance between development efficiency and user experience. The debug version supports rapid problem fixing through full recording and traceability, while the release version ensures service stability through seamless and highly reliable updates.

[0073] To better implement the embedded system architecture method in this embodiment of the invention, based on the embedded system architecture method, please refer to the corresponding documentation. Figure 4 , Figure 4 This is a schematic diagram of an embodiment of the embedded system architecture device provided by the present invention. The embodiment of the present invention provides an embedded system architecture device 400, comprising: Architecture layering module 410 is configured to establish a layered architecture, which includes a workspace layer, a product component layer, and a platform component layer. Functional component module 420 is configured to create multiple independent functional components for version management in both the product component layer and the platform component layer. Component linking module 430 is configured to create a workspace layer for a specific target device, linking the required functional components from the product component layer and platform component layer to the workspace layer; Architecture building module 440 is configured to execute a build process in the workspace layer, taking functional components as input, to generate a software upgrade package for the target device.

[0074] It should be noted that the device 400 provided in the above embodiments can implement the technical solutions described in the above method embodiments. The specific implementation principles of the above modules or units can be found in the corresponding content in the above method embodiments, and will not be repeated here.

[0075] Please see Figure 5 , Figure 5This is a schematic diagram of the architecture device for an embedded system provided in an embodiment of the present invention. Based on the above-described embedded system architecture method, the present invention also provides an embedded system architecture device, which can be a computing device such as a mobile terminal, desktop computer, laptop, handheld computer, or server. The embedded system architecture device 500 includes a processor 510, a memory 520, and a display 530. Figure 5 Only a portion of the components of the embedded system architecture are shown; however, it should be understood that implementation of all shown components is not required, and more or fewer components may be implemented instead.

[0076] In some embodiments, memory 520 may be an internal storage unit of the embedded system architecture device 500, such as a hard disk or memory of the embedded system architecture device 500. In other embodiments, memory 520 may be an external storage device of the embedded system architecture device 500, such as a pluggable hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the embedded system architecture device 500. Furthermore, memory 520 may include both internal and external storage units of the embedded system architecture device 500. Memory 520 is used to store application software and various types of data installed on the embedded system architecture device 500, such as program code installed on the embedded system architecture device 500. Memory 520 may also be used for temporary storage of data that has been output or will be output. In one embodiment, the memory 520 stores an embedded system architecture program 540, which can be executed by the processor 510 to implement the embedded system architecture method of the various embodiments of this application.

[0077] In some embodiments, processor 510 may be a central processing unit (CPU), a microprocessor, or other data processing chip, used to run program code stored in memory 520 or process data, such as executing the architecture method of an embedded system.

[0078] In some embodiments, display 530 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen. Display 530 is used to display information from the embedded system architecture device 500 and to display a visual user interface. Components 510-530 of the embedded system architecture device 500 communicate with each other via a system bus.

[0079] In one embodiment, when the processor 510 executes the embedded system architecture architecture program 540 in the memory 520, the steps in the embedded system architecture architecture method described above are implemented.

[0080] This embodiment also provides a computer-readable storage medium storing an architecture program for an embedded system, which, when executed by a processor, performs the following steps: Establish a layered architecture, which includes a workspace layer, a product component layer, and a platform component layer; Create multiple independent functional components for version management in both the product component layer and the platform component layer; Create a workspace layer for a specific target device and link the required functional components from the product component layer and platform component layer to the workspace layer; The build process is executed in the workspace layer, taking functional components as input to generate a software upgrade package for the target device.

[0081] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method. The computer-readable storage medium may include, but is not limited to, any type of disk, including floppy disks, optical disks, DVDs, CD-ROMs, microdrives, as well as magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic cards or optical cards, nanosystems (including molecular memory ICs), or any type of medium or device suitable for storing instructions and / or data.

[0082] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0083] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0084] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some service interface; the indirect coupling or communication connection between devices or units may be electrical or other forms.

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

[0086] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0087] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, 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. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0088] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0089] The foregoing description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Those skilled in the art will readily conceive of embodiments of this disclosure upon considering the specification and practicing the disclosure herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described herein. The specification and embodiments are to be considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

[0090] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0091] Those skilled in the art will readily understand that the above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. An architecture construction method of an embedded system, characterized by, The method comprises the following steps: establishing a hierarchical architecture, which comprises a workspace layer, a product component layer and a platform component layer; creating a plurality of function components for version management independently for the product component layer and the platform component layer respectively; creating a workspace layer for a specific target device, and linking the required function components in the product component layer and the platform component layer to the workspace layer; executing a build process in the workspace layer to generate a software upgrade package for the target device by taking the function components as input.

2. The method of claim 1, wherein, The step of executing a build process in the workspace layer to generate a software upgrade package for the target device by taking the function components as input further comprises the following steps: parsing a device configuration file to obtain attribute information of the target device; according to the attribute information, calling corresponding processor build rule files for a plurality of processor types of the target device respectively; for each processor type, calling a module build rule file corresponding to each function component in a predefined module list; compiling the corresponding function component according to the module build rule file; linking and packaging the compiled function component to generate the software upgrade package.

3. The method of claim 2, wherein, The function component comprises an executable file, a configuration file and a device firmware; the step of linking and packaging the compiled function component to generate the software upgrade package further comprises the following steps: classifying the executable file, the configuration file and the device firmware, and packaging them into a plurality of independent sub-compressed packages respectively; generating an upgrade script for controlling the upgrade process, and merging the sub-compressed packages into an upgrade compressed package; merging a pre-compiled target device unpacking program, a package header containing verification information and the upgrade compressed package in a predetermined order to output a software upgrade package.

4. The method of claim 3, wherein, Further comprising a type control step of the software upgrade package: in response to a received build type instruction, selecting a corresponding packaging strategy; when the build type instruction indicates a full upgrade package, the packaging strategy includes all sub-compressed packages in the upgrade compressed package; when the build type instruction indicates an incremental upgrade package, the packaging strategy includes files and their metadata that are different from the baseline version in the upgrade compressed package through a binary difference algorithm; when the build type instruction indicates a module upgrade package, the packaging strategy includes a sub-compressed package corresponding to a specific function component that has changed in the upgrade compressed package.

5. The method of claim 2, wherein, Further comprising a preparation and verification step of the build environment: before calling the processor build rule file, executing an environment check routine; the environment check routine at least includes verifying the existence and version compatibility of a cross-compilation tool chain, checking the validity of a header file path of a system kernel component, and confirming whether library files provided by the platform component layer meet the dependency relationship; when the environment check routine passes, executing the subsequent compilation step.

6. The method of claim 2, wherein, Further comprising a version differentiation build step: when compiling the function component, according to an input version type option, load different configuration parameter sets; When the version type option indicates a debug version, the loaded configuration parameter set causes the compiling process to introduce debug symbols, enable assertion checking and open core dump function; When the version type option indicates a release version, the loaded configuration parameter set causes the compiling process to perform code size and execution speed optimization, remove debug symbols, and disable assertion checking and core dump function.

7. The method of claim 6, wherein, The version differentiation building step further comprises: For a debug version, the upgrade script contains detailed log output instructions and exception site saving logic; For a release version, the upgrade script removes the log output instructions and exception site saving logic, and adds instructions for silent execution of the upgrade process.

8. An apparatus for constructing an architecture of an embedded system, characterized by comprising: Comprise: an architecture layering module configured to establish a layered architecture, the layered architecture comprising a workspace layer, a product component layer and a platform component layer; a functional component module configured to create a plurality of independently version-managed functional components for the product component layer and the platform component layer respectively; a component linking module configured to create a workspace layer for a specific target device, and link required functional components in the product component layer and the platform component layer to the workspace layer; an architecture building module configured to perform a building process in the workspace layer, taking the functional components as input, to generate a software upgrade package for the target device.

9. An architectural building block device for embedded systems, characterized by comprise at least one processing unit and at least one storage unit, wherein the storage unit stores a computer program which, when executed by the processing unit, causes the processing unit to perform the steps of the architecture building method of the embedded system according to any one of claims 1-7.

10. A storage medium, characterized by comprise at least one processing unit and at least one storage unit, wherein the storage unit stores a computer program which, when executed by the processing unit, causes the processing unit to perform the steps of the architecture building method of the embedded system according to any one of claims 1-7. comprise at least one processing unit and at least one storage unit, wherein the storage unit stores a computer program which, when executed by the processing unit, causes the processing unit to perform the steps of the architecture building method of the embedded system according to any one of claims 1-7.

Images