Industrial software compatibility adaptation method and device based on intermediate business model

Abstract

The present invention discloses an industrial software compatibility adaptation method and device based on an intermediate business model, which relates to the technical field of industrial software compatibility adaptation, and includes the following steps: between different devices and monitoring systems, the response time of the device during actual operation is collected, the overall system performance and compatibility are reflected through the response time, and the intermediate business model is preliminarily identified to have hidden dangers of improper abstraction level configuration. The present invention analyzes the response time of the device during operation, identifies and adjusts the abstraction level of the intermediate business model, ensures efficient model adaptation, and improves system interoperability and flexibility. Through real-time monitoring and early warning mechanisms, the success of dynamic processing is guaranteed, and early warning of unsuccessful processing is issued, thereby improving the reliability and accuracy of model adaptation, reducing maintenance costs and workload, and making the equipment monitoring system more stable and efficient.

Description

Technical Field

[0001] The present invention relates to the technical field of industrial software compatibility adaptation, and in particular to an industrial software compatibility adaptation method and device based on an intermediate business model. Background Art

[0002] Industrial software compatibility and adaptation based on intermediate business models refers to the design and use of intermediate business models in industrial software development and application, so that different industrial software systems can achieve compatibility and adaptation in data exchange, functional integration and business processes. As an abstract layer, the intermediate business model unifies the interfaces and data structures between different systems, thereby simplifying the interoperability between systems and reducing the complexity and cost of direct integration.

[0003] Specifically, this approach defines unified business models and interface standards, allowing different software systems to communicate data and call functions based on these standards. This not only improves the flexibility and scalability of the system, but also accelerates the development and deployment of new systems, because developers only need to follow the standards of the intermediate business model to ensure the compatibility of the new system with the existing system.

[0004] Industrial software compatibility and adaptation based on the intermediate business model ensures that different types of equipment and monitoring systems can seamlessly exchange data and integrate functions through unified business models and interface standards. The core of this approach is to create an abstraction layer that unifies the interfaces and data structures between devices and systems, reducing the complexity and inconsistency of direct integration. Through this abstraction layer, different types of equipment can communicate and transmit data through standardized interfaces, even if their underlying implementations are different. In this way, the system can be compatible with a variety of devices, and no major modifications to the core architecture of the system are required, whether new equipment is added or old equipment is replaced. This approach not only improves the interoperability of the system, but also significantly reduces the adaptation workload and maintenance costs, ensuring that the system can run stably and efficiently.

[0005] Industrial software compatibility and adaptation based on the intermediate business model also shows significant advantages in portability. Through the design of the abstract layer, business logic and device characteristics are decoupled, so that the business model can be independent of the implementation of specific devices. This means that when industrial software needs to be ported from one environment to another, only the abstract layer and interface standards need to be adjusted without redesigning the entire system. This approach ensures that the system's business logic and data processing can run in different hardware and software environments, thereby improving the portability of the software. In addition, the standardized interface and modular design make it possible to quickly deploy and run the system in the new environment with only a small amount of configuration and adaptation work, greatly shortening the development and deployment cycle and reducing the risk and cost of the migration process.

[0006] In the equipment monitoring system of a manufacturing enterprise, the role of industrial software compatibility adaptation based on the intermediate business model is to ensure that different types of equipment and monitoring systems can seamlessly exchange data and integrate functions through a unified business model and interface standard, thereby improving the interoperability and flexibility of the system, reducing adaptation workload and maintenance costs, and ensuring data accuracy and system reliability. However, industrial software compatibility adaptation based on the intermediate business model is prone to increase the difficulty of adaptation due to improper abstraction levels. Models that are too abstract cannot cover all equipment types and monitoring requirements, and models that are too specific introduce unnecessary complexity, all of which will lead to inefficient data exchange and functional integration between different devices, increased adaptation workload and maintenance costs, and may even lead to communication failures between systems. Therefore, it is particularly important to configure an efficient intermediate business model for the equipment monitoring system of a manufacturing enterprise;

[0007] For example, if all types of sensor data are abstracted into a general "sensor data" object, while ignoring the characteristics of different devices such as temperature sensors and pressure sensors, the overly abstract model will not be able to accurately reflect the data requirements of different devices, making it difficult for the monitoring system to effectively process and analyze data. On the contrary, if a specific data model is established for each sensor, the model is too specific, which will introduce too much complexity. Whenever a new device is added, the model needs to be redefined and adapted, increasing the adaptation workload and maintenance costs. Such a design will lead to inefficient data exchange and functional integration between systems, and may even cause communication failures between systems.

[0008] The above information disclosed in this Background section is only for enhancement of understanding of the background of the present disclosure and therefore it may contain information that does not constitute the prior art that is already known to one of ordinary skill in the art. Summary of the invention

[0009] The purpose of the present invention is to provide an industrial software compatibility adaptation method and device based on an intermediate business model. By collecting and analyzing the response time of the equipment during operation, it is preliminarily identified whether the intermediate business model has the hidden danger of improper configuration of the abstract level, thereby quickly reflecting the system performance and compatibility, and helping enterprises to discover and solve potential problems as early as possible. Through real-time analysis of the abstract evaluation coefficient during the monitoring cycle, the abstract level of the model is timely identified and adjusted, and dynamic adjustments are made for excessive or insufficient abstraction to ensure efficient model adaptation and improve the interoperability and flexibility of the system. The real-time monitoring and early warning mechanism ensures the success of dynamic processing and warns of unsuccessful processing, significantly improving the reliability and accuracy of the model adaptation process, reducing system maintenance costs and workload, and making the equipment monitoring system more stable and efficient. To solve the problems in the above-mentioned background technology.

[0010] In order to achieve the above object, the present invention provides the following technical solution: an industrial software compatibility adaptation method based on an intermediate business model, comprising the following steps:

[0011] Collect the response time of the devices during actual operation between different devices and monitoring systems. The response time reflects the overall performance and compatibility of the system, and preliminarily identifies whether there are hidden dangers of improper configuration of the abstract level in the intermediate business model.

[0012] When the potential risk of improper configuration of the abstraction level of the intermediate business model is initially identified, relevant information of the intermediate business model is obtained to establish a data analysis mechanism to identify abnormalities in the improper configuration of the abstraction level of the intermediate business model;

[0013] Based on the data analysis mechanism, the improper configuration of the abstraction level of the intermediate business model is classified as over-abstraction or under-abstraction;

[0014] In order to solve the problem of over-abstraction, the intermediate business model is dynamically refined, different types of equipment and monitoring requirements are processed separately, and the description of attributes and behaviors is increased. In order to solve the problem of insufficient abstraction, the details and specialization in the intermediate business model are dynamically reduced, and the abstraction level of the model is improved to cover more types of equipment and requirements, so as to configure an efficient intermediate business model for the equipment monitoring system of manufacturing enterprises.

