An agent-oriented physical world object ontology modeling and cross-domain association method

Abstract

The application discloses a kind of physical world object ontology modeling and cross-domain association method for intelligent agent, belong to industrial software and intelligent agent system technical field.The information of existing business system is organized with technical intermediate object such as database table, report index, which leads to the problem that intelligent agent is difficult to distinguish real business object from statistical snapshot, cannot understand cross-domain semantic relationship, the physical object, business object, event object, fact object and governance object in the business system are identified as ontology node in the application, the business domain is divided, and the cross-domain reference of source domain mark is used for cross-domain object;Direction, type and operation name are defined for object relationship, wherein the type includes link indicating static attribution, function indicating analysis and calculation and action indicating state action;Statistical granularity is carried by the attribute of fact object instead of creating virtual object;After model verification, object graph can be output for intelligent agent to traverse, call and reason.The application enables intelligent agent to analyze forward and trace back, supports cross-domain association and explainable reasoning of complex business system in shipbuilding, energy management and other fields.

Description

Technical Field

[0001] This invention relates to the fields of enterprise information systems, industrial software, knowledge modeling, ontology modeling, intelligent agent systems, data governance, and complex business system modeling, and in particular to a method for physical world object ontology modeling and cross-domain association for intelligent agents.

[0002] The physical world objects described in this invention refer to objects that have clear business meaning in the business site or during business operations, can be understood by business personnel, and can form states, events, facts, or responsibility relationships. These include, but are not limited to, equipment, spaces, organizations, personnel, work teams, products, structural components, processes, tasks, work packages, resources, materials, technical documents, metering points, energy media, production events, energy consumption facts, quality events, risks, blockages, and handling actions. The ontology world model described in this invention refers to a business world expression model composed of the aforementioned objects, object attributes, object behaviors, cross-domain reference relationships, and directed semantic relationships.

[0003] With the application of large language models and intelligent agent technology in enterprise information systems, intelligent agents need to understand objects, relationships, facts, and actions within business systems, and based on this, perform problem analysis, plan generation, anomaly detection, root cause tracing, and remediation recommendations. However, traditional business systems typically organize information around database tables, menus, reports, metrics, process configurations, or interface fields, a method that is not intuitive for both human business users and intelligent agents. Especially in complex business scenarios such as shipbuilding, equipment manufacturing, energy management, production planning, equipment operation and maintenance, quality management, and supply chain management, there are numerous cross-domain relationships between objects from different domains, making it difficult to express the semantic paths between real business objects using only data table structures or ordinary entity relationship diagrams.

[0004] Therefore, this invention proposes a physical world object ontology modeling and cross-domain association method for intelligent agents, enabling business systems to model with real objects, event objects, fact objects, and disposal objects as the core, and to express the attribution, computation, triggering, disposal, and reverse tracing relationships between objects through cross-domain references and directional semantic relationships, thereby providing intelligent agents with an understandable, traversable, and reasonable business world model. Background Technology

[0005] Existing business system modeling methods Existing enterprise information systems typically organize business data using database tables, business menus, process nodes, report indicators, configuration items, or interface fields. For example, a manufacturing execution system may contain production plan tables, work task tables, work reports, material requirements tables, equipment ledgers, personnel shift tables, and exception record tables; an energy management system may contain data collection point tables, raw reading tables, hourly energy consumption tables, daily reports, cost statistics tables, and alarm event tables; and a shipbuilding system may contain various business records such as ship number, section, assembly, compartment, system, process route, work plan, work package, pallet, drawings, resource allocation, and congestion risk.

[0006] The above methods are suitable for transaction processing and data storage, but not naturally suitable for intelligent agent understanding. Database tables are usually divided according to system implementation or data source, and table names and field names contain many traces of technical implementation; menus and pages are organized according to user operation habits and cannot reflect the real business relationships between objects; reports and indicators are usually the result of aggregating multiple objects, multiple time windows, or multiple metrics, and cannot be directly understood as real objects in the physical world; process configuration emphasizes the order of operations and does not necessarily express the static ownership, dynamic facts, and business responsibility relationships between objects.

[0007] The shortcomings of ordinary knowledge graphs or triple modeling Knowledge graphs can express some business semantics through entities, relationships, and attributes, but ordinary triple modeling still has shortcomings in complex industrial software scenarios. First, ordinary triple relationships often only express static relationships such as "related," "belongs to," and "contains," making it difficult to distinguish static links, computational functions, business actions, and governance loops between objects. Second, nodes in ordinary knowledge graphs are prone to mixing in non-physical world objects such as indicators, snapshots, reports, query results, and technical intermediate tables, resulting in nodes in the model containing both real objects and derived statistical results. During reasoning, it is difficult for the agent to distinguish which objects can be used as business responsibility objects and which objects are just temporary views or statistical definitions. Third, if cross-domain objects are repeatedly modeled in multiple domains, it will cause semantic inconsistencies and path breaks. For example, the same "work task" may appear in the planning domain, resource domain, material domain, and risk domain. Without a cross-domain reference mechanism, it is difficult for the agent to determine whether these objects are the same business object.

