Acquisition terminal operating system compatible with main control chips with different architectures

Abstract

The invention provides an acquisition terminal operating system compatible with main control chips of different architectures, solves the problems of high version management cost, limited chip type selection and lack of a unified basic service module caused by a traditional mode of one core and one system, and realizes seamless operation of the operating system on multiple types of main control chips. The system comprises a hardware layer which is used for providing hardware resources and comprises a main control chip supporting a plurality of different architectures; the operating system layer is located on the hardware layer and used for managing hardware resources and providing a running environment for the application layer, and the operating system layer comprises a bootstrap program which comprises a preloading program module and further comprises a universal bootstrap program module; and a drive program, a hardware abstraction layer, a system kernel, a root file system and a system component. And the application layer is positioned on the operating system layer and is used for executing a terminal acquisition task and upper-layer application logic and accessing resources provided by the operating system layer through a system calling interface.

Description

Technical Field

[0001] This application relates to the field of intelligent measurement technology, specifically to an operating system for a data acquisition terminal that is compatible with main control chips of different architectures. Background Technology

[0002] In existing technologies, the trend towards intelligence and digitalization in power data acquisition terminals is becoming increasingly significant; however, their operating systems exhibit obvious limitations in design and application. Current operating system architectures mostly follow a "one chip, one system" model, meaning that an independent operating system image is designed for each main control chip. While this design strategy could meet basic functional requirements in the early stages of the power industry, it has gradually revealed the following problems in the context of new power system construction:

[0003] 1. Fragmentation of Hardware Adaptation: Statistics show that power data acquisition terminals in operation in China involve a variety of main control chips with different architectures. To support these chips, the operating system development team needs to maintain multiple kernel branches, drivers, and toolchains, which not only increases the complexity of version management but also significantly increases development and maintenance costs.

[0004] 2. High coupling between hardware and software: The tight coupling between the operating system and the main control chip restricts the freedom of hardware upgrades and replacements for terminal devices. Once the main control chip is replaced, the original operating system's underlying code often needs to be significantly refactored, leading to longer upgrade cycles and increased costs.

[0005] 3. Lack of Application Ecosystem: While individual terminal device manufacturers have implemented basic modules such as encryption services and identity authentication, there is a lack of a unified, complete trust chain from the bootloader to the application layer. This fragmented development model hinders the promotion and use of standardized applications and limits the establishment and expansion of the ecosystem.

[0006] Therefore, given that the above-mentioned problems limit the flexibility, security, and application potential of the power acquisition terminal operating system, there is an urgent need for a solution that can cross different architecture main control chips, achieve software and hardware decoupling, and have strong security protection capabilities. Summary of the Invention

[0007] This application provides an operating system and method for a data acquisition terminal that is compatible with different architecture main control chips, solving the problems of high version management costs, limited chip selection, and lack of unified basic service modules caused by the traditional "one chip, one system" model, and realizing seamless operation of the operating system on multiple main control chips.

[0008] To achieve the above objectives, this application adopts the following technical solution:

[0009] In the first aspect, this application provides an operating system for a data acquisition terminal that is compatible with main control chips of different architectures. The system includes: a hardware layer, an operating system layer, and an application layer.

[0010] The hardware layer provides hardware resources, including main control chips that support various architectures.

[0011] The operating system layer sits above the hardware layer, managing hardware resources and providing a runtime environment for the application layer. The operating system layer includes:

[0012] The bootloader includes a preload module for initializing hardware resources and main control chip information when the system powers on or restarts; it also includes a general bootloader module for configuring the system based on different architecture main control chips after the preload module has completed hardware initialization, and loading the system kernel.

[0013] Drivers are used to communicate with the hardware layer and provide hardware drivers to the hardware abstraction layer.

[0014] The hardware abstraction layer is used to shield the hardware differences of different main control chips based on the hardware drivers provided by the driver unit, and to provide a standardized hardware driver interface to the application layer.

[0015] The system kernel is used to schedule hardware resources, manage tasks and processes, and provide system call interfaces to the application layer.

[0016] The root file system is used to store the core files and configuration data required for the operating system to run;

[0017] System components, used to support the operation of the application layer;

[0018] The application layer, located above the operating system layer, is used to execute terminal data acquisition tasks and upper-layer application logic, and accesses resources provided by the operating system layer through system call interfaces.