[0015] The dynamic processing of the intermediate business model is monitored in real time to ensure that the dynamic processing of the intermediate business model is successful within the specified time, and an early warning is issued in the event of unsuccessful dynamic processing.

[0016] Preferably, the specific steps for preliminarily identifying whether there are inappropriate hidden dangers in the model abstraction level are as follows:

[0017] In the monitoring window, the monitoring system records the response time of each device under different operations, and establishes a data set based on the response time;

[0018] Calculate the mean response time and the standard deviation of response time through the response time in the data set;

[0019] The response time mean and response time standard deviation are compared and analyzed with the pre-set response time reference threshold and standard deviation reference threshold respectively. If the response time mean is less than the shortest time benchmark and the response time standard deviation is less than the standard deviation reference threshold, an efficient response signal is generated. If the response time mean is greater than or equal to the shortest time benchmark and the response time standard deviation is less than the standard deviation reference threshold, a hidden danger signal is generated.

[0020] Preferably, when the intermediate business model generates a hidden danger signal in the compatibility adaptation of industrial software, model-related information is obtained to establish a data analysis mechanism, wherein the model-related information includes the data processing information and interface call information of the model, and after abnormal analysis and processing of the data processing information and interface call information of the model, a data redundancy rate index and an interface call frequency proportion index are generated, and by establishing a data analysis mechanism with the data redundancy rate index and the interface call frequency proportion index, an abstract evaluation coefficient is generated, and abnormalities of the model abstraction level are identified through the abstract evaluation coefficient.

[0021] Preferably, within the monitoring period T, the abstract evaluation coefficient generated for industrial software compatibility adaptation based on the intermediate business model is compared and analyzed with the pre-set abstract evaluation coefficient reference threshold range. If the abstract evaluation coefficient is not within the abstract evaluation coefficient reference threshold range, an abnormal signal is generated, indicating that the intermediate business model has an abnormality of improper abstract level configuration. If the abstract evaluation coefficient is within the abstract evaluation coefficient reference threshold range, a normal signal is generated, indicating that the abstract level configuration of the intermediate business model is efficient.

[0022] Preferably, the steps of classifying the improper configuration of the abstraction level of the intermediate business model as over-abstraction or under-abstraction are as follows:

[0023] If the abstract evaluation coefficient is greater than the maximum value of the abstract evaluation coefficient reference threshold range, the improper configuration of the abstract level of the intermediate business model is classified as over-abstraction; if the abstract evaluation coefficient is less than the minimum value of the abstract evaluation coefficient reference threshold range, the improper configuration of the abstract level of the intermediate business model is classified as over-abstraction.

[0024] Preferably, the model is dynamically refined to separately handle different types of equipment and monitoring requirements, and to add descriptions of attributes and behaviors. The specific steps are as follows:

[0025] Classify the devices in the system, identify different types of devices, analyze the monitoring requirements of each device, and clarify the specific attributes and behaviors required for each device;

[0026] Define specific properties for each device type and define specific behaviors for each device type;

[0027] Separate the processing logic of different device types into independent modules, define a unified interface for each module, and ensure seamless integration and replacement between modules;

[0028] According to the modular design, develop processing modules for each device type, write unit test cases for each module to verify its functions and performance, and perform integration tests in the system environment to ensure that the modules work together;

[0029] Use configuration files to define the processing logic and parameters of different devices. When the system is started or running, dynamically load and initialize the corresponding device modules according to the configuration files.

[0030] Create one or more configuration files, list all devices and their corresponding modules and parameter settings, write code to load the configuration, read the configuration files when the system starts, and dynamically load the corresponding modules according to the configuration.

[0031] Preferably, in view of the lack of abstraction, the details and specialization in the model are dynamically reduced to improve the abstraction level of the model so that it covers more types of devices and requirements. The specific steps are as follows:

[0032] List all devices in the system and their current processing logic and properties, analyze the common and characteristic requirements of the devices, and classify the devices according to the common requirements;

[0033] Extract common requirements between devices, define them as common attributes and behaviors, identify device feature requirements, and refine feature requirements into scalable parameters and configurations;

[0034] Design a high-level abstract model that includes the common requirements of all devices and supports feature requirements in a parameterized manner to make the model scalable;

[0035] Refactor existing code, extract common requirements into a high-level abstract model, implement parameterized configuration of feature requirements, and remove specific details and specialization;

[0036] Create configuration files to define the parameters and configurations of different devices. When the system starts or runs, dynamically load and initialize the corresponding device models according to the configuration files.

[0037] Preferably, when the intermediate business model is dynamically processed, the abstract evaluation coefficient generated within each monitoring period T is obtained through the data analysis mechanism, and the abstract evaluation coefficient is compared and analyzed with the abstract evaluation coefficient reference threshold range. If the abstract evaluation coefficient is within the abstract evaluation coefficient reference threshold range within the specified time, a success signal of dynamic processing of the intermediate business model is generated, and the industrial software compatibility continues to be efficiently adapted based on the intermediate business model. If the abstract evaluation coefficient is not within the abstract evaluation coefficient reference threshold range within the specified time, a failure signal of dynamic processing of the intermediate business model is generated, and an early warning prompt is issued for this situation, indicating that the dynamic processing of the intermediate business model cannot reach the expected state and requires human intervention.

[0038] Preferably, the specific steps of obtaining the data processing information of the model and generating the data redundancy rate index after performing anomaly analysis based on the data processing information are as follows:

[0039] During the monitoring period T, data processing information of each device is collected, including:

[0040] Total data volume D total : The total amount of data generated by all devices in the monitoring period T;

[0041] Unique data volume D unique : The amount of non-repetitive data generated by all devices within the monitoring period T;

[0042] Number of devices N: the total number of devices in the system;

[0043] Calculate the data redundancy rate. The calculation expression is:

[0044] Calculate the data redundancy index. The calculation expression is: In the formula, R i represents the data redundancy rate generated by device i in period T, D total，i represents the total amount of data generated by device i in period T, D unique，i represents the amount of non-repetitive data generated by device i in period T, Red Ra Represents the data redundancy index.

[0045] Preferably, the specific steps of obtaining the interface call count information of the model and generating the interface call count proportion index after performing anomaly analysis based on the interface call count information are as follows:

[0046] Collect interface call data, including:

[0047] Record the total number of calls C total : In the monitoring period T, record the total number of calls of all interfaces in the system;

[0048] Record the number of general interface calls C common : Record the number of calls of all common interfaces within the monitoring period T;

[0049] Calculate the proportion of interface calls. The proportion of interface calls is the proportion of general interface calls in all interface calls. The specific calculation formula is: Where P represents the proportion of interface calls;