[0008] Problems faced by intelligent agents in integrating into complex business systems The intelligent agent needs to automatically select relevant objects based on user questions, understand object relationships, call system functions, combine analysis paths, and generate interpretations. If the business system only provides the intelligent agent with table structures, interface descriptions, report names, or ordinary knowledge graphs, the agent is prone to the following problems: 1. Mistaking statistical indicators, report snapshots, or temporary query results for real business objects; 2. Unable to distinguish whether the relationship between objects is a static attribution relationship, a computational analysis relationship, or a state change action; 3. Unable to perform reliable forward analysis and reverse tracing based on the direction of the relationship; 4. Unable to identify the source domain and business responsibility boundaries of cross-domain referenced objects; 5. It is difficult to trace the abnormal results back to the true cause, such as equipment, personnel, work group, materials, documents, tasks, space, processes, metering points, or factual events; 6. It is difficult to explain the reasoning path to business personnel, resulting in the lack of verifiability and business credibility of the suggestions generated by the agent.

[0009] Typical problems in complex industrial scenarios Taking production planning management in a shipbuilding post-production manufacturing execution system as an example, its business objects include not only production plans, work plans, work tasks, and work packages, but also ship product structural units, shipboard areas or compartments, ship systems, process routes, procedures, operational condition requirements, personnel teams, manufacturing equipment, tooling resources, site work areas, material requirements, nesting or palletizing, technical document versions, issuance and receipt records, constraints, blockages, risks, on-site anomalies, and handling actions. These objects span multiple areas including products, space, processes, plans, resources, materials, documents, and governance, and each type of object can potentially affect whether a task can be started, whether it can be assigned, whether it can be reported, and whether there is a risk of plan delays.

[0010] Taking energy management systems as another example, energy consumption anomalies are not isolated indicators. An energy consumption anomaly typically needs to be traced back to various entities such as energy medium, metering points, equipment assets, production lines, shifts, shift schedules, number of workers, production events, product work orders, time-of-use energy consumption facts, energy-saving opportunities, and countermeasures. If only hourly, daily, and monthly energy consumption statistics are used as nodes, the intelligent agent can see numerical changes, but it is difficult to understand the real-world chain behind the numbers.

[0011] Therefore, a new modeling approach is needed to enable business systems to focus on real-world objects and express the connections between different objects using cross-domain references and relationships with direction, type, and operational semantics, thereby supporting agents in understanding, analyzing, and tracing origins. Summary of the Invention

[0012] The technical problems to be solved by this invention include: 1. How to identify real physical objects, business objects, organizational objects, event objects, and fact objects from complex business systems, and use them as the basic nodes of the ontology world model; 2. How to avoid mistakenly modeling statistical snapshots, virtual indicators, temporary reports, technical intermediate tables, interface caches, or algorithm output results as ontology objects; 3. How to divide objects according to business domains while maintaining consistent references and semantics across objects in different business domains; 4. How to assign direction, relationship type, and operation name to relationships between objects so that the agent can understand the business meaning of the relationship; 5. How to distinguish between static link relationships, analytical calculation relationships, and business action relationships that change state between objects; 6. How to express statistical time granularity, object scope, and measurement attributes through fact objects, instead of creating separate virtual objects for different statistical calibers; 7. How to enable intelligent agents to perform positive analysis, anomaly detection, reverse tracing, and generate handling suggestions based on the above ontology world model; 8. How can this method be made applicable not only to complex industrial scenarios such as shipbuilding and equipment manufacturing, but also to other business systems such as energy management, equipment management, quality management, and supply chain management?

[0013] Overall technical solution This invention provides a method for physical world object ontology modeling and cross-domain association for intelligent agents. The method first identifies real objects, events, and facts from the business system and categorizes them into several business domains. Then, it expresses objects appearing across domains using cross-domain references to avoid redundant modeling. Next, it establishes semantic relationships between objects with direction, relationship type, and operation name, where the relationship type includes at least link, function, and action. Finally, it excludes virtual statistical objects and technical intermediate objects through model validation rules, forming an ontology world model that can be traversed, invoked, and reasoned about by intelligent agents.

[0014] The overall process of this invention is as follows: Figure 1 As shown. Attached Figure Description

