Multi-OS communication module hybrid deployment solution based on openEuler

Abstract

This application relates to the field of communication technology and discloses a hybrid deployment solution for multi-OS communication modules based on openEuler. The solution is applied to a communication module, and an openEuler embedded platform is provided in the communication module. The openEuler embedded platform deploys multiple operating systems. The solution includes: obtaining pending tasks and determining the task type of the pending tasks; selecting at least two candidate operating systems from each operating system according to the task type; selecting a target operating system from each candidate operating system to respond to the pending tasks; judging whether there is an abnormality in the target operating system during operation; if so, selecting an alternative operating system from each candidate operating system to respond to the pending tasks, thereby ensuring that the pending tasks can be successfully responded to, meet user needs, and improve user experience.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a hybrid deployment solution of multi-OS communication modules based on openEuler. Background Art

[0002] With the development of embedded systems, the Linux operating system is increasingly being used in communication modules. As an open-source operating system, Linux allows users to customize it to meet their specific hardware and performance requirements.

[0003] However, during the process of the communication module processing the corresponding task, if the Linux operating system of the communication module is abnormal, it will not be able to successfully respond to the task to be processed, causing the function corresponding to the task to be temporarily invalid, which in turn will fail to meet user needs and affect the user experience. Summary of the Invention

[0004] The main purpose of this application is to provide a hybrid deployment solution for multi-OS communication modules based on openEuler, which aims to solve the technical problem that abnormalities in the Linux operating system of the existing communication module will lead to the inability to meet user needs and affect the user experience.

[0005] To achieve the above objectives, the present application provides a multi-OS communication module hybrid deployment solution based on openEuler. The solution is applied to a communication module, in which an openEuler embedded platform is provided. The openEuler embedded platform deploys multiple operating systems. The solution includes:

[0006] Obtaining a task to be processed and determining the task type of the task to be processed;

[0007] selecting at least two candidate operating systems from the operating systems according to the task type;

[0008] Selecting a target operating system from each of the candidate operating systems to respond to the pending task;

[0009] Determining whether there is an abnormality during the operation of the target operating system;

[0010] If so, a candidate operating system is selected from each of the candidate operating systems to respond to the task to be processed.

[0011] In one embodiment, the task type includes a real-time type and a non-real-time type, and the step of determining the task type of the to-be-processed task includes:

[0012] Extracting feature information of the task to be processed;

[0013] Predicting the response time of the task to be processed based on the feature information;

[0014] Determining whether the response time exceeds a preset time threshold;

[0015] If not, determining that the task type of the task to be processed is the real-time type;

[0016] If so, it is determined that the task type of the real-time task to be processed is the non-real-time type.

[0017] In one embodiment, the step of selecting at least two candidate operating systems from the operating systems according to the task type includes:

[0018] Obtaining identification information of each operating system, where the identification information is used to characterize a task type applicable to the operating system;

[0019] When the task type is the real-time type, selecting an operating system whose identification information indicates that it is applicable to the real-time type as a candidate operating system;

[0020] When the task type is the non-real-time type, an operating system whose identification information indicates that it is applicable to the non-real-time type is selected as a candidate operating system.

[0021] In one embodiment, the step of selecting a target operating system from each of the candidate operating systems to respond to the pending task includes:

[0022] Determining the priority of each candidate operating system;

[0023] Select the candidate operating system with the highest priority as the target operating system;

[0024] The target operating system responds to the pending task.

[0025] In one embodiment, before the step of selecting at least two candidate operating systems from the operating systems according to the task type, the method further includes:

[0026] Obtaining historical performance indicator reference values of each of the operating systems;

[0027] Calculating the difference between each of the historical performance indicator reference values and a preset benchmark indicator;

[0028] A corresponding priority is configured for each of the operating systems according to the difference.

[0029] In one embodiment, the step of determining whether there is an abnormality in the target operating system during operation includes:

[0030] Obtaining a target performance indicator generated when the target operating system responds to the task to be processed;

[0031] Determining whether the target performance indicator exceeds a preset indicator threshold;

[0032] If the preset indicator threshold is exceeded, it is determined that an abnormality exists in the operation of the target operating system.

[0033] In one embodiment, after the step of determining whether the target performance indicator exceeds a preset indicator threshold, the method further includes:

[0034] If the preset indicator threshold is not exceeded, obtaining the target historical performance indicator set of the target operating system;

[0035] Determining a target historical performance benchmark value that does not exceed the preset indicator threshold from the target historical performance indicator set;

[0036] Calculating the deviation between the target performance indicator and the target historical performance benchmark value;

[0037] Determining whether the deviation exceeds a preset deviation;

[0038] If the predetermined deviation is exceeded, it is determined that an abnormality exists in the operation of the target operating system;

[0039] If the preset deviation is not exceeded, it is determined that there is no abnormality in the operation of the target operating system.

[0040] In one embodiment, if yes, the step of selecting a candidate operating system from each of the candidate operating systems to respond to the pending task includes:

[0041] If yes, selecting an alternative operating system from the candidate operating systems that has a priority lower than the target operating system and higher than other candidate operating systems;

[0042] The candidate operating system is used as the target operating system to respond to the pending task, and the process returns to the step of determining whether there is an abnormality in the running process of the target operating system until the pending task response is completed.

[0043] In addition, to achieve the above objectives, the present application also proposes a communication module, which includes:

[0044] A task acquisition module is used to acquire tasks to be processed and determine the task type of the tasks to be processed;

[0045] An operating system selection module, configured to select at least two candidate operating systems from among the operating systems according to the task type;

[0046] A task response module, configured to select a target operating system from each of the candidate operating systems to respond to the pending task;

[0047] An anomaly detection module, used to determine whether there is an anomaly in the operation of the target operating system;

[0048] The task response module is further configured to, if yes, select a candidate operating system from each of the candidate operating systems to respond to the task to be processed.

[0049] In addition, to achieve the above-mentioned purpose, the present application also proposes a communication device, which includes: a memory, a processor, and a computer program stored on the memory and runnable on the processor, and the computer program is configured to implement the steps of the multi-OS communication module hybrid deployment solution based on openEuler as described above.

[0050] One or more technical solutions proposed in this application have at least the following technical effects:

[0051] The present application is applied to a communication module, in which an openEuler embedded platform is provided, and the openEuler embedded platform deploys multiple operating systems. The solution includes: obtaining pending tasks and determining the task type of the pending tasks; selecting at least two candidate operating systems from each operating system according to the task type; selecting a target operating system from each candidate operating system to respond to the pending tasks; judging whether there is an abnormality in the target operating system during operation; if so, selecting an alternative operating system from each candidate operating system to respond to the pending tasks. Since the present application deploys multiple operating systems through the openEuler embedded platform, and selects the corresponding target operating system to respond according to the task type of the pending tasks, when there is an abnormality in the target operating system, the alternative operating system can be selected to continue to respond to the pending tasks. Therefore, compared with the existing communication module using a single Linux operating system, the present application can ensure that the pending tasks can be successfully responded to, avoid the temporary failure of the corresponding function of the pending tasks, effectively meet user needs, and thus improve the user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0053] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0054] Figure 1 This is a flow chart of the first embodiment of the hybrid deployment solution of multi-OS communication modules based on openEuler in this application;

[0055] Figure 2 This is a flow chart of the second embodiment of the hybrid deployment solution of multi-OS communication modules based on openEuler in this application;

[0056] Figure 3 This is a flow chart of the third embodiment of the hybrid deployment solution of multi-OS communication modules based on openEuler in this application;

[0057] Figure 4 This is a schematic diagram of the module structure of the communication module of this application;

[0058] Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the hybrid deployment solution of multi-OS communication modules based on openEuler in an embodiment of the present application.

[0059] The realization of the objectives, functional features and advantages of this application will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0060] It should be understood that the specific embodiments described herein are merely used to explain the technical solutions of the present application and are not intended to limit the present application.

[0061] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0062] The main solution of the embodiment of the present application is: an openEuler embedded platform is provided in the communication module, and the openEuler embedded platform deploys multiple operating systems. The communication module obtains the tasks to be processed and determines the task type of the tasks to be processed; at least two candidate operating systems are selected from each operating system according to the task type; a target operating system is selected from each candidate operating system to respond to the tasks to be processed; it is determined whether there is an abnormality in the target operating system during operation; if so, an alternative operating system is selected from each candidate operating system to respond to the tasks to be processed.

[0063] In the embodiments of the present application, for ease of description, the following description is made with the communication module as the execution entity.

[0064] When the existing communication module is processing the corresponding task, if the Linux operating system of the communication module is abnormal, it will not be able to successfully respond to the task to be processed, causing the function corresponding to the task to be temporarily invalid, which in turn will not be able to meet user needs and affect the user experience.

[0065] This application provides a solution that deploys multiple operating systems through the openEuler embedded platform, selects the corresponding target operating system to respond based on the task type of the pending task, and when there is an abnormality in the target operating system, an alternative operating system can be selected to continue responding to the pending task. Therefore, compared with the existing communication module that uses a single Linux operating system, this application can ensure that the pending task can be successfully responded to, avoid the temporary failure of the corresponding function of the pending task, effectively meet user needs, and thus improve the user experience.

[0066] It should be noted that the communication module of the embodiment of the present application can be a module with data processing, network communication and program running functions. The communication module can be integrated into a communication device that also has data processing, network communication and program running functions. The communication device can be a computing service device, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device that can realize the above functions.

[0067] Based on this, the embodiment of the present application provides a multi-OS communication module hybrid deployment solution based on openEuler, referring to Figure 1 , Figure 1 This is a flow chart of the first embodiment of the hybrid deployment solution of multi-OS communication modules based on openEuler in this application.