[0050] Calculate the interface call frequency ratio index, the calculation expression is: log(C total +1) is the logarithm of the total number of calls, which is used to reflect the scale of the call volume, σ C is the standard deviation of the number of calls to different types of interfaces, C τis the average number of calls to different types of interfaces, Int fa Indicates the proportion index of interface call times.

[0051] An industrial software compatibility adaptation device based on an intermediate business model comprises the following steps:

[0052] The preliminary hidden danger identification module collects the response time of the actual operation of the equipment between different devices and monitoring systems, reflects the overall performance and compatibility of the system through the response time, and preliminarily identifies whether there are hidden dangers of improper configuration of the abstract level in the intermediate business model;

[0053] The anomaly identification module, when initially identifying the hidden danger of improper configuration of the abstract level of the intermediate business model, obtains the relevant information of the intermediate business model to establish a data analysis mechanism and identify the anomaly of improper configuration of the abstract level of the intermediate business model;

[0054] The abstraction level classification module classifies the improper configuration of the abstraction level of the intermediate business model into over-abstraction or under-abstraction based on the data analysis mechanism;

[0055] The model dynamic processing module dynamically refines the intermediate business model to address over-abstraction, handles different types of equipment and monitoring requirements separately, and adds descriptions of attributes and behaviors. In response to insufficient abstraction, it dynamically reduces the details and specialization within the intermediate business model, improves the model's abstraction level, covers more types of equipment and requirements, and configures efficient intermediate business models for manufacturing enterprises' equipment monitoring systems.

[0056] The real-time monitoring and early warning prompt module monitors the dynamic processing of the intermediate business model in real time to ensure that the dynamic processing of the intermediate business model is successful within the specified time, and issues early warning prompts in the event of unsuccessful dynamic processing.

[0057] In the above technical solution, the technical effects and advantages provided by the present invention are:

[0058] The present invention collects and analyzes the response time of the device during actual operation to preliminarily identify whether there is a hidden danger of improper abstraction level configuration in the intermediate business model. This process can quickly reflect the overall performance and compatibility of the system, help enterprises discover potential problems early, and avoid performance bottlenecks and compatibility problems caused by improper model abstraction level during the adaptation process.

[0059] The present invention timely identifies and classifies abstraction level configuration problems of the intermediate business model through real-time comparison and analysis of abstract evaluation coefficients within the monitoring cycle. For the case of over-abstraction, the intermediate business model is dynamically refined to handle different types of equipment and monitoring requirements separately, and necessary attributes and behavior descriptions are added to ensure that the model can accurately cover the equipment and requirements. For the case of insufficient abstraction, the abstraction level of the model is improved by dynamically reducing the details and specialization of the intermediate business model, so that it can be more widely applied to different types of equipment and requirements. Through this dynamic adjustment mechanism, it is ensured that the intermediate business model is always in an efficient and adaptive state, thereby improving the interoperability and flexibility of the system.

[0060] The present invention ensures that the dynamic processing of the model can be successful within the specified time through real-time monitoring of the dynamic processing process of the intermediate business model, and issues early warning prompts for unsuccessful dynamic processing. It continuously obtains and compares abstract evaluation coefficients through a data analysis mechanism, promptly generates a signal of success or failure of the dynamic processing of the model, and issues an early warning prompt when necessary, indicating that human intervention is required. This real-time monitoring and early warning mechanism not only improves the reliability and accuracy of the model adaptation process, but also significantly reduces the system maintenance cost and workload, so that the equipment monitoring system of the manufacturing enterprise can operate more stably and efficiently. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0062] Figure 1 The present invention is a method flow chart of an industrial software compatibility adaptation method based on an intermediate business model.

[0063] Figure 2 The present invention is a module schematic diagram of an industrial software compatible adapter device based on an intermediate business model. DETAILED DESCRIPTION

[0064] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in a variety of forms and should not be construed as limited to the examples set forth herein; rather, these example embodiments are provided so that the description of the present disclosure will be more comprehensive and complete, and the concept of the example embodiments will be fully conveyed to those skilled in the art.

[0065] The present invention provides Figure 1 An industrial software compatibility adaptation method based on an intermediate business model is shown, comprising the following steps:

[0066] Collect the response time of the devices during actual operation between different devices and monitoring systems. The response time reflects the overall performance and compatibility of the system, and preliminarily identifies whether there are hidden dangers of improper configuration of the abstract level in the intermediate business model.

[0067] Collect response time data of different devices and monitoring systems during actual operation. These data should cover various device types and different operation scenarios, including different environmental conditions, workloads, and network environments. By analyzing these data, the overall performance and compatibility of the system can be reflected.

[0068] When the device is running, improper configuration of the abstraction level of the intermediate business model will lead to longer response time when the device is actually running. The reason is that the intermediate business model serves as an interface and data structure bridge between different devices and the monitoring system, and its design directly affects the efficiency and performance of the system. Specifically, an overly abstract model may ignore the specific requirements and characteristics of the device, making the system inefficient in processing these requirements.

[0069] For example, unifying temperature sensors and pressure sensors into a common "sensor data" object will cause the system to require additional logic to distinguish and process different types of data, thereby increasing processing time. On the contrary, models with too low an abstraction level or too specific will introduce too much detail and complexity, making the processing path of each device lengthy and cumbersome, increasing the burden of communication and data exchange between systems. Therefore, improper configuration of the abstraction level of the intermediate business model may lead to inefficient processing due to over-simplification, or lengthy processing paths due to excessive complexity, ultimately prolonging the actual operation response time of the device. By reasonably designing the abstraction level of the intermediate business model, a balance can be achieved between the reflection of device characteristics and system complexity, thereby improving the response efficiency of the system.

[0070] The specific steps to initially identify whether there are inappropriate risks in the model abstraction level are as follows:

[0071] In the monitoring window, the monitoring system records the response time of each device under different operations, and establishes a data set based on the response time;

[0072] Calculate the mean response time and the standard deviation of response time through the response time in the data set;

[0073] The response time mean and response time standard deviation are compared and analyzed with the pre-set response time reference threshold and standard deviation reference threshold respectively. If the response time mean is less than the shortest time benchmark and the response time standard deviation is less than the standard deviation reference threshold, an efficient response signal is generated, indicating that the compatibility and adaptation of the industrial software based on the intermediate business model are efficient. If the response time mean is greater than or equal to the shortest time benchmark and the response time standard deviation is less than the standard deviation reference threshold, a hidden danger signal is generated, indicating that the compatibility and adaptation of the industrial software based on the intermediate business model are inefficient, which further indicates that there are improper hidden dangers in the abstract level of the intermediate business model.

[0074] When the potential risk of improper configuration of the abstraction level of the intermediate business model is initially identified, relevant information of the intermediate business model is obtained to establish a data analysis mechanism to identify abnormalities in the improper configuration of the abstraction level of the intermediate business model;