[0015] Figure 1 This is a flowchart for modeling the ontology world model for intelligent agents.

[0016] Figure 2 It is a schematic diagram of physical world objects, cross-domain references, and semantic relationship structures.

[0017] Figure 3 This is a diagram illustrating the cross-domain object relationships in the MES production planning management system after shipbuilding.

[0018] Figure 4 This is a schematic diagram of an auxiliary implementation of reverse tracing of EMS energy consumption anomalies.

[0019] Business object identification method In one implementation, business object identification includes the following steps: 1. Obtain the target business system's business processes, data dictionary, user interface, interface specifications, report metrics, business rules, and on-site business data; 2. Extract candidate objects from the above information; 3. Determine whether the candidate object corresponds to a real physical object, business object, organizational object, event object, fact object, or governance object; 4. If the candidate object is only a statistical snapshot, temporary report, virtual indicator, cache table, interface intermediate table, technical pipeline or algorithm intermediate result, then it will not be regarded as an ontology object; 5. Define the object name, object type, core attributes, readable functions, and executable business actions for the retained objects.

[0020] Among them, real physical objects include equipment, space, production lines, ship structures, installation locations, energy media, metering points, etc.; business objects include products, process routes, work tasks, work packages, material requirements, technical documents, work orders, shift schedules, etc.; organizational objects include departments, personnel, teams, positions, resource capabilities, etc.; event objects include schedule events, production events, status events, quality events, alarm events, etc.; factual objects include time-of-use energy consumption facts, worker count records, resource allocation facts, receipt records, etc.; governance objects include blockages, risks, on-site anomalies, decisions, handling actions, and countermeasures, etc.

[0021] Business domain division method In one implementation, objects in the business system are divided into multiple business domains, each with clear object boundaries and primary responsibility semantics. Business domains can be divided based on the natural division of labor in the business context, object lifecycle, responsibility attribution, and analysis path, rather than mechanically based on database tables, menus, or existing system modules.

[0022] For example, in a ship's post-ship manufacturing execution system, it can be divided into: 1. Ship Products and Configuration Domain; 2. Spatial and System Domains; 3. Technology and Construction Methods Domain; 4. Planning and Operations Execution Domain; 5. Resource and Capability Domains; 6. Materials and Technical Documentation Field; 7. Problem, Risk, and Governance Domain.

[0023] For example, in an energy management system, it can be divided into: 1. Factory area organization and spatial domain; 2. Energy media and metering network domain; 3. Collection logs and data quality domains; 4. Organize personnel and work groups; 5. Production process and shift history; 6. Equipment Assets and Operating Status Domain; 7. Energy consumption statistics and time-sharing fact domain; 8. Cost, carbon emissions, and peak / valley areas; 9. Energy efficiency, regression, and energy conservation exploration domain; 10. Alarms, Security, Countermeasures and Governance Domain.

[0024] Cross-domain reference modeling methods In complex business systems, the same object is often referenced by multiple business domains. For example, a work task belongs to the planning and execution domain, but is also referenced by the resource and capability domain, the material and technical document domain, and the problem, risk, and governance domain; a production line belongs to the spatial organization domain, but is also referenced by the metering network domain, the production domain, and the energy efficiency domain. If the same object is repeatedly modeled in each domain, it will lead to inconsistent object definitions, broken relationships, and incorrect inference paths for the agent.

[0025] Therefore, this invention employs a cross-domain referencing approach to represent cross-domain objects. The referenced object is displayed as a node within the current domain, but retains its source domain identifier. The current domain can define the object's relationship from the current analysis perspective, but does not change the object's primary domain of responsibility. In this way, the agent can distinguish between the "source of the object's definition" and the "object's role in the current domain," thereby avoiding redundant modeling.

[0026] The cross-domain reference structure of this invention is as follows: Figure 2 As shown. Directed semantic relation modeling methods This invention defines at least three fields for each object relationship: relationship direction, relationship type, and operation name. The relationship direction is determined by the starting and ending objects; the relationship type describes the semantic category of the relationship; and the operation name describes the business semantics of the relationship, which can be recognized or invoked by an agent in the system.

[0027] In one implementation, the relationship types include: 1. `link`: Represents static linking, attribution, referencing, spatial, organizational, or responsibility relationships between objects. For example, a department links to a work group, a work group links to a production line, and a work task links to a product structural unit.

[0028] 2. Function: Represents an analytical, computational, data collection, aggregation, identification, or interpretation relationship from one object to another. For example, a metering point function generates time-of-use energy consumption facts, a shift scheduling function aggregates energy consumption for shifts within a shift, and a time-of-use energy consumption fact function identifies shift anomalies.