[0019] Secondly, this application provides a method for enabling an operating system for a data acquisition terminal that is compatible with different architecture main control chips. The enabling method includes:

[0020] When the data acquisition terminal is powered on or restarted, the preload program module initializes hardware resources and main control chip information;

[0021] The general bootloader module starts and reverse-verifies the signature of the preloaded program module. After successful signature verification, it then verifies the signature of the system kernel. After successful verification, the system kernel starts.

[0022] After the system kernel starts, it verifies the signatures of key configuration files in the root file system and security management components in system components. If the signature verification is successful, the root file system is loaded.

[0023] The security management component in the system components reverse verifies the signatures of the general bootloader module and the system kernel. After successful verification, the system call interface is opened.

[0024] The security management component in the system uses a system call interface to verify the signature of the business application in the application layer. If the verification is successful, the business application can be installed or used.

[0025] The general bootloader module, based on the main control chip provided at the hardware layer, performs system configuration and loads the system kernel.

[0026] The data acquisition terminal operating system provided in this application, compatible with different main control chip architectures, achieves compatibility with various main control chips through the design of pre-loaded program modules and a universal boot program module. This solves the problems of high version management costs, limited chip selection, and lack of unified basic service modules caused by the traditional "one chip, one system" model, enabling seamless operation of the operating system on multiple main control chips. Furthermore, the operating system of this application introduces a bidirectional trusted boot chain during the boot process, namely a "forward measurement + reverse signature verification" mechanism, to ensure the software integrity and reliability of the terminal device, thereby meeting the high requirements of new power systems for data acquisition terminals.

[0027] Other features and advantages of this application will be described in detail in the following detailed description section. Attached Figure Description

[0028] To more clearly illustrate the technical solutions in the embodiments of this application, 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 this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0029] Figure 1 A schematic diagram of the architecture of the acquisition terminal operating system that is compatible with different architecture main control chips, provided for the embodiments of this application;

[0030] Figure 2 A schematic diagram of the startup process of the acquisition terminal operating system that is compatible with different architecture main control chips provided in the embodiments of this application. Figure 1 ;

[0031] Figure 3 A schematic diagram of the startup process of the acquisition terminal operating system that is compatible with different architecture main control chips provided in the embodiments of this application. Figure 2 ; Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of the embodiments in this specification clearer, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. The components of the embodiments of this specification described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0033] Therefore, the following detailed description of the embodiments of this specification provided in the accompanying drawings is not intended to limit the scope of the claimed specification, but merely to illustrate selected embodiments of this specification. All other embodiments obtained by those skilled in the art based on the embodiments in this specification without inventive effort are within the scope of protection of this specification.

[0034] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0035] In the description of the embodiments in this specification, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," indicating orientation or positional relationships, are based on the orientation or positional relationships shown in the accompanying drawings, or the orientation or positional relationships commonly used when the product is in use. These are merely for the convenience of describing this specification and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this specification. Furthermore, the terms "first," "second," and "third," etc., are only used to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0036] Furthermore, the use of terms such as "horizontal," "vertical," and "sag" does not imply that the component must be absolutely horizontal or suspended, but rather that it can be slightly tilted. For example, "horizontal" simply means that its direction is more horizontal relative to "vertical," and does not mean that the structure must be completely horizontal, but can be slightly tilted.

[0037] In the description of the embodiments in this specification, it should also be noted that, unless otherwise explicitly specified and limited, the terms "set," "install," "connect," and "link" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this specification according to the specific circumstances.

[0038] The following section will introduce a data acquisition terminal operating system compatible with different architecture main control chips. This system solves the problems of high version management costs, limited chip selection, and lack of unified basic service modules caused by the traditional "one chip, one system" model, and realizes the seamless operation of the operating system on multiple main control chips.

[0039] Figure 1 This is a schematic diagram of the structure of the acquisition terminal operating system that is compatible with different architecture main control chips, provided in the embodiments of this application.

[0040] like Figure 1 As shown, this data acquisition terminal operating system is compatible with different main control chip architectures.

[0041] The system comprises: a hardware layer, an operating system layer, and an application layer;

[0042] The hardware layer provides hardware resources, including main control chips that support various architectures.

[0043] The operating system layer sits above the hardware layer, managing hardware resources and providing a runtime environment for the application layer. The operating system layer includes:

[0044] The bootloader includes a preload module for initializing hardware resources and main control chip information when the system powers on or restarts; it also includes a general bootloader module for configuring the system based on different architecture main control chips after the preload module has completed hardware initialization, and loading the system kernel.