[0075] When the intermediate business model generates a hidden danger signal in the compatibility adaptation of industrial software, model-related information is obtained to establish a data analysis mechanism, wherein the model-related information includes the model's data processing information and interface call information. After abnormal analysis and processing of the model's data processing information and interface call information, a data redundancy rate index and an interface call frequency proportion index are generated. By establishing a data analysis mechanism with the data redundancy rate index and the interface call frequency proportion index, an abstract evaluation coefficient is generated, and the abstract evaluation coefficient is used to identify abnormalities at the model's abstract level.

[0076] In the equipment monitoring system of a manufacturing enterprise, when industrial software is compatible and adapted based on an intermediate business model, if the intermediate business model is overly abstracted, the data redundancy rate will become excessively large. This is because overly abstract models often cannot fully reflect the specific needs and characteristics of different devices, resulting in the unified storage and processing of data from each device, ignoring their differences, resulting in a large amount of duplicate and redundant data during data storage and processing. For example, unifying the data of various sensors into a common "sensor data" object may result in repeated storage of the same or similar data attributes, increasing data redundancy.

[0077] In the equipment monitoring system of a manufacturing enterprise, when industrial software compatibility adaptation is performed based on the intermediate business model, if the intermediate business model is not abstract enough, the data redundancy rate will be excessively reduced. This is because the insufficiently abstract model will establish a very specific data model and interface for each device type, and describe the characteristics and requirements of each device in detail, so that the data storage and processing methods are very refined, avoiding repeated storage and redundancy of data between different devices. Although this refined processing reduces data redundancy, it also increases the complexity and maintenance cost of the system, because the addition of each new device requires the redefinition and adaptation of the new data model.

[0078] The specific steps of obtaining the data processing information of the model and generating the data redundancy rate index after performing anomaly analysis based on the data processing information are as follows:

[0079] During the monitoring period T, data processing information of each device is collected, including:

[0080] Total data volume D total : The total amount of data generated by all devices in the monitoring period T;

[0081] Unique data volume D unique : The amount of non-repetitive data generated by all devices within the monitoring period T;

[0082] Number of devices N: the total number of devices in the system;

[0083] Deploy a data logging mechanism in the system to record the amount of data generated by each device within the monitoring period T. The log of each device can include information such as timestamp, data size, and data type. By aggregating these log data, the total amount of data generated by all devices within the period T can be calculated, and a data deduplication algorithm (such as hash table, Bloom filter) can be implemented in the system to deduplicate the data generated by all devices and record the size of non-duplicate data. The data deduplication algorithm can be performed before the data enters the database or storage system to ensure that the stored data is unique.

[0084] Calculate the data redundancy rate. The calculation expression is:

[0085] Calculate the data redundancy index. The calculation expression is: In the formula, R i represents the data redundancy rate generated by device i in period T, D total，i represents the total amount of data generated by device i in period T, D unique，i represents the amount of non-repetitive data generated by device i in period T, Red Ra Represents the data redundancy rate index;

[0086] log(D total +1) means taking the logarithm of the total data volume and increasing the impact of the large data volume on the redundancy rate index.

[0087] It can be seen from the data redundancy rate index that within the monitoring period T, the larger the performance value of the data redundancy rate index generated for industrial software compatibility adaptation based on the intermediate business model, the higher the risk of excessive abstraction of the intermediate business model; the smaller the performance value of the data redundancy rate index generated for industrial software compatibility adaptation based on the intermediate business model, the higher the risk of insufficient abstraction of the intermediate business model.

[0088] In the equipment monitoring system of a manufacturing enterprise, when industrial software compatibility adaptation is performed based on an intermediate business model, if the intermediate business model is overly abstracted, the proportion of interface calls will become excessively large. This is because overly abstract models tend to use a small number of general interfaces to handle a variety of devices and operations, and these general interfaces must be called frequently to adapt to the specific needs and functions of different devices. This frequent call increases the total number of interface calls, and the proportion becomes larger, because the system needs to process a large number of diverse requests through these general interfaces, rather than through more specialized and direct paths.

[0089] In the equipment monitoring system of a manufacturing enterprise, when industrial software compatibility adaptation is performed based on an intermediate business model, if the intermediate business model is not abstract enough, the proportion of interface calls will be excessively reduced. This is because the insufficiently abstract model will define very specific and dedicated interfaces for each device and operation, so that each device and operation has an independent processing path, reducing the dependence on the general interface and the number of calls. Therefore, the proportion of interface calls in the system as a whole will be smaller, because more processing is done within the dedicated interface, rather than by sharing and reusing the general interface.

[0090] The specific steps for obtaining the model's interface call count information and generating an interface call count ratio index after performing anomaly analysis based on the interface call count information are as follows:

[0091] Collect interface call data, including:

[0092] Record the total number of calls C total : In the monitoring period T, record the total number of calls of all interfaces in the system;

[0093] Record the number of general interface calls C common : Record the number of calls of all common interfaces (i.e. interfaces used for multiple devices and operations) within the monitoring period T;

[0094] System logs usually record detailed information about all interface calls, including timestamps, calling interfaces, calling parameters, etc. By analyzing these logs, the total number of calls to all interfaces within the monitoring period T can be counted. Log analysis tools (such as ELK Stack, Splunk) can be used to automatically process and count the number of interface calls. Similarly, by analyzing system logs, the number of calls to specific common interfaces can be identified and counted. Common interfaces usually have specific names or identifiers, which can be counted by filtering log records. Use log analysis tools to set filtering conditions, extract call records of common interfaces, and count their call times.

[0095] Calculate the proportion of interface calls. The proportion of interface calls is the proportion of general interface calls in all interface calls. The specific calculation formula is: Where P represents the proportion of interface calls;

[0096] Calculate the interface call frequency ratio index, the calculation expression is: log(C total +1) is the logarithm of the total number of calls, which is used to reflect the scale of the call volume, σ C is the standard deviation of the number of calls to different types of interfaces, C τ is the average number of calls to different types of interfaces, Int fa Indicates the proportion index of interface call times.

[0097] It can be seen from the interface call count ratio index that within the monitoring period T, the larger the performance value of the interface call count ratio index generated for industrial software compatibility adaptation based on the intermediate business model, the higher the risk of excessive abstraction of the intermediate business model; the smaller the performance value of the interface call count ratio index generated for industrial software compatibility adaptation based on the intermediate business model, the higher the risk of insufficient abstraction of the intermediate business model.

[0098] The data analysis mechanism is not specifically limited here, and can achieve the data redundancy rate index Red Ra And the interface call frequency ratio index Int fa Perform comprehensive analysis to generate abstract evaluation coefficient λ Abs In order to realize the technical solution of the present invention, the present invention provides a specific implementation method;