[0029] 3. Action: Represents an action relationship that triggers a state change, creates a business object, or forms a governance loop. For example, the energy-saving opportunity action creates countermeasures, the work package action issues work instructions, and the blocking action triggers a disposal action.

[0030] Through the aforementioned relationship types, the intelligent agent can automatically select the traversal path based on the user's question. For example, when a user asks "Why can't a certain task start?", the intelligent agent can search for resources, materials, and document conditions along the link relationship from the task to the operational requirements, and then locate the blockage, risk, and handling action along the function or action relationship. When a user asks "Why is the energy consumption of a certain shift's night shift too high?", the intelligent agent can start from the time-of-use energy consumption facts and trace back to the shift schedule, production line, shift, output events, number of workers, equipment status, and energy-saving opportunities.

[0031] Methods for Fact Objects to Carry Statistical Dimensions This invention does not use derived statistical results such as hourly, daily, monthly, ranking snapshots, and comparison snapshots as ontology objects. For scenarios requiring the expression of statistical scope, this invention uses fact objects to carry statistical dimensions. For example, in an energy management system, a time-of-use energy consumption fact object is set up, whose attributes include fact identifier, metering point identifier, energy medium identifier, object scope identifier, object scope type, cycle start time, cycle end time, cycle granularity, usage, and quality status. The cycle granularity can be hourly, daily, weekly, monthly, shift, or billing cycle, etc.

[0032] In this way, statistical results can still be queried and analyzed without compromising the realism of the ontology object model. An agent can interpret the statistical results as the fact that a real object was formed within a certain time window, rather than mistaking an "hourly statistics table" or "monthly snapshot" for a physical world object.

[0033] Model validation methods To ensure that the ontology world model can be stably understood by the intelligent agent, this invention also includes a model verification step. The model verification rules include at least: 1. Each node must have an object name, object type, core attributes, readable functions, and executable business actions; 2. Each edge must have a starting object, an ending object, a relation type, and an operation name; 3. Cross-domain references to nodes must be marked with their source domain; 4. It is prohibited to use statistical snapshots, virtual indicators, temporary reports, interface caches, technical pipelines, and intermediate algorithm results as ontology objects; 5. When the same business object appears in multiple domains, it should be treated as a cross-domain reference except in the primary domain. 6. Facts must be traceable to their scope, time window, and data source; 7. Action type relationships should point to objects that will cause state changes, business object creation, or governance closure. 8. The function type relation should point to an object that can produce calculations, collect data, aggregate results, identify results, or interpret results.

[0034] Output methods for intelligent agents The ontology world model formed by this invention can be output as an object graph, structured JSON, graph database structure, semantic index, or tool description for intelligent agents to call. Each object node can provide an object definition, a list of attributes, readable functions, executable actions, and relationships. Each relationship can provide the relationship direction, relationship type, operation name, and descriptive text. After receiving a user's question, the intelligent agent can first identify the object type involved in the question, then select relevant subgraphs based on the object graph, and reason along link, function, and action relationships.

[0035] Effects and advantages of this invention

[0036] Compared with the prior art, the present invention has at least the following beneficial effects:

[0037] Improve the ability of business models to express the physical world This invention uses real physical objects, business objects, organizational objects, event objects, fact objects, and governance objects as ontology nodes, making the model closer to the business environment and avoiding mistaking database tables, reports, metrics, and technical intermediate objects as business world objects.

[0038] Enhance the agent's ability to understand business systems Each relationship has a direction, relationship type, and operation name, enabling the agent to distinguish between static attribution, computational analysis, and state change actions, thereby more accurately understanding the business meaning between objects.

[0039] Support cross-domain consistent modeling Cross-domain references allow the same object to be referenced in multiple business domains without being redefined, thus avoiding semantic conflicts and cross-domain path breaks.

[0040] Supports forward analysis and reverse tracing Intelligent agents can start from objects such as planned tasks, energy consumption facts, risk events, resource arrangements, and material shortages, and perform forward analysis along directed relationships. They can also trace back from abnormal results to the cause and responsible objects.

[0041] Lowering the barrier for business personnel to understand the model The model nodes of this invention are all real objects that business personnel can understand, avoiding the use of database tables, interface fields or intermediate algorithm results as the main expression, so that business personnel can participate in model review and business creation.

[0042] Enhancing the scalability of complex industrial software This invention is applicable not only to complex industrial systems such as shipbuilding and equipment manufacturing, but also to other complex business systems such as energy management, equipment management, quality management, supply chain management, and project management. Detailed Implementation

[0043] The technical solution of the present invention will now be described in detail with reference to the accompanying drawings. It should be understood that the following embodiments are only used to illustrate the technical solution of the present invention and are not intended to limit the scope of protection of the present invention.