[0068] In this embodiment, the openEuler-based multi-OS communication module hybrid deployment solution is applied to the communication module. The communication module is provided with an openEuler embedded platform, and the openEuler embedded platform deploys multiple operating systems. The solution includes steps S10 to S50:

[0069] Step S10: Obtain a task to be processed and determine the task type of the task to be processed.

[0070] It should be noted that the above-mentioned pending tasks may be tasks that are required to be processed by the operating system and have not yet been completed, such as device management tasks that control the operation of external devices, memory management tasks responsible for memory allocation and recovery, disk management tasks that manage files and folders on the disk, etc.

[0071] It is understood that the above task types can be divided into real-time and non-real-time types based on the time constraints required for the tasks to be processed. Real-time tasks can be tasks that need to be completed within a set time period, such as alarm calls, emergency dispatches, and node failure messages. Non-real-time tasks can be tasks that do not need to be completed within a set time period, that is, tasks that are not subject to time constraints. Examples include management information, status display information, configuration information, and monitoring information transmitted to each node in the control network.

[0072] It should be noted that the above-mentioned openEuler embedded platform can be a Linux-centric platform, a Linux version platform for embedded scenarios, such as openEuler Embedded.

[0073] It is understandable that for the mixed deployment of different operating systems, a mixed deployment framework can be built on the openEuler embedded platform, and the communication mechanism of the mixed deployment framework can be configured and tested to ensure that different operating systems can work together and communicate efficiently. The communication module can divide its hardware resources into multiple virtual machines, and then load the image files of different operating systems on each virtual machine, so that each virtual machine runs the corresponding operating system, realizing the mixed deployment of different operating systems. Among them, the operating system can be divided into the first type of operating system suitable for processing real-time tasks, and the number of the first type of operating system is at least two, such as UniProton, FreeRTOS and RT-Thread, and the second type of operating system suitable for processing non-real-time tasks, such as openEuler, Ubuntu Core and FreeBSD, and the number of the second type of operating system is at least two.

[0074] In a specific implementation, the above-mentioned pending tasks can be actively initiated by the user through input devices such as a keyboard and a mouse connected to the communication module, or can be automatically generated by the system of the communication module. Among them, the real-time type pending tasks can contain time constraint information, and the time constraint information includes a constraint time, indicating that the pending tasks need to be completed within the constraint time. Based on this, after obtaining the above-mentioned pending tasks, the communication module can determine whether there is time constraint information in the pending tasks, and identify the task type of the pending tasks based on the judgment result, that is, if there is time constraint information in the pending tasks, the task type of the pending tasks is determined to be a real-time type, and if there is no time constraint information in the pending tasks, the task type of the pending tasks is determined to be a non-real-time type.

[0075] Step S20: selecting at least two candidate operating systems from the operating systems according to the task type.

[0076] In a specific implementation, the communication module may determine the task type applicable to each operating system, and then select an operating system that matches the task type of the task to be processed from each operating system as a candidate operating system.

[0077] Step S30: Select a target operating system from the candidate operating systems to respond to the task to be processed.

[0078] In a specific implementation, the communication module may randomly select any candidate operating system from among the candidate operating systems as the target operating system, and then send the task to be processed to the virtual machine running the target operating system, which responds to the task to be processed based on the target operating system.

[0079] Step S40: determining whether there is any abnormality in the operation of the target operating system.

[0080] In a specific implementation, the above-mentioned communication module can monitor the performance indicators of the target operating system in real time and determine whether the performance indicators exceed the set threshold. If so, it is determined that there is an abnormality in the operation of the target operating system. For example, when the CPU usage exceeds 90% or the memory usage exceeds 80%, an abnormal alarm is triggered. If not, it is determined that there is no abnormality in the operation of the target operating system, and the target operating system continues to be used to respond to pending tasks until the pending tasks are completed.

[0081] Step S50: If yes, select an alternative operating system from each of the candidate operating systems to respond to the task to be processed.

[0082] In a specific implementation, when an abnormality occurs during the operation of the target operating system, the above-mentioned communication module can randomly select another candidate operation other than the target operating system from each candidate operating system as an alternative operating system, and send the task to be processed to the virtual machine running the alternative operating system, and the virtual machine will continue to respond to the task to be processed based on the alternative operating system.

[0083] It should be understood that when using an alternative operating system to respond to pending tasks, it is possible to determine whether there are any abnormalities in the operation of the alternative operating system, that is, to use the alternative operating system as the new target operating system and repeat the above process until the pending tasks are completed.