[0099] Abstract evaluation coefficient λ Abs The resulting calculation formula is: Abs =*Red Ra +*Int fa , where α and β are the data redundancy rate index Red Ra And the interface call frequency ratio index Int fa The preset proportional coefficient, and α and β are both greater than 0.

[0100] It can be seen from the abstract evaluation coefficient that within the monitoring period T, the larger the performance value of the data redundancy rate index generated for industrial software compatibility adaptation based on the intermediate business model, and the larger the performance value of the interface call frequency ratio index, that is, the larger the performance value of the generated abstract evaluation coefficient, the higher the risk of excessive abstraction in the intermediate business model; the smaller the performance value of the data redundancy rate index generated for industrial software compatibility adaptation based on the intermediate business model, and the smaller the performance value of the interface call frequency ratio index, that is, the smaller the performance value of the generated abstract evaluation coefficient, the higher the risk of insufficient abstraction in the intermediate business model.

[0101] Based on the data analysis mechanism, the improper configuration of the abstraction level of the intermediate business model is classified as over-abstraction or under-abstraction;

[0102] In the monitoring period T, the abstract evaluation coefficient generated by the industrial software compatibility adaptation based on the intermediate business model is compared and analyzed with the pre-set reference threshold range of the abstract evaluation coefficient. If the abstract evaluation coefficient is not within the reference threshold range of the abstract evaluation coefficient, an abnormal signal is generated, indicating that the intermediate business model has an abnormality of improper abstraction level configuration. If the abstract evaluation coefficient is within the reference threshold range of the abstract evaluation coefficient, a normal signal is generated, indicating that the abstraction level configuration of the intermediate business model is efficient.

[0103] Within the monitoring period T, if the abstract evaluation coefficient is greater than the maximum value of the abstract evaluation coefficient reference threshold range, the improper configuration of the abstract level of the intermediate business model is classified as over-abstraction; if the abstract evaluation coefficient is less than the minimum value of the abstract evaluation coefficient reference threshold range, the improper configuration of the abstract level of the intermediate business model is classified as over-abstraction.

[0104] In order to solve the problem of over-abstraction, the intermediate business model is dynamically refined, different types of equipment and monitoring requirements are processed separately, and the description of attributes and behaviors is increased. In order to solve the problem of insufficient abstraction, the details and specialization in the intermediate business model are dynamically reduced, and the abstraction level of the model is improved to cover more types of equipment and requirements, so as to configure an efficient intermediate business model for the equipment monitoring system of manufacturing enterprises.

[0105] In response to over-abstraction, the model is dynamically refined, different types of equipment and monitoring requirements are handled separately, and descriptions of attributes and behaviors are added. This means that in the equipment monitoring system, if the intermediate business model is too simplified and cannot fully reflect the specific needs and characteristics of different equipment, the model needs to be redesigned to make it more refined. Specifically, it is necessary to identify and distinguish different types of equipment in the system (such as temperature sensors, pressure sensors, etc.), and define unique attributes (such as temperature range, accuracy, pressure range, sensitivity, etc.) and behaviors (such as data acquisition, calibration, anomaly detection, etc.) for each device, so as to more accurately and efficiently process the data and operation requirements of each device. In this way, the model can better adapt to the specific requirements of various types of equipment, avoid problems such as poor performance and low data processing efficiency caused by over-abstraction, and improve the overall performance and reliability of the system.

[0106] In the equipment monitoring system of a manufacturing enterprise, in order to solve the problem of over-abstraction of the intermediate business model, the model is dynamically refined to separately handle different types of equipment and monitoring requirements, and to increase the description of attributes and behaviors. The following are the specific implementation steps:

[0107] Classify the devices in the system, identify different types of devices (such as temperature sensors, pressure sensors, etc.), analyze the monitoring requirements of each device, and clarify the specific attributes and behaviors required for each device;

[0108] Identify the types of all devices in the system through equipment lists and technical documentation, and work with equipment suppliers and technical teams to collect and analyze specific requirements for each device, such as measurement range, accuracy, response time, etc.

[0109] Identify and categorize all devices in the system. List the device types, such as temperature sensors, pressure sensors, etc., and analyze the monitoring requirements for each device. This includes the parameters, performance indicators, and specific functions that need to be monitored for each device. For example, the attributes that need to be monitored for a temperature sensor may include temperature range and response time, while a pressure sensor needs to monitor pressure range and response time. Through classification, the specific attributes and behaviors required for each device are clarified for subsequent definition and implementation.

[0110] Define specific properties for each device type (such as temperature range and accuracy for temperature sensors; pressure range and sensitivity for pressure sensors), and define specific behaviors for each device type (such as calibration and data acquisition frequency setting for temperature sensors; pressure correction and data filtering for pressure sensors);

[0111] Based on the requirements analysis results, list the required attributes and behaviors for each device, create detailed definitions and description documents of the attributes and behaviors, and ensure that all team members understand these definitions;

[0112] Define specific properties and behaviors for each device type. Each device type may require unique properties, such as the measurement range and accuracy of a temperature sensor, or the maximum pressure and sensitivity of a pressure sensor. In addition, define specific behaviors for each device, such as data collection frequency, alarm conditions, etc. In this way, a clear property and behavior model can be established for each device type, ensuring the correct function and performance of the device in the system.

[0113] Separate the processing logic of different device types into independent modules, define a unified interface for each module, and ensure seamless integration and replacement between modules;

[0114] According to the device type, the logic of data collection, processing, storage, etc. is divided into independent modular components, and the standard interface methods that each module needs to implement (such as data collection interface, anomaly detection interface, etc.) are defined to ensure that different modules can interoperate;

[0115] Separate the processing logic of different device types into independent modules. Define a unified interface for each module to ensure seamless integration and replacement between modules. For example, define a common interface for the temperature sensor module for data acquisition and status monitoring. Similarly, define a corresponding interface for the pressure sensor module. Through modular design, the flexibility and maintainability of the system can be improved, ensuring that each module can be independently developed, tested, and deployed.

[0116] According to the modular design, develop processing modules for each device type, write unit test cases for each module to verify its functions and performance, and perform integration tests in the system environment to ensure that the modules work together;

[0117] Write the processing logic code for each device type to ensure that it complies with the definition in the design document, verify the correctness of the function of each module through unit testing, and perform integration testing in real or simulated environments to verify whether the interaction between modules is normal;

[0118] According to the modular design, develop processing modules for each device type. Write unit test cases for each module to verify its functions and performance. For example, write test cases for the temperature sensor module to verify its temperature measurement accuracy and response time. Perform integration testing in the system environment to ensure that the modules can work together and exchange data and call functions through a unified interface. Integration testing should also include load testing and performance testing to ensure the stability and reliability of the system under high load.