[0044] Implement boundary conditions In one embodiment, implementing the present invention requires satisfying the following boundary conditions: 1 The target business system can provide at least one of the following: business objects, business processes, data dictionary, interface specifications, or on-site business documentation. 2 Candidate objects can be classified as real objects, event objects, fact objects, governance objects, or non-ontology objects. 3 Each business domain has a clearly defined set of responsible entities. 4 When the same object appears across multiple domains, its primary domain of responsibility should be identifiable. 5 Each object relationship must have at least a direction, a relationship type, and an operation name. 6 Statistical dimensions are expressed through the attributes of fact objects, rather than through newly added virtual statistical objects. 7 Intelligent agents can read objects, attributes, functions, actions, and relational structures. 8 The model output should support both human review and machine parsing. Detailed implementation steps Obtain business information The system acquires business data from the target business system. This data may include database table structures, business process diagrams, a glossary of business terms, interface documentation, report lists, business rules, page descriptions, historical issue logs, on-site operating procedures, and expert interview content. The system can also acquire object configurations and historical business data from existing systems.

[0045] Generate a set of candidate objects The system extracts candidate objects from business data. Candidate objects can be generated through manual annotation, rule parsing, natural language processing, or agent-assisted extraction. The names of candidate objects can include "work task", "work package", "production plan", "material requirements", "technical document version", "resource allocation", "time-of-use energy consumption facts", etc.

[0046] Determine the object type of the candidate objects The system performs type determination for each candidate object. The determination rules include: 1. If a candidate object represents equipment, space, structure, product, personnel, work team, material, document, or location existing at the business site, it is determined to be a physical object or a business object; 2. If a candidate object represents a factual record that occurred at a certain point in time or within a certain time period, it is determined to be an event object or a factual object; 3. If the candidate represents organizational responsibility, resource capabilities, personnel positions, or team member relationships, it is determined to be an organizational target; 4. If a candidate object represents a blockage, risk, anomaly, decision, countermeasure, or handling action, it is determined to be a governance object; 5. If the candidate object only represents a report, indicator, ranking, snapshot, cache, intermediate result of interface or temporary query result, it will not be included in the ontology object collection.

[0047] Divide business domains and determine primary responsibility domains The system categorizes objects into multiple business domains based on their lifecycle, business responsibility, analysis path, and on-site business division of labor. Each object has a primary responsibility domain. If an object is referenced in another domain, a cross-domain reference node is created in that domain, and the source domain is recorded.

[0048] Create object properties, functions, and actions. The system establishes core attributes, readable functions, and executable actions for each object. Core attributes describe the object's identity and state; readable functions are used to query, calculate, aggregate, or analyze object information; and executable actions trigger changes in the object's state or close business loops. For example, a work task may have attributes such as task code, target object, planned start time, planned end time, and current state; its readable functions may include start-up status, critical path, and planned deviation; and its actions may include adjusting the task and reporting progress.

[0049] Establish directed semantic relations The system establishes directed relationships based on the business meaning between objects and labels each relationship with a link, function, or action type. For example: Work tasks Operating conditions requirements link readinessRequirements The work task requires certain conditions to commence. Operating conditions requirements Resource allocation link requiredResources Conditions and requirements need to be met by resource allocation Material Requirements Nesting / Pallet function groupKitForTask Material requirements form kits or pallets block Disposal Action action createCorrectiveAction Blocking triggers response action Time-of-use energy consumption facts Energy saving opportunities function detectTeamShiftEnergyAnomaly Time-of-use energy consumption fact identification: abnormal shifts in work groups Energy saving opportunities countermeasures action createTeamEnergyCountermeasure Energy-saving opportunities: Creating work team energy consumption strategies Perform model validation The system performs model validation. If a relationship is found to be missing direction, type, or operation name, a prompt will be given to supplement it; if a cross-domain object is found to be unmarked as having a source domain, a prompt will be given to correct it; if a statistical snapshot, dummy indicator, or technical intermediate table is found to be built as an object, a prompt will be given to remove it and change it to an attribute or readable function of the fact object; if the same object is found to be defined repeatedly in multiple domains, a prompt will be given to change it to a cross-domain reference.

[0050] Output ontology world model that the intelligent agent can use The system outputs the validated model to the agent. The output includes a list of objects, object attributes, object functions, object actions, a list of relationships, cross-domain reference markers, a business domain description, and the model validation results. After receiving the user's question, the agent can generate an analysis path based on the object graph and invoke object functions or actions as necessary.