[0084] This embodiment is applied to a communication module, in which an openEuler embedded platform is provided, and the openEuler embedded platform deploys multiple operating systems. The solution includes: obtaining pending tasks and determining the task type of the pending tasks; selecting at least two candidate operating systems from each operating system according to the task type; selecting a target operating system from each candidate operating system to respond to the pending tasks; judging whether there is an abnormality in the target operating system during operation; if so, selecting an alternative operating system from each candidate operating system to respond to the pending tasks. Since this embodiment deploys multiple operating systems through the openEuler embedded platform, the corresponding target operating system is selected to respond according to the task type of the pending tasks. When there is an abnormality in the target operating system, the alternative operating system can be selected to continue to respond to the pending tasks. Therefore, compared with the existing communication module using a single Linux operating system, this embodiment can ensure that the pending tasks can be successfully responded to, avoid the situation where the corresponding function of the pending tasks is temporarily invalid, effectively meet user needs, and thus improve the user experience.

[0085] Based on the first embodiment of the present application, the second embodiment of the present application is proposed. In the second embodiment of the present application, the same or similar contents as those in the first embodiment can be referred to the above introduction and will not be repeated hereafter. Figure 2 , Figure 2 This is a flow chart of the second embodiment of the multi-OS communication module hybrid deployment solution based on openEuler in this application.

[0086] In this embodiment, the step of determining the task type of the to-be-processed task includes:

[0087] Step S101: extracting feature information of the task to be processed.

[0088] It should be noted that the above-mentioned characteristic information may be information describing the characteristics of the task to be processed, such as task size, task complexity, and resource requirements.

[0089] In a specific implementation, the above-mentioned communication module can extract feature information of the task to be processed through a task manager, system log, performance monitoring tool, etc.

[0090] Step S102: predicting the response time of the task to be processed based on the feature information.

[0091] In a specific implementation, historical feature information and historical response times for different tasks can be collected in advance. Historical training data can then be constructed based on each historical feature and response time. An initial learning model, such as a linear regression, decision tree, random forest, or neural network, can then be obtained and trained using this historical training data to produce a target learning model for predicting task response times. After extracting the feature information of the task to be processed, the communication module can input this feature information into the target learning model, which then predicts the response time corresponding to the feature learning.

[0092] Step S103: determine whether the response time exceeds a preset time threshold.

[0093] It should be noted that the above-mentioned preset time threshold may be a pre-set threshold.

[0094] In a specific implementation, the preset time threshold can be determined based on factors such as system performance requirements, task urgency, etc. The communication module can compare the response time of the pending task with the preset time threshold to determine whether the response time exceeds the preset time threshold.

[0095] Step S104: If not, determine that the task type of the task to be processed is the real-time type.

[0096] In a specific implementation, when the above-mentioned communication module detects that the response time does not exceed the preset time threshold, it determines that the task to be processed is subject to the preset time threshold, that is, the task to be processed can be completed within an acceptable time, and then determines that the task type of the task to be processed is a real-time type.

[0097] Step S105: If yes, determine that the task type of the real-time task to be processed is the non-real-time type.

[0098] In a specific implementation, when the above-mentioned communication module detects that the response time exceeds the preset time threshold, it determines that the pending task is not subject to the preset time threshold, that is, the pending task may not be completed within the required time, and then determines that the task type of the pending task is a non-real-time type.

[0099] In this embodiment, step S20 may include steps S201 to S203:

[0100] Step S201: Acquire identification information of each operating system, where the identification information is used to characterize a task type applicable to the operating system.

[0101] In a specific implementation, the task types applicable to different operating systems can be pre-determined, and identification information representing the task types can be generated. Then, each operating system can be associated with its corresponding identification information. After determining the task type of the task to be processed, the above-mentioned communication module can obtain the identification information associated with each operating system.

[0102] Step S202 : When the task type is the real-time type, an operating system whose identification information indicates that the task type is suitable for the real-time type is selected as a candidate operating system.

[0103] In a specific implementation, the above-mentioned communication module can match the task type of the task to be processed with the identification information of each operating system. When the task type of the task to be processed is a real-time type, an operating system that represents the applicable real-time type is selected as a candidate operating system, such as UniProton.

[0104] Step S203 : When the task type is the non-real-time type, an operating system whose identification information indicates that the task type is suitable for the non-real-time type is selected as a candidate operating system.

[0105] In a specific implementation, when the task type of the task to be processed is a non-real-time type, the communication module selects an operating system that is suitable for the non-real-time type as a candidate operating system, such as openEuler.

[0106] This embodiment automatically predicts the response time of a pending task based on its characteristic information. If the response time does not exceed a preset time threshold, the task type of the pending task is determined to be real-time, and an operating system suitable for the real-time type is selected as a candidate operating system based on the identification information. If the response time exceeds the preset time threshold, the task type of the pending task is determined to be non-real-time, and an operating system suitable for the non-real-time type is selected as a candidate operating system based on the identification information. This allows the pending task to be intelligently assigned to an appropriate operating system based on its characteristic information and the preset response time, thereby improving the overall efficiency and responsiveness of the system, and effectively ensuring that the task is assigned to the most appropriate operating system, effectively improving the flexibility and reliability of the operating system.

[0107] Based on the first and second embodiments of the present application, the third embodiment of the present application is proposed. In the third embodiment of the present application, the same or similar contents as those of the first and second embodiments can be referred to above and will not be described in detail later. Figure 3 , Figure 3 This is a flow chart of the third embodiment of the multi-OS communication module hybrid deployment solution based on openEuler in this application.