[0119] Use configuration files to define the processing logic and parameters of different devices. When the system is started or running, dynamically load and initialize the corresponding device modules according to the configuration files.

[0120] Create one or more configuration files, list all devices and their corresponding modules and parameter settings, write code to load the configuration, read the configuration files when the system starts, and dynamically load the corresponding modules according to the configuration;

[0121] Use configuration files to define the processing logic and parameters of different devices. When the system starts or runs, dynamically load and initialize the corresponding device modules according to the configuration files. Create one or more configuration files to list all devices and their corresponding modules and parameter settings. Write code to load the configuration, read the configuration files when the system starts, and dynamically load the corresponding modules according to the configuration. For example, define the measurement range and acquisition frequency of the temperature sensor through the configuration file, and dynamically load the temperature sensor module and initialize its parameters when the system starts. This allows the system configuration to be flexibly adjusted according to actual needs, improving the adaptability and scalability of the system.

[0122] In view of the lack of abstraction, the details and specialization in the model are dynamically reduced, and the abstraction level of the model is improved to cover more types of equipment and needs. This means that in the equipment monitoring system, if the intermediate business model is too detailed, each device has very specific processing logic and attributes, which leads to increased system complexity and maintenance costs, the model design needs to be simplified. Specifically, it is necessary to identify which details and specializations are redundant, and abstract these details into more general features and behaviors to create a higher-level general model. In this way, the model can cover more types of equipment, provide a unified interface and processing logic, reduce duplicate code and redundant configuration, and improve the maintainability and scalability of the system, thereby configuring an efficient intermediate business model for the equipment monitoring system of manufacturing enterprises. By improving the level of abstraction, the system can more flexibly adapt to the needs of different equipment and achieve more efficient data processing and function integration.

[0123] In view of the lack of abstraction, the details and specialization in the model are dynamically reduced to improve the abstraction level of the model so that it covers more types of devices and requirements. The specific implementation steps are as follows:

[0124] List all devices in the system and their current processing logic and properties, analyze the common and characteristic requirements of the devices, and classify the devices according to the common requirements;

[0125] First, you need to have a comprehensive understanding of all the devices in the system. List all devices, including temperature sensors, pressure sensors, humidity sensors, etc., and record the processing logic and properties of each device. These properties may include measurement range, accuracy, response time, sampling frequency, etc. Through in-depth analysis of these devices, identify their common requirements and characteristic requirements. Common requirements refer to requirements shared by all devices, such as data acquisition and status monitoring; characteristic requirements refer to requirements unique to specific devices, such as temperature calibration of temperature sensors, pressure correction of pressure sensors, etc. Then, classify the devices according to common requirements, and group devices with the same or similar common requirements so that these common requirements can be handled uniformly in subsequent steps.

[0126] Extract common requirements between devices, define them as common attributes and behaviors, identify device feature requirements, and refine feature requirements into scalable parameters and configurations;

[0127] After the equipment classification is completed, the common requirements between various types of equipment are extracted and defined as common attributes and behaviors. For example, all sensors need to collect data regularly and upload it to the server, which can be used as a common behavior; all devices need a unique device ID and status identification, which can be used as common attributes. At the same time, identify the characteristic requirements of each device, such as temperature sensors may need to be calibrated regularly, and pressure sensors may need to calibrate the pressure range regularly. These characteristic requirements should not be hard-coded directly into the model, but refined into extensible parameters and configurations, so that they can be dynamically adjusted and expanded through configuration files or parameter settings to adapt to the characteristic requirements of different devices.

[0128] Design a high-level abstract model that includes the common requirements of all devices and supports feature requirements in a parameterized manner to make the model scalable;

[0129] Based on the extracted common requirements and characteristic requirements, design a high-level abstract model. This model should include the common requirements of all devices and define common properties and behaviors. For example, you can design a common device base class (or interface) that includes device ID, status, data acquisition method, etc. At the same time, support characteristic requirements through parameterization. For example, you can determine the sampling frequency and calibration method of a device through parameter configuration. The parameterized design makes the model have good scalability and can be dynamically adjusted according to the characteristic requirements of different devices without modifying the core logic of the model. This design not only simplifies the implementation of the model, but also improves the flexibility and adaptability of the model.

[0130] Refactor existing code, extract common requirements into a high-level abstract model, implement parameterized configuration of feature requirements, and remove specific details and specialization;

[0131] After designing a high-level abstract model, the existing code needs to be refactored. First, extract the common demand logic of each device into the newly designed abstract model so that all devices can share these common logics and avoid repeated implementation. For example, implement common requirements such as data acquisition and status monitoring as methods or properties of the abstract model. Next, implement the characteristic requirements of the device as parameterized configurations through parameter configuration files or dynamic settings, rather than hard-coding these characteristic requirements in the model. For example, the calibration method of the temperature sensor can be specified through a configuration file instead of being specifically implemented in the code. In this way, the characteristic requirements can be flexibly adjusted according to different devices, and the model implementation is also more concise and modular.

[0132] Create configuration files to define the parameters and configurations of different devices. When the system is started or running, dynamically load and initialize the corresponding device model according to the configuration files.

[0133] In order to achieve dynamic configuration and loading, it is necessary to create configuration files to define the parameters and configurations of different devices. These configuration files can use formats such as XML, JSON, or YAML to record the type, parameters, and specific configuration items of each device. For example, the sampling frequency, calibration method, data upload interval, and other parameters of the temperature sensor can be defined in the configuration file. When the system is started or running, write code to read the configuration file and dynamically load and initialize the corresponding device model according to the content in the configuration file. This can be achieved through a reflection mechanism or a dependency injection framework to ensure that the system can dynamically adjust the processing logic and behavior of the device according to actual needs, thereby improving the flexibility and scalability of the system. In this way, new devices can be easily added or the configuration of existing devices can be adjusted without modifying the core code.

[0134] Monitor the dynamic processing of the intermediate business model in real time to ensure that the dynamic processing of the intermediate business model is successful within the specified time, and issue early warning prompts if the dynamic processing fails;

[0135] When the intermediate business model is dynamically processed, the abstract evaluation coefficient generated within each monitoring period T is obtained through the data analysis mechanism, and the abstract evaluation coefficient is compared and analyzed with the abstract evaluation coefficient reference threshold range. If the abstract evaluation coefficient is within the abstract evaluation coefficient reference threshold range within the specified time, a success signal of dynamic processing of the intermediate business model is generated, and the industrial software compatibility continues to be efficiently adapted based on the intermediate business model. If the abstract evaluation coefficient is not within the abstract evaluation coefficient reference threshold range within the specified time, a failure signal of dynamic processing of the intermediate business model is generated, and an early warning prompt is issued for this situation, indicating that the dynamic processing of the intermediate business model cannot reach the expected state and requires human intervention.