[0045] Drivers are used to communicate with the hardware layer and provide hardware drivers to the hardware abstraction layer.

[0046] The hardware abstraction layer is used to shield the hardware differences of different main control chips based on the hardware drivers provided by the driver unit, and to provide a standardized hardware driver interface to the application layer.

[0047] The system kernel is used to schedule hardware resources, manage tasks and processes, and provide system call interfaces to the application layer.

[0048] The root file system is used to store the core files and configuration data required for the operating system to run;

[0049] System components, used to support the operation of the application layer;

[0050] The application layer, located above the operating system layer, is used to execute terminal data acquisition tasks and upper-layer application logic, and accesses resources provided by the operating system layer through system call interfaces.

[0051] It is understandable that the aforementioned bootloader includes a Pre-Loader (pre-loader module) and a U-Boot (universal bootloader module). The Pre-Loader is used to initialize chip-related information and boot U-Boot. Due to significant differences in the implementation of various main control chips, it is impossible to achieve compatibility across different chip platforms. This part can be implemented in a differentiated and customizable manner, and the Pre-Loaders for different platforms can be managed through a unified repository.

[0052] In this embodiment, the hardware layer includes a hardware abstraction layer framework and hardware abstraction layer modules; the hardware abstraction layer framework provides the structural definition of the hardware abstraction layer in the form of a dynamic link library; the hardware abstraction layer modules provide standardized hardware driver interfaces to the application layer in the form of a dynamic link library.

[0053] Furthermore, the Hardware Abstraction Layer (HAL) framework and HAL module specifications have unified data structure definitions and external interface definitions; the HAL framework dynamic link library can be named libhd.so; the HAL module dynamic link library can be uniformly named libhal_ <moduleid>so or libhal_common.so; the path of the hardware abstraction layer framework dynamic link library and the hardware abstraction layer module dynamic link library is uniformly defined as / lib / hal_lib / .

[0054] In this embodiment, the configuration of the system kernel allows the user to select different compilation options, and different compilation options will compile different kernel image files, which are used for digital signature processing to ensure system security.

[0055] It can be understood that the configuration of the system kernel allows the user to select different compilation options according to the needs, and the system will generate different kernel image files for different options. Each kernel image file will be processed by digital signature after being generated, and the digital signature ensures that the file is not tampered with during storage and transmission, and only the verified and trusted version can be loaded into the system. For example, the signature process can use public key infrastructure (PKI) technology to use key pairs for encryption and decryption operations to ensure the integrity and security of the system. When the system starts, the operating system will verify the digital signature of the kernel image file to ensure that the loaded kernel file is authorized and has not been maliciously modified, thereby effectively preventing potential security threats such as the implantation of malicious code or viruses.

[0056] In this embodiment, the root file system adopts a read-only storage mode, and through a data integrity verification mechanism, it is ensured that the core files and configuration data are not tampered with.

[0057] The root file system includes a basic tool set and an extended tool set; the basic tool set includes management and monitoring tools related to general functions and features of the operating system; the extended tool set includes tools related to terminal function acquisition and standard set specifications.

[0058] The following Table 1 shows the commonly used commands of the basic tool set and the extended tool set, as follows:

[0059]

[0060]

[0061] Table 1

[0062] In this embodiment, the system components include a network service component for providing remote management services, network connection services, and port configuration services. For example, the system provides a SSHD server by default, and the Ethernet device interface FE0 is set as the default security test connection port, with the IP address uniformly set as 192.168.2.170, and the SSH service port uniformly set as 8888. Through this configuration, remote management operations can be performed, so that users can securely access the system through the network for configuration and maintenance.

[0063] In this embodiment, the system components include a container engine component for supporting containerization technology, providing container creation, management and deployment functions, and ensuring application layer running, management and maintenance by porting Docker and related tools. It can be understood that containerization technology enables the application and its dependent environment to be encapsulated in a lightweight independent container, thereby improving the portability, scalability and isolation of the application. The container engine component not only supports the creation and running of containers, but also provides a series of management functions, such as automated deployment, container image building and version control, and container lifecycle management (such as starting, stopping, restarting and destroying). By integrating Docker and other container tools, the system can easily deploy applications in different environments, whether in development, testing or production environments.

[0064] For example, the container engine component ports the docker container engine and related components, and the specific implementation generally includes the following commands:

[0065] docker: the client of docker, mainly responsible for sending docker operation requests;

[0066] dockerd: the server entry of docker, mainly responsible for receiving client requests and returning results;

[0067] docker-init: mainly responsible for managing child processes within the container;

[0068] docker-proxy: mainly responsible for implementing the network function of docker;

[0069] containerd: mainly responsible for managing the lifecycle of containers, by receiving dockerd requests, performing start or destroy container operations;

[0070] containerd-shim: uses containerd-shim as the parent process of the container process, to decouple containerd and the container process;

[0071] ctr: the client of containerd, which can be used for development and debugging;

[0072] runc: container runtime component, which creates and destroys containers by calling namespace, cgroup and other system interfaces.

[0073] In this embodiment, the system components include a security management component for providing encryption services and secure boot services. The encryption service sets up a dedicated encryption interface for encryption, and the secure boot service performs secure boot service through a bidirectional trusted boot chain.

[0074] For example, the aforementioned two-way trusted boot chain can be understood as two processes: hardware to operating system (one-way verification) and operating system to hardware (reverse verification). During one-way verification, at boot time, the system firmware (such as BIOS or UEFI) checks the trustworthiness of the hardware and boot code to ensure they haven't been tampered with. Then, it loads and verifies the operating system's bootloader to ensure the operating system is trustworthy. During reverse verification, after booting, the operating system checks whether the hardware is in a secure state to ensure it hasn't been maliciously modified. Furthermore, the operating system uses hardware security modules (such as TPM) to verify the trustworthiness of critical components and prevent malware intrusion.

[0075] In this embodiment, the application layer includes a basic application (basic APP) and a business application (business APP). The basic application and the business application include both 32-bit and 64-bit binary programs. The choice between 32-bit and 64-bit depends on the actual situation.

[0076] In summary, the data acquisition terminal operating system provided in this application, which is compatible with different main control chips, achieves compatibility with different main control chips through the design of pre-loaded program modules and universal boot program modules. This solves the problems of high version management costs, limited chip selection, and lack of unified basic service modules caused by the traditional "one chip, one system" model, enabling seamless operation of the operating system on multiple main control chips. Furthermore, the operating system of this application introduces a bidirectional trusted boot chain, namely a "forward measurement + reverse signature verification" verification mechanism, during the specific boot process to ensure the software integrity and reliability of the terminal device, thereby meeting the high requirements of new power systems for data acquisition terminals.

[0077] The above combination Figure 1 This application describes the data acquisition terminal operating system provided in its embodiments, which is compatible with different architecture main control chips. The following is in conjunction with... Figure 2 and Figure 3 This document explains how to enable the operating system of a data acquisition terminal that is compatible with different main control chip architectures.

[0078] When the data acquisition terminal is powered on or restarted, the preload program module initializes hardware resources and main control chip information;

[0079] The general bootloader module starts and reverse-verifies the signature of the preloaded program module. After successful signature verification, it then verifies the signature of the system kernel. After successful verification, the system kernel starts.

[0080] After the system kernel starts, it verifies the signatures of key configuration files in the root file system and security management components in system components. If the signature verification is successful, the root file system is loaded.

[0081] The security management component in the system components reverse verifies the signatures of the general bootloader module and the system kernel. After successful verification, the system call interface is opened.

[0082] The security management component in the system uses a system call interface to verify the signature of the business application in the application layer. If the verification is successful, the business application can be installed or used.

[0083] The general bootloader module, based on the main control chip provided at the hardware layer, performs system configuration and loads the system kernel.

[0084] In this embodiment, when the acquisition terminal is powered on or restarted, the preload program module initializes hardware resources and main control chip information in three stages: BL0, BL1, and BL2. For example... Figure 2 As shown, in the BL0 stage: BootRom is the bootloader, which is a program directly embedded in the SoC chip ROM and will be executed by default when powered on;

[0085] BL1 stage: The Pre-Loader is called by the BootRom in the chip and is mainly responsible for initializing chip-related information and booting U-Boot;

[0086] BL2 stage: The open-source tool U-Boot (generic bootloader module) is selected to complete the remaining device initialization work. After the operating system kernel starts up, the bootloader completes its mission and exits, and then the subsequent steps are executed.

[0087] Furthermore, the specific implementation of the above method is basically similar to the system implementation, so the description is relatively simple. For relevant details, please refer to the description of the system implementation.