[0108] In this embodiment, step S30 may include steps S301 to S303:

[0109] Step S301: Determine the priority of each candidate operating system.

[0110] It should be noted that the above priorities can be used as a basis for the order of selecting the operating system, that is, the operating system with a higher priority is selected first.

[0111] In a specific implementation, corresponding weights may be pre-assigned to different operating systems as their priorities. After selecting a candidate operating system based on the task type of the task to be processed, the communication module may obtain the priority of each candidate operating system.

[0112] Step S302: Select the candidate operating system with the highest priority as the target operating system.

[0113] In a specific implementation, the communication module may determine the candidate operating system with the highest priority and use it as the target operating system that responds to the pending task with priority.

[0114] Step S303: respond to the pending task through the target operating system.

[0115] In a specific implementation, the communication module may send the pending task to a virtual machine running the target operating system, and the virtual machine may respond to the pending task based on the target operating system.

[0116] In this embodiment, steps S21 to S23 may be further included before step S20:

[0117] Step S21: Obtain historical performance index reference values of each of the operating systems.

[0118] It should be noted that the above historical performance index reference values can be used as performance index reference values of the operating system over a period of time. The performance index reference values can be parameters that characterize the performance of the operating system, such as CPU usage, memory usage, I / O operation speed, response time, etc.

[0119] In a specific implementation, the communication module can obtain historical performance index reference values of each operating system within a preset time range from historical logs, monitoring tools, or performance management systems. The preset time range can be a pre-set range, such as a day or a week, to avoid obtaining too much data.

[0120] Step S22: Calculate the difference between each of the historical performance index reference values and a preset benchmark index.

[0121] It should be noted that the above-mentioned preset benchmark indicators can be pre-set according to business needs or the historical best performance of the operating system, and are performance indicators that the operating system is expected to achieve.

[0122] In a specific implementation, the communication module may compare the historical performance indicators of each operating system with the same preset benchmark indicator, and calculate the difference between each historical performance indicator and the preset benchmark indicator.

[0123] Step S23: configuring a corresponding priority for each operating system according to the difference.

[0124] In a specific implementation, the above-mentioned communication module can configure corresponding priorities for different operating systems according to the size of the difference.

[0125] For example, assuming the historical performance indicator is A and the preset benchmark indicator is B, the difference is AB. For each operating system with AB>0, its priority is higher than that of the operating system with AB<0. Furthermore, for each operating system with AB>0 or each operating system with AB<0, the larger the difference, the higher the priority.

[0126] This embodiment determines the priority of each candidate operating system; selects the candidate operating system with the highest priority as the target operating system; and responds to the pending task by the target operating system. Compared with randomly selecting the target operating system from each candidate operating system, the selection based on priority effectively improves the selection accuracy of the target operating system, thereby improving the processing accuracy of the pending task.

[0127] In this embodiment, step S40 may include steps S401 to S403:

[0128] Step S401: obtaining a target performance indicator generated when the target operating system responds to the task to be processed.

[0129] In a specific implementation, the communication module can monitor the tool or performance management system to obtain the target performance indicators generated when the target operating system responds to the pending tasks.

[0130] Step S402: determine whether the target performance indicator exceeds a preset indicator threshold.

[0131] It should be noted that the above-mentioned preset indicator threshold may be a critical value at which the operating system performance is normal, and may be determined according to demand or by testing the operating system.

[0132] In a specific implementation, the above-mentioned communication module may compare the target performance indicator with a preset indicator threshold to determine whether the target performance indicator exceeds the preset indicator threshold.

[0133] Step S403: If the preset indicator threshold is exceeded, it is determined that an abnormality exists in the operation of the target operating system.

[0134] In a specific implementation, when the above-mentioned communication module detects that the target performance indicator exceeds the preset indicator threshold, it can determine that the performance of the target operating system exceeds the normal range and that there is an abnormality in the operation of the target operating system.

[0135] In a feasible implementation manner, step S402 may further include steps S404 to S409:

[0136] Step S404: If the preset indicator threshold is not exceeded, the target historical performance indicator set of the target operating system is obtained.

[0137] It should be noted that the above-mentioned target historical performance indicator set may be a set consisting of historical performance indicators of the target operating system.

[0138] In a specific implementation, when the above-mentioned communication module detects that the target performance indicator does not exceed the preset indicator threshold, it can obtain the historical performance indicators of the target operating system within a preset time range from historical logs, monitoring tools or performance management systems, and add each of its historical performance indicators to the same set to form a target historical performance indicator set.

[0139] Step S405 : determining a target historical performance benchmark value that does not exceed a preset indicator threshold from the target historical performance indicator set.