[0051] Example 1: Post-shipbuilding MES production planning management Post-shipbuilding MES production planning management is a primary embodiment of this invention. Post-shipbuilding production planning management involves multiple areas such as product structure, spatial systems, process routes, planned tasks, work packages, resource allocation, material pallets, technical documents, congestion risks, and handling actions. There are complex cross-domain relationships between business objects, making it suitable for demonstrating the technical value of this invention.

[0052] In this embodiment, the system divides the objects into seven business domains: 1. Ship Products and Configuration Domain, including ships, product structural units, controlled objects, controlled versions, and engineering changes; 2. Spatial and system domains, including spatial locations, shipboard areas or compartments, ship systems, system components, and installation locations; 3. The technology and construction methodology domain includes construction phases, construction strategies, process routes, procedures, steps, and work release points; 4. Planning and execution domain, including production planning, work planning, work tasks, work packages, work condition requirements, work instructions, and schedule events; 5. Resource and capability domains, including organizational units, personnel or work groups, manufacturing equipment, tooling resources, work areas, resource capabilities, resource calendars, and resource allocation; 6. Materials and Technical Documentation Field, including installation materials or equipment parts, material requirements, kits or pallets, technical documents, technical document versions, and issuance and receipt records; 7. Problem, risk and governance domain, including constraints, blockages, risks, on-site anomalies, decision-making, handling actions, action logs and source lineage.

[0053] In a specific scenario, when an agent receives a user's question, "Why can't a certain task start?", the system can analyze it according to the following path: 1. Starting from the task object, read its target object, plan window, and current status; 2. Trace along the link relationship to the product structural unit, spatial or system object, process route, and operation; 3. Locate the job requirements corresponding to this task by following the link relationship; 4. Based on the operational requirements, locate the resource allocation, material requirements, nesting or palletizing, technical document versions, and previous release points; 5. If resources are insufficient, further investigate resource capacity, personnel teams, manufacturing equipment, tooling resources, and work areas. 6. If materials or documents are incomplete, trace the material requirements, pallet shipment status, receipt records, and technical document versions and validity status. 7. If there is a blockage or risk, trace the blockage, risk, on-site anomaly, decision-making, and handling actions; 8. Output the reasons why work cannot start, the responsible parties, the scope of impact, and suggested actions.

[0054] In this embodiment, work tasks are defined in the planning and execution domain and appear as cross-domain references in the resource and capability domain, material and technical document domain, and problem, risk, and governance domain. Technical document versions, nesting or palletizing, resource arrangements, and blockages are all real objects that business personnel can understand, rather than temporary query results or report metrics. Therefore, the agent can explain the analysis path to business personnel.

[0055] The cross-domain object relationship in this embodiment is as follows: Figure 3 As shown.

[0056] Example 2: EMS Energy Management System The EMS energy management system is an auxiliary embodiment of the present invention, used to illustrate that the present invention is also applicable to energy management scenarios.

[0057] In this embodiment, the system divides the objects into multiple business domains, including the plant organization and spatial domain, energy medium and metering network domain, data collection log and data quality domain, personnel organization and work group domain, production process and shift history domain, equipment assets and operating status domain, energy consumption statistics and time-of-use data domain, cost carbon emission and peak and valley domain, energy efficiency regression and energy saving exploration domain, and alarm safety countermeasures and governance domain.

[0058] The system treats "time-of-use energy consumption facts" as fact objects, rather than creating separate virtual objects such as hourly, daily, and monthly energy consumption snapshots. Time-of-use energy consumption facts are expressed by the periodGrain property (hour, day, week, month, shift, or billing cycle), the scope of the object is expressed by scopeObjectId and scopeObjectType, and the time window is expressed by periodStart and periodEnd.

[0059] In a specific scenario, the agent receives a user question: "Why is the energy consumption per unit output higher on a certain production line during the night shift?" The system can analyze it according to the following path: 1. Starting from the actual objects of time-of-use energy consumption, determine the time granularity, energy medium, object scope, and energy consumption quantity; 2. Trace along the link relationship to metering points, energy media, production lines, and equipment assets; 3. Calculate the energy consumption per unit output by combining the output events along the function relationship; 4. Locate shift calendars and shift schedules along the link relationships; 5. Locate the number of workers along the function relationship and calculate the average energy consumption per worker; 6. Identify abnormal energy consumption or equipment status in work groups / shifts by following the function relationship; 7. Create energy-saving opportunities, countermeasures, or governance tasks along the action relationship.

[0060] In this embodiment, shift schedules, worker count records, production events, equipment status events, and time-of-use energy consumption data are all real business or factual objects. The intelligent agent can trace back from energy consumption anomalies to production lines, equipment, shifts, work groups, output, and countermeasures, rather than simply seeing abnormal values ​​in statistical tables.

[0061] The reverse tracing link in this embodiment is as follows: Figure 4 As shown.