[0088] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this disclosure (including the claims) is limited to these examples; within the scope of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of the different aspects of this application as described above, which are not provided in the details for the sake of brevity.

[0089] The embodiments of this application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.< / moduleid>

Claims

1. A data acquisition terminal operating system compatible with different main control chip architectures, characterized in that, The system includes: a hardware layer, an operating system layer, and an application layer; The hardware layer is used to provide hardware resources, including a main control chip that supports multiple different architectures; The operating system layer is located above the hardware layer and is used to manage hardware resources and provide a runtime environment for the application layer. The operating system layer includes: The bootloader includes a preload module for initializing hardware resources and main control chip information when the system is powered on or restarted; it also includes a general bootloader module for configuring the system based on different architecture main control chips after the preload module has completed hardware initialization, and loading the system kernel. The driver is used to communicate with the hardware layer and provide hardware drivers to the hardware abstraction layer; The hardware abstraction layer is used to shield the hardware differences of different architecture main control chips based on the hardware driver provided by the driver unit, and to provide a standardized hardware driver interface to the application layer. The system kernel is used to schedule hardware resources, manage tasks and processes, and provide system call interfaces to the application layer. The root file system is used to store the core files and configuration data required for the operating system to run; System components, used to support the operation of the application layer; The application layer, located above the operating system layer, is used to execute terminal data acquisition tasks and upper-layer application logic, and accesses resources provided by the operating system layer through system call interfaces.

2. The data acquisition terminal operating system compatible with different architecture main control chips according to claim 1, characterized in that, The hardware layer includes a hardware abstraction layer framework and a hardware abstraction layer module; The hardware abstraction layer framework provides the structural definition of the hardware abstraction layer in the form of a dynamic link library; The hardware abstraction layer module provides standardized hardware driver interfaces to the application layer in the form of dynamic link libraries.

3. The data acquisition terminal operating system compatible with different architecture main control chips according to claim 1, characterized in that, The system kernel configuration allows users to select different compilation options, which will compile different kernel image files. These kernel image files are used for digital signature processing to ensure system security.

4. The acquisition terminal operating system compatible with different architecture main control chips according to claim 1, characterized in that, The root file system uses a read-only storage mode.

5. The data acquisition terminal operating system compatible with different architecture main control chips according to claim 1, characterized in that, The root file system includes a basic toolset and an extended toolset; The basic toolset includes management and monitoring tools related to the general functions and features of the operating system; The extended toolset includes tools related to the functions of the data acquisition terminal and the standards set specifications.

6. The acquisition terminal operating system compatible with different architecture main control chips according to claim 1, characterized in that, The system components include network service components, which provide remote management services, network connection services, and port configuration services.

7. The data acquisition terminal operating system compatible with different architecture main control chips according to claim 1, characterized in that, The system components include a container engine component, which supports containerization technology, provides container creation, management and deployment functions, and ensures the operation, management and maintenance of the application layer by porting Docker and related tools.

8. The data acquisition terminal operating system compatible with different architecture main control chips according to claim 1, characterized in that, The system components include a security management component for providing encryption services and secure boot services. The encryption service uses a dedicated encryption interface for encryption, and the secure boot service uses a two-way trusted boot chain for secure booting.

9. The data acquisition terminal operating system compatible with different architecture main control chips according to claim 1, characterized in that, The application layer includes basic applications and business applications, and the basic applications and business applications include both 32-bit and 64-bit binary programs.

10. A method for enabling an operating system for a data acquisition terminal compatible with different architecture main control chips, applied to the data acquisition terminal operating system compatible with different architecture main control chips as described in any one of claims 1-8, characterized in that, The activation method includes: When the data acquisition terminal is powered on or restarted, the preload program module initializes hardware resources and main control chip information; The general bootloader module starts and reverse-verifies the signature of the preloaded program module. After successful signature verification, it then verifies the signature of the system kernel. After successful verification, the system kernel starts. After the system kernel starts, it verifies the signatures of key configuration files in the root file system and security management components in system components. If the signature verification is successful, the root file system is loaded. The security management component in the system components reverse verifies the signatures of the general bootloader module and the system kernel. After successful verification, the system call interface is opened. The security management component in the system components verifies the signature of the business APP in the application layer based on the system call interface. After successful verification, the business APP is installed or used. The general bootloader module, based on the main control chip provided at the hardware layer, performs system configuration and loads the system kernel.

Images