[0140] In a specific implementation, the above-mentioned communication module can traverse each historical performance indicator in the target historical performance indicator set, and screen out the target historical performance indicators that do not exceed the preset indicator threshold. If the number of screened target historical performance indicators is one, the target historical performance indicator is used as the historical performance benchmark value. If at least two target historical performance indicators are screened out, the average of each target historical performance indicator is determined to obtain the target historical performance benchmark value.

[0141] Step S406: Calculate the deviation between the target performance indicator and the target historical performance benchmark value.

[0142] In a specific implementation, the above-mentioned communication module can compare the target performance indicator with the target historical performance benchmark value, calculate the difference between the target performance indicator and the target historical performance benchmark value, and take the absolute value of the difference to obtain the deviation between the target performance indicator and the target historical performance benchmark value.

[0143] Step S407: determine whether the deviation exceeds a preset deviation.

[0144] It should be noted that the above-mentioned preset deviation may be a threshold for determining whether the deviation between the target performance indicator and the target historical performance benchmark value is too large.

[0145] In a specific implementation, the communication module may compare the deviation between the target performance indicator and the target historical performance benchmark value with a preset deviation to determine whether the deviation exceeds the preset deviation.

[0146] Step S408: If the preset deviation is exceeded, it is determined that an abnormality exists in the operation of the target operating system.

[0147] In a specific implementation, when the deviation between the target performance indicator and the target historical performance benchmark value exceeds the preset deviation, the above-mentioned communication module determines that the deviation is large and the target performance indicator exceeds the normal range, and then determines that there is an abnormality in the operation of the target operating system.

[0148] Step S409: If the preset deviation is not exceeded, it is determined that there is no abnormality in the operation of the target operating system.

[0149] In a specific implementation, when the deviation between the target performance indicator and the target historical performance benchmark value does not exceed the preset deviation, the above-mentioned communication module determines that the deviation is small and the target performance indicator is within the normal range, and then determines that there is no abnormality in the operation of the target operating system.

[0150] In this embodiment, when the target performance indicator of the target operating system exceeds a preset indicator threshold, it is determined that an abnormality exists in the target operating system during operation; when the target performance indicator does not exceed the preset indicator threshold, the deviation between the target performance indicator and the target historical benchmark value is calculated. When the deviation exceeds the preset deviation, it is determined that an abnormality exists in the target operating system during operation; when the deviation does not exceed the preset deviation, it is determined that no abnormality exists in the target operating system during operation, thereby effectively improving the accuracy of abnormality detection of the target operating system.

[0151] In this embodiment, step S50 may include steps S501 and S502:

[0152] Step S501: If yes, select an alternative operating system from the candidate operating systems, the alternative operating system having a priority lower than the target operating system and higher than other candidate operating systems.

[0153] In a specific implementation, when an abnormality occurs during the operation of the target operating system, the above-mentioned communication module can select a candidate operating system with a lower priority than the target operating system from the candidate operating systems, that is, a candidate operating system with a lower priority than the target operating system and higher than other candidate operating systems.

[0154] Step S502: Using the candidate operating system as the target operating system to respond to the pending task, and returning to the step of determining whether there is an abnormality in the running process of the target operating system until the pending task response is completed.

[0155] In a specific implementation, the communication module can use the candidate operating system as the new target operating system to respond to the pending task, then return to the step of determining whether the target operating system has any anomalies during operation, repeating the above process. If the new target operating system still has an anomaly, a new target operating system is selected in the above manner until the pending task is completed. If all candidate operating systems have an anomaly after traversing, a warning message can be triggered, requiring manual inspection and repair by relevant personnel.

[0156] In this embodiment, when an exception occurs during the operation of the target operating system, an alternative operating system with a priority lower than the target operating system and higher than other candidate operating systems is selected from the candidate operating systems; the alternative operating system is used as the target operating system to respond to the pending task, and the step of determining whether there is an exception during the operation of the target operating system is returned to, thereby ensuring that the pending task can be responded to and completed, and ensuring the realization of the corresponding function of the communication module.

[0157] It should be noted that the above examples are only used to understand this application and do not constitute a limitation on the hybrid deployment solution of multi-OS communication modules based on openEuler in this application. More simple transformations based on this technical concept are all within the scope of protection of this application.

[0158] This application also provides a communication module, please refer to Figure 4 , Figure 4 This is a schematic diagram of the module structure of the communication module of this application, which includes:

[0159] The task acquisition module 10 is used to acquire the task to be processed and determine the task type of the task to be processed;

[0160] An operating system selection module 20 is configured to select at least two candidate operating systems from the operating systems according to the task type;

[0161] A task response module 30 is configured to select a target operating system from each of the candidate operating systems to respond to the pending task;

[0162] Anomaly detection module 40, used to determine whether there is an anomaly in the operation of the target operating system;

[0163] The task response module 30 is further configured to, if yes, select an alternative operating system from the candidate operating systems to respond to the task to be processed.