[0062] Optional embodiments and extensions This invention can also be applied to business systems such as MES, ERP, PLM, EAM, QMS, SCM, project management, asset management, equipment operation and maintenance, quality traceability, supply chain collaboration, engineering construction, and park operation. Different systems can be divided into different business domains according to their business objects, but all can adopt real object identification, cross-domain reference, link / function / action relationship, fact object statistical dimensions, and model validation rules.

[0063] In optional embodiments, the present invention can also be combined with graph databases, vector databases, large language model tool invocation frameworks, business rule engines, and low-code platforms. Graph databases are used to store objects and relationships; vector databases are used to retrieve object descriptions and business documents; large language models are used to identify user questions and generate analysis paths; business rule engines are used to perform model validation; and low-code platforms are used to create business pages, processes, and reports based on ontology objects.

Claims

1. A method for physical world object ontology modeling and cross-domain association for intelligent agents, characterized in that, The method is executed by a computing device and includes: Obtain business data from the target business system, including at least one of the following: business processes, data dictionary, user interface, interface description, report indicators, business rules, and on-site business data. Extract a set of candidate objects based on the aforementioned business data; The candidate objects in the candidate object set are judged by object type. Candidate objects that are judged to be physical objects, business objects, organizational objects, event objects, fact objects or governance objects are retained to form an ontology object set, and candidate objects that are judged to be statistical snapshots, virtual indicators, temporary reports, interface caches, technical intermediate tables or algorithm intermediate results are excluded. Based on the business responsibilities, lifecycles, analysis paths, or business site divisions of each object in the ontology object set, the ontology object set is divided into multiple business domains, and a primary responsibility domain is determined for each ontology object. When an ontology object appears in a non-responsible domain, a cross-domain reference node for the ontology object is generated in the non-responsible domain, and the source domain identifier and source object identifier are recorded for the cross-domain reference node. Establish object description information for the ontology objects in the ontology object collection. The object description information includes object name, object type, core attributes, readable functions, and executable actions. A directed semantic relationship is established within and between the multiple business domains. The directed semantic relationship includes a starting object, an ending object, a relationship type, and an operation name. The relationship type includes at least a link representing a static link relationship, a function representing an analysis and calculation relationship, and an action representing a state change or governance closed-loop action relationship. Statistical dimensions are expressed through the time granularity of fact objects, object scope, period start time, period end time, and metric attributes. According to the preset model verification rules, the ontology object set, the cross-domain reference node, the object description information, the directed semantic relationship and the fact object are verified. After successful verification, an ontology world model for the intelligent agent is output. The ontology world model includes ontology objects, object description information, cross-domain reference nodes, and directed semantic relationships, enabling the intelligent agent to perform object traversal, function calls, action recognition, forward analysis, or reverse tracing based on the ontology world model.

2. The method according to claim 1, characterized in that, The step of determining the object type of the candidate objects in the candidate object set includes: When a candidate object represents equipment, space, structure, product, personnel, work group, material, document, or location existing at the business site, the candidate object is determined to be a physical object or a business object. When a candidate object represents a business record that occurred at a point in time or within a time period, the candidate object is determined to be an event object or a fact object. When a candidate object represents organizational responsibility, resource capabilities, personnel positions, or member relationships, the candidate object is determined to be an organizational object; When a candidate object represents a constraint, blockage, risk, on-site anomaly, decision, countermeasure, or handling action, the candidate object is determined to be a governance object.

3. The method according to claim 1, characterized in that, The exclusion of candidate objects identified as statistical snapshots, virtual indicators, temporary reports, interface caches, technical intermediate tables, or algorithm intermediate results includes: When a candidate object only represents a statistical result formed by the aggregation of one or more ontology objects under a statistical caliber, the candidate object is not considered an ontology object; When a candidate object only represents data transmission, data caching, interface adaptation, batch processing pipeline, or temporary query results, the candidate object will not be used as an ontology object. The statistical results can be expressed as attributes of fact objects, readable functions of fact objects, or views generated based on fact objects.

4. The method according to claim 1, characterized in that, The multiple business domains include at least two or more of the following: Product and Configuration Domain, Space and System Domain, Process and Method Domain, Planning and Operation Execution Domain, Resources and Capabilities Domain, Materials and Documents Domain, Problem, Risk and Governance Domain, Organization, Personnel and Team Domain, Metering Network Domain, Equipment Asset Domain, Time-of-Use Facts Domain, Energy Efficiency Analysis Domain.

5. The method according to claim 1, characterized in that, The cross-domain reference nodes include: Reference node identifier, source object identifier, source domain identifier, current domain identifier, reference role, set of reference attributes, and set of reference relationships; The reference relationship set is used to record the directed semantic relationships in which the cross-domain reference node participates in the current domain, without changing the object definition of the source object in the source domain.

