Deployment method and device of real-time operating system instance and computing equipment
Obtaining and configuring MICA client and back-end services through containerized services, the complexity of UniProton's real-time operating system deployment is solved, and efficient and general real-time operating system deployment is achieved.
Patent Information
- Application Number
- CN202510409277.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-01
- Publication Date
- 2025-08-15
AI Technical Summary
The deployment method of the existing UniProton real-time operating system requires the user to manually configure CPU and memory resources, and the operation is complex and not universal.
By obtaining the first container image file and the second container image file, the MICA client and MICA back-end services are respectively started, and the real-time operating system deployment is realized using containerized services, including configuring kernel modules and management components, and orchestrating and management using the container engine.
Simplifies the deployment process of real-time operating systems, improves deployment efficiency and system stability, and enhances deployment universality and flexibility.
Smart Images
Figure CN120492039A_ABST
Abstract
Description
Technical Field
[0001] The embodiments of the present application relate to the field of computer technology, and in particular to a method, apparatus, and computing device for deploying a real-time operating system instance. Background Art
[0002] UniProton is a lightweight real-time operating system for embedded systems based on the open source heterogeneous multi-core processing (OpenAMP) architecture. It can be hosted on general-purpose Linux systems, providing low latency and flexible deployment capabilities for real-time applications. The UniProton RTOS is deployed using a dedicated Mixed Criticality System (MCS) deployment tool, and its form factor differs from typical Linux operating system applications.
[0003] However, the deployment method for the UniProton real-time operating system requires users to manually configure independent central processing unit (CPU) and memory resources and load kernel modules. This deployment method is not universal and the operation is complex and difficult to understand. Summary of the Invention
[0004] The present invention provides a method, apparatus, and computing device for deploying a real-time operating system instance, which simplifies the deployment method of a real-time operating system instance and avoids complex operation processes. The technical solution is as follows:
[0005] In a first aspect, a deployment method for a real-time operating system instance is provided, which is applied to a computing device for execution, and the method includes: obtaining a first container image file and a second container image file; the first container image file includes a script file and an operating environment of a hybrid criticality deployment framework MICA client; the second container image file includes a kernel module, a MICA backend service, and a management component; the management component is used to manage resources of the real-time operating system instance; according to the first container image file, starting the first container triggers the process of starting the real-time operating system instance; starting the first container is used to configure the MICA client and the operating environment for the computing device; according to the second container image file, starting the second container triggers the process of starting the MICA backend service; wherein, starting the second container is used to configure the kernel module, the MICA backend service, and the management component for the computing device, and the MICA backend service supports the running of the real-time operating system instance.
[0006] From the above, it can be seen that the computing device obtains the container image file including the MICA client, kernel module, MICA backend service and related components, and implements the deployment of the real-time operating system instance through containerized service. This can reduce the complex operations of the real-time operating system instance deployment and make the real-time operating system deployment process universal.
[0007] In a possible implementation, the entry command of the first container is set to start a process of a real-time operating system instance; and the entry command of the second container is set to start a process of a MICA backend service.
[0008] From the above, it can be seen that by setting the entry command of the first container and the entry command of the second container, it is possible to start the process of the real-time operating system instance and the MICA backend service when the first container and the second container are started, thereby completing the deployment of the real-time operating system instance, reducing the complex operations of the real-time operating system instance deployment, and improving deployment efficiency.
[0009] In a possible implementation, a shared storage volume is created; the shared storage volume is used to share files between containers; and the shared storage volume includes real-time operating system instance files.
[0010] From the above, it can be seen that storing the real-time operating system instance files in the shared storage volume of the container system can not only reduce the storage space occupied by the first container and / or the second container, but also maintain the uniformity of the real-time operating system instance files, thereby improving the stability of the system.
[0011] In a possible implementation, the shared storage volume includes a configuration file; the configuration file is used to configure computing resources occupied by the real-time operating system instance; the configuration file includes the number of central processing units occupied by the real-time operating system instance.
[0012] As can be seen from the above, the shared storage volume includes the configuration file, which can reduce the storage space occupied by the first container and improve the flexibility of real-time operating system deployment.
[0013] In a possible implementation, access permissions for the second container are configured; the access permissions are used to indicate that the second container can access a kernel of the operating system.
[0014] As can be seen from the above, since the second container image file includes a kernel module, when starting the second container, the kernel module must be loaded into the operating system kernel. Therefore, the second container needs to access the operating system kernel to enable the operating system kernel to install the kernel module.
[0015] In a possible implementation, path information of the communication channel is mounted to the first container and the second container, so that the first container and the second container communicate through the communication channel.
[0016] As can be seen above, since the first container image includes the MICA client and the second container image includes the MICA backend service, communication between the MICA client and the MICA backend service is required during the process of launching the first and second containers to deploy the real-time operating system. Therefore, communication between the first and second containers is enabled by mounting the path information of the communication channel to the first and second containers.
[0017] In one possible implementation, the first container is started by a first deployment command; the first deployment command is used to start the first container; or, the first container is started on the target host by a first configuration script; the first configuration script includes a label of the target host.
[0018] In one possible implementation, the second container is started by a second deployment command; the second deployment command is used to start the second container; or, the second container is started on the target host by a second configuration script; the second configuration script includes a label of the target host.
[0019] As can be seen from the above, different container startup methods are suitable for different scenarios, improving the universality of RTOS instance deployment. Furthermore, clustered deployment, achieved by starting the first and second containers through configuration scripts, is more suitable for various complex scenarios and RTOS instances. Furthermore, the clustering features of the container engine can be leveraged to orchestrate and manage RTOS instances, further improving the efficiency of RTOS deployment.
[0020] In the second aspect, a deployment device for a real-time operating system instance is provided. In an embodiment of the present application, the deployment device for the real-time operating system instance can be divided into functional modules according to the method provided in the first aspect. For example, each functional module can be divided corresponding to each function, or two or more functions can be inherited in one processing module. Exemplarily, an embodiment of the present application can divide the deployment device for the real-time operating system into an acquisition module and a startup module according to the function. The description of the possible technical solutions and beneficial effects executed by the above-mentioned divided functional modules can refer to the technical solutions provided by the first aspect or its corresponding possible implementation methods, and will not be repeated here.
[0021] In a third aspect, an embodiment of the present application provides a computing device, comprising a processor and a memory, wherein the memory stores computer instructions, which are loaded and executed by the processor to enable the server to implement the deployment method of a real-time operating system instance as described in the first aspect above.
[0022] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which at least one computer program is stored. The computer program is loaded and executed by a processor to implement the deployment method of a real-time operating system instance as described in the first aspect above.
[0023] In a fifth aspect, embodiments of the present application provide a computer program product or computer program, comprising computer instructions stored in a computer-readable storage medium. A processor of a computing device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computing device to perform the method for deploying a real-time operating system instance provided in various optional implementations of the first aspect.
[0024] For the specific description of the second to fifth aspects and their various implementations in the embodiments of the present application, reference can be made to the detailed description in the first aspect and its various implementations; and for the beneficial effects of the second to fifth aspects and their various implementations, reference can be made to the analysis of the beneficial effects in the first aspect and its various implementations, which will not be repeated here.
[0025] These and other aspects of the embodiments of the present application will be more clearly understood in the following description. BRIEF DESCRIPTION OF THE DRAWINGS
[0026] Figure 1 1 shows a schematic diagram of the architecture of a real-time operating system instance 100 provided in an embodiment of the present application;
[0027] Figure 2 A hardware schematic diagram of a computing device 200 provided in an embodiment of the present application is shown;
[0028] Figure 3 A schematic diagram illustrating a process of deploying a real-time operating system instance provided by an embodiment of the present application is shown;
[0029] Figure 4 A schematic diagram of a first container image file and a second container image file provided in an embodiment of the present application is shown;
[0030] Figure 5 A software framework diagram of a real-time operating system instance 100 provided in an embodiment of the present application is shown;
[0031] Figure 6 A schematic diagram of a process for constructing a first container image file provided by an embodiment of the present application is shown;
[0032] Figure 7 A schematic diagram of a process for constructing a second container image file provided by an embodiment of the present application is shown;
[0033] Figure 8 A schematic diagram showing the structure of a deployment device 400 for a real-time operating system instance provided in an embodiment of the present application is shown. DETAILED DESCRIPTION
[0034] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application. Among them, in the description of the present application, unless otherwise specified, " / " indicates that the objects associated before and after are in an "or" relationship. For example, A / B can represent A or B; "and / or" in the present application is only a description of the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. In addition, in the description of the present application, unless otherwise specified, "multiple" refers to two or more than two. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, c can be single or multiple. In addition, in order to facilitate a clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish identical or similar items with basically the same functions and effects.
[0035] Those skilled in the art will understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit differences. At the same time, in some embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or design. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a concrete way for easy understanding.
[0036] In addition, the device architecture and business scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Ordinary technicians in this field can know that with the evolution of device architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.
[0037] Terminology Introduction:
[0038] Mixed Criticality System (MCS): A computer system that includes tasks and applications of varying criticality. This system emphasizes the multi-criticality nature of the system as a whole and the tasks and applications it runs. Functionally, it focuses on completing tasks of varying criticality to meet diverse application scenarios.
[0039] Mixed Criticality Architecture (MICA): An architecture for managing and coordinating tasks and resources of varying criticality levels within mixed-criticality systems. This architecture or mechanism enables the rational deployment of multiple tasks and applications across hardware and software resources within mixed-criticality systems, supporting the running of real-time operating system instances.
[0040] Rpm-ivh: is a commonly used command in Linux operating systems based on the Red Hat Package Manager (RPM) package management system, used to install RPM software packages.
[0041] insmod: is a command used to load kernel modules in the Linux operating system, which is the abbreviation of install module; the basic syntax includes insmod [options] <module>;in, <module>It is the kernel module file to be loaded, usually with the suffix .ko; [options] is an optional parameter.
[0042] First, the application scenarios of the embodiments of the present application are exemplarily introduced.
[0043] A real-time operating system (RTOS) is an operating system that can accept and process external events or data quickly enough when they occur, and whose results can be used to control production processes or respond quickly to processing systems within a specified timeframe. It also dispatches all available resources to complete real-time tasks and ensures the coordinated and consistent operation of all real-time tasks. RTOSs are widely used in various industrial automation fields, including intelligent production lines, autonomous driving, medical equipment, and other scenarios requiring precise control and stable operation.
[0044] UniProton is a real-time operating system for embedded scenarios. Real-time applications built on UniProton are deployed on the Linux operating system through a hybrid deployment framework and coexist with the Linux operating system.
[0045] An embodiment of the present application provides a method for deploying a real-time operating system. The method is applied to a computing device, wherein the computing device obtains a first container image file and a second container image file. The first container image file includes a script file and an operating environment for a hybrid criticality deployment framework MICA client; the second container image file includes a kernel module, a MICA backend service, and a management component; the management component is used to manage the resources of the real-time operating system instance. The computing device starts the first container based on the first container image file, triggering the process of starting the real-time operating system instance; wherein starting the first container is used to enable the computing device to configure the MICA client and the operating environment. The computing device starts the second container based on the second container image file, triggering the process of starting the MICA backend service; wherein starting the second container is used to enable the computing device to configure the kernel module, the MICA backend service, and the management component, and the MICA backend service supports the operation of the real-time operating system instance. As can be seen from the above method, the deployment of the real-time operating system instance through a containerized service approach can greatly reduce the complex operations of real-time operating system deployment. In addition, the characteristics of the container engine can also be used to orchestrate and manage the real-time operating system instance, further improving the efficiency of real-time operating system deployment.
[0046] Next, the system architecture of the embodiment of the present application is exemplarily introduced.
[0047] Figure 1 FIG. 1 shows a schematic diagram of the architecture of a real-time operating system instance 100 provided in an embodiment of the present application. Figure 1 As shown, the real-time operating system instance 100 includes a first container 110 and a second container 120 .
[0048] First container 110 is an instance of a first container image file; second container 120 is an instance of a second container image file. First container 110 and second container 120 communicate via a communication channel (socket). Both first container 110 and second container 120 can access a shared storage volume.
[0049] Optionally, the shared storage volume includes instance files of the real-time operating system instance 100. The real-time operating system instance 100 includes real-time operating system files and program files of services running in real-time operation.
[0050] The first container 110 includes the script files and operating environment of the Mixed Criticality Architecture (MICA) client. The second container 120 includes the MICA backend service, kernel module, and management component. The management component is used to manage the resources of the real-time operating system instance 100. Among them, the MICA client is used to interact with the real-time operating system instance 100 for data. The MICA backend service is used to support the operation of the real-time operating system instance, for example, to perform lifecycle management and coordinated scheduling of the real-time operating system instance 100.
[0051] The kernel module is loaded into the general operating system kernel when the second container 120 starts. Specifically, the kernel module may include the mcs_km.ko file and the eth_i210.ko file. mcs_km.ko provides computing resource management for the real-time operating system instance 100, including mechanisms such as CPU startup, program loading, inter-core communication, interrupt management, and transmission and reception. eth_i210.ko is a network card driver developed specifically for the real-time operating system instance 100, connecting the real-time operating system instance 100 to the hardware.
[0052] The general operating system kernel can specifically be the kernel of the Linux operating system, which is used to load the kernel module in the second container 120. The kernel module provides computing resource management, inter-core communication, interrupt management, etc. for the real-time operating system instance 100.
[0053] Figure 2 FIG2 shows a hardware diagram of a computing device 200 provided in an embodiment of the present application, wherein the computing device 200 is used to implement a method for deploying a real-time operating system. Figure 2 As shown, computing device 200 includes a processor 210, a memory 220, a communication interface 230, and a bus 240. Processor 210, memory 220, and communication interface 230 are connected via bus 240. For example, computing device 200 may be a standard general-purpose server, specifically a blade server, a high-density server, a rack server, or a high-performance server. It should be understood that this application does not limit the number of processors 210 and memory 220 in computing device 200.
[0054] Specifically, the processor 210 may be a central processing unit (CPU) or a graphics processing unit (GPU). The processor 210 is used to obtain a first container image file and a second container image file; the first container image file includes a script file and an operating environment of a Hybrid Criticality Architecture (MICA) client; the second container image file includes a kernel module, a MICA backend service, and a management component; the management component is used to manage the resources of a real-time operating system instance; based on the first container image file, the first container is started to trigger the process of starting the real-time operating system instance; wherein starting the first container is used to configure the computing device with the MICA client and the operating environment; based on the second container image file, the second container is started to trigger the process of starting the MICA backend service, wherein starting the second container is used to configure the computing device with the kernel module, the MICA backend service, and the management component, and the MICA backend service supports running the real-time operating system instance.
[0055] Memory 220 is used to store processor-executable instructions. Memory 220 can be a storage space that maintains data even after a power outage, such as non-volatile RAM (NVRAM) or electrically erasable programmable read-only memory (EEPROM). Communication interface 230 is used to facilitate data transmission and communication between devices.
[0056] It should be noted that the system architecture and application scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Ordinary technicians in this field can know that with the evolution of the system architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.
[0057] For ease of understanding, the following describes an exemplary method for deploying a real-time operating system instance provided by the present application in conjunction with the accompanying drawings. The method for deploying a real-time operating system instance is as follows: Figure 2 The computing device 200 shown executes the method, which includes:
[0058] Figure 3 A flow chart of a method for deploying a real-time operating system instance provided by an embodiment of the present application is shown. The method for deploying a real-time operating system instance is executed by a computing device and includes the following steps:
[0059] S101: A computing device obtains a first container image file and a second container image file.
[0060] The first container image file includes the script files and runtime environment for the Hybrid-Criticality Architecture (MICA) client. The second container image file includes the kernel module, MICA backend services, and management components. The management components are used to manage the resources of the real-time operating system instance. For example, they can be used to manage the real-time operating system lifecycle, inter-processor communication, kernel information acquisition, resource management, and configuration.
[0061] In the embodiment of the present application, the first container image file and the second container image file are read-only files encapsulated according to the first container and the second container. The running instance of the first container image file is the first container; the running instance of the second container image file is the second container.
[0062] For example, Figure 4 A schematic diagram of a first container image file and a second container image file provided in an embodiment of the present application is shown. Figure 4 As shown, the first container image file also includes the MICA client script file and the Python runtime environment. The second container image file includes the kernel module, the MICA backend service, and the management component.
[0063] The management components include those that the real-time operating system instance relies on to run, specifically components such as the Heterogeneous Multiprocessor Remote Management System (OpenAMP), the Hardware Abstraction Layer (Libmetal), and the Kernel Interface File System Tool (SysfsUtils). Kernel modules can specifically include the mcs_km.ko file and the eth_i210.ko file. mcs_km.ko is used to provide computing resource management for the real-time operating system instance, including central processing unit (CPU) startup, program loading, inter-core communication, interrupt management, and transmission and reception mechanisms. eth_i210.ko is a network card driver developed specifically for the real-time operating system, connecting the real-time operating system to the hardware.
[0064] S102: The computing device starts the first container according to the first container image file, triggering the process of starting the real-time operating system instance. The starting of the first container is used to configure the computing device with a MICA client and an operating environment.
[0065] In one possible implementation, a computing device creates a shared storage volume for sharing files between containers; the shared storage volume includes a real-time operating system instance file; and the real-time operating system instance file is loaded into a first container and used to start the real-time operating system instance.
[0066] Exemplarily, taking the real-time operating system instance as a UniProton system instance as an example, the real-time operating system instance file includes the UniProton system instance file.
[0067] For example, the computing device can create a shared storage volume through the container creation command and copy the UniProton system instance file to the shared storage volume. When the first container image file and the second container image file are started, the shared storage volume is mounted to realize the sharing of the UniProton system instance file.
[0068] In one possible implementation, the shared storage volume includes a configuration file, wherein the configuration file is used to configure computing resources occupied by the real-time operating system instance, and the configuration file includes the number of central processing units (CPUs) occupied by the real-time operating system instance.
[0069] When the first container and the second container are started, the configuration file is obtained by the MICA client in the first container, and the real-time operating system instance is configured according to the configuration file.
[0070] As can be seen from the above, the shared storage volume includes the configuration file, which can reduce the storage space occupied by the first container and improve the flexibility of real-time operating system deployment.
[0071] In one possible implementation, the computing device mounts path information of the communication channel to the first container and the second container, so that the first container and the second container communicate through the communication channel.
[0072] In this embodiment of the present application, the first container includes a MICA client, and the second container includes a MICA backend service. To enable communication between the first and second containers, the computing device must enable communication between the first and second containers. To make / dev / mcs visible in both the first and second containers, the computing device's / dev / mcs device must be directly connected to the first and second containers. This allows the MICA client in the first container and the MICA backend service in the second container to directly access the / dev / mcs device.
[0073] For example, the communication channel includes a socket file. The first container and the second container interact through / run / micasocket. The computing device mounts the socket file path / run / mica as a shared storage volume into the first and second containers, thereby enabling communication between the first and second containers. A socket is an abstraction layer between the application layer and the transport layer, encapsulating complex network communications into a simple interface, allowing processes on different hosts to connect and communicate through the interface.
[0074] In one possible implementation, the computing device starts the first container through a first deployment command; the first deployment command is used to start the first container; or, the computing device starts the first container on a target host through a first configuration script; the first configuration script includes a label of the target host.
[0075] In some examples, before the computing device executes the first deployment command through the first container engine, the computing device needs to install the first container engine and the runtime environment. Therefore, the computing device needs to obtain the first deployment command first.
[0076] For example, a computing device launches a first container using the Docker container engine. Because the first container engine uses the docker run command to launch the container, the first deployment command also includes mounting a shared storage volume, launching the MICA client, and implementing access to the underlying serial communication interface abstracted by the / dev / mcs device.
[0077] As can be seen from the above, starting a container using a deployment command by a computing device is suitable for the deployment and management of a single container, and the startup method is simple and easy to operate. Starting the first container by the computing device using the first container engine can improve the efficiency of starting the first container.
[0078] In other examples, a first container is started on a target host using a first configuration script; the first configuration script includes a label of the target host. The computing device executes the first configuration script using a second container engine to start the first container on the target host. Before the computing device executes the first configuration script using the second container engine, it must establish a runtime environment for the second container engine.
[0079] For example, a computing device starts a first container using K8S. K8S can use configuration files in YAML or JSON format to define container deployment and services. Therefore, the computing device must first obtain a first configuration script. The first configuration script includes a configuration file in YAML or JSON format. The first configuration script specifically defines shared storage volumes and shared memory space.
[0080] Optionally, through the YAML file, using the K8S node selector, the target host is selected by including the label of the target host in the first configuration script, so that the first container is started on the target host.
[0081] From the above, we can see that K8S is capable of managing large-scale container clusters, scheduling multiple containers at the same time, and realizing clustered deployment. It is suitable for various complex scenarios and real-time operating system instances.
[0082] S103, the computing device starts the second container according to the second container image file, triggering the process of starting the MICA backend service, wherein starting the second container is used to enable the computing device to configure the kernel module, the MICA backend service and the management component, and the MICA backend service supports running the real-time operating system instance.
[0083] In one possible implementation, the computing device configures access permissions for the second container, wherein the access permissions are used to indicate that the second container can access the kernel of the operating system.
[0084] In the embodiment of the present application, during the process of deploying a real-time operating system instance by starting the first container and the second container, the kernel module must be loaded into the operating system kernel. Because the second container image file includes the kernel module, the second container needs to access the operating system kernel to enable the operating system kernel to install the kernel module.
[0085] For example, the computing device configures a privileged privilege level permission for the second container, so that the second container has the right to access the kernel of the operating system.
[0086] In one possible implementation, the computing device starts the second container through a second deployment command; the second deployment command is used to start the second container; or, the computing device starts the second container on the target host through a second configuration script; the second configuration script includes a label of the target host.
[0087] In some instances, the computing device executes the second deployment command through the first container engine to start the second container. Therefore, the computing device needs to obtain the second deployment command first.
[0088] For example, the computing device starts the second container using the container engine Docker. The second deployment command includes configuring access permissions so that the second container has access to the operating system kernel. The first container engine starts the container using the docker run command.
[0089] In some other instances, the computing device starts the second container on the target host using a second configuration script; the second configuration script includes a label of the target host.
[0090] For example, the computing device starts the second container through K8S. The computing device needs to obtain the second configuration script first. The second configuration script includes configuring access permissions so that the second container can access the kernel of the operating system. Optionally, the computing device can start the first container and the second container through the container configuration script. The container configuration script specifically includes defining the labels of the target host, shared storage volumes and shared memory space, and configuring access permissions so that the second container can access the kernel of the operating system. Among them, the computing device uses the YAML file and the node selector of K8S to select the target host through the container configuration script including the label of the target host, so that the first container and the second container are started on the target host.
[0091] In one possible implementation, before obtaining the first container image file and the second container image file, the computing device sets the entry command of the first container to the process of starting the real-time operating system instance; and sets the entry command of the second container to the process of starting the MICA backend service.
[0092] In other words, based on the RTOS instance file, the computing device launches the RTOS instance process through the first container. The computing device then launches the MICA backend service, which is used to deploy the RTOS instance, through the second container. The RTOS instance file is loaded into the first container and starts the RTOS instance.
[0093] For example, taking the real-time operating system instance as the UniProton system instance, the real-time operating system instance file includes the UniProton system instance file. In the process of deploying the UniProton real-time operating system, it is first necessary to reserve resources and allocate independent CPU and memory resources for the UniProton real-time operating system. Secondly, the kernel module is loaded through the MICA tool to provide computing power resource management, inter-core communication, interrupt management, etc. for the UniProton real-time operating system. Finally, the UniProton real-time operating system is compiled into an executable file and the UniProton real-time operating system is deployed. Since the first container image file includes the script file of the hybrid criticality deployment framework MICA client, the second container image file includes the kernel module and the MICA back-end service.
[0094] Therefore, after the first container and the second container are started, the second container accesses the kernel of the computing device and loads the kernel module in the second container onto the kernel of the computing device. The first container runs the MICA client according to the script file of the MICA client and obtains the UniProton system instance file in the shared storage volume. Through the execution entry command of the first container, the process of the UniProton system instance is started at the moment the first container is started. Among them, the shared storage volume also includes a configuration file. The computing device pulls up the MICA backend service at the moment the second container is started through the execution entry command of the second container. Through the interaction between the MICA client in the first container and the MICA backend service in the second container, the process of the UniProton system instance is configured using MICA commands and configuration files, thereby completing the deployment of the UniProton system instance.
[0095] Figure 5 FIG. 1 shows a software framework diagram of a real-time operating system instance 100 provided in an embodiment of the present application. Figure 5 As shown, the real-time operating system instance 100 includes an interrupt framework 310, an exception framework 320, a process framework 330, a communication framework 340 and a user interface framework 350. Among them, the interrupt framework 310 is used to manage the hardware interrupts of the computing device, including initializing related hardware interfaces and processing interrupts of external interfaces. The exception framework 320 is used to implement the application programming interface (API) of the exception function distribution entrance and the API related to software exceptions. The process framework 330 is used to manage operations such as creation, destruction, scheduling and switching of processes. The communication framework 340 is used to implement communication and synchronization between different processes or threads, so that they can cooperate with each other. The user interface framework 350 is used to provide a series of interfaces for developing applications. The software architecture of the above-mentioned real-time operating system instance 100 is divided into different frameworks, which can improve the maintainability and scalability of the real-time operating system instance 100.
[0096] As can be seen above, obtaining a container image file that includes the MICA client, kernel module, MICA backend services, and management components, and deploying an RTOS instance through a containerized service approach, can reduce the complexity of RTOS instance deployment and make the RTOS instance deployment process universal. Furthermore, the characteristics of the container engine can be leveraged to orchestrate and manage RTOS instances, further improving the efficiency of RTOS instance deployment.
[0097] In an embodiment of the present application, before obtaining the first container image file and the second container image file, the development device packages the MICA client and the operating environment, the kernel module, the MICA backend service and the management component into the first container image and the second container image respectively to facilitate the deployment of the real-time operating system instance.
[0098] For ease of understanding, the following is an exemplary introduction to a method for constructing a first container image file and a second container image file provided in an embodiment of the present application. The method for constructing a first container image file and a second container image file is executed by a development device.
[0099] It should be noted that the development equipment and Figure 2 The computing devices 200 shown may be the same device or different devices, which is not limited here.
[0100] In a possible implementation, the first container image file and the second container image file are container image files created by a first container engine.
[0101] For example, using a UniProton system instance as a real-time operating system instance, deployment of the UniProton system instance requires the use of a dedicated mixed criticality system (MCS) deployment tool, specifically the mixed criticality deployment framework MICA. The primary function of the MICA criticality deployment framework is to address the deployment of multiple tasks and applications within the system, including task scheduling, resource allocation, and communication collaboration. Therefore, the first and second containers can be constructed based on the UniProton system instance and the MICA criticality deployment framework.
[0102] For example, the first container is used to provide the MICA client for deploying a UniProton system instance; the second container is used to provide the MICA backend services and kernel modules for deploying the UniProton system instance, performing lifecycle management and coordinated scheduling of the UniProton system instance. Therefore, the first container image file includes the MICA client and runtime environment. The second container image file includes the kernel module, MICA backend services, and management components. The management components are used to manage the communication resources, remote resources, and / or file resources of the real-time operating system instance.
[0103] The development device builds a first container image file according to the script file and operating environment of the MICA client.
[0104] Figure 6 The schematic diagram of a process of constructing a first container image file provided by an embodiment of the present application is shown. The process of constructing the first container image file can be executed by a development device, such as Figure 6 As shown, the steps for building the first container image file are as follows:
[0105] S201: A development device creates a first initial container.
[0106] Containers are a lightweight, portable, and self-contained software packaging technology that can encapsulate applications and their dependencies (e.g., runtime environments, libraries, etc.) in an isolated environment.
[0107] For example, the development device can execute a creation command through a command line tool to create and run a first initial container. The development device can also complete the creation of the first initial container through a container orchestration tool and a YAML file.
[0108] For example, taking the creation of the first initial container through the command line tool as an example, the development device uses the Docker tool to execute the "FROM" instruction to specify the basic image of the general server operating system; and the development device uses the Docker tool based on the general server operating system to execute the "Docker RUN" command through the Docker tool to create the first initial container.
[0109] S202: The development device installs the MICA client operating environment for the first initial container.
[0110] The operating environment that the MICA client relies on may specifically be a Python operating environment.
[0111] For example, the development device executes the "RUN" command using the Docker tool to install the Python runtime environment. The "RUN" command is used to install software packages and configure the environment. For example, a "RUN" command such as "RUN yum install python3 python3 -arg complete -y" configures the local yum source repo file to install the Python component in the container and set up the Python runtime environment.
[0112] S203: The development device installs the MICA client for the first initial container and determines the first container.
[0113] Exemplarily, the development device copies the script file of the MICA client locally to the / usr / local / bin directory of the first initial container, thereby determining the first container.
[0114] For example, the development device executes a "COPY" instruction through the Docker tool to copy the script file of the MICA client to the image of the first container to obtain the first container.
[0115] S204: The development device sets a first container entry command, wherein the execution entry command of the first container is used to start the MICA client process in the first container when the first container is started.
[0116] For example, the development device uses the Docker tool to execute the "CMD" command to set the container entry command. For example, the "CMD" command includes "CMD cd / opt && mica create kp920_0.conf," which represents the execution entry command of the first container. When the container starts, it launches the UniProton system instance process based on the UniProton system instance file.
[0117] S205: The development device builds an image of the first container and determines the first container image file.
[0118] Exemplarily, the development device may execute a "Docker Build" command through a Docker tool to build an image of the first container.
[0119] The development device can obtain a first Dockerfile and run it to build a first container image, thereby determining the first container image file. The first Dockerfile includes a "FROM" instruction to specify a base image of a general server operating system, a "RUN" command to install the runtime environment, a "COPY" instruction to copy a MICA client script file, a "CMD" command to set the entry command, and a "Docker Build" command to build the first container image, thereby determining the first container image file.
[0120] Optionally, the configuration file is copied to the first container by executing a "COPY" instruction through the Docker tool, so that the first container image file includes the configuration file. The configuration file is used to configure the real-time operating system instance.
[0121] The development device can also build a second container image file based on the kernel module, MICA backend service and management components.
[0122] Figure 7 A schematic diagram of a process for constructing a second container image file provided by an embodiment of the present application is shown. Figure 7 As shown, the steps for building the second container image file are as follows:
[0123] S301: The development device creates a second initial container.
[0124] The specific steps of developing the device to create the second initial container are the same as those of the above-mentioned S201 and are not described again here.
[0125] S302: The development device configures a kernel module for the second initial container.
[0126] Exemplarily, kernel modules include "mcs_km.ko" and "eth_i210.ko." mcs_km.ko manages computing resources for the UniProton system instance, including CPU startup, program loading, inter-core communication, interrupt management, and transmission and reception mechanisms. eth_i210.ko is a network card driver developed specifically for the UniProton system, connecting the UniProton system to the hardware. The development device copies the "mcs_km.ko" and "eth_i210.ko" files to the second initial container.
[0127] For example, the development device executes the "COPY" command using the Docker tool to copy the "mcs_km.ko" and "eth_i210.ko" files to the second initial container. This allows the second container to access the kernel of a general-purpose operating system (e.g., Linux) by instructing the general-purpose operating system (e.g., Linux) to execute the kernel module load command (install module) and install the kernel module.
[0128] S303: The development device configures the MICA backend service for the second initial container.
[0129] For example, the development device executes the "COPY" instruction through the Docker tool to copy the program file MICAD of the MICA backend service to the second initial container.
[0130] S304: The development device installs a management component for the second initial container and determines the second container.
[0131] Among them, the management components include the component software packages that the UniProton system instance depends on for operation.
[0132] For example, the development device executes the "COPY" command using the Docker tool to copy the files of each software package to a second initial container, establishing a second container. This allows the second container to access the kernel of a general-purpose operating system (e.g., Linux) by executing the rpm-ivh command to install the RPM packages of the components that the UniProton system instance relies on. These RPM packages include libraries related to libmetal, openamp, and sysfsutils, development kits, and debugging information, and can be used to manage the real-time operating system's lifecycle, inter-processor communication, kernel information acquisition, resource management, and configuration.
[0133] S305: The development device sets the entry command for the second container. The execution entry command of the first container is used to start the MICA backend service process in the second container when the second container is started.
[0134] For example, the development device uses the Docker tool to execute the "CMD" command to set the container entry command. The "CMD" command includes "CMD cd / opt && mica create kp920_0.conf," which is the execution entry command for the second container and starts the MICA backend service process in the second container when it starts.
[0135] S306: The development device builds an image of the second container and determines the second container image file.
[0136] The specific steps of developing the device to create the image of the second container and determining the image file of the second container are the same as those of the above-mentioned S205 and are not repeated here.
[0137] Similarly, the development device can obtain a second Dockerfile and run it to build a second container image, thereby determining the second container image file. The second Dockerfile includes a "FROM" instruction to specify a base image of a general server operating system, a "RUN" command to install a software package, a "COPY" instruction to copy the program files of the MICA backend service, a "CMD" command to set the entry command, and a "DockerBuild" command to build the second container image, thereby determining the second container image file.
[0138] As can be seen above, the MICA client included in the first container image changes with the real-time system instance. However, the kernel module and MICA backend services included in the second container image remain fixed. The development device uses containers to separate the MICA tools and related components involved in deploying the real-time operating system instance, separating static tools from dynamic resources. This eliminates the need for users to understand and operate the kernel module when launching the real-time operating system. This improves the stability of launching the real-time operating system through container deployment.
[0139] In summary, an embodiment of the present application provides a method for deploying a real-time operating system instance, and the method is applied to a computing device. The computing device obtains a first container image file and a second container image file. The first container image file includes a script file and an operating environment of a hybrid criticality deployment framework (MICA) client; the second container image file includes a kernel module, a MICA back-end service, and a management component; the management component is used to manage the resources of the real-time operating system instance. The computing device starts the first container according to the first container image file, triggering the process of starting the real-time operating system instance; starting the first container is used to enable the computing device to configure the MICA client and the operating environment; starting the second container according to the second container image file triggers the process of starting the MICA back-end service, wherein starting the second container is used to enable the computing device to configure the kernel module, the MICA back-end service, and the management component, and the MICA back-end service supports the running of the real-time operating system instance. The above-mentioned deployment of the real-time operating system instance is realized by containerized service, which realizes a universal deployment method of the real-time operating system instance and reduces the complex process in the deployment process of the real-time operating system instance.
[0140] The above mainly introduces the solution of the embodiment of the present application from the perspective of method. It can be understood that in order to realize the above functions, the deployment device of the real-time operating system instance includes at least one of the hardware structure and software modules corresponding to the execution of each function. It should be easy for those skilled in the art to realize that, in combination with the units and algorithm steps of each example described in the embodiment disclosed herein, the embodiment of the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the embodiment of the present application.
[0141] The embodiment of the present application can divide the deployment device of the real-time operating system instance into functional units according to the above method example. For example, each functional unit can be divided corresponding to each function, or two or more functions can be integrated into one processing unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. It should be noted that the division of units in the embodiment of the present application is schematic and is only a logical functional division. There may be other division methods in actual implementation.
[0142] For example, Figure 8 FIG. 4 is a schematic diagram showing the structure of a deployment device 400 for a real-time operating system instance provided in an embodiment of the present application. Figure 8 As shown, the deployment device of the real-time operating system instance can be applied to Figure 2 In the computing device 200 shown, the deployment apparatus 400 of the real-time operating system instance includes:
[0143] The acquisition module 410 is used to obtain a first container image file and a second container image file; the first container image file includes the script file and operating environment of the hybrid criticality deployment framework MICA client; the second container image file includes the kernel module, MICA backend service and management component; the management component is used to manage the resources of the real-time operating system instance.
[0144] The startup module 420 is used to start the first container according to the first container image file, triggering the process of starting the real-time operating system instance; starting the first container is used to configure the computing device with the MICA client and operating environment; starting the second container according to the second container image file, triggering the process of starting the MICA backend service; wherein, starting the second container is used to configure the computing device with the kernel module, MICA backend service and management component, and the MICA backend service supports running the real-time operating system instance.
[0145] In one possible implementation, the real-time operating system deployment device 400 also includes a creation module for creating a shared storage volume; the shared storage volume is used to share files between containers; the shared storage volume includes a real-time operating system instance file; the real-time operating system instance file is used to load into the first container and the second container and start the real-time operating system instance.
[0146] In a possible implementation, the creation module is further configured to configure access permissions for the second container; the access permissions are used to indicate that the second container can access the kernel of the operating system.
[0147] In a possible implementation, the creation module is further configured to mount path information of the communication channel to the first container and the second container, so that the first container and the second container communicate through the communication channel.
[0148] In one possible implementation, the startup module 420 is further used to start the first container through a first deployment command; the first deployment command is used to start the first container; or, to start the first container on the target host through a first configuration script; the first configuration script includes a label of the target host.
[0149] In one possible implementation, the startup module 420 is further used to start the second container through a second deployment command; the second deployment command is used to start the second container; or, to start the second container on the target host through a second configuration script; the second configuration script includes a label of the target host.
[0150] The acquisition module 410 and the start-up module 420 may be implemented by software or hardware.
[0151] For example, the following describes the implementation of the acquisition module 410 by taking the acquisition module 410 as an example. Similarly, the implementation of the startup module 420 can refer to the implementation of the acquisition module 410.
[0152] The acquisition module 410 is an example of a software functional unit. The acquisition module 410 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the computing instance may be one or more. For example, the acquisition module 410 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple geographically close data centers. Typically, a region may include multiple AZs.
[0153] Similarly, multiple hosts / virtual machines / containers used to run the code can be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Typically, one VPC is set up in one region, and two VPCs are set up in the same region.
[0154] Cross-region communication between VPCs, and between VPCs in different regions, requires setting up a communication gateway in each VPC to interconnect the VPCs through the communication gateway.
[0155] As an example of a hardware functional unit, acquisition module 410 may include at least one computing device, such as a server. Alternatively, acquisition module 410 may be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.
[0156] The multiple computing devices included in the acquisition module 410 can be distributed in the same region or in different regions. The multiple computing devices included in the acquisition module 410 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the acquisition module 410 can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of servers, ASICs, PLDs, CPLDs, FPGAs, GALs, and other computing devices.
[0157] It should be noted that, in other embodiments, the acquisition module 410 can be used to execute any step in the process scheduling method, and the startup module 420 can be used to execute any step in the process scheduling method. The steps that the acquisition module 410 and the startup module are responsible for implementing can be specified as needed. The full functions of the real-time operating system deployment device 400 are realized by respectively implementing different steps in the process scheduling method through the acquisition module 410 and the startup module.
[0158] The specific description of the above optional methods can be found in the above method embodiments, which will not be repeated here. In addition, the explanation of any of the above-mentioned real-time operating system deployment devices 400 and the description of the beneficial effects can be found in the above-mentioned Figure 3 The corresponding method embodiments will not be described in detail.
[0159] An embodiment of the present application also provides a computer-readable storage medium, which stores instructions. When the computer-readable storage medium is run on a computing device, it enables the computing device to execute operations corresponding to any one implementation scheme and various feasible implementation schemes of the process scheduling method.
[0160] An embodiment of the present application also provides a computer program product containing instructions, which, when executed on a computing device, enables the computing device to execute operations corresponding to any one of the implementation schemes and various feasible implementation schemes of the process scheduling method.
[0161] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0162] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.
[0163] An embodiment of the present application also provides a chip system, including: a processor, the processor is coupled to a memory, the memory is used to store programs or instructions, and when the program or instructions are executed by the processor, the chip system implements the method in any of the above method embodiments.
[0164] Optionally, there may be one or more processors in the chip system. The processor may be implemented in hardware or software. When implemented in hardware, the processor may be a logic circuit, an integrated circuit, etc. When implemented in software, the processor may be a general-purpose processor implemented by reading software code stored in a memory.
[0165] Optionally, the memory in the chip system may be one or more. The memory may be integrated with the processor or may be provided separately from the processor, which is not limited in the embodiments of the present application. For example, the memory may be a non-transient processor, such as a read-only memory (ROM), which may be integrated with the processor on the same chip or provided on different chips. The embodiments of the present application do not specifically limit the type of memory or the configuration of the memory and the processor.
[0166] Exemplarily, the chip system can be a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on chip (SoC), a central processor unit (CPU), a network processor (NP), a digital signal processor (DSP), a microcontroller unit (MCU), a programmable logic device (PLD) or other integrated chips.
[0167] The electronic device, computer storage medium or computer program product provided in this application is used to execute the corresponding method provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding method provided above, and will not be repeated here.
[0168] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.
[0169] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of modules or units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.
[0170] Units described as separate components may or may not be physically separate, and components shown as units may be one physical unit or multiple physical units, located in one place or distributed across multiple locations. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.
[0171] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.
[0172] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the contributing part or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a device (which can be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, and other media that can store program code.
[0173] The above content is only a specific embodiment of this application, but the scope of protection of this application is not limited to this. Any changes or replacements within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.< / module> < / module>
Claims
1. A method for deploying a real-time operating system instance, characterized in that: The method is applied to a computing device, and includes: Obtain a first container image file and a second container image file; the first container image file includes a script file and an operating environment of a hybrid criticality deployment framework MICA client; the second container image file includes a kernel module, a MICA backend service, and a management component; the management component is used to manage resources of the real-time operating system instance; Starting a first container according to the first container image file to trigger starting a process of the real-time operating system instance; wherein starting the first container is used to enable the computing device to configure the MICA client and the operating environment; According to the second container image file, the second container is started to trigger the process of starting the MICA backend service; wherein, the starting of the second container is used to enable the computing device to configure the kernel module, the MICA backend service and the management component, and the MICA backend service supports running the real-time operating system instance.
2. The method according to claim 1, characterized in that Before obtaining the first container image file and the second container image file, the method further includes: Setting the entry command of the first container to a process for starting the real-time operating system instance; The entry command of the second container is set to start the process of the MICA backend service.
3. The method according to claim 1 or 2, characterized in that Before obtaining the first container image file and the second container image file, the method further includes: A shared storage volume is created; the shared storage volume is used to share files between containers; the shared storage volume includes the real-time operating system instance file.
4. The method according to claim 3, characterized in that The shared storage volume includes a configuration file; the configuration file is used to configure the computing resources occupied by the real-time operating system instance; the configuration file includes the number of central processing units occupied by the real-time operating system instance.
5. The method according to any one of claims 1 to 4, characterized in that Said method further comprises: Configure access permissions for the second container; the access permissions are used to indicate that the second container can access the kernel of the operating system.
6. The method according to any one of claims 1 to 5, characterized in that The method further comprises: Mount path information of the communication channel to the first container and the second container, so that the first container and the second container communicate through the communication channel.
7. The method according to any one of claims 1 to 6, characterized in that The starting of the first container according to the first container image file to trigger the process of starting the real-time operating system instance includes: Start the first container through a first deployment command; the first deployment command is used to start the first container; Alternatively, the first container is started on the target host through a first configuration script; the first configuration script includes a label of the target host.
8. The method according to any one of claims 1 to 6, characterized in that The step of starting the second container according to the second container image file and triggering the process of starting the MICA backend service includes: Start the second container through a second deployment command; the second deployment command is used to start the second container; Alternatively, the second container is started on the target host through a second configuration script; the second configuration script includes a label of the target host.
9. A deployment device for a real-time operating system instance, characterized in that: The device comprises: An acquisition module is configured to obtain a first container image file and a second container image file; the first container image file includes a script file and an operating environment of a hybrid criticality deployment framework MICA client; the second container image file includes a kernel module, a MICA backend service, and a management component; the management component is configured to manage the real-time operating system instance; A startup module is used to start a first container according to the first container image file, triggering the process of starting the real-time operating system instance; wherein, starting the first container is used to enable the computing device to configure the MICA client and the operating environment; and starting a second container according to the second container image file, triggering the process of starting the MICA backend service; wherein, starting the second container is used to enable the computing device to configure the kernel module, the MICA backend service and the management component, and the MICA backend service supports running the real-time operating system instance.
10. A computing device, characterized in that The computing device includes: a processor and a memory for storing instructions executable by the processor; the processor is configured to execute the instructions, so that the computing device executes the method for deploying a real-time operating system instance according to any one of claims 1 to 8.