[0164] The communication module provided in this application adopts the multi-OS communication module hybrid deployment solution based on openEuler in the above-mentioned embodiment, which can solve the technical problem that the Linux operating system of the communication module in the prior art is abnormal, which will lead to the inability to meet user needs and affect the user experience. Compared with the prior art, the beneficial effects of the communication module provided in this application are the same as the beneficial effects of the multi-OS communication module hybrid deployment solution based on openEuler provided in the above-mentioned embodiment, and the other technical features in the communication module are the same as the features disclosed in the above-mentioned embodiment, which will not be repeated here.

[0165] The present application provides a communication device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the multi-OS communication module hybrid deployment solution based on openEuler in the above-mentioned embodiment one.

[0166] Reference below Figure 5 , Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the hybrid deployment solution of multi-OS communication modules based on openEuler in the embodiment of the present application, which shows a schematic diagram of the structure of the communication device suitable for implementing the embodiment of the present application. The communication device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (such as in-vehicle navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 5 The communication device shown is merely an example and should not limit the functions and scope of use of the embodiments of the present application.

[0167] like Figure 5As shown, the communication device may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes based on programs stored in a read-only memory (ROM) 1002 or programs loaded from a storage device 1003 into a random access memory (RAM) 1004. RAM 1004 also stores various programs and data required for the operation of the communication device. Processing device 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems may be connected to I / O interface 1006: input devices 1007, such as a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008, such as a liquid crystal display (LCD), speaker, vibrator, etc.; storage device 1003, such as a magnetic tape or hard disk; and communication device 1009. The communication device 1009 can allow the communication device to communicate with other devices wirelessly or wired to exchange data. Although the figure shows a communication device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or have instead.

[0168] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the scheme shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the scheme of the embodiment disclosed in the present application are executed.

[0169] The communication device provided in this application adopts the multi-OS communication module hybrid deployment solution based on openEuler in the above-mentioned embodiment, which can solve the technical problem that the Linux operating system of the communication module in the prior art is abnormal, which will lead to the inability to meet user needs and affect the user experience. Compared with the prior art, the beneficial effects of the communication device provided in this application are the same as the beneficial effects of the multi-OS communication module hybrid deployment solution based on openEuler provided in the above-mentioned embodiment, and the other technical features in the communication device are the same as the features disclosed in the previous embodiment, which will not be repeated here.

[0170] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0171] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art 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.

[0172] The present application provides a computer-readable storage medium having computer-readable program instructions (i.e., computer programs) stored thereon. The computer-readable program instructions are used to execute the openEuler-based multi-OS communication module hybrid deployment solution in the above-mentioned embodiment.

[0173] The computer-readable storage medium provided herein may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including, but not limited to, wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0174] The computer-readable storage medium may be included in the communication device, or may exist independently without being incorporated into the communication device.

[0175] Computer program code for performing the operations of the present application may be written in one or more programming languages, or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, C++, and conventional procedural programming languages such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0176] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, schemes and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code includes one or more executable instructions for realizing the prescribed logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a sequence different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the prescribed function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0177] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

[0178] The readable storage medium provided in this application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned multi-OS communication module hybrid deployment solution based on openEuler, which can solve the technical problem that the Linux operating system of the communication module in the prior art has an abnormality, which will lead to the inability to meet user needs and affect the user's experience. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the multi-OS communication module hybrid deployment solution based on openEuler provided in the above embodiment, and will not be repeated here.