[0136] The present invention collects and analyzes the response time of the device during actual operation to preliminarily identify whether there is a hidden danger of improper abstraction level configuration in the intermediate business model. This process can quickly reflect the overall performance and compatibility of the system, help enterprises discover potential problems early, and avoid performance bottlenecks and compatibility problems caused by improper model abstraction level during the adaptation process.

[0137] The present invention timely identifies and classifies abstraction level configuration problems of the intermediate business model through real-time comparison and analysis of abstract evaluation coefficients within the monitoring cycle. For the case of over-abstraction, the intermediate business model is dynamically refined to handle different types of equipment and monitoring requirements separately, and necessary attributes and behavior descriptions are added to ensure that the model can accurately cover the equipment and requirements. For the case of insufficient abstraction, the abstraction level of the model is improved by dynamically reducing the details and specialization of the intermediate business model, so that it can be more widely applied to different types of equipment and requirements. Through this dynamic adjustment mechanism, it is ensured that the intermediate business model is always in an efficient and adaptive state, thereby improving the interoperability and flexibility of the system.

[0138] The present invention ensures that the dynamic processing of the model can be successful within the specified time through real-time monitoring of the dynamic processing process of the intermediate business model, and issues early warning prompts for unsuccessful dynamic processing. It continuously obtains and compares abstract evaluation coefficients through a data analysis mechanism, promptly generates a signal of success or failure of the dynamic processing of the model, and issues an early warning prompt when necessary, indicating that human intervention is required. This real-time monitoring and early warning mechanism not only improves the reliability and accuracy of the model adaptation process, but also significantly reduces the system maintenance cost and workload, so that the equipment monitoring system of the manufacturing enterprise can operate more stably and efficiently.

[0139] The present invention provides Figure 2 An industrial software compatibility adaptation device based on an intermediate business model is shown, comprising the following steps:

[0140] The preliminary hidden danger identification module collects the response time of the actual operation of the equipment between different devices and monitoring systems, reflects the overall performance and compatibility of the system through the response time, and preliminarily identifies whether there are hidden dangers of improper configuration of the abstract level in the intermediate business model;

[0141] The anomaly identification module, when initially identifying the hidden danger of improper configuration of the abstract level of the intermediate business model, obtains the relevant information of the intermediate business model to establish a data analysis mechanism and identify the anomaly of improper configuration of the abstract level of the intermediate business model;

[0142] The abstraction level classification module classifies the improper configuration of the abstraction level of the intermediate business model into over-abstraction or under-abstraction based on the data analysis mechanism;

[0143] The model dynamic processing module dynamically refines the intermediate business model to address over-abstraction, handles different types of equipment and monitoring requirements separately, and adds descriptions of attributes and behaviors. In response to insufficient abstraction, it dynamically reduces the details and specialization within the intermediate business model, improves the model's abstraction level, covers more types of equipment and requirements, and configures efficient intermediate business models for manufacturing enterprises' equipment monitoring systems.

[0144] The real-time monitoring and early warning prompt module monitors the dynamic processing of the intermediate business model in real time to ensure that the dynamic processing of the intermediate business model is successful within the specified time, and issues early warning prompts in the event of unsuccessful dynamic processing;

[0145] An industrial software compatibility adaptation method based on an intermediate business model provided in an embodiment of the present invention is implemented by the above-mentioned industrial software compatibility adaptation device based on an intermediate business model. The specific method and process of an industrial software compatibility adaptation device based on an intermediate business model are detailed in the embodiment of the above-mentioned industrial software compatibility adaptation method based on an intermediate business model, which will not be repeated here.

[0146] The above formulas are all dimensionless and numerical calculations. The formula is a formula for the most recent real situation obtained by collecting a large amount of data and performing software simulation. The preset parameters in the formula are set by technicians in this field according to actual conditions.

[0147] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0148] The above description is only by way of illustration of certain exemplary embodiments of the present invention. It is undoubted that those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the above drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.

Claims

1. An industrial software compatibility adaptation method based on an intermediate business model, characterized in that: The following steps are involved: Collect the response time of the devices during actual operation between different devices and monitoring systems. The response time reflects the overall performance and compatibility of the system, and preliminarily identifies whether there are hidden dangers of improper configuration of the abstract level in the intermediate business model. When the potential risk of improper configuration of the abstraction level of the intermediate business model is initially identified, relevant information of the intermediate business model is obtained to establish a data analysis mechanism to identify abnormalities in the improper configuration of the abstraction level of the intermediate business model; Based on the data analysis mechanism, the improper configuration of the abstraction level of the intermediate business model is classified as over-abstraction or under-abstraction; In order to solve the problem of over-abstraction, the intermediate business model is dynamically refined, different types of equipment and monitoring requirements are processed separately, and the description of attributes and behaviors is increased. In order to solve the problem of insufficient abstraction, the details and specialization in the intermediate business model are dynamically reduced, and the abstraction level of the model is improved to cover more types of equipment and requirements, so as to configure an efficient intermediate business model for the equipment monitoring system of manufacturing enterprises. Monitor the dynamic processing of the intermediate business model in real time to ensure that the dynamic processing of the intermediate business model is successful within the specified time, and issue early warning prompts if the dynamic processing fails; The specific steps to initially identify whether there are inappropriate risks in the model abstraction level are as follows: In the monitoring window, the monitoring system records the response time of each device under different operations, and establishes a data set based on the response time; Calculate the mean response time and the standard deviation of response time through the response time in the data set; The response time mean and response time standard deviation are compared and analyzed with the preset response time reference threshold and standard deviation reference threshold respectively. If the response time mean is less than the shortest time benchmark and the response time standard deviation is less than the standard deviation reference threshold, an efficient response signal is generated. If the response time mean is less than the shortest time benchmark and the response time standard deviation is less than the standard deviation reference threshold, a hidden danger signal is generated. When the intermediate business model generates a hidden danger signal in the compatibility adaptation of industrial software, obtain model-related information to establish a data analysis mechanism, wherein the model-related information includes the data processing information and interface call information of the model. After abnormal analysis and processing of the data processing information and interface call information of the model, generate a data redundancy rate index and an interface call frequency ratio index. By establishing a data analysis mechanism with the data redundancy rate index and the interface call frequency ratio index, generate an abstract evaluation coefficient, and use the abstract evaluation coefficient to identify abnormalities at the model abstraction level. The steps to classify improper configuration of the abstraction level of the intermediate business model as over-abstraction or under-abstraction are as follows: If the abstract evaluation coefficient is greater than the maximum value of the abstract evaluation coefficient reference threshold range, the improper configuration of the abstract level of the intermediate business model is classified as over-abstraction; if the abstract evaluation coefficient is less than the minimum value of the abstract evaluation coefficient reference threshold range, the improper configuration of the abstract level of the intermediate business model is classified as insufficient abstraction.

