Automation design of process automation equipment

Abstract

Implementations herein leverage knowledge of past process automation equipment to automate the design of new process automation equipment. A first level of design input may be processed to generate a first embedding that encodes a design aspect of a required process automation equipment at a level of detail commensurate with a first level of a hierarchy reflected by design documents typically used to design the process automation equipment. The first embedding may be used to find a first level of reference embedding that encodes a design aspect of a reference process automation equipment. A second level of reference embedding may be identified based on a mapping from the selected first level of reference embedding. Each second level of reference embedding may encode a design aspect of a respective reference process automation equipment at a level of detail commensurate with a second level of the design document hierarchy. A template design document may be provided based on the second level of reference embedding.

Description

[Technical Field]

[0001] The present disclosure relates to automated design of process automation equipment. [Background technology]

[0002] Process automation facilities are increasingly being implemented as distributed computing environments with numerous process automation hardware components, such as distributed control nodes (DCNs) connected to a process automation network. Designing a process automation facility from scratch requires significant expertise and / or experience and, as a result, tends to be costly both financially and in terms of time. Additionally, the required process automation facility may have many similarities to reference process automation facilities, such as currently existing and / or previously existing process automation facilities. However, the knowledge gained by personnel who designed and implemented those reference process automation facilities may not be easily transferable to other personnel. Summary of the Invention [Means for solving the problem]

[0003] Described herein are implementations for capturing, organizing, and leveraging knowledge associated with the design and / or implementation of reference process automation equipment to automate aspects of designing new and / or updating existing process automation equipment. More particularly, but not exclusively, described herein are implementations for processing information about the reference process automation equipment to generate what is referred to herein as a "federated information model." The federated information model can be used as a reference point for designing new process automation equipment, for example, by automatically generating and / or providing template design documents.

[0004] In some implementations, a method for designing at least a portion of a requested process automation equipment may be performed using one or more processors and includes the steps of: processing first level design inputs for the requested process automation equipment to generate a first embedding, the first embedding encoding design aspects of the requested process automation equipment at a level of detail corresponding to a first level of a design document hierarchy typically associated with designing the process automation equipment; and comparing the first embedding to a plurality of first level reference embeddings to select one or more first level reference embeddings that satisfy a first criterion, the plurality of first level reference embeddings being at least one of the first level of the design document hierarchy. The method may include steps of: encoding a design aspect of each of the plurality of reference process automation equipment; identifying one or more second-level reference embeddings based on one or more mappings from the selected one or more first-level reference embeddings, each of the one or more second-level reference embeddings encoding a design aspect of a respective one of the plurality of reference process automation equipment at a level of detail corresponding to a second level in the design document hierarchy below the first level in the design document hierarchy; and providing one or more template design documents for the requested process automation equipment based on the identified one or more second-level reference embeddings.

[0005] In various implementations, the first level design input for the required process automation equipment may be a process flow diagram, and the one or more template design documents for the required process automation equipment may include a template piping and instrumentation diagram (P&ID) for at least a portion of the required process automation equipment.

[0006] In various implementations, the first level design input for the required process automation equipment may include natural language input, and the one or more template design documents for the required process automation equipment may include a template process flow diagram (PFD) or a template piping and instrumentation diagram (P&ID) of at least a portion of the required process automation equipment.

[0007] In various implementations, the first level design input for the required process automation facility may include information about a central control room for the required process automation facility, and the one or more template design documents for the required process automation facility may include a template design of a field equipment room (FER) for the required process automation facility.

[0008] In various implementations, processing the first-level design inputs to generate a first embedding may include generating a graph based on the first-level design inputs and processing the graph based on one or more machine learning models to generate the first embedding. In various implementations, one or more of the machine learning models may be a graph neural network (GNN). In some implementations, the graph may include a plurality of nodes representing a plurality of processes to be implemented in the requested process automation facility and a plurality of edges defining relationships between the plurality of processes. In other implementations, the graph may include a plurality of nodes representing a plurality of process automation nodes to be implemented in the requested process automation facility and a plurality of edges representing network communication channels between the plurality of process automation nodes. In some implementations, the graph may include one or more nodes representing one or more modular automated process assemblies to be implemented in the requested process automation facility and a plurality of edges defining relationships between one or more pre-planned process automation assemblies and other elements of the requested process automation facility.

[0009] In various implementations, one or more of the template design documents may be generated based on persistent elements shared among multiple reference process automation equipment. In various implementations, the first design input may include input / output (I / O) information for a process unit of the process automation equipment, and the processing may include calculating a number of distributed control nodes (DCNs) for the process unit.

[0010] Additionally, some implementations include one or more processors of one or more computing devices, the one or more processors operable to execute instructions stored in associated memory, the instructions configured to cause performance of any of the above-described methods. Some implementations also include one or more non-transitory computer-readable storage media that store computer instructions executable by the one or more processors to perform any of the above-described methods.