6. The method according to claim 1, characterized in that: When the relationship type is link, the directed semantic relationship represents a relationship of belonging, inclusion, responsibility, space, organization, or reference between objects; When the relation type is function, the directed semantic relation represents the collection, calculation, aggregation, identification, interpretation or analysis relationship from the starting object to the ending object; When the relationship type is action, the directed semantic relationship represents an action relationship in which the starting object triggers the creation of the ending object, state change, task assignment, strategy generation, or governance loop.

7. The method according to claim 1, characterized in that, The fact object includes fact object identifier, source object identifier, object scope identifier, object scope type, cycle start time, cycle end time, cycle granularity, metric value, and quality status; The period granularity includes at least one of hour, day, week, month, shift, or billing period.

8. The method according to claim 1, characterized in that, The preset model validation rules include at least one of the following: Verify that each ontology object has an object name, object type, core properties, readable functions, and executable actions; Verify that each directed semantic relation has a start object, an end object, a relation type, and an operation name; Verify whether cross-domain reference nodes have source domain identifiers and source object identifiers; Validate whether the same source object is defined repeatedly in different business domains; Verify whether statistical snapshots, virtual metrics, temporary reports, interface caches, technical intermediate tables, or algorithm intermediate results have been incorrectly set as ontology objects; Verify whether the fact object can be traced back to the object scope, time window, and data source.

9. The method according to claim 1, characterized in that, The output agent-oriented ontology world model includes: The ontology world model can be output as an object graph, graph database structure, structured JSON, semantic index, or intelligent agent tool description. The intelligent agent tool description includes at least one of object query tool, relationship traversal tool, function call tool, and action recognition tool.

10. The method according to claim 1, characterized in that, The target business system is a ship post-production manufacturing execution system. The multiple business domains include the ship product and configuration domain, space and system domain, process and construction method domain, planning and operation execution domain, resource and capability domain, material and technical document domain, and problem, risk and governance domain. Among them, work tasks are defined in the planning and operation execution domain and appear as cross-domain reference nodes in the resource and capability domain, material and technical document domain, or problem, risk and governance domain.

11. The method according to claim 1, characterized in that, The target business system is an energy management system, and the fact objects include time-of-use energy consumption facts. The time-of-use energy consumption facts are expressed in terms of hourly, daily, weekly, monthly, shift, or billing cycle statistical caliber through periodic granularity, and the energy consumption statistical objects are expressed through object scope identifiers and object scope types. They are also associated with metering points, energy media, production lines, equipment assets, shift schedules, production events, operator records, energy-saving opportunities, or countermeasures through directed semantic relationships.

12. A device for physical world object ontology modeling and cross-domain association for intelligent agents, characterized in that, include: The data acquisition module is used to acquire business data from the target business system. The candidate object extraction module is used to extract a set of candidate objects based on the business data. The object type determination module is used to determine the object type of the candidate objects in the candidate object set, retain the candidate objects that are determined to be physical objects, business objects, organizational objects, event objects, fact objects or governance objects, and exclude the candidate objects that are determined to be statistical snapshots, virtual indicators, temporary reports, interface caches, technical intermediate tables or algorithm intermediate results. The business domain segmentation module is used to divide the ontology object collection into multiple business domains and determine the primary responsibility domain of each ontology object; The cross-domain reference module is used to generate cross-domain reference nodes when an ontology object appears in a non-primary domain, and to record the source domain identifier and the source object identifier; The object description module is used to establish the object name, object type, core properties, readable functions, and executable actions for the ontology object; The semantic relationship module is used to establish directed semantic relationships, which include a starting object, an ending object, a relationship type, and an operation name. The relationship type includes at least link, function, and action. The Fact Object module is used to express statistical dimensions through the fact object's time granularity, object range, period start time, period end time, and metric attributes. The model validation module is used to validate ontology objects, cross-domain reference nodes, object description information, directed semantic relationships, and fact objects according to preset model validation rules. The model output module is used to output an ontology world model for intelligent agents after the verification is passed.

13. The apparatus according to claim 12, characterized in that, The semantic relationship module is configured as follows: Mark static links, attribution relationships, reference relationships, spatial relationships, organizational relationships, or responsibility relationships as "link"; Mark the functions that collect, calculate, aggregate, identify, interpret, or analyze relationships as functions; Mark state changes, object creation, task assignment, countermeasure generation, or governance loop relationships as actions.

14. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program that, when executed by the processor, implements the method according to any one of claims 1 to 11.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method according to any one of claims 1 to 11.

Images