A product service network-oriented collaborative and interactive mode modeling method and system
Patent Information
- Application Number
- CN202611164197.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-08-03
- Publication Date
- 2026-10-13
AI Technical Summary
这种局限性使得构建的交互网络模型缺乏执行层面的保障,既不能适应服务载体的动态更替,也无法支持服务组合的弹性调整,最终制约了产品服务网络的演进能力和运营效率
(1)从黑盒抽象建模到白盒精细化建模:采用基于原子计算单元、功能聚合与接口的递归载体模型,实现对异构服务载体内部结构、性能与能力的形式化描述,突破传统方法将载体视为黑盒的局限,清晰刻画不同载体的执行特性与约束条件。
Smart Images

Figure CN122909093A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of service computing, specifically relating to a method and system for modeling collaborative and interactive patterns in product service networks. Background Technology
[0002] With the rapid development of technologies such as the Internet of Things (IoT), 5G, and edge computing, the modern service industry is undergoing a profound transformation from single services to complex product-service networks. Against this backdrop, numerous heterogeneous devices, software systems, and departments are being integrated into the service ecosystem as service carriers, forming a highly dynamic and distributed collaborative environment. This evolution poses a significant challenge to traditional product-service network modeling methods in describing multi-stakeholder collaboration, dynamic resource allocation, and value co-creation. The complexity of product-service networks lies not only in the diversity of participating entities but also in the dynamism of their collaborative modes and the heterogeneity of their execution carriers. This necessitates new modeling methods capable of simultaneously characterizing multiple dimensions, including network logical sequences, information transmission paths, resource transfer processes, and the flow of economic value.
[0003] Among existing technical solutions, the most representative are Business Process Modeling and Notation (BPMN 2.0) and Service Pattern Description Language (SPDL). BPMN 2.0, as an international standard for business process modeling, provides an intuitive framework for describing business processes through elements such as activities, gateways, events, and sequence flows. Its core advantage lies in its powerful ability to express the execution sequence and control logic of business processes. However, this activity-centric modeling approach treats service participants as atomic black-box units, failing to reveal their internal structure and capabilities. Following closely behind, the SPDL language significantly expands upon BPMN by introducing the concepts of data flow, resource flow, and value flow, establishing a more comprehensive service pattern description framework that enables the quantitative evaluation and optimization of service ecosystems.
[0004] Despite the significant progress these technologies have made in business process modeling, they still have fundamental shortcomings when faced with the dynamic and heterogeneous nature of modern product and service networks.
[0005] The primary problem lies in the overly abstract description of service deployment platforms. Neither the "participant" concept in BPMN nor the service execution unit in SPDL provides a formal definition of the platform's internal structure, performance metrics, and functional constraints. This black-box approach prevents the model from distinguishing the execution characteristics of the same service on different platforms and from providing a basis for decision-making regarding dynamic service deployment and platform replacement. A deeper problem lies in the lack of dynamic coordination mechanisms. When services need to migrate across heterogeneous platforms or network topology needs adjustment, the existing model lacks the necessary constraints to verify the feasibility of the changes. It cannot ensure functional compatibility or assess performance capacity, resulting in a severe disconnect between business logic and execution infrastructure.
[0006] The root cause of these technical shortcomings lies in the incomplete abstraction level of existing modeling methods. They focus on collaboration at the business function level while neglecting the interaction relationships at the infrastructure level. In actual product-service networks, the connection methods between carriers, the collaboration mechanisms of internal components, and the binding relationship between services and carriers together constitute the physical foundation supporting the execution of business logic. However, existing technical solutions fail to incorporate these key elements into the modeling scope. This limitation results in the constructed interactive network model lacking execution-level guarantees, making it unable to adapt to the dynamic replacement of service carriers or support the flexible adjustment of service compositions, ultimately restricting the evolution capability and operational efficiency of the product-service network.
[0007] Furthermore, neither BPMN 2.0 nor SPDL-related research has developed systematic regulatory evaluation indicators for product-service network modeling models. There are no clear indicators to measure the accuracy of modeling methods in characterizing heterogeneous carriers and their ability to support dynamic collaboration. There is also a lack of core criteria for evaluating the adaptability of modeling models to business needs and their compatibility with infrastructure. This lack of regulatory indicators makes it impossible to quantitatively evaluate the merits of existing modeling methods, and it is difficult to accurately identify shortcomings in the modeling process. This not only hinders the iterative optimization of modeling methods but also fails to provide reliable support for the actual operation and decision-making adjustments of product-service networks. It may even lead to service collaboration failures and resource waste due to modeling biases.
[0008] Therefore, establishing a regulatory evaluation index system that adapts to the dynamic heterogeneous characteristics of product service networks is a necessary prerequisite for making up for the shortcomings of existing research, promoting the improvement of modeling methods, and ensuring the efficient and orderly operation of product service networks. Summary of the Invention
[0009] Traditional methods rely on manual experience or static rules to allocate services to carriers, leading to resource mismatch and collaborative failures. To address these problems, this invention proposes a method and system for modeling collaborative and interactive patterns in product service networks.
[0010] Firstly, this invention proposes a collaborative and interactive pattern modeling system for product service networks, used to formally bind product service activities with carriers and generate deployment schemes in cloud-edge collaborative or IoT environments. The specific technical solution is as follows: The modeling system is a quadruple, including a product network process layer, a carrier network layer, a regulatory indicator layer, and a binding and constraint layer; The product network process layer is used to acquire externally input product service networks and extract the dependencies between product service activities. Combining the information transmission, resource consumption, and value transformation processes generated during the operation of product service activities, a five-tuple is obtained. At the same time, the product network process layer also extracts the functional requirements, performance requirements, and type requirements of each product service activity in the product service network to form a requirement triple. The carrier network layer is used to accept external input carriers to be assigned and calculate the performance and supported resource types of each carrier. It further treats all carriers as nodes, the performance and supported resource types of the carriers as node features, and binds the association and dependency relationships between carriers obtained in the constraint layer as edges, thereby constructing a directed graph. The regulatory indicator layer is used to import external data in real time based on the deployment scheme generated by the binding and constraint layer, calculate the collaborative coupling strength, carrier constraint adaptability and distributed collaborative efficiency, so as to quantitatively evaluate the effectiveness of the deployment scheme. The binding and constraint layer is used to establish realization relationships between product service activities and carriers, and association or dependency relationships between carriers, based on the five-tuple, requirement triple, carrier performance and the resource types supported by the carrier, combined with functional implementation constraints, scale constraints, type constraints and transmission constraints; based on the established relationships, a deployment plan is further obtained.
[0011] Furthermore, the functional requirements represent the specific business functions implemented by the product service activities; the performance requirements represent the performance resources required to implement the functional requirements; and the type requirements represent the types of resources required to implement the functional requirements.
[0012] Furthermore, the carrier adopts a recursive architecture, with each carrier consisting of atomic computing units, functional aggregates, and interface recursion. Each interface contains at least one functional aggregate, and each functional aggregate consists of at least one atomic computing unit or a lower-level functional aggregate.
[0013] Furthermore, in the carrier network layer, the formula for calculating carrier performance is as follows: ; in, M represents the i-th component in the carrier, F represents the set of atomic computing units, and I represents the set of functional aggregates. Representative components Overall performance Representative components All child components The sum of total performance, Representative components Its own performance.
[0014] Furthermore, in the carrier network layer, the formula for calculating the resource types supported by the carrier is as follows: ; in, M represents the i-th component in the carrier, F represents the set of atomic computing units, and I represents the set of functional aggregates. Representative components Total supported types Representative components All child components The sum of all supported types, Representative components Types that it supports.
[0015] Furthermore, based on the deployment scheme generated by the binding and constraint layer, the formula for calculating the cooperative coupling strength is: ; in, A collection of product and service activities. The total number of product and service activities. A set of dependencies between product and service activities. This represents the total number of dependencies. The strength of the cooperative coupling; The formula for calculating the carrier constraint fit degree is: ; in, Product service activities The resource requirement vector includes performance requirements; as a carrier The resource capacity vector includes the performance of the carrier; As an allocation variable between services and carriers, when product service activities Deployed on carrier When, Otherwise, it is 0; For carrier constraint adaptation, For carrier collection, A collection of product and service activities; The formula for calculating the distributed collaboration efficiency is as follows: ; in, This represents the minimum number of communications under ideal conditions. The number of communications that occur for the deployment scheme generated by the binding and constraint layer. For distributed collaboration efficiency; The collaborative coupling strength, carrier constraint adaptability, and distributed collaborative efficiency output by the regulatory indicator layer are used as the decision-making basis for the modeling system to automatically adjust the deployment scheme.
[0016] Furthermore, the functional implementation constraint is that for carriers and product service activities that have an implementation relationship, the functions provided by the carrier must meet the functional requirements of the product service activities; The scale constraint is that the sum of the performance and type requirements of all product and service activities allocated to the same carrier must not exceed the carrier's performance. The type constraint is that if there is a dependency between the product service activities allocated by the two carriers, then the resource types supported by the two carriers must simultaneously meet the resource types required by the two product service activities. The transmission constraint is that if there is a dependency between the product service activities allocated to the two carriers, then there must be a feasible communication path between the carriers.
[0017] Furthermore, the realization relationship is used to indicate that product service activities are assigned to corresponding carriers for execution; The association between carriers is used to indicate that there are feasible communication paths between different carriers; Dependencies between carriers are used to represent the collaborative dependencies between different components within a carrier.
[0018] Secondly, this invention proposes a modeling method for collaborative and interactive patterns of product service networks implemented using the above-mentioned system.
[0019] The beneficial effects of this invention are: (1) From black-box abstract modeling to white-box refined modeling: A recursive carrier model based on atomic computing units, functional aggregation and interfaces is adopted to realize a formal description of the internal structure, performance and capabilities of heterogeneous service carriers. This breaks through the limitation of the traditional method of treating the carrier as a black box and clearly describes the execution characteristics and constraints of different carriers.
[0020] (2) Fill the gap in regulatory evaluation indicators: Construct three types of quantitative regulatory indicators: synergistic coupling strength, carrier constraint adaptability, and distributed synergistic efficiency, to form a complete product service network evaluation system and solve the problem that existing methods cannot quantify the rationality of modeling, synergistic efficiency and resource adaptability.
[0021] (3) From two-layer collaboration of business and resources to three-layer collaboration of business, resources and supervision: Construct a unified modeling architecture that includes product network process layer, carrier network layer and supervision indicator layer to realize full-link collaboration and closed-loop verification of business logic, physical carrier and quantitative evaluation.
[0022] (4) From human experience-based decision-making to data-driven quantitative decision-making: Relying on regulatory indicators to provide objective basis for service deployment, carrier allocation, and topology adjustment, improve scheduling accuracy and execution reliability, and reduce dynamic adjustment risks and decision-making subjectivity.
[0023] (5) Improve the verifiability, stability and evolvability of the system: By constraining the system and regulatory indicators, the pre-verification of service collaboration can be achieved, avoiding problems such as functional mismatch, resource overload and communication unreachability in advance, and enhancing the robustness and long-term iteration capability of the product service network in a dynamic heterogeneous environment.
[0024] In summary, the aforementioned technical means collectively enable automated, verifiable, and quantifiable modeling and deployment of product service networks, constituting a specific technical improvement to computer systems in the field of distributed service deployment, rather than a simple description of abstract organizational rules or business methods. Attached Figure Description
[0025] Figure 1 This is an overall framework diagram of the present invention.
[0026] Figure 2 This is a schematic diagram of the electronic device terminal structure of the present invention. Detailed Implementation
[0027] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Many specific details are set forth in the following description to provide a thorough understanding of the present invention. However, the present invention can be practiced in many other ways different from those described herein, and those skilled in the art can make similar modifications without departing from the spirit of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below. Technical features in the various embodiments of the present invention can be combined accordingly without mutual conflict.
[0028] The technical problem to be solved by this invention is a typical constrained service composition and resource allocation problem. Therefore, a formal model is used to accurately describe each element and its complex constraints in the problem, and a regulatory indicator system is introduced to provide a solid foundation for designing efficient allocation algorithms or heuristic strategies.
[0029] For ease of explanation, some terms appearing in the specific embodiments of this invention will first be explained: Product service network: This refers to an integrated, collaborative operation network supported by the Internet of Things (IoT), 5G, and edge computing, integrating multiple types of services, heterogeneous resources, and distributed entities, and oriented towards complex service scenarios. For example, in automated smart ports, heterogeneous equipment such as quay cranes, AGVs (Automated Guided Vehicles), yard cranes, and gates are interconnected through 5G and IoT to form a product service network. Among them, unloading services, horizontal transport services, yard storage services, and gate passage services, as multiple types of service nodes, share computing, communication, and logistics resources, and complete the entire process of container handling from ship to landside under the coordination of the scheduling system.
[0030] Data flow: refers to the process by which information or data is transmitted, transformed, stored, or consumed between different services according to specific logical dependencies.
[0031] Resource flow: The paths and processes by which various computing, storage, or physical assets are allocated, occupied, released, contested, or transferred between product and service activities.
[0032] Value stream: The complete sequence of all necessary product and service activities to transform a business need (such as a user placing an order) into a final result that is valuable to the user or the business (such as a successful order).
[0033] Carrier network diagram: A topological structure used to describe the service execution carriers and their connections, consisting of carrier nodes and physical or logical connection edges between carriers.
[0034] Product service activity: The basic execution unit in the product service network that completes a specific business function, representing the smallest schedulable task in the business process.
[0035] Service platform: The hardware equipment that carries out product service activities and provides basic capabilities such as computing, storage, and networking for service execution.
[0036] Functional aggregation: Components unique to the service carrier, formed by hierarchical aggregation of lower-level atomic computing units and lower-level functional sets, used to characterize the business processing and service support capabilities that the carrier can provide to the outside world.
[0037] Logical dependencies between services: These are the pre-existing constraints and relationships between different product / service activities in terms of execution order, data transfer, and resource access. For example, the order service must be executed before the logistics service, or service A must call a certain interface of service B to continue.
[0038] Physical or logical connections between service carriers: The actual or abstract links established between service carriers to enable communication. For example, service 1 accesses service 2 through a specific IP address, port, and network link.
[0039] Secondly, this invention defines each node in a complex product service network. Represents a product or service activity, on the side Represents the logical dependencies between services, and is carried by a network diagram. In the middle, node Represents a service carrier, side This represents the physical or logical connection between service providers. Furthermore, each product / service activity... Resource demand vector , Represents the resource requirements of the m-th function in a product service activity, for each service carrier. Resource capacity vector and function set .
[0040] This invention further introduces a regulatory indicator system, which can be used to proactively evaluate strategies such as service deployment and carrier replacement based on the current network status and business load, providing a basis for dynamic optimization decisions.
[0041] Against this backdrop, the core of this invention lies in constructing a unified, formalized service-carrier collaboration model that integrates regulatory assessment by introducing multi-layered abstraction, rigorous mathematical definitions, and a regulatory indicator quantification mechanism. This model can accurately describe the business logic, execution infrastructure, indicator mapping relationships, and dynamic binding relationships between services and carriers in a product service network, solving the problems of dynamic adaptation, quantitative assessment, and optimization decision-making in service composition and resource allocation under heterogeneous environments.
[0042] like Figure 1 The diagram shown is an overall framework diagram of the product service network collaboration and interaction mode modeling method provided in an embodiment of the present invention.
[0043] Specifically, this invention defines the service-carrier collaboration and interaction model as a quadruple. ,in Representing the product network process layer, it is responsible for multi-dimensional modeling of business processes; The representative carrier network layer is used to describe the heterogeneous physical or logical carriers that perform services. Representing the regulatory indicator layer, a quantitative evaluation system is established to achieve unified supervision and quantitative assessment of modeling effectiveness, collaborative relationships, and resource adaptability; This represents the binding and constraint layer, which dynamically associates service requirements with carrier capabilities through formal rules, while also... Apply explicit constraints.
[0044] (1) Product network process layer
[0045] At the product network process layer In this invention, all product services in a product service network are formally defined as a quintuple:
[0046] in A collection of product and service activities. These represent the sets of data flow, resource flow, and value flow, respectively. The execution order dependencies between activities are defined.
[0047] In the collection of product and service activities, each product and service activity Further link a demand triple ,in This represents the set of functional requirements for a product or service activity, i.e., the specific business functions or operations of the product or service activity. For example, the functional requirements for an order payment product or service activity may include verifying sufficient inventory, locking inventory, verifying account balance, deducting balance, creating order record, and sending order message. This represents the performance requirement vector of a product or service activity, which is a quantitative resource indicator required by the product or service activity at runtime to fulfill its functional requirements, such as memory size, number of CPU cores, and GPU memory. This represents the set of requirements for different types of product and service activities, namely, the discrete categories of requirements for the operating environment, hardware characteristics, and service quality levels of product and service activities, such as computing hardware and storage media.
[0048] This formal definition allows for a precise description of all aspects of the business logic.
[0049] (2) Carrier network layer
[0050] In the carrier network layer In this model, the service carriers of all unassigned product and service activities are modeled as directed graphs. The carrier network diagram is obtained.
[0051] Each carrier node It is a recursive structure. ,in, Atomic computing units, representing the smallest indivisible computing entities within the carrier structure, represent the basic hardware or software resources required for the carrier to execute services. At the physical level... This could be a hardware unit such as a CPU core or a sensor; at the logical level, It can also be a software runtime environment such as an operating system process, a virtual machine, or a container instance. Each atomic computing unit has its inherent performance attributes Pe (such as computing power and storage capacity) and type attributes T (such as instruction set architecture and operating system type). These attributes constitute the basic unit of measurement for the computing capabilities of the carrier.
[0052] Functional aggregation Edge computing is a composite functional module composed of multiple atomic computing units or smaller functional aggregates through specific collaborative relationships. It embodies the hierarchical organizational capabilities of the carrier. For example, an edge computing node may consist of multiple CPU cores, memory modules, and storage devices (all M) aggregated into a data processing unit (F). Multiple data processing units are then aggregated with a network module to form a complete "edge server" (another F). Each functional aggregate... In addition to inheriting the combined performance of its constituent components, it also possesses its own unique set of aggregated functions, such as video analytics and data fusion capabilities. This recursive definition allows the carrier to describe its capabilities at different granularities, enabling unified modeling from a single chip to an entire server cluster.
[0053] interface The interface layer serves as the access point for the service provider, encapsulating the internal implementation details of the service provider and defining the contract for interaction with the external environment. Each interface is associated with three key elements: first, the access protocol, which defines how external entities communicate with the interface, such as RESTful API, MQTT, OPC UA, etc.; second, the functional exposure, which specifies the specific functions that can be invoked through the interface, typically provided by underlying functional aggregates; and finally, the performance commitment, which defines the quality of service guaranteed by the interface, such as response time and throughput limits. The introduction of the interface layer decouples service implementation from invocation, allowing the same function to be provided externally in different ways through different interfaces.
[0054] Therefore, for the performance calculation of each component in the carrier, this invention adopts a recursive method to perform the calculation from bottom to top:
[0055] in, Represents the i-th component in the carrier, i.e. Represents the overall performance of a component. Each component contains several interfaces, and each interface further contains several functional aggregates composed of atomic computational units. Therefore, when It is an interface At that time, its performance is equal to that of the connected underlying components. The sum of performance; when When a function is aggregated into F, its performance equals its own performance. Add underlying components The sum of performance; when When the computational unit is an atom M, its performance is its own performance. ; , M and M are components respectively The set of interfaces, the set of functional aggregates, and the set of atomic computing units.
[0056] Ultimately, the overall performance of the components It equals the sum of the performance of all interfaces in the component.
[0057] For each component type of the carrier, calculations are supported, and a recursive method is used to calculate from bottom to top:
[0058] in, Represents the i-th component in the carrier, i.e. , This represents the total number of types supported by the component. When It is an interface At that time, the total number of types it supports is equal to the number of underlying components it connects to. The sum of all supported types; when It is a functional aggregation At that time, the total number of types it supports is equal to the total number of types it supports. Add underlying components The sum of all supported types; when When it is an atomic computing unit, the total number of types it supports is the total number of types it supports itself. .
[0059] Ultimately, the total number of types supported by the component It equals the sum of all types supported by all interfaces of the component.
[0060] (3) Regulatory Indicator Layer
[0061] To achieve quantitative supervision of the collaborative and interactive modes of product service networks, this invention introduces three core regulatory indicators in the regulatory indicator layer: collaborative coupling strength, carrier constraint adaptability, and distributed collaborative efficiency, and receives externally transmitted data in real time to calculate the indicators.
[0062] The specific calculation methods for each indicator are as follows: Cooperative coupling strength is denoted as This metric is used to characterize the tightness of collaborative dependencies between product and service activities. It can reveal weakly related service nodes and provide guidance for simplifying business dependency topologies. Its calculation formula is as follows:
[0063] in, A collection of product and service activities. The total number of product and service activities. This refers to the set of actual dependencies between product and service activities. This represents the actual number of dependent edges. This represents the maximum possible number of dependency edges between all activities.
[0064] Carrier constraint fit is denoted as This metric is used to quantify the degree of matching between service resource demand and carrier supply capacity. It provides guidance for migrating resource-overloaded product and service activities to idle carriers, splitting multi-service loads on a single carrier, and replacing heterogeneous carriers with mismatched capabilities. The calculation formula is as follows:
[0065] in, Product service activities The resource demand vector, i.e., P in the demand triple. as a carrier The resource provision capability vector, i.e., carrier performance; As an allocation variable between services and carriers, when product service activities Deployed on carrier When, Otherwise, it is 0. The numerator represents the sum of the portion of resource demand on all carriers that exceeds the carrier's capacity, and the denominator represents the total resource demand of all product and service activities.
[0066] Distributed collaborative efficiency is denoted as This metric is used to measure the communication optimization level of multi-carrier distributed collaboration. It provides guidance for adding direct communication links between carriers, consolidating co-coupled services into the same carrier, and reducing redundant cross-carrier interaction paths. Its calculation formula is as follows:
[0067] in, This represents the minimum number of communications required to complete all collaborative interactions under ideal conditions. This represents the actual number of communications that occurred under the current deployment scheme.
[0068] The above three types of indicators can objectively and quantitatively evaluate the modeling effect from three dimensions: business coupling relationship, resource constraint adaptability, and distributed collaboration efficiency. They provide a standardized and reliable quantitative basis for model rationality verification, dynamic service deployment, and system optimization decisions.
[0069] (4) Binding and Constraint Layer
[0070] Binding and Constraint Layer By implementing relationships Relationship and dependency These three key relationships connect the product network process layer and the carrier network layer, enabling dynamic collaboration between services and carriers, and establishing a strict constraint system. Ensure the accuracy of dynamic adjustments.
[0071] Among them, realizing the relationship Used to describe the binding relationship between product service activities and carrier interfaces, representing which carrier interface provides the capability to support the execution of product service activities, formally defined as:
[0072] in, A collection of product and service activities. This is a set of carrier interfaces. For any This indicates product and service activities. Bind to interface The corresponding functional aggregation and underlying carrier provide execution capabilities. The implementation relationship clarifies who executes the service and is the core basis for service deployment and carrier allocation.
[0073] Relationship Used to describe the communication and interaction channels between different carrier interfaces, characterizing the ability to establish data transmission, command invocation, and collaborative interaction between interfaces, formally defined as:
[0074] For any , indicating interface and There are reachable communication paths between them, supporting service collaboration across carriers and modules. The relationships characterize the topological connectivity of the carrier network and are the foundation for distributed collaboration and scheduling.
[0075] Dependency This describes the collaborative dependencies between components within the carrier:
[0076] in, A set of atomic computing units, It is a collection of functions. For any set of interfaces. , indicates component Functionality and performance dependent components There are direct dependencies between them. These dependencies reflect the hierarchical constraints of the recursive structure within the carrier, ensuring that the carrier's capabilities can be aggregated step by step and can be computationally verified.
[0077] The association between binding and constraint layer definitions and dependency This constitutes a directed graph in the carrier network layer. edge set The source, specifically, .
[0078] constraint system It is a multi-level, multi-dimensional formal verification system that uses four core dimensions—functional implementation constraints, scale constraints, type constraints, and transmission constraints—to jointly ensure the correctness and feasibility of service-carrier collaboration.
[0079] Functionality implementation constraints ensure the executability of product and service activities on the carrier, requiring each to achieve the relationship. Product service activities bound to the carrier interface must have all their functions provided by the target carrier, thus fundamentally eliminating deployment failures caused by missing functions.
[0080] Specifically, each product / service activity must be assigned to a service platform that can provide its required functionality:
[0081] in, A collection of product and service activity nodes. A set of service carrier nodes; Assign variables to 0-1. This indicates that product / service activity u is deployed on carrier v, and vice versa. A function to obtain the set of functional requirements F for product / service activity u; This is the set of functionalities that the carrier v can provide. This constraint prevents deployment mismatches at the functional level.
[0082] Scale constraints ensure the rational allocation and use of carrier resources, requiring that the total resource demand of all product and service activities bound to the same carrier must not exceed the capacity limit of that carrier. By quantitatively managing resources such as CPU, memory, and bandwidth, system instability caused by performance overload is effectively avoided.
[0083] Specifically, the total resource requirements of all product and service activities allocated to the same service carrier must not exceed the total performance of the service carrier:
[0084] in, The resource requirement vector for product service activity u, i.e., P in the requirement triple; The total performance of the service carrier v.
[0085] Type constraints solve the interoperability problem between heterogeneous carriers. For product service activities with dependencies, the carriers must be able to meet all the resource types required by the two product service activities, ensuring smooth and compatible cross-carrier interaction.
[0086] Specifically, product and service activities with dependency relationships It must be deployed on a carrier that meets specific type support requirements. and superior.
[0087]
[0088] in, This represents the union of the data types required by product / service activities u and p. and These represent the total types supported by service carrier v and the total types supported by service carrier l, respectively. Type constraints ensure interoperability between heterogeneous carriers.
[0089] Transmission constraints ensure the physical reachability and quality of service of data flows between services. For product service activities with dependencies, there must be a communication path between their carriers that meets the bandwidth and latency requirements. This transforms the logical dependencies of the business layer into communication guarantees of the infrastructure layer, and realizes the collaborative verification of business logic and network topology.
[0090] Specifically, if there is a dependency relationship between two product / service activities u and p Then the service carrier that carries them and (Right now and There must be a feasible relationship between them:
[0091] in, This represents the direct communication relationship between carriers v and l.
[0092] These constraints provide comprehensive protection from business logic to execution. This collaborative mechanism ensures that the entire system, when dealing with dynamic changes, can meet both the underlying resource and performance limitations and maintain the consistency of the top-level business logic, achieving a balance between business agility and system robustness.
[0093] This invention, combined with the scenario of collaborative operation of automated port robots, further illustrates the modeling process of the system of this invention: Step 1, Modeling and Abstraction: Abstract typical port operations such as unloading, transshipment, and storage, and identify real-world business service entities such as unloading tasks, AGV transshipment tasks, yard crane storage tasks, and gate verification tasks as product service activities; identify the real business logic dependencies between entities (e.g., transshipment can only be completed after unloading, and storage can only be completed after transshipment); identify real-world carrier hardware entities such as quay cranes, AGVs, yard cranes, edge computing gateways, server clusters, and sensors.
[0094] Step 2, Model Standardization: Standardize the definition of the abstracted business model, unify the description of the functional, performance, and type requirements of product service activities; unify the hierarchical specifications of the actual hardware carrier, decompose each quay crane / AGV into atomic computing units (sensors, CPU cores), functional aggregations (path calculation modules, cargo identification modules), and external communication interfaces (MQTT / OPC UA interfaces), solidify the recursive calculation formula parameters of carrier performance and resource types, and form a reusable standardized template.
[0095] Step 3: Establish a mapping table: Traverse all real-world port business service entities and hardware carrier entities collected in Step 1, and enter them one by one into the mapping table. Bind the unique code of each real-world entity to an abstract node within the modeling system, constructing a two-way linkage mapping data table between real-world entities and the system model. The mapping table continuously communicates with and updates data at the port site. When a new AGV is added, a new unloading service is added, an old yard crane is phased out, or a business process is modified, the external system pushes an entity change signal to the mapping table.
[0096] Step 4, Adaptive Calculation of Constraints: Based on the mapping table, by binding the implementation relationship, association relationship, dependency relationship, and constraints such as function implementation, scale, and type of the constraint layer, the system adaptively verifies and generates a valid service-carrier binding scheme.
[0097] Step 5, Real-time Monitoring: The monitoring indicator layer combines three types of monitoring indicators—cooperative coupling strength, carrier constraint adaptability, and distributed collaborative efficiency—and automatically issues control commands to the underlying system based on the thresholds of these three indicators. This drives the binding and constraint layer to regenerate deployment plans, thereby continuously supporting dynamic adaptation across all scenarios of adding / scrapping carriers, adding / deleting business services, and revising business processes at the port. This enables real-time synchronous optimization between the modeling system and the actual operational scenario. For example, if the carrier constraint adaptability is too low, the system re-selects carrier nodes for product service activities, thereby updating the entire product network.
[0098] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the present invention according to actual needs. Those skilled in the art can understand and implement this without any creative effort.
[0099] The system embodiments of the present invention can be applied to any device with data processing capabilities, such as a computer or other similar device. The system embodiments can be implemented in software, hardware, or a combination of both. Taking software implementation as an example, as a logical device, it is formed by the processor of any data processing device loading the corresponding computer program instructions from non-volatile memory into memory for execution.
[0100] It should also be noted that the method for constructing a collaborative and interactive mode for a product service network in the above embodiments can essentially be executed by a computer program. Therefore, similarly, based on the same inventive concept, another preferred embodiment of the present invention also provides a computer electronic device corresponding to the method provided in the above embodiments, which includes a memory and a processor; The memory is used to store computer programs; The processor is configured to implement, when executing the computer program, a method for constructing a collaborative and interactive mode for a product service network as described in the above embodiments.
[0101] From a hardware perspective, such as Figure 2 The diagram shown is a hardware structure diagram provided in this embodiment. In addition to the processor, memory, network interface and non-volatile memory shown in the diagram, any device with data processing capabilities in the embodiment may also include other hardware depending on the actual function of the device with data processing capabilities, which will not be described in detail here.
[0102] When the logical instructions in the aforementioned memory can be implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium.
[0103] Therefore, based on the same inventive concept, another preferred embodiment of the present invention also provides a computer-readable storage medium corresponding to the method provided in the above embodiments. The storage medium stores a computer program, which, when executed by a processor, can realize a method for constructing a collaborative and interactive mode for a product service network as described in the above embodiments.
[0104] It is understood that the computer-readable storage medium can be an internal storage unit of any data processing device described in any of the foregoing embodiments, such as a hard disk or memory. The computer-readable storage medium can also be an external storage device of any data processing device, such as a plug-in hard disk, smart media card (SMC), SD card, flash card, etc., equipped on the device. Furthermore, the computer-readable storage medium can include both internal storage units and external storage devices of any data processing device. The computer-readable storage medium is used to store the computer program and other programs and data required by the data processing device, and can also be used to temporarily store data that has been output or will be output.
[0105] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the invention. Those skilled in the art can make various changes and modifications without departing from the spirit and scope of the invention. Therefore, all technical solutions obtained through equivalent substitution or transformation fall within the protection scope of the present invention.
Claims
1. A modeling system for collaborative and interactive patterns in product service networks, used to formally bind product service activities to carriers and generate deployment schemes in cloud-edge collaborative or IoT environments, characterized in that, The modeling system is a quadruple, including a product network process layer, a carrier network layer, a regulatory indicator layer, and a binding and constraint layer; The product network process layer is used to acquire externally input product service networks and extract the dependencies between product service activities. Combining the information transmission, resource consumption, and value transformation processes generated during the operation of product service activities, a five-tuple is obtained. At the same time, the product network process layer also extracts the functional requirements, performance requirements, and type requirements of each product service activity in the product service network to form a requirement triple. The carrier network layer is used to accept external input carriers to be assigned and calculate the performance and supported resource types of each carrier. It further treats all carriers as nodes, the performance and supported resource types of the carriers as node features, and binds the association and dependency relationships between carriers obtained in the constraint layer as edges, thereby constructing a directed graph. The regulatory indicator layer is used to import external data in real time based on the deployment scheme generated by the binding and constraint layer, calculate the collaborative coupling strength, carrier constraint adaptability and distributed collaborative efficiency, so as to quantitatively evaluate the effectiveness of the deployment scheme. The binding and constraint layer is used to establish realization relationships between product service activities and carriers, and association or dependency relationships between carriers, based on the five-tuple, requirement triple, carrier performance and the resource types supported by the carrier, combined with functional implementation constraints, scale constraints, type constraints and transmission constraints; based on the established relationships, a deployment plan is further obtained.
2. The collaborative and interactive mode modeling system for product service networks according to claim 1, characterized in that, The functional requirements represent the specific business functions implemented by the product service activities; the performance requirements represent the performance resources required to implement the functional requirements; and the type requirements represent the types of resources required to implement the functional requirements.
3. The collaborative and interactive mode modeling system for product service networks according to claim 1, characterized in that, The carrier adopts a recursive architecture. Each carrier consists of atomic computing units, functional aggregates, and recursive interfaces. Each interface contains at least one functional aggregate, and each functional aggregate consists of at least one atomic computing unit or a lower-level functional aggregate.
4. The collaborative and interactive mode modeling system for product service networks according to claim 3, characterized in that, In the carrier network layer, the formula for calculating carrier performance is: ; in, M represents the i-th component in the carrier, F represents the set of atomic computing units, and I represents the set of functional aggregates. Representative components Overall performance Representative components All child components The sum of total performance, Representative components Its own performance.
5. A collaborative and interactive modeling system for product service networks according to claim 3, characterized in that, In the carrier network layer, the formula for calculating the resource types supported by the carrier is as follows: ; in, M represents the i-th component in the carrier, F represents the set of atomic computing units, and I represents the set of functional aggregates. Representative components Total supported types Representative components All child components The sum of all supported types, Representative components Types that it supports.
6. The collaborative and interactive mode modeling system for product service networks according to claim 1, characterized in that, Based on the deployment scheme generated by the binding and constraint layer, the formula for calculating the cooperative coupling strength is: ; in, A collection of product and service activities. The total number of product and service activities. A set of dependencies between product and service activities. This represents the total number of dependencies. The strength of the cooperative coupling; The formula for calculating the carrier constraint fit degree is: ; in, Product service activities The resource requirement vector includes performance requirements; as a carrier The resource capacity vector includes the performance of the carrier; As an allocation variable between services and carriers, when product service activities Deployed on carrier When, Otherwise, it is 0; For carrier constraint adaptation, For carrier collection, A collection of product and service activities; The formula for calculating the distributed collaboration efficiency is as follows: ; in, This represents the minimum number of communications under ideal conditions. The number of communications that occur for the deployment scheme generated by the binding and constraint layer. For distributed collaboration efficiency; The collaborative coupling strength, carrier constraint adaptability, and distributed collaborative efficiency output by the regulatory indicator layer are used as the decision-making basis for the modeling system to automatically adjust the deployment scheme.
7. A collaborative and interactive modeling system for product service networks according to claim 1, characterized in that, The functional implementation constraint is that for carriers and product service activities that have an implementation relationship, the functions provided by the carrier must meet the functional requirements of the product service activities. The scale constraint is that the sum of the performance and type requirements of all product and service activities allocated to the same carrier must not exceed the carrier's performance. The type constraint is that if there is a dependency between the product service activities allocated by the two carriers, then the resource types supported by the two carriers must simultaneously meet the resource types required by the two product service activities. The transmission constraint is that if there is a dependency between the product service activities allocated to the two carriers, then there must be a feasible communication path between the carriers.
8. A modeling system for collaborative and interactive modes of product service networks according to claim 1, characterized in that, The implementation relationship is used to indicate that product service activities are assigned to corresponding carriers for execution; The association between carriers is used to indicate that there are feasible communication paths between different carriers; Dependencies between carriers are used to represent the collaborative dependencies between different components within a carrier.
9. A method for modeling collaborative and interactive patterns of product service networks using the modeling system described in claim 1, characterized in that, include: S1, abstract the work process in the business scenario, extract the product service network and input it into the modeling system; S2, in the product network process layer, identifies product service activities in the product service network and establishes quintuples and demand triples; in the carrier network layer, identifies carriers in the product service network and calculates the carrier's performance and supported resource types; S3, in the binding and constraint layer, combines functional implementation constraints, scale constraints, type constraints and transmission constraints to establish implementation relationships between product service activities and carriers, and to establish association or dependency relationships between carriers; S5, in the regulatory indicator layer, calculates the collaborative coupling strength, carrier constraint adaptability, and distributed collaborative efficiency based on the realization relationship, association relationship, and dependency relationship established in the binding and constraint layer, combined with real-time input external data, to achieve quantitative evaluation and dynamic monitoring.
10. A computer electronic device, characterized in that, Including memory and processor; The memory is used to store computer programs; The processor is configured to implement, when executing the computer program, a collaborative and interactive mode modeling method for product service networks as described in claim 9.