[0179] The above description is only part of the embodiments of the present application and does not limit the patent scope of the present application. All equivalent structural transformations made by using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A multi-OS communication module hybrid deployment method based on openEuler, characterized in that: The method is applied to a communication module, wherein the communication module is provided with an openEuler embedded platform, and the openEuler embedded platform deploys multiple operating systems. The method includes: Obtaining a task to be processed and determining the task type of the task to be processed; selecting at least two candidate operating systems from the operating systems according to the task type; Selecting a target operating system from each of the candidate operating systems to respond to the pending task; Determining whether there is an abnormality during the operation of the target operating system; If yes, selecting a candidate operating system from each of the candidate operating systems to respond to the pending task; The task type includes a real-time type and a non-real-time type, and the step of determining the task type of the task to be processed includes: Extracting feature information of the task to be processed; Inputting the feature information into a target learning model to obtain a response time of the task to be processed; Determining whether the response time exceeds a preset time threshold; If not, determining that the task type of the task to be processed is the real-time type; If so, determining that the task type of the real-time task to be processed is the non-real-time type; The step of selecting at least two candidate operating systems from the operating systems according to the task type includes: Obtaining identification information of each operating system, where the identification information is used to characterize a task type applicable to the operating system; When the task type is the real-time type, selecting an operating system whose identification information indicates that it is applicable to the real-time type as a candidate operating system; When the task type is the non-real-time type, selecting an operating system whose identification information indicates that it is applicable to the non-real-time type as a candidate operating system; The hardware resources in the communication module are divided into a plurality of virtual machines, each of which runs a corresponding operating system. The step of selecting a target operating system from the candidate operating systems to respond to the task to be processed includes: Determining the priority of each candidate operating system; Select the candidate operating system with the highest priority as the target operating system; Sending the pending task to a target virtual machine running the target operating system, so that the target virtual machine responds to the pending task based on the target operating system; Before the step of selecting at least two candidate operating systems from the operating systems according to the task type, the method further includes: Obtaining historical performance indicator reference values of each of the operating systems; Calculating the difference between each of the historical performance indicator reference values and a preset benchmark indicator; Configuring a corresponding priority for each operating system according to the difference; The step of determining whether there is an abnormality in the target operating system during operation includes: Obtaining a target performance indicator generated when the target operating system responds to the task to be processed; Determining whether the target performance indicator exceeds a preset indicator threshold; If the preset indicator threshold is exceeded, it is determined that an abnormality exists in the operation of the target operating system; If the preset indicator threshold is not exceeded, obtaining the target historical performance indicator set of the target operating system; Determining a target historical performance benchmark value that does not exceed the preset indicator threshold from the target historical performance indicator set; Calculating the deviation between the target performance indicator and the target historical performance benchmark value; Determining whether the deviation exceeds a preset deviation; If the predetermined deviation is exceeded, it is determined that an abnormality exists in the operation of the target operating system; If the preset deviation is not exceeded, it is determined that there is no abnormality in the operation of the target operating system; If yes, the step of selecting a candidate operating system from each of the candidate operating systems to respond to the task to be processed includes: If so, selecting an alternative operating system from the candidate operating systems that has a priority lower than the target operating system and higher than other candidate operating systems; The alternative operating system is used as a new target operating system, and the step of sending the pending task to the target virtual machine running the target operating system is returned to so that the target virtual machine responds to the pending task based on the target operating system until the pending task response is completed.

2. A communication module, characterized in that: The communication module includes: A task acquisition module is used to acquire tasks to be processed and determine the task type of the tasks to be processed; An operating system selection module, configured to select at least two candidate operating systems from among the operating systems according to the task type; A task response module, configured to select a target operating system from each of the candidate operating systems to respond to the pending task; An anomaly detection module, used to determine whether there is an anomaly in the operation of the target operating system; The task response module is further configured to select a candidate operating system from each of the candidate operating systems to respond to the pending task; The task acquisition module is further used to: Extracting feature information of the task to be processed; Inputting the feature information into a target learning model to obtain a response time of the task to be processed; Determining whether the response time exceeds a preset time threshold; If not, determining that the task type of the task to be processed is a real-time type; If so, the task type of the real-time task to be processed is determined to be a non-real-time type; The operating system selection module is further used to: Obtaining identification information of each operating system, where the identification information is used to characterize a task type applicable to the operating system; When the task type is the real-time type, selecting an operating system whose identification information indicates that it is applicable to the real-time type as a candidate operating system; When the task type is the non-real-time type, selecting an operating system whose identification information indicates that it is applicable to the non-real-time type as a candidate operating system; The hardware resources in the communication module are divided into a plurality of virtual machines, each of which runs a corresponding operating system. The task response module is further configured to: Determining the priority of each candidate operating system; Select the candidate operating system with the highest priority as the target operating system; Sending the pending task to a target virtual machine running the target operating system, so that the target virtual machine responds to the pending task based on the target operating system; The operating system selection module is further used to: Obtaining historical performance indicator reference values of each of the operating systems; Calculating the difference between each of the historical performance indicator reference values and a preset benchmark indicator; Configuring a corresponding priority for each operating system according to the difference; The anomaly detection module is further configured to: Obtaining a target performance indicator generated when the target operating system responds to the task to be processed; Determining whether the target performance indicator exceeds a preset indicator threshold; If the preset indicator threshold is exceeded, it is determined that an abnormality exists in the operation of the target operating system; If the preset indicator threshold is not exceeded, obtaining the target historical performance indicator set of the target operating system; Determining a target historical performance benchmark value that does not exceed the preset indicator threshold from the target historical performance indicator set; Calculating the deviation between the target performance indicator and the target historical performance benchmark value; Determining whether the deviation exceeds a preset deviation; If the predetermined deviation is exceeded, it is determined that an abnormality exists in the operation of the target operating system; If the preset deviation is not exceeded, it is determined that there is no abnormality in the operation of the target operating system; The task response module is further used to: If it is determined that the target operating system has an abnormality during operation, selecting an alternative operating system from the candidate operating systems that has a lower priority than the target operating system and higher priority than other candidate operating systems; The alternative operating system is used as a new target operating system, and the operation of sending the pending task to the target virtual machine running the target operating system is executed so that the target virtual machine responds to the pending task based on the target operating system until the pending task response is completed.

3. A communication device, characterized in that: The communication device includes: a memory, a processor, and a computer program stored in the memory and runnable on the processor, wherein the computer program is configured to implement the steps of the openEuler-based multi-OS communication module hybrid deployment method as claimed in claim 1.

Images