[0011] It should be appreciated that all combinations of the above concepts and additional concepts described in more detail herein are contemplated as being part of the subject matter disclosed herein, for example, all combinations of claimed subject matter listed at the end of this disclosure are contemplated as being part of the subject matter disclosed herein. [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 1 is a diagram that schematically illustrates an exemplary environment in which selected aspects of the present disclosure may be implemented. [Figure 2] FIG. 1 is a diagram that schematically illustrates an example physical plant layout for a process automation facility, in accordance with various implementations. [Figure 3] FIG. 1 is a diagram that schematically illustrates an example of a design cycle for a process automation facility, according to various implementations. [Figure 4] FIG. 1 is a diagram that schematically illustrates an exemplary process flow for a process automation facility. [Figure 5] FIG. 10 is a diagram that schematically illustrates an example of how embedding spaces, semantic embeddings, and mappings between them can be leveraged to automate aspects of process automation equipment design. [Figure 6] FIG. 1 illustrates one example of how design inputs can be processed to generate a template design document. [Figure 7]FIG. 10 illustrates another example of how design inputs can be processed to generate a template design document. [Figure 8] 1A-1C illustrate exemplary methods for implementing selected aspects of the present disclosure. [Figure 9] FIG. 1 illustrates a schematic diagram of an exemplary computer architecture in which selected aspects of the present disclosure may be implemented. DETAILED DESCRIPTION OF THE INVENTION

[0013] Described herein are implementations for capturing, organizing, and leveraging knowledge associated with the design and / or implementation of reference process automation equipment to automate aspects of designing new and / or updating existing process automation equipment. More particularly, but not exclusively, described herein are implementations for processing information about the reference process automation equipment to generate what is referred to herein as a "federated information model." The federated information model can be used as a reference point for designing new process automation equipment, for example, by automatically generating and / or providing template design documents.

[0014] In various implementations, machine learning techniques may be used to leverage the knowledge stored in the federated information model to automate aspects of a new process automation equipment design or an update to an existing process automation equipment, i.e., to “bootstrap” the design or update. For example, in some implementations, when new process automation equipment is requested, a requestor (e.g., a customer) may provide at least some level of detail and / or documentation of what the requestor wants. Initially, this level of detail may be relatively abstract. For example, the customer may provide a high-level documentation of what the customer wants, such as a process flow diagram (PFD) created by, for example, a chemical engineer, or even a free-form narrative of what the customer needs to accomplish. This high-level documentation may be processed alone or in combination with other data (e.g., natural language input, transcriptions of phone calls, etc.) to generate semantically rich embeddings.

[0015] This semantic-rich embedding can then be compared to multiple first-level reference embeddings to select one or more first-level reference embeddings that meet a first criterion. The multiple first-level reference embeddings can encode design aspects of the respective multiple reference process automation equipment at a level of detail or abstraction commensurate with the level of detail or abstraction provided by the customer. The criteria can include, for example, those N (a positive integer) reference embeddings that are most similar, i.e., “closest,” to the semantic-rich embedding generated from the user input, or those reference embeddings that meet some similarity threshold. Such similarity can be calculated in a variety of different ways, including, but not limited to, cosine similarity, dot product, Euclidean distance, etc.

[0016] As an example, assume that a customer provides a PFD as design input. The PFD may include a level of detail commonly found in PFDs. More generally, the PFD may include a level of detail corresponding to a first level in a design document hierarchy associated with designing a process automation facility. The design document hierarchy may reflect the level of abstraction or detail included in design documents provided at various stages of designing and / or building the process automation facility. Each level in the design document hierarchy may reflect documents with a level of detail or abstraction typically associated with a particular stage in the design process. Figure 3 illustrates a design process cycle illustrating different stages, and therefore different levels, of such a hierarchy of design documents. Returning to this example, the reference embedding may include a similar level of detail or abstraction, for example, the amount of detail that may be found in a PFD created for the reference process automation facility, or more generally, the amount of detail corresponding to a first level in the design document hierarchy.

[0017] For example, the PFDs initially created during the development of those reference process automation equipment may be used to generate the first-level reference embeddings, e.g., in real time or in advance. Alternatively, the first-level reference embeddings may include much more detail (e.g., much more populated dimensions), e.g., generated from comprehensive details about the reference process automation equipment. In the latter case, the semantically rich embeddings generated based on the corresponding customer input may have similar dimensionality, but many of those dimensions are not populated because the customer did not provide those details. In yet other implementations, customer input may be used to populate as many dimensions as possible. Then, the reference embeddings of those same dimensions may be populated from relevant data points included in the federated information model associated with the reference process automation equipment.

[0018] Once one or more first-level reference embeddings are identified, in various implementations, they can be utilized as representations of knowledge of the reference process automation equipment to automate the design of the required process automation equipment. For example, in some implementations, each of the one or more first-level reference embeddings can be mapped to one or more second-level reference embeddings, e.g., via a function such as a trained feedforward neural network. Each of the one or more second-level reference embeddings can encode “second-level” information about a respective one of the multiple reference process automation equipment. The second-level information can refer to a level of detail or abstraction corresponding to the second level of the design document hierarchy described above. Documents at the second level of the design document hierarchy can have more detail and / or narrower scope than documents at the first level of the design document hierarchy. Based on the identified one or more second-level reference embeddings, one or more template design documents for the required process automation equipment can be provided, for example, as a starting point for designing the required process automation equipment.

[0019] As one example, a second-level reference embedding may include more detail than a PFD, such as detail commensurate with the level of detail found in a piping and instrumentation diagram (P&ID). Thus, for example, a customer may provide a high-level PFD that can be processed into a first embedding. This first embedding can be used to find one or more similar first-level reference embeddings that represent PFD-level detail in one or more reference process automation equipment. These one or more first-level reference embeddings can each be mapped to one or more second-level reference embeddings that each represent P&ID-level detail (e.g., by being generated from actual P&IDs) of one or more reference process automation equipment. These details can then be used to generate, or retrieve if already existing, a template P&ID for at least a portion of the requested process automation equipment.

[0020] Substitutions are contemplated, except for finding similar PFDs and generating P&IDs. For example, in some implementations, a customer may provide details about the central control room (CCR) of a requested process automation facility as first-level information. These CCR details may include details about, for example, human-machine interfaces (HMIs), alarms, distributed control system (DCS) controllers, safety information system (SIS) controllers, fire and gas system (FGS) controllers, asset management systems, advanced process control, third-party systems, etc. An embedding may be generated using these various details. As previously described, this embedding may be compared to a reference embedding representing the CCR of a reference process automation facility. The most similar N (a positive integer) first-level reference embeddings may be mapped to several second-level reference embeddings. These second-level reference embeddings may represent, for example, details about field equipment rooms (FERs) at the reference process automation facility. Thus, the second-level reference embeddings may be used to generate template designs, I / O summaries, and / or lists for the FERs at the requested process automation facility.

[0021] In some implementations, there may be some form of selection from the second-level reference embeddings, for example, based on one or more additional criteria. For example, the first-level information provided by the customer may include a finer level of detail than would be included in the PFD. The details provided by the customer in the first-level information, which typically correspond to the details found in the PFD, may be used to identify one or more first-level reference embeddings. Additional details provided by the customer, which may or may not have been used to find the first-level reference embeddings, may then be used to select from multiple second-level reference embeddings mapped by one or more first-level embeddings.

[0022] In some implementations, a customer may provide information incrementally, and at each increment, additional searches may be performed. For example, a customer may provide a PFD as initial input, which may be used to select any number of first-level reference embeddings as potential matches. The customer may then provide additional input in response to prompts requesting additional details, which may be usable, for example, to further narrow the search space of first-level embeddings or to narrow the search space of second-level embeddings. For example, a customer may provide natural language input describing additional details of the process automation equipment the customer desires, or may indicate specific portions (e.g., CCR, FER) of the required process automation equipment that the customer wants to design or has initially designed.

[0023] Process automation equipment and / or aspects thereof may be represented in a federated information model in a variety of ways. In some implementations, the process automation equipment may be represented in whole or in part by one or more graphs. Representing the entire process automation equipment or portions thereof (e.g., FER, P&ID, PFD, circuit diagram, network topology, etc.) as a graph may enable the use of machine learning models, such as graph neural networks (GNNs), to process the graph and generate embeddings that semantically represent not only the nodes of the graph but also the relationships between the nodes of the graph. Thus, by representing the first level of information provided by a user as a graph and / or by representing aspects of the reference process automation equipment as a graph, it is possible to generate embeddings that represent not only the individual components of the process automation equipment but also the relationships between those components. This makes the various comparisons of embeddings described herein more accurate.

[0024] As one example, a first-level graph may be used to represent an entire process automation facility or a portion thereof. Such a first-level graph may include, for example, multiple nodes representing multiple processes to be implemented in the required process automation facility. Multiple edges may also be included, defining relationships between multiple processes. Such a graph may have a level of detail commensurate with a particular level in the design document hierarchy, such as a level including a PFD and other similarly detailed documents.

[0025] As another example, one or more second-level graphs may be used to represent one or more portions of a process automation facility at levels of detail corresponding to different levels in the design document hierarchy. For example, a second-level graph may include multiple nodes representing multiple process automation nodes (e.g., DCNs, input / output nodes, etc.) to be implemented in a required process automation facility. The graph may also include multiple edges representing, for example, network communication channels between multiple process automation nodes.

[0026] As previously mentioned, a process automation facility may include a large number of process automation nodes. For example, representing each node individually as a node in a graph may result in an unmanageable amount of data. Many assemblies of process automation nodes are used repeatedly, for example, across multiple process automation facilities. For example, an air dryer may include several process automation nodes (e.g., hundreds) that cooperate to automate the air drying process. Such assemblies may be designed to be modular, e.g., pre-fabricated and / or pre-planned, so that they may be used in the same or substantially similar manner in multiple different process automation facilities. In some implementations where a graph is used to represent at least a portion of a process automation facility, one or more nodes may represent one or more pre-planned modular automated process assemblies to be implemented in the required process automation facility. At least some edges of the graph may define relationships between the one or more pre-planned process automation assemblies and other elements of the required process automation facility.

[0027] The examples described herein primarily involve first finding embeddings of greater abstraction and / or less detail (e.g., a first level) and then mapping those abstract embeddings to embeddings of less abstraction and more detail (e.g., a second level). However, this is not intended to be limiting. These mappings may be used in other ways to bootstrap and / or otherwise automate process automation equipment design. For example, a less abstract embedding (e.g., representing a P&ID, an individual FER) may map to an embedding of a greater abstraction (e.g., representing a PFD, a CCR, a control safety narrative, etc.). As another example, an embedding may map to other embeddings at a corresponding level of abstraction. For example, an embedding representing an FER may map to an embedding representing one or more other FERs that fit the first FER as, for example, a subordinate companion of a CCR. In terms of a design document hierarchy, an embedding at any level of the design document hierarchy may map to an embedding at any other level of the design document hierarchy, including the same level.

[0028] To illustrate, assume that a customer provides as input information about one or more sub-portions of a required process automation facility. For example, the customer may provide information about one or more of the aforementioned modular automated process assemblies that the customer wants incorporated into their plant. In some implementations, one or more embeddings may be generated based on the characteristics of these modular automated process assemblies. For example, each assembly may be represented as a graph. In some cases, a larger graph may be created based on each assembly's individual graph (and based on heuristics that embody a common process flow), but this is not required. Techniques such as GNNs may then be applied to generate semantically rich embeddings that can be mapped to reference embeddings that can be used to design CCRs and one or more FERs to accommodate the desired configuration of the modular automated process assembly. In some such implementations, such a graph may include multiple nodes representing multiple processes to be implemented in the required process automation facility and multiple edges defining relationships between the multiple processes. In other such implementations, the graph may include multiple nodes representing multiple process automation nodes to be implemented in the required process automation facility and multiple edges representing network communication channels between the multiple process automation nodes.

[0029] 1 schematically illustrates an exemplary environment in which selected aspects of the present disclosure may be implemented, according to various embodiments. A user (not shown), such as a representative of an end customer (e.g., a company) desiring new process automation equipment or modifying and / or updating existing equipment, may operate a client device 10 to interact with an integrated development environment (IDE) 12 to design aspects of the desired process automation equipment. The IDE 12 may communicate with a process automation design system 20, for example, directly or via one or more computer networks (not shown).

[0030] The process automation design system 20 may be configured in accordance with selected aspects of the present disclosure to facilitate at least partially automated design of process automation equipment. The process automation design system 20 may include an intake module 22, an encoder module 24, a matcher 26, and a template module 28. One or more of the modules 22-28 may be combined with others of the modules 22-28, implemented outside the process automation design system 20 (e.g., entirely or partially on the client device 10), etc. In some implementations, the process automation design system 20 may be implemented on one or more server computer systems forming what is often referred to as a "cloud infrastructure" or simply "the cloud."

[0031] The process automation design system 20 may also include one or more databases for storing various information used, modified, or created by the modules 22-28. For example, a reference process automation equipment ("PAF" in FIG. 1) database 30 may contain information about reference process automation equipment, whether it still exists or existed at some time in the past. In some implementations, information about a given reference process automation equipment may be stored in the database 28 as a "federated information model." A federated information model may organize information about a given reference process automation equipment in a consistent and standardized manner. Thus, the same type of information about different reference process automation equipment may be accessed using similar techniques, such as the same function calls.

[0032] In some implementations, the federated information model may organize information about the reference process automation equipment as a graph, for example, with nodes representing process automation nodes (e.g., DCNs) and edges representing logical and / or communication paths between the process automation nodes. In some such implementations, such a graph may be encoded, for example, by encoder module 24, into a semantically rich embedding that represents various aspects of the reference process automation equipment at a selected dimension and / or level of detail corresponding to some level of the design document hierarchy. For example, a GNN or other similar machine learning model may be used, for example, by encoder module 24, to encode individual nodes of the graph into embeddings. These embeddings may then be propagated along edges to neighboring nodes over a number of iterations (which may be hyperparameters of the GNN). The data propagated along edges may be processed, for example, by encoder module 24, using a machine learning model such as a feedforward neural network. The data of neighbors may be integrated and / or combined with the data of a given node in various ways, such as concatenation, averaging, etc. The more iterations of the GNN, the more information from increasingly distant nodes is incorporated into each given node.

[0033] Machine learning (ML in FIG. 1 ) database 32 may store various different machine learning models (e.g., weights associated with those machine learning models) used using the techniques described herein. For example, ML database 32 may store machine learning models used by intake module 22 to capture data from different design documents or other data sources about the reference process automation equipment, to generate a federated information model or portions thereof, and / or to generate reference embeddings that may or may not form part of the federated information model, by encoder module 24 to generate semantic embeddings from different design inputs, by matcher 26 to match semantic embeddings with other similar semantic embeddings, by template module 28 to retrieve information stored in reference PAF database 30 as part of the federated information model, etc.

[0034] Intake module 22 may be configured to use any number of techniques to capture, acquire, retrieve, collect, and / or otherwise obtain information about the reference process automation equipment. Intake module 22 may then process this captured information into a federated information model. Intake module 22 may store this federated information model in reference PAF database 30. Individual data points or collections of data points may then be easily retrieved from this federated information model.

[0035] Intake module 22 may process a variety of different types of documents to obtain this data. These documents may be structured or unstructured. Structured documents may include, for example, markup language documents (e.g., XML, JSON), vector-based graphics files, or other similar types of documents (e.g., ODF, VSD, VSDX, XPS, etc.) created and / or modified using appropriate software applications. Due to their known structure, structured documents may be processed methodically to extract information, for example, using rules, heuristics, etc. In contrast, unstructured documents may lack such underlying structural details. Unstructured documents may include, for example, raster image files or raster Portable Document Format (PDF) files, or documents containing narrative natural language prose. Extracting information from unstructured documents may be performed using, for example, object recognition, optical character recognition (OCR), natural language processing (NLP), etc.

[0036] In some implementations, one or more machine learning models, such as a convolutional neural network (CNN), may be trained using supervised or unsupervised techniques so that they can be used by intake module 22 to automatically extract information of interest from unstructured documents. As an example, the machine learning model may be trained using labeled raster blueprints of a plant's physical layout, in which visual elements of interest (e.g., FERs, CCRs, instruments, tags, etc.) are annotated with ground truth annotations, such as bounding boxes and / or pixel-wise annotations. These annotated images may be processed using the machine learning model to generate output, which may include the extracted features in the form of predicted annotations. The output (e.g., predicted annotations) may then be compared to the ground truth annotations to generate an error. Based on this error, techniques such as backpropagation and gradient descent may be performed to train the weights of the machine learning model.

[0037] In some implementations, structured documents can be leveraged to create synthetic training data that can supplement or replace human-labeled training data. For example, vector-based graphics files illustrating physical plant layouts can be rasterized into unstructured versions, and visual elements from which features can be extracted are pre-rendered with annotations such as bounding boxes, pixel-wise annotations, etc. These rasterized and annotated images can be used to train machine learning models as previously described.

[0038] Once trained, the machine learning model may be used, for example, by intake module 22, to process unlabeled and unstructured documents to extract relevant information and / or features. For example, a central control room (CCR) 201, one or more field equipment rooms (FERs) 202, 1~N , junction box, instrument 204 1~N 2, such as the elements of the design, and / or the connections or edges between them. These features can be used, for example, by intake module 22, to generate reference embeddings that can be easily compared (e.g., by matcher 26) to other embeddings. Mapping from these reference embeddings can lead to other reference embeddings that represent other documents with levels of detail corresponding to different levels in the design document hierarchy. The documents represented by these other reference embeddings can be used, for example, by template module 28, to generate template architecture documents such as P&IDs, PFDs, schematic diagrams, network topology plans / diagrams, etc.

[0039] Encoder module 24 may be configured to obtain information, such as data extracted from design inputs or other reference process automation equipment information by intake module 22, and encode this information into semantic embeddings (or simply “embeddings”). In the context of reference information stored in reference PAF database 30, encoder module 24 may encode all or a portion of a federated information model representing the reference process automation equipment. For example, the entire reference process automation equipment may be represented as a hierarchy of graphs. Encoder module 24 may encode this hierarchy of graphs into one or more embeddings using, for example, a machine learning model, such as a GNN, stored in ML database 32. Such embeddings may be readily compared, for example, by matcher 26, to other similarly created reference embeddings, such as reference embeddings generated from graphs created based on design inputs describing the process automation equipment to be built, to determine a measure of similarity.

[0040] As mentioned above, matcher 26 may be configured to compare data indicative of process automation equipment with data indicative of other process automation equipment to find a “match.” As used herein, a match may be found when two or more pieces of process automation equipment are sufficiently similar to one another that design documents created for one of the pieces of process automation equipment can be leveraged to provide template design documents for the other pieces of process automation equipment. When comparing semantic embeddings, matcher 26 may use techniques such as Euclidean distance, cosine similarity, dot product, etc. Otherwise, matcher 26 may use various rules and / or heuristics to compare individual data points, which may or may not be weighted in various ways depending on various factors. As one non-limiting example, the type or overarching goal of the process automation equipment (e.g., gas refining, hydraulic fracturing) may be weighted more heavily than other factors, such as lower-level design alternatives within the FER.

[0041] In some implementations, template module 28 may be configured to retrieve, acquire, generate, and / or provide template design documents to a user of client device 10 based on operations performed by modules 22-26. For example, if a user provides a high-level control narrative for a desired process automation facility at client device 10, template module 28 may return one or more lower-level design documents, such as a physical plant layout (see FIG. 2 for illustrative examples), PFD, P&ID, schematic diagram, network topology, and any other design documents based on one or more reference process automation facilities.

[0042] FIG. 2 schematically illustrates an example of a physical plant layout 200 for a process automation facility. What is illustrated in FIG. 2 may be contained in, for example, a structured or unstructured document. Intake module 22 may process such a document to extract relevant features. These features may be used, for example, by intake module 22 to generate a federated information model that is stored in database 30. Additionally or alternatively, these features may be encoded by encoder module 24 to create a semantic embedding that represents physical plant layout 200 in a form that can be easily compared to other similarly created embeddings.

[0043] Starting from the top, the central control room (CCR) 201 may include various devices that may be used to control process automation equipment. These devices may include, but are not limited to, one or more computing systems, circuitry, and / or hardware that implement and / or otherwise provide a human-machine interface (HMI) to control alarm management systems, distributed control systems (DCS), safety instrumented systems (SIS), and / or fire and gas system (FGS) controllers, open platform communication (OPC) servers, asset management systems, historians and / or logging systems, advanced process control systems, third-party systems and / or controllers, etc.

[0044] Multiple Field Equipment Rooms (FER) 202 1~N (N is a positive integer) are shown in network communication with CCR 201 via one or more process automation networks 206. Process automation networks 206 may include one or more personal area networks (PANs), such as a Bluetooth network, one or more local area networks (LANs), such as a Wi-Fi network, one or more mesh networks (e.g., Z-Wave, ZigBee), and / or one or more wide area networks (WANs), such as the Internet. When process automation equipment is considered as a hierarchy, FER 202 1~N may be considered subordinate to and / or at a lower level than CCR 201. In various implementations, FER 202 may include a subset of the HMIs available in CCR 201, such that the HMIs in FER 202 may be operated to control only a portion of the process automation equipment. For example, FER 202 may not necessarily include an HMI for an OPC server or an asset management system, although this is not intended to be limiting.

[0045] Each FER 202 may be operatively coupled to a respective meter 204 via one or more junction boxes (JBs). A junction box is an enclosure, typically constructed of plastic and / or metal, for housing wire connections and often includes passive electronic components such as fuses, relays, etc. In some implementations, one or more of the junction boxes may take the form of a “smart” junction box. A “smart” junction box may integrate a microcontroller or other similar circuitry with relays and / or fuses to facilitate further control. The meter 204 associated with the FER 202 (e.g., controllable using the FER 202's HMI) may include, for example, input / output elements such as actuators or sensors, as well as other process automation nodes such as the DCN 210.

[0046] Some non-limiting examples of actuators include, but are not limited to, valves, pistons, rotors, switches, heaters, coolers, stirrers, injectors, devices for creating a vacuum, belts, tracks, gears, grippers, motors, relays, servo machines, etc. Sensors can take a variety of forms, including, but not limited to, pressure sensors, temperature sensors, flow sensors, various types of proximity sensors, optical sensors (e.g., photodiodes), pressure wave sensors (e.g., microphones), humidity sensors (e.g., humistors), radiation dosimeters, laser absorption spectroscopy (e.g., multi-pass optical cells), etc.

[0047] FIG. 3 schematically illustrates, at a high level, an exemplary process for designing and / or developing a process automation system / equipment. The development process is illustrated as cycles 310 because the process often involves multiple iterations in which various types of design input are received from various entities, such as an end customer who has requested the system, engineering, procurement, and construction (EPC) personnel, etc., to be involved in the design and / or implementation process. Often, the design input received during each iteration may be more detailed than the design input received during previous iterations because, for example, various entities have articulated more detailed views of what they want, how they want to implement it, technical constraints, etc. In this manner, FIG. 3 also illustrates a design document hierarchy, with higher-level documents being more general and / or less detailed, while lower-level documents are less general and / or more detailed or focused.

[0048] Designing a process automation facility (whether a new facility or an update to an existing facility) can begin at various points with various types of design input, depending, for example, on how much detail the end customer is ready to provide. Each type of design input may or may not correspond to a level in the design document hierarchy, depending on how specific and / or prescriptive those levels are.

[0049] For purposes of explanation, it is assumed that the first design inputs provided by the end customer are high-level project specifications and / or requirements 312. These data may include, for example, high-level goals for the process automation system and / or its components. The high-level project specifications and / or requirements 312 may be provided in various forms of documentation, such as free-form narrative / prose, flowcharts (e.g., high-level PFDs), requirements checklists, etc. Another relatively high-level design input is the control safety narrative 314. These data may include, for example, free-form prose, flowcharts, requirements, and / or other information that conveys how aspects of the process automation system are controlled and / or how safety protocols are implemented.

[0050] Another design input that may be received as part of the cycle 310, before or after the design inputs 312-314, is operational alarm management policies and / or standard operating procedures (SOPs) 316. This data may include, for example, general guidelines and procedures for operating the process automation system and for triggering alarms in the process automation system.

[0051] Further along the cycle 310 are design inputs that have more detail and therefore may be considered to belong to lower levels of the design document hierarchy. Physical plant layout design input 318 may include information about how the process automation systems / equipment are physically laid out, at various levels of detail. Physical plant layout design input 318 may include, for example, blueprints, architectural mockups, etc. Figure 2 illustrates one example of how a physical plant layout (200) may be manifested in a document.

[0052] The instrumentation database design input 322 may include, for example, a wiring module 3201, an instrument index 3202, and / or a plant hierarchy 3203. The wiring module 3201 may include, for example, information about junction boxes (including “smart” junction boxes), hardware cabinets (e.g., where DCNs, rack servers, etc. are mounted), etc. The instrument index 3202 may include, for example, a list or database of instruments such as sensors, actuators, DCNs, etc. The plant hierarchy 3203 may indicate, for example, particular areas of the desired process automation plant and the units and / or equipment in those areas. Finally, in cycle 310, a process flow diagram (PFD) 326 may be provided, for example, in conjunction with or based on one or more P&IDs 324.

[0053] The various design inputs 312-326 provided during cycle 310 may be provided in any order and at any time. Cycle 310 itself may repeat, in whole or in part, as additional design inputs and / or additional details associated with each design input are received. Additionally, using techniques described herein, the various design inputs may be used to automatically generate templates for other design inputs for which information is missing. In some implementations, the various design inputs may be mapped to various other design inputs, for example, across various levels of a design document hierarchy. These mappings may be leveraged as described herein to automate aspects of process automation system design.

[0054] For example, one or more of the design inputs for a required process automation equipment may be processed to generate a first embedding. The first embedding may encode one or more aspects of the required process automation equipment at a level of detail or abstraction corresponding to a design document hierarchy. The first embedding may be compared to a plurality of first-level reference embeddings to select one or more first-level reference embeddings that meet a first criterion. The plurality of first-level reference embeddings may encode aspects of a respective plurality of existing process automation equipment at a level of detail or abstraction corresponding to the same level in the design document hierarchy.

[0055] Based on the mapping from the selected one or more first-level reference embeddings, one or more second-level reference embeddings may be identified. In various implementations, each of the one or more second-level reference embeddings may encode second-level information about a respective one of the plurality of existing process automation equipment at a second level of detail or abstraction corresponding to a second level of the design document hierarchy that generally has a higher level of attention or detail than the first level of the hierarchy. Based on the identified one or more second-level reference embeddings, one or more template design documents for the requested process automation equipment may be provided.

[0056] 3 may be included in documents that can be processed using the techniques described herein to extract information for generating template design documents and / or other templates for the required process automation equipment. For example, a variety of different documents that are non-textual or at least partially graphical may be processed, for example, by intake module 22, to extract features and / or information that can be used by encoder module 24 to generate semantic embeddings. In some implementations, these semantic embeddings may be used and / or stored as part of a federated information model.

[0057] FIG. 4 schematically illustrates an exemplary high-level process flow 400 for a hypothetical process automation facility. FIG. 4 illustrates how various units 430A-S may be implemented in and / or controllable by equipment within (or otherwise associated with) various different FERs, which are shown on the right (FERs #1, #2, #3, #4, #5, and #12) and in the center (FER #11). Like the physical plant layout design input 318 in FIG. 3, the process flow 400 illustrated in FIG. 4 may be contained in a structured or unstructured document. As previously explained, such a document (or portions thereof) may be processed using the techniques described herein to generate a semantic embedding. This semantic embedding may be matched against a reference embedding, which includes a mapping to other embeddings (at various levels of the design document hierarchy) representing other documents (e.g., PFDs, P&IDs, schematics, etc.) associated with the existing process automation facility. These other documents can be used as the basis for a template design document for designing new process automation equipment.

[0058] Flow proceeds from top to bottom in Figure 4. The exemplary process illustrated in Figure 4 includes process units that may be implemented as part of a liquid natural gas liquefaction plant, but this is not intended to be limiting. Starting from the top, in blocks 430A-B, gas wells and inlet processing for offshore oil extraction are controlled in a first FER #1. A second FER #2 controls the processes in blocks 430C-D. Block 430C represents a common or shared CO2 compression process unit. Block 430D represents a common or shared acid gas removal process unit.

[0059] At this point, the overall process splits into two parallel "trains." The left train corresponds to the sequence of process units controlled by FER #11. The right train corresponds to the sequence of process units controlled by FER #12. Because the two trains are nearly identical, only the process units in the first left train will be described in detail.

[0060] Block 430E corresponds to a CO2 compression process unit that operates only on the oil processed by the left train (controlled by FER #11). The oil processed by the right train (FER #12) is processed by a separate CO2 compression process unit. Similarly, block 430F corresponds to an acid gas removal process unit that operates only on the oil processed by the left train (controlled by FER #11). Moving down the rest of the left train, block 430G corresponds to a dehydration process unit, block 430H corresponds to a mercury removal process unit, block 430I corresponds to a liquefaction process unit, block 430J corresponds to a fractionation process unit, block 430K corresponds to a heat transfer medium system process unit, block 430L corresponds to a fuel gas process unit, block 430M corresponds to a cooling / enrichment system process unit, and block 430N corresponds to a flare vent system process unit.

[0061] Upon exiting the left train, both trains lead to a refrigerant storage process unit at block 430O. This refrigerant storage process unit 430O, as well as a condensate storage process unit (block 430P) and a liquefied natural gas (LNG) storage and boil-off gas (BOG) treatment process unit (block 430Q), are controllable by FER #3. The output from the process units controlled by FER #4 then passes to an LNG jet fueling facility process unit at block 430R, which is controlled by FER #4. Finally, miscellaneous downstream utilities at block 430S are controlled by FER #5.

[0062] 4 may be implemented using one or more process automation nodes, including, but not limited to, inputs such as sensors, outputs such as actuators, and other nodes such as a DCN configured for computational purposes. One or more of the process units 430A-S may also be designed using documents such as a PFD and / or P&ID. An arrow extending from the liquefaction process unit 430I in the right-hand process train points to a PFD 432 and corresponding P&ID 434 for implementing that liquefaction process unit. 1~N These arrows show how PFD432 can be used to represent multiple different P&IDs434. 1~N In other words, the PFD 432 indicates whether it can correspond to (e.g., include) the P&ID 434. 1~N may belong to a higher level in the design document hierarchy.

[0063] In some implementations, all or portions of the process flow 400 can be utilized to provide a template design document. For example, information about the process units 430A-S of the process flow 400 can be extracted from a structured or unstructured document to generate a graph, e.g., by the intake module 22. The encoder module 24 can encode this graph into a reference semantic embedding at a first level of abstraction. The matcher 26 can match this semantic embedding with one or more reference embeddings representing one or more reference process automation equipment at a similar level of abstraction to the process flow 400. These mappings from these reference embeddings can lead to reference embeddings at different levels. The template module can take the documents represented by these different levels of reference embeddings and return them with or without preprocessing, e.g., to remove temporary or extraneous data.

[0064] FIG. 5 schematically illustrates an example of how embedding spaces 540, 542, 544, 546, and 548 and the mappings between them can be utilized to facilitate providing template design documents for new or updated process automation equipment, according to various implementations. The embedding spaces 540, 542, 544, 546, and 548 are illustrated with two dimensions. However, this is for ease of understanding only and is not intended to be limiting. The embedding spaces 540, 542, 544, 546, and 548 may have as many dimensions as the individual embeddings contained therein. Similarly, it is not necessary that various documents (or, more generally, information at different levels of abstraction) be encoded in separate embedding spaces. The embedding spaces 540, 542, 544, 546, and 548 are illustrated as separate spaces in FIG. 5 for ease of understanding only. Furthermore, neither the number of embeddings and embedding clusters illustrated in FIG. 5 nor the illustrated mappings between the embeddings and embedding clusters are intended to be limiting. Rather, they are presented for illustrative purposes.

[0065] The first embedding space 540 includes embeddings (small white circles) that represent the “first level” of information about the process automation equipment required to generate the first embedding. Each embedding in the first embedding space 540 encodes one or more aspects of the process automation equipment at a level of detail or abstraction corresponding to the first level of the design document hierarchy described above. Examples of first level information for the process automation equipment may include, for example, the project specification and / or requirements 312, the control safety narrative 314, the operational alarm management and standard operating procedures 316, and other similarly high-level information of FIG. 3 . In many cases, the first level of information represented by the embeddings in the first embedding space 540 may be at a level of abstraction similar to the initial information received or provided when designing new process automation equipment.

[0066] In FIG. 5, the first embedding space 540 is a set of multiple clusters 540 of embeddings. 1~4 Each cluster may include embeddings that encode information about process automation equipment that is similar in various ways. In some implementations, the similarity between embeddings in any of the embedding spaces 540, 542, 544, 546, or 548 may be determined by matcher 26 by comparing the individual embeddings using techniques such as Euclidean distance, cosine similarity, dot product, etc. For example, first cluster 5401 may include embeddings generated based on a first level of information about natural gas refineries. Second cluster 5402 may include embeddings generated based on a first level of information about offshore oil extraction and processing equipment. Third cluster 5403 may include embeddings generated based on a first level of information about hydraulic fracking equipment. Fourth cluster 5404 may include embeddings generated based on a first level of information about nuclear fuel processing equipment.

[0067] The second embedding space 542 includes individual embeddings (small white circles) that represent "second level" information about the process automation equipment. Similar to the first embedding space 540, each of the one or more second level reference embeddings in the second embedding space 542 encodes second level information about the existing process automation equipment at a level of detail or abstraction corresponding to a second level in the design document hierarchy. For example, each embedding in the first embedding space 540 may represent a high-level description (e.g., narrative, specification) of the process automation equipment or a portion thereof, while each embedding in the second embedding space 542 may represent a lower-level description of a portion of the process automation equipment, which in FIG. 2 is assumed to be a PFD. Also similar to the first embedding space 540, in the second embedding space 542, embeddings are organized into clusters 542 of embeddings. 1~4 In some cases, the clusters of embeddings may represent PFDs that are semantically similar to one another (e.g., may represent similar PFDs). Additionally or alternatively, in some implementations, the clusters of embeddings may represent PFDs used in the same process automation equipment. In this way, the second embedding space 542 may be indexed in part based on distinct process automation equipment.

[0068] Various mappings are illustrated in FIG. 5 as double-headed arrows between various embeddings, clusters of embeddings, embedding spaces, etc. Each mapping may represent a similarity function. In some implementations, these mappings (and other mappings illustrated in FIG. 5 and described elsewhere herein) may be learned using a machine learning model, such as, for example, a feedforward neural network. Such machine learning models may be trained using similarity learning techniques, such as, for example, triplet loss, covariance matrix, locality-sensitive hashing, etc. In triplet loss, for example, a "baseline" or "anchor" input is compared to a "positive" or "true" input and a "negative" or "false" input. The distance (e.g., Euclidean, cosine similarity, etc.) between the anchor input and the positive input may be minimized. The distance between the anchor input and the negative input may be maximized.

[0069] Illustrated are multiple mappings 541A-D from embeddings in a first embedding space 540 to clusters of embeddings in a second embedding space 542. The mappings 541A-D effectively map individual instances of first level information (embeddings in the first embedding space 540) about existing and / or past (collectively "past") process automation equipment to clusters of embeddings in the second embedding space 542. For example, the first mapping 541A maps an embedding representing the first level of information for a given piece of process automation equipment to a first cluster 5421 of embeddings representing multiple PFDs associated with (e.g., describing portions of) that same piece of process automation equipment. The second mapping 541B maps an embedding representing the first level of information for another piece of process automation equipment to a second cluster 5422 of embeddings representing multiple PFDs associated with (e.g., describing portions of) that same piece of process automation equipment.

[0070] A third mapping 541C maps embeddings representing first level information for a third piece of process automation equipment to a third cluster 5423 of embeddings representing multiple PFDs associated with (e.g., describing parts of) that same piece of third process automation equipment. A fourth mapping 541D maps embeddings representing first level information for a fourth piece of process automation equipment that is part of a different cluster (5404) to a fourth cluster 5424 of embeddings representing multiple PFDs associated with (e.g., describing parts of) that same piece of fourth process automation equipment. Other mappings are possible but are omitted for brevity and clarity.

[0071] In various implementations, these mappings 541A-D can be leveraged to automate aspects of a process automation system design. For example, a user can provide first-level design input, such as a project specification or requirements 312, in a document, such as an email, a PDF, or a transcript of a phone call or voicemail. This design input can be processed by intake module 22 (e.g., using NLP, OCR, object recognition, etc.) to generate a semantic embedding 539, which is represented in first embedding space 540 as a black star. Semantic embedding 539 is found to be close to, and therefore similar to, the embedding of second cluster 5402 in first embedding space 540. Thus, it can follow any of mappings 541A-C to embeddings for second embedding space 542. For example, semantic embedding 539 is closest to the embedding at one end of third mapping 541C, which leads to third cluster 5423 of embeddings in second embedding space 542. Thus, one or more of the PFDs represented by the embeddings of the third cluster 5423 of embeddings in the second embedding space 542 may be retrieved and provided to a user as templates, either "as is" or after some form of preprocessing has been performed (e.g., to remove sensitive, transient, or irrelevant information).

[0072] As indicated by the double-headed arrows, mappings 541A-D (and other mappings described herein) are not limited to mappings from lower levels to lower levels in the design document hierarchy. These mappings can also be utilized in reverse. For example, a user may provide one or more PFDs 326 as design input. These one or more PFDs 326 may be processed in various ways, depending on whether they are structured or unstructured, to generate semantic embeddings in the second embedding space 542. The mappings from the second embedding space 542 back to the first embedding space 540 may then be used to generate documents at a higher level of abstraction than the PFDs 326, such as, for example, project specifications / requirements 312, control safety narratives, etc.

[0073] 5, a third embedding space 544 may contain embeddings representing a third level of information, such as P&IDs 324 used in historical process automation facilities. The third embedding space 544 may include three clusters of embeddings 544 1~3 Each cluster may contain embeddings that are semantically similar to one another because, for example, the underlying P&IDs have many shared characteristics, the underlying P&IDs are part of the same process automation equipment, are controlled by the same FER, were used in semantically similar process automation equipment, etc. As before, mappings 543A and 543B may represent a similarity function learned between embeddings (representing individual PFDs) in second embedding space 542 and third-level embeddings (representing P&IDs) in third embedding space 544. Thus, as before, a PFD represented by an embedding in second cluster 5422 of second embedding space 542 may connect to first cluster 5441 of third embedding space 544 via mapping 543B. The four embeddings in first cluster 5441 may represent four P&IDs 324 that may be provided to a user as template P&IDs.

[0074] The fourth embedding space 546 may, for example, contain embeddings (white circles) that represent network topologies used in past process automation installations. The fourth embedding space 546 contains three clusters 546 1~3 Each cluster includes embeddings that represent network topologies that are semantically similar to each other, used in similar contexts (e.g., in the same or similar process automation equipment), etc.

[0075] Two mappings 545A-B are shown between the third embedded space 544 and the fourth embedded space 546. One mapping 545A is between an individual embedding representing an individual P&ID in the third embedded space 544 and a first cluster 5461 of embeddings in the fourth embedded space 546 representing four different network topologies. Mapping 545A may indicate, for example, that the same P&ID was implemented in four different historical process automation facilities where four different network topologies were implemented.

[0076] The other mapping 545B between the third embedded space 544 and the fourth embedded space 546 is between a cluster 5443 of embeddings representing four different P&IDs in the third embedded space 544 and individual embeddings representing individual network topologies in the second cluster 5462 of the fourth embedded space 546. Mapping 545B may indicate, for example, that the same network topology was implemented in four different historical process automation facilities in which four different P&IDs were implemented. Mappings 545A and 545B illustrate the more general principle that the mapping between two given embedded spaces is not limited to a cluster on one side and an individual embedding on the other side. Rather, an individual embedding in either embedded space may map to a cluster or individual embedding in the other space, and vice versa.

[0077] A fifth embedding space 548 is illustrated in Figure 5, which contains embeddings (small white circles) that represent physical plant layouts, such as 200 illustrated in Figure 2. For example, three clusters of embeddings 548 correspond to semantically / physically similar physical plant layouts: 1~3 5 is illustrated. Mappings 547 and 549A-B are illustrated between the fifth embedding space 548 and other embedding spaces of FIG. 5 , illustrating how mappings between any type of document and / or level in the design document hierarchy can be learned. For example, mapping 547 extends between an individual network topology in the fourth embedding space 546 and a second cluster 5482 of physical plant layout embeddings in the fifth embedding space 548. This may indicate, for example, that the same network topology was used in four different physical plant layouts represented by the four embeddings in the second cluster 5482.

[0078] Mapping 549A extends between a first cluster 5481 of embeddings representing physical plant layouts and the individual PFD embeddings in the second embedding space 542. This may indicate, for example, that the four different physical plant layouts represented by the embeddings of the first cluster 5481 all included the same PFDs for at least some portion of the process automation equipment. Mapping 549B extends between a second cluster 5482 of embeddings representing physical plant layouts and a fourth cluster 5424 of embeddings in the second embedding space 542. This may indicate, for example, that the four different physical plant layouts represented by the embeddings of the second cluster 5482 all included the same four PFDs represented by the embeddings of cluster 5424.

[0079] In some implementations, individual embeddings may represent (e.g., be generated from) an underlying graph. For example, documents such as PFDs, P&IDs, and network topologies may be represented as graphs. In a PFD, for example, each graph may include multiple nodes representing multiple processes to be implemented in a required process automation facility (e.g., processes 430A-S in process flow 400). Multiple edges may define relationships between multiple processes. Such graphs may be encoded by encoder module 24, for example, using a GNN, into one of the semantic embeddings illustrated in the third embedding space 544 of FIG. 5.

[0080] In the context of a network topology (e.g., the embedding of the fourth embedding space 546), a graph may include nodes representing process automation nodes (e.g., DCNs) to be implemented in a required process automation facility. Corresponding edges may represent network communication channels between the process automation nodes. Thus, each embedding in the fourth embedding space 546 of FIG. 5 may represent such a graph. In the context of a physical plant layout (e.g., the embedding of the fifth embedding space 548), a graph may include nodes corresponding to areas or process units, such as CCRs and FERs, and junction boxes, and edges corresponding to network communication channels between the various areas or process units. Thus, each embedding in the fifth embedding space 548 may represent such a graph.

[0081] FIG. 6 illustrates schematically one example of how design inputs may be processed to generate template design documents. Starting on the left, the design inputs are processed into one or more FERs (202 in FIG. 2). 1~NThe amount of DCN for a given FER may take the form of one or more input / output (I / O) summaries 670 for that FER (see ). In block 672, the amount of process automation nodes, such as DCN, controlled by and / or otherwise associated with each FER (or process unit) may be calculated based on the corresponding I / O summaries 670. In some implementations, the amount of DCN for a given FER may be estimated in block 672 as follows:

[0082]

number

[0083] Assume spare_requirement% is 25%, or 0.25. If the maximum I / O points in the DCN model to be deployed is 100, the maximum number of I / O points available to be assigned to an instance of that DCN during the design phase is 75. If the total amount of I / O points in the FER (the I / O amount in equation (1)) is 10,000, the amount of DCN required is 134 (10,000 / 75=133.333...).

[0084] At block 673, an embedding may be created, e.g., by encoder module 24, based on the amount of DCN determined at block 672 and all or a portion of FER I / O summary 670. At block 674, the embedding may be matched, e.g., by matcher 26, with reference embeddings in reference PAF database 30 that represent one or more reference process automation equipment. Based on the matched reference embeddings, template module 28 may generate, retrieve, and / or provide design documents, such as one or more template network architecture drawings 676 and / or one or more template network configurations 678.

[0085] Figure 7 illustrates another example of how design inputs may be processed to generate a template design document. Many aspects of Figure 7 are similar to those illustrated in Figure 6. However, Figure 7 may represent a later stage in the process automation equipment design cycle (e.g., 310 in Figure 3) than Figure 6. Thus, more detailed design inputs are available in Figure 7.

[0086] Starting again from the left, an I / O instrument index 782 for each FER (or process unit) is provided as a design input (as opposed to the less detailed I / O summary 670 of FIG. 6). One or more P&IDs 784 for each process unit are also provided as design input. In some implementations, the P&IDs 784 may have been created using and / or may take the form of templates generated and / or retrieved using the techniques described herein.

[0087] 6 , in block 772, the quantity of process automation nodes, such as DCNs, controlled by and / or otherwise associated with each FER may be calculated based on the corresponding I / O instrument index 782. In some implementations, the same equation (1) described above may be used. Meanwhile, software connections associated with P&IDs 784 may be analyzed in block 786 to identify, for example, groups of tags that form a process control loop. In some implementations, these tags may be used as additional inputs for processing in block 772. In some implementations, tags in the same group may be assigned to the same DCN.

[0088] At block 773, encoder module 24 may generate embeddings representing, for example, the amount of DCN calculated at block 772 and all or a portion of I / O instrument index 782 and P&ID 784 (and possibly the tag group identified at block 786). At block 774, the embeddings may be matched, for example by matcher 26, to reference embeddings in reference PAF database 30 representing one or more reference process automation equipment. Based on the matched reference embeddings, template module 28 may generate, retrieve, and / or provide updated design documents, such as one or more updated template network architecture drawings 776 and / or one or more updated template network configurations 778. At block 788, the DCN assignment information determined at block 772 may be used to update I / O instrument index 782.

[0089] 8 is a flowchart illustrating an example method 800 for practicing selected aspects of the present disclosure, according to implementations disclosed herein. For convenience, the operations of the flowchart are described with reference to a system that performs the operations. This system may include various components of various computer systems. Furthermore, while the operations of method 800 are shown in a particular order, this is not intended to be limiting. One or more operations may be reordered, omitted, or added.

[0090] In block 802, the system may process one or more first-level design inputs for the required process automation equipment, for example, via intake module 22 and / or encoder module 24, to generate a first embedding. Various techniques may be used to generate the first embedding. If the first-level design input includes text data, various NLP techniques may be used, such as word2vec, transformer networks, and various types of RNNs. If the first-level design input includes raster graphics, object recognition techniques such as trained machine learning models (e.g., CNNs) may be used. If the first-level design input includes a graph with nodes and edges or other data that can be preprocessed to form such a graph, techniques such as graph neural networks may be used to create the first embedding. In some implementations in which multiple design inputs are provided, multiple embeddings may be created based on different modalities of the design inputs (e.g., graph-based, image-based, text-based). These multiple embeddings may be combined in various ways, such as averaging, concatenation, etc.

[0091] In some implementations, the first embedding may encode the desired process automation equipment design at a level of detail or abstraction corresponding to a high level in the design document hierarchy. In such implementations, the first level of design input may include one or more relatively high-level design inputs received from an end customer or EPC personnel, such as, for example, a control narrative, a project specification (which may include prose, lists, diagrams, etc.). Other types of design inputs that may not necessarily be created for design purposes may also be used as such first-level design input. As one non-limiting example, written documents (e.g., letters, emails, text messages) exchanged between stakeholders may contain high-level information about the desired process automation equipment and therefore may be processed (e.g., using NLP) to generate the first embedding. Transcriptions of audio conversations (in-person or over the phone) may also be used.

[0092] However, the first level of design input is not required to be at a level of detail corresponding to any particular level in the design document hierarchy. As previously mentioned, mappings such as the one illustrated in Figure 4 can be bidirectional. Thus, embeddings representing documents at a relatively low level in the hierarchy (i.e., a relatively high level of detail), such as a P&ID for a particular process, can be mapped back to (and ultimately used to generate / select templates for) higher-level documents, such as PDFs, plant layouts, control narratives, project specifications, etc.

[0093] Referring again to FIG. 8 , at block 804, the system may compare the first embedding to multiple first-level reference embeddings, for example, by matcher 26, to select one or more first-level reference embeddings that satisfy a first criterion. The multiple first-level reference embeddings may encode respective multiple reference process automation equipment at a level of detail or abstraction corresponding to a first level of the design document hierarchy. In various implementations, the first criterion may include, for example, a threshold measure of similarity. Such a similarity measure (which may or may not correspond to a distance in the embedding space) may be determined using techniques such as Euclidean distance, cosine similarity, dot product, etc. As another example, the first criterion may include several reference embeddings that are closest and / or most similar to the first embedding in the embedding space.

[0094] In block 806, the system may identify, e.g., by matcher 26, one or more second-level reference embeddings based on mappings from the selected one or more first-level reference embeddings. Each of the one or more second-level reference embeddings may encode second-level information about a respective one of a plurality of existing process automation equipment at a level of detail or abstraction corresponding to a different level in the design document hierarchy. An example of such a mapping is illustrated in FIG. 4 as the arrows between the various embedding spaces 540, 542, 544, 546, and 548 in FIG. 5.

[0095] Based on the identified one or more second-level reference embeddings, the system may provide one or more template design documents for the requested process automation equipment in block 808. For example, the second-level reference embeddings may represent design documents such as P&IDs, PFDs, network topologies, physical plant layouts, etc. This existing documentation may be taken as-is and provided to the requesting user, or it may be used to generate a more generally applicable template, either option effectively bootstrapping the design process for new process automation equipment.

[0096] In some implementations, one or more of the template design documents may be generated based on “intransient” elements shared among multiple reference design documents associated with the reference process automation equipment (e.g., used to design, implement, build, refurbish, improve, etc., the reference process automation equipment). These reference design documents may be similar to one another to the extent that they may share any number of intransient elements (e.g., matching equipment, matching process units). Similarly, these reference design documents may differ from one another to the extent that they include disparate or “transient” elements. In various implementations, these reference design documents may be used to generate multiple reference embeddings, which may be used to generate template design documents that are likely to be useful for building or maintaining another process automation equipment.

[0097] Assume that a first-level reference embedding maps to a cluster of second-level reference embeddings, each representing a different reference process automation equipment design. In some such implementations, data points that are shared or common among the cluster of reference process automation equipment may be identified and used to automatically populate corresponding fields or slots in a template design document. Meanwhile, transient data points that vary among multiple reference process automation equipment may be discarded or compiled into a list of selectable options for the corresponding fields or slots in the template design document.

[0098] 9 is a block diagram of an exemplary computing device 910 that may optionally be utilized to implement one or more aspects of the techniques described herein. The computing device 910 typically includes at least one processor 914 that communicates with several peripheral devices via a bus subsystem 912. These peripheral devices may include, for example, a storage subsystem 924 including a memory subsystem 925 and a file storage subsystem 926, a user interface output device 920, a user interface input device 922, and a network interface subsystem 916. The input and output devices enable user interaction with the computing device 910. The network interface subsystem 916 provides an interface to a network (physical and / or virtual) and is coupled to corresponding interface devices in other computing devices.

[0099] The user interface input devices 922 may include a keyboard, a pointing device such as a mouse, a trackball, a touchpad, or a graphics tablet, a scanner, a touchscreen integrated into a display, an audio input device such as a voice recognition system, a microphone, and / or other types of input devices. In general, use of the term "input device" is intended to include all conceivable types of devices and methods for inputting information into the computing device 910 or over a communications network.

[0100] The user interface output devices 920 may include a display subsystem, a printer, a fax machine, or a non-visual display such as an audio output device. The display subsystem may include a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD), a projection device, or some other mechanism for producing a visible image. The display subsystem may also provide a non-visual display, such as via an audio output device. In general, use of the term "output device" is intended to include all conceivable types of devices and methods for outputting information from the computing device 910 to a user or to another machine or computing device.

[0101] The storage subsystem 924 stores programming and data structures that provide the functionality of some or all of the modules described herein. For example, the storage subsystem 924 may include logic for operating the components illustrated in Figure 1 and for implementing selected aspects of Figures 6-8.

[0102] These software modules are generally executed by the processor 914 alone or in combination with other processors. The memory subsystem 925 used in the storage subsystem 924 can include several memories, including a main random access memory (RAM) 930 for storing instructions and data during program execution and a read-only memory (ROM) 932 in which fixed instructions are stored. The file storage subsystem 926 can provide persistent storage for program and data files and may include a hard disk drive, a floppy disk drive with associated removable media, a CD-ROM drive, an optical drive, or a removable media cartridge. Modules that implement the functionality of some implementations can be stored in the storage subsystem 924 by the file storage subsystem 926 or on other machines accessible by the processor 914.

[0103] The bus subsystem 912 provides a mechanism for allowing the various components and subsystems of the computing device 910 to communicate with each other as intended. Although the bus subsystem 912 is shown schematically as a single bus, alternative implementations of the bus subsystem may use multiple buses.

[0104] Computing device 910 can be of various types, including a workstation, a server, a computing cluster, a blade server, a server farm, or any other data processing system or computing device. Due to the ever-changing nature of computers and networks, the description of computing device 910 illustrated in Figure 9 is intended only as a specific example to illustrate some implementations. Many other configurations of computing device 910 are possible, having more or fewer components than the computing device illustrated in Figure 9.

[0105] While several implementations have been described and illustrated herein, various other means and / or structures for performing the functions and / or obtaining the results and / or one or more of the advantages described herein may be utilized, and each such variation and / or modification is considered to be within the scope of the implementations described herein. More generally, it is intended that all parameters, dimensions, materials, and configurations described herein are exemplary, and that the actual parameters, dimensions, materials, and / or configurations will depend on the particular application or applications in which one or more of the present teachings are used. Those skilled in the art will recognize or be able to ascertain using no more than routine experimentation many equivalents to the specific implementations described herein. Accordingly, it should be understood that the above-described implementations are presented merely by way of example, and that, within the scope of the appended claims and their equivalents, implementations may be practiced otherwise than as specifically described and claimed. Implementations of the present disclosure are directed to each individual feature, system, article, material, kit, and / or method described herein. In addition, any combination of two or more such features, systems, articles, materials, kits, and / or methods is included within the scope of the present disclosure, provided that such features, systems, articles, materials, kits, and / or methods are not mutually inconsistent. [Explanation of symbols]

[0106] 10 client devices 12 Integrated Development Environment (IDE) 20 Process Automation Design System 22 Intake module 24 Encoder Module 26 Matcha 28 Template Module 30 Reference Process Automation Facilities (PAF) Database 32 Machine Learning Database, ML Database 200 Physical Plant Layout 201 Central Control Room (CCR) 202,2021,2022,2023,202 N Field equipment room (FER) 204,2041,2042,2043,204 N Instruments 206 Process Automation Network 310 cycles 312 High-level project specifications and / or requirements 314 Control Safety Narrative 316 Operational Alarm Management Policy and / or Standard Operating Procedure (SOP) 318 Physical Plant Layout Design Input 3201 Wiring Module 3202 Instrument Index 3203 Plant Hierarchy 322 Instrumentation Database Design Input 324 P&ID 326 Process Flow Diagram (PFD) 400 Process Flow 430 Process Unit 430A, 430B, 430C, 430D, 430E, 430F, 430G, 430H, 430J, 430K, 430L, 430M, 430N, 430P, 430Q, 430R, 430S Process Unit 430I Liquefaction Process Unit 430O Refrigerant Storage Process Unit 432 PFD 4341,434 N P&ID 539 Semantic Embedding 540 First Embedding Space 5401 First Cluster 5402 Second Cluster 5403 Third Cluster 5404 Fourth Cluster 541A First Mapping 541B Second Mapping 541C Third Mapping 541D Fourth Mapping 542 Second Embedding Space 5421 First Cluster 5422 Second Cluster 5423 Third Cluster 5424 Fourth Cluster 543A Mapping 543B Mapping 544 The third embedding space 5441 First Cluster 5442 Second Cluster 5443 Third Cluster 545A Mapping 545B Mapping 546 The Fourth Embedding Space 547 Mapping 548 The fifth embedding space 5481 First Cluster 5482 Second Cluster 5483 Third Cluster 549A Mapping 549B Mapping 670 Input / Output (I / O) Summary 676 Template Network Architecture Drawings 678 Template Network Configuration 776 Updated Template Network Architecture Drawings 778 Updated template network configuration 782 I / O Instrument Index 784 P&ID 800 ways 910 Computing Devices 912 Bus Subsystem 914 processor 916 Network Interface Subsystem 920 User Interface Output Device 922 User Interface Input Devices 924 Memory Subsystem 925 Memory Subsystem 926 File Storage Subsystem 930 Main Random Access Memory (RAM) 932 Read-Only Memory (ROM)

Claims

1. 1. A method for designing at least a portion of a required process automation facility, the method being implemented using one or more processors, comprising: processing first level design inputs for the required process automation equipment to generate a first embedding, the first embedding encoding a design aspect of the required process automation equipment at a first level of abstraction; comparing the first embedding to a plurality of first-level reference embeddings to select one or more first-level reference embeddings that satisfy a first criterion, the plurality of first-level reference embeddings encoding respective designs of a plurality of reference process automation equipment at the first level of abstraction; identifying one or more second-level reference embeddings based on one or more mappings from the one or more selected first-level reference embeddings, each of the one or more second-level reference embeddings encoding a design aspect of a respective one of the plurality of reference process automation equipment at a second level of abstraction that is less abstract than the first level of abstraction; providing one or more template design documents for the requested process automation equipment based on the identified one or more second-level reference embeddings; A method comprising:

2. 2. The method of claim 1, wherein the first level design input for the required process automation equipment includes a process flow diagram, and the one or more template design documents for the required process automation equipment include a template piping and instrumentation diagram (P&ID) for at least a portion of the required process automation equipment.

3. 2. The method of claim 1, wherein the first level design input for the requested process automation equipment comprises natural language input, and the one or more template design documents for the requested process automation equipment comprise a template process flow diagram (PFD) or a template piping and instrumentation diagram (P&ID) for at least a portion of the requested process automation equipment.

4. 2. The method of claim 1, wherein the first level design input for the requested process automation facility includes information about a central control room for the requested process automation facility, and the one or more template design documents for the requested process automation facility include a template design of a field equipment room (FER) for the requested process automation facility.

5. said step of processing a first level design input to generate a first embedding comprises: generating a graph based on the first level design input; processing the graph based on one or more machine learning models to generate the first embedding; 2. The method of claim 1, comprising:

6. 6. The method of claim 5, wherein one or more of the machine learning models comprises a graph neural network (GNN).

7. 6. The method of claim 5, wherein the graph comprises a plurality of nodes representing a plurality of processes to be implemented in the requested process automation facility and a plurality of edges defining relationships between the plurality of processes.

8. 6. The method of claim 5, wherein the graph includes a plurality of nodes representing a plurality of process automation nodes to be implemented in the requested process automation facility and a plurality of edges representing network communication channels between the plurality of process automation nodes.

9. 6. The method of claim 5, wherein the graph includes one or more nodes representing one or more modular automated process assemblies to be implemented in the requested process automation facility and a plurality of edges defining relationships between the one or more modular automated process assemblies and other elements of the requested process automation facility.

10. 2. The method of claim 1, wherein the one or more second-level reference embeddings include a plurality of second-level reference embeddings generated from a plurality of reference design documents associated with the reference process automation equipment, and one or more of the template design documents are generated based on persistent elements shared among the plurality of reference design documents.

11. 2. The method of claim 1, wherein the first level design input includes input / output (I / O) information for a process unit of the process automation facility, and wherein the processing includes calculating a number of distributed control nodes (DCNs) for the process unit.

12. 1. A system for designing at least a portion of a required process automation facility, comprising: processing first level design inputs for the required process automation equipment to generate a first embedding, the first embedding encoding a design aspect of the required process automation equipment at a first level of abstraction; comparing the first embedding to a plurality of first-level reference embeddings to select one or more first-level reference embeddings that meet a first criterion, the plurality of first-level reference embeddings encoding respective designs of a plurality of reference process automation equipment at the first level of abstraction; identifying one or more second-level reference embeddings based on one or more mappings from the selected one or more first-level reference embeddings, each of the one or more second-level reference embeddings encoding a design aspect of a respective one of the plurality of reference process automation equipment at a second level of abstraction that is less abstract than the first level of abstraction; providing one or more template design documents for the requested process automation equipment based on the identified one or more second-level reference embeddings; and 1. A system comprising one or more processors for performing the steps of:

13. 13. The system of claim 12, wherein the first level design input for the requested process automation equipment includes a process flow diagram, and the one or more template design documents for the requested process automation equipment include a template piping and instrumentation diagram (P&ID) for at least a portion of the requested process automation equipment.

14. 13. The system of claim 12, wherein the first level design input for the requested process automation equipment comprises natural language input, and the one or more template design documents for the requested process automation equipment comprise a template process flow diagram (PFD) or a template piping and instrumentation diagram (P&ID) for at least a portion of the requested process automation equipment.

15. 13. The system of claim 12, wherein the first level design input for the requested process automation facility includes information about a central control room for the requested process automation facility, and the one or more template design documents for the requested process automation facility include a template design of a field equipment room (FER) for the requested process automation facility.

16. processing the first level design input to generate the first embedding; generating a graph based on the first level design input; processing the graph based on one or more machine learning models to generate the first embedding; The system of claim 12, comprising:

17. 17. The system of claim 16, wherein one or more of the machine learning models comprises a graph neural network (GNN).

18. 17. The system of claim 16, wherein the graph includes a plurality of nodes representing a plurality of processes to be implemented in the requested process automation equipment and a plurality of edges defining relationships between the plurality of processes.

19. 17. The system of claim 16, wherein the graph includes a plurality of nodes representing a plurality of process automation nodes to be implemented in the requested process automation facility and a plurality of edges representing network communication channels between the plurality of process automation nodes.

20. 1. A non-transitory computer-readable medium for designing at least a portion of a required process automation facility, the medium comprising: processing first level design inputs for the required process automation equipment to generate a first embedding, the first embedding encoding one or more design aspects of the required process automation equipment at a first level of abstraction; comparing the first embedding to a plurality of first-level reference embeddings to select one or more first-level reference embeddings that meet a first criterion, the plurality of first-level reference embeddings encoding respective designs of a plurality of reference process automation equipment at the first level of abstraction; identifying one or more second-level reference embeddings based on one or more mappings from the selected one or more first-level reference embeddings, each of the one or more second-level reference embeddings encoding a design aspect of a respective one of the plurality of reference process automation equipment at a second level of abstraction that is less abstract than the first level of abstraction; providing one or more template design documents for the requested process automation equipment based on the identified one or more second-level reference embeddings; and A non-transitory computer-readable medium storing instructions to cause a

21. 1. A method for designing at least a portion of a required process automation facility, the method being implemented using one or more processors, comprising: receiving one or more natural language inputs at one or more input components; performing natural language processing on the one or more natural language inputs to identify a set of the required process automation equipment designs communicated in the one or more natural language inputs; identifying one or more reference process automation equipment designs similar to the required process automation equipment based on the set of required process automation equipment designs; identifying one or more additional designs of one or more of the reference process automation equipment that were not included in the set of requested process automation equipment designs; providing one or more of the identified additional design aspects of one or more of the reference process automation equipment via one or more output devices; Including, The method, wherein the additional design aspects are provided using a mapping between two or more levels of reference embedding that encode different design aspects of the reference process automation equipment.

22. 22. The method of claim 21, wherein the natural language processing identifies the set of design aspects of the requested process automation equipment at a level of detail corresponding to a first level of a design document hierarchy associated with designing process automation equipment, and the one or more reference process automation equipment are similar to the requested process automation equipment at a level of detail corresponding to the first level of the design document hierarchy.

23. 23. The method of claim 22, wherein design aspects of one or more of the reference process automation equipment are identified at a level of detail corresponding to a second level of the design document hierarchy below the first level of the design document hierarchy.

24. 24. The method of claim 21, wherein the providing step comprises providing one or more template design documents for the requested process automation equipment based on the identified additional design aspects of one or more of the reference process automation equipment.

25. 24. The method of any one of claims 21 to 23, wherein the one or more reference process automation facilities comprise a plurality of reference process automation facilities.

26. 26. The method of claim 25, wherein the one or more additional designs comprise a persistent design shared among the plurality of reference process automation equipment.

27. 24. The method of claim 21, further comprising: comparing a first embedding generated based on the set of designs of the requested process automation equipment with reference embeddings generated from designs of a plurality of candidate reference process automation equipment, wherein the one or more reference process automation equipment are selected from the plurality of candidate reference process automation equipment based on a measure of similarity between the first embedding and the reference embedding.

28. 1. A system for designing at least a portion of a required process automation facility, comprising: one or more processors; and a memory storing instructions, the instructions causing the one or more processors, in response to execution of the instructions, to: receiving one or more natural language inputs at one or more input components; performing natural language processing on the one or more natural language inputs to identify a set of the required process automation equipment designs communicated in the one or more natural language inputs; Identifying one or more reference process automation equipment designs similar to the required process automation equipment based on the set of required process automation equipment designs; identifying one or more additional designs of one or more of the reference process automation equipment that were not included in the set of requested process automation equipment designs; providing one or more of the identified additional design aspects of one or more of the reference process automation equipment via one or more output devices; Let them do this, The system wherein the additional design aspects are provided using a mapping between two or more levels of reference embedding that encode different design aspects of the reference process automation equipment.

29. 29. The system of claim 28, wherein the natural language processing identifies the set of design aspects of the requested process automation equipment at a level of detail corresponding to a first level of a design document hierarchy associated with designing process automation equipment, and the one or more reference process automation equipment are similar to the requested process automation equipment at a level of detail corresponding to the first level of the design document hierarchy.

30. 30. The system of claim 29, wherein design aspects of one or more of the reference process automation equipment are identified at a level of detail corresponding to a second level of the design document hierarchy below the first level of the design document hierarchy.

31. 31. The system of claim 28, further comprising instructions for providing one or more template design documents for the requested process automation equipment based on the identified additional design aspects of one or more of the reference process automation equipment.

32. 30. The system of claim 28, wherein the one or more reference process automation facilities include a plurality of reference process automation facilities.

33. 33. The system of claim 32, wherein the one or more additional designs comprise a persistent design shared among the plurality of reference process automation equipment.

34. 30. The system of claim 28, further comprising instructions for comparing a first embedding generated based on the set of designs of the requested process automation equipment with reference embeddings generated from designs of a plurality of candidate reference process automation equipment, wherein the one or more reference process automation equipment are selected from the plurality of candidate reference process automation equipment based on a measure of similarity between the first embedding and the reference embedding.

35. 1. A non-transitory computer-readable medium for designing at least a portion of a required process automation facility, the non-transitory computer-readable medium comprising instructions that, in response to execution of the instructions by a processor, cause the processor to: receiving one or more natural language inputs at one or more input components; performing natural language processing on the one or more natural language inputs to identify a set of the required process automation equipment designs communicated in the one or more natural language inputs; Identifying one or more reference process automation equipment designs similar to the required process automation equipment based on the set of required process automation equipment designs; identifying one or more additional designs of one or more of the reference process automation equipment that were not included in the set of requested process automation equipment designs; providing one or more of the identified additional design aspects of one or more of the reference process automation facilities via one or more output devices; Let them do this, A non-transitory computer-readable medium, wherein the additional design aspects are provided using a mapping between two or more levels of reference embedding that encode different design aspects of the reference process automation equipment.

36. 36. The non-transitory computer-readable medium of claim 35, wherein the natural language processing identifies the set of design aspects of the requested process automation equipment at a level of detail corresponding to a first level of a design document hierarchy associated with designing process automation equipment, and the one or more reference process automation equipment are similar to the requested process automation equipment at a level of detail corresponding to the first level of the design document hierarchy.

37. 37. The non-transitory computer-readable medium of claim 36, wherein design aspects of one or more of the reference process automation equipment are identified at a level of detail corresponding to a second level of the design document hierarchy below the first level of the design document hierarchy.

38. 38. The non-transitory computer-readable medium of any one of claims 35 to 37, further comprising instructions for providing one or more template design documents for the requested process automation equipment based on the identified additional design aspects of one or more of the reference process automation equipment.

39. 36. The non-transitory computer-readable medium of claim 35, wherein the one or more reference process automation facilities comprise a plurality of reference process automation facilities.

40. 40. The non-transitory computer-readable medium of claim 39, wherein the one or more additional designs comprise a persistent design shared among the plurality of reference process automation equipment.

41. 1. A method for designing at least a portion of a required process automation facility, the method being implemented using one or more processors, comprising: receiving, at one or more input components, one or more inputs describing the required process automation equipment; generating a graph based on the one or more inputs, the graph including a set of the required process automation equipment designs conveyed in the one or more inputs; processing the graph based on one or more machine learning models to identify one or more reference process automation equipment that are similar to the requested process automation equipment; identifying one or more additional designs of one or more of the reference process automation equipment that were not included in the set of requested process automation equipment designs; providing one or more of the identified additional design aspects of one or more of the reference process automation equipment via one or more output devices; Including, The method, wherein the additional design aspects are provided using a mapping between two or more levels of reference embedding that encode different design aspects of the reference process automation equipment.

42. 42. The method of claim 41 , wherein one or more of the machine learning models comprises a graph neural network (GNN).

43. 43. The method of claim 41 or 42, wherein the graph comprises a plurality of nodes representing a plurality of processes to be implemented in the required process automation equipment and a plurality of edges defining relationships between the plurality of processes.

44. 42. The method of claim 41, wherein the graph includes a plurality of nodes representing a plurality of process automation nodes to be implemented in the requested process automation facility and a plurality of edges representing network communication channels between the plurality of process automation nodes.

45. 42. The method of claim 41 , wherein the graph includes one or more nodes representing one or more modular automated process assemblies to be implemented in the requested process automation facility and a plurality of edges defining relationships between the one or more modular automated process assemblies and other elements of the requested process automation facility.

46. 42. The method of claim 41 , wherein the providing step comprises providing one or more template design documents for the requested process automation equipment based on the identified additional design aspects of one or more of the reference process automation equipment.

47. 42. The method of claim 41, wherein the one or more reference process automation facilities comprise a plurality of reference process automation facilities.

48. 47. The method of claim 46, wherein the one or more additional designs comprise a persistent design shared among multiple reference process automation facilities.

49. 42. The method of claim 41, further comprising: comparing a first embedding generated based on the set of designs of the requested process automation equipment using one or more of the machine learning models with reference embeddings generated based on designs of a plurality of candidate reference process automation equipment using one or more of the machine learning models, wherein the one or more reference process automation equipment are selected from the plurality of candidate reference process automation equipment based on a measure of similarity between the first embedding and the reference embedding.

50. 1. A system for designing at least a portion of a required process automation facility, comprising: one or more processors; and a memory storing instructions, the instructions causing the one or more processors, in response to execution of the instructions, to: receiving, at one or more input components, one or more inputs describing the required process automation equipment; generating a graph based on the one or more inputs, the graph including a set of the required process automation equipment designs conveyed in the one or more inputs; processing the graph based on one or more machine learning models to identify one or more reference process automation equipment that are similar to the requested process automation equipment; identifying one or more additional designs of one or more of the reference process automation equipment that were not included in the set of requested process automation equipment designs; providing one or more of the identified additional design aspects of one or more of the reference process automation equipment via one or more output devices; Let them do this, The system wherein the additional design aspects are provided using a mapping between two or more levels of reference embedding that encode different design aspects of the reference process automation equipment.

51. 51. The system of claim 50, wherein one or more of the machine learning models comprises a graph neural network (GNN).

52. 52. The system of claim 50 or 51, wherein the graph includes a plurality of nodes representing a plurality of processes to be implemented in the required process automation equipment and a plurality of edges defining relationships between the plurality of processes.

53. 51. The system of claim 50, wherein the graph includes a plurality of nodes representing a plurality of process automation nodes to be implemented in the requested process automation facility and a plurality of edges representing network communication channels between the plurality of process automation nodes.

54. 51. The system of claim 50, wherein the graph includes one or more nodes representing one or more modular automated process assemblies to be implemented in the requested process automation facility and a plurality of edges defining relationships between the one or more modular automated process assemblies and other elements of the requested process automation facility.

55. 51. The system of claim 50, wherein the instructions for providing include instructions for providing one or more template design documents for the requested process automation equipment based on the identified additional design aspects of one or more of the reference process automation equipment.

56. 51. The system of claim 50, wherein the one or more reference process automation facilities include a plurality of reference process automation facilities.

57. 57. The system of claim 56, wherein the one or more additional designs comprise a persistent design shared among the plurality of reference process automation equipment.

58. 51. The system of claim 50, further comprising instructions for comparing a first embedding generated based on the set of designs of the requested process automation equipment using one or more of the machine learning models with reference embeddings generated based on designs of a plurality of candidate reference process automation equipment using one or more of the machine learning models, wherein the one or more reference process automation equipment are selected from the plurality of candidate reference process automation equipment based on a measure of similarity between the first embedding and the reference embedding.

59. A non-transitory computer-readable medium comprising instructions that, in response to execution of the instructions by a processor, cause the processor to: receiving, at one or more input components, one or more inputs describing the required process automation equipment; generating a graph based on the one or more inputs, the graph including a set of the required process automation equipment designs conveyed in the one or more inputs; processing the graph based on one or more machine learning models to identify one or more reference process automation equipment that are similar to the requested process automation equipment; identifying one or more additional designs of one or more of the reference process automation equipment that were not included in the set of requested process automation equipment designs; providing one or more of the identified additional design aspects of one or more of the reference process automation equipment via one or more output devices; Let them do this, A non-transitory computer-readable medium, wherein the additional design aspects are provided using a mapping between two or more levels of reference embedding that encode different design aspects of the reference process automation equipment.

60. 60. The non-transitory computer-readable medium of claim 59, wherein one or more of the machine learning models comprises a graph neural network (GNN).

Images