2. According to claim 1, an industrial software compatibility adaptation method based on an intermediate business model is characterized in that: During the monitoring period T, the abstract evaluation coefficient generated for industrial software compatibility adaptation based on the intermediate business model is compared and analyzed with the pre-set abstract evaluation coefficient reference threshold range. If the abstract evaluation coefficient is not within the abstract evaluation coefficient reference threshold range, an abnormal signal is generated, indicating that the intermediate business model has an abnormality of improper abstract level configuration. If the abstract evaluation coefficient is within the abstract evaluation coefficient reference threshold range, a normal signal is generated, indicating that the abstract level configuration of the intermediate business model is efficient.

3. The industrial software compatibility adaptation method based on the intermediate business model according to claim 1 is characterized in that: By dynamically refining the model, different types of equipment and monitoring requirements are handled separately, and descriptions of attributes and behaviors are added. The specific steps are as follows: Classify the devices in the system, identify different types of devices, analyze the monitoring requirements of each device, and clarify the specific attributes and behaviors required for each device; Define specific properties for each device type and define specific behaviors for each device type; Separate the processing logic of different device types into independent modules, define a unified interface for each module, and ensure seamless integration and replacement between modules; According to the modular design, develop processing modules for each device type, write unit test cases for each module to verify its functions and performance, and perform integration tests in the system environment to ensure that the modules work together; Use configuration files to define the processing logic and parameters of different devices. When the system is started or running, dynamically load and initialize the corresponding device modules according to the configuration files. Create one or more configuration files, list all devices and their corresponding modules and parameter settings, write code to load the configuration, read the configuration files when the system starts, and dynamically load the corresponding modules according to the configuration.

4. The industrial software compatibility adaptation method based on the intermediate business model according to claim 1 is characterized in that: To address the lack of abstraction, dynamically reduce the details and specialization in the model, and improve the model's abstraction level to cover more types of devices and requirements. The specific steps are as follows: List all devices in the system and their current processing logic and properties, analyze the common and characteristic requirements of the devices, and classify the devices according to the common requirements; Extract common requirements between devices, define them as common attributes and behaviors, identify device feature requirements, and refine feature requirements into scalable parameters and configurations; Design a high-level abstract model that includes the common requirements of all devices and supports feature requirements in a parameterized manner to make the model scalable; Refactor existing code, extract common requirements into a high-level abstract model, implement parameterized configuration of feature requirements, and remove specific details and specialization; Create configuration files to define the parameters and configurations of different devices. When the system starts or runs, dynamically load and initialize the corresponding device models according to the configuration files.

5. The industrial software compatibility adaptation method based on the intermediate business model according to claim 1 is characterized in that: When the intermediate business model is dynamically processed, the abstract evaluation coefficient generated within each monitoring period T is obtained through the data analysis mechanism, and the abstract evaluation coefficient is compared and analyzed with the abstract evaluation coefficient reference threshold range. If the abstract evaluation coefficient is within the abstract evaluation coefficient reference threshold range within the specified time, a success signal of dynamic processing of the intermediate business model is generated, and the industrial software compatibility continues to be efficiently adapted based on the intermediate business model. If the abstract evaluation coefficient is not within the abstract evaluation coefficient reference threshold range within the specified time, a failure signal of dynamic processing of the intermediate business model is generated, and an early warning prompt is issued for this situation, indicating that the dynamic processing of the intermediate business model cannot reach the expected state and requires human intervention.

6. The industrial software compatibility adaptation method based on the intermediate business model according to claim 1 is characterized in that: The specific steps of obtaining the data processing information of the model and generating the data redundancy rate index after performing anomaly analysis based on the data processing information are as follows: During the monitoring period T, data processing information of each device is collected, including: Total data volume D total : The total amount of data generated by all devices in the monitoring period T; Unique data volume D unique : The amount of non-repetitive data generated by all devices within the monitoring period T; Number of devices N: the total number of devices in the system; Calculate the data redundancy rate. The calculation expression is: Calculate the data redundancy index. The calculation expression is: In the formula, R l represents the data redundancy rate generated by device i in period T, represents the total amount of data generated by device i in period T, D unique，i represents the amount of non-repetitive data generated by device i in period T, Red Ra Represents the data redundancy index.

7. The industrial software compatibility adaptation method based on the intermediate business model according to claim 1 is characterized in that: The specific steps for obtaining the model's interface call count information and generating an interface call count ratio index after performing anomaly analysis based on the interface call count information are as follows: Collect interface call data, including: Record the total number of calls C total : In the monitoring period T, record the total number of calls of all interfaces in the system; Record the number of general interface calls C common : Record the number of calls of all common interfaces within the monitoring period T; Calculate the proportion of interface calls. The proportion of interface calls is the proportion of general interface calls in all interface calls. The specific calculation formula is: Where P represents the proportion of interface calls; Calculate the interface call frequency ratio index, the calculation expression is: log(C total +1) is the logarithm of the total number of calls, which is used to reflect the scale of the call volume, σ C is the standard deviation of the number of calls to different types of interfaces, C τ is the average number of calls to different types of interfaces, Int fa Indicates the proportion index of interface call times.

8. An industrial software compatibility adaptation device based on an intermediate business model, implemented by an industrial software compatibility adaptation method based on an intermediate business model as described in any one of claims 1 to 7, characterized in that: The following steps are involved: The preliminary hidden danger identification module collects the response time of the actual operation of the equipment between different devices and monitoring systems, reflects the overall performance and compatibility of the system through the response time, and preliminarily identifies whether there are hidden dangers of improper configuration of the abstract level in the intermediate business model; The anomaly identification module, when initially identifying the hidden danger of improper configuration of the abstract level of the intermediate business model, obtains the relevant information of the intermediate business model to establish a data analysis mechanism and identify the anomaly of improper configuration of the abstract level of the intermediate business model; The abstraction level classification module classifies the improper configuration of the abstraction level of the intermediate business model into over-abstraction or under-abstraction based on the data analysis mechanism; The model dynamic processing module dynamically refines the intermediate business model to address over-abstraction, handles different types of equipment and monitoring requirements separately, and adds descriptions of attributes and behaviors. In response to insufficient abstraction, it dynamically reduces the details and specialization within the intermediate business model, improves the model's abstraction level, covers more types of equipment and requirements, and configures efficient intermediate business models for manufacturing enterprises' equipment monitoring systems. The real-time monitoring and early warning prompt module monitors the dynamic processing of the intermediate business model in real time to ensure that the dynamic processing of the intermediate business model is successful within the specified time, and issues early warning prompts in the event of unsuccessful dynamic processing.

Images