JP7794312B2 - Automation design of process automation equipment - Google Patents

Description

This disclosure relates to the automation design of process automation equipment.

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. In addition, 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 the personnel who designed and implemented those reference process automation facilities may not be easily transferable to other personnel.

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 process automation equipment 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.

In some implementations, a method for designing at least a portion of a required process automation equipment may be implemented using one or more processors and includes the steps of processing first-level design inputs for the required process automation equipment to generate a first embedding, the first embedding encoding design aspects of the required 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 with 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 first-level reference embedding corresponding to a first level of a design document hierarchy. 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.

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.

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) for at least a portion of the required process automation equipment.

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 for a field equipment room (FER) for the required process automation facility.

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.

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 step may include calculating the number of distributed control nodes (DCNs) for the process unit.

In addition, 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 methods described above. Some implementations also include one or more non-transitory computer-readable storage media storing computer instructions executable by the one or more processors to perform any of the methods described above.

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.

FIG. 1 is a diagram that schematically illustrates an exemplary environment in which selected aspects of the present disclosure may be implemented. FIG. 1 is a diagram that schematically illustrates an example physical plant layout for a process automation facility, in accordance with various implementations. FIG. 1 is a diagram that schematically illustrates an example of a design cycle for a process automation facility, according to various implementations. FIG. 1 is a diagram that schematically illustrates an exemplary process flow for a process automation facility. 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. FIG. 1 illustrates one example of how design inputs can be processed to generate a template design document. FIG. 10 illustrates another example of how design inputs can be processed to generate a template design document. 1A-1C illustrate exemplary methods for implementing selected aspects of the present disclosure. FIG. 1 illustrates a schematic diagram of an exemplary computer architecture in which selected aspects of the present disclosure may be implemented.

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 process automation equipment 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.

In various implementations, machine learning techniques may be used to leverage the knowledge stored in the federated information model to automate aspects of the design of new process automation equipment or updates to existing process automation equipment, i.e., "bootstrap" the design or update. For example, in some implementations, when new process automation equipment is requested, the 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.

This semantic-rich embedding may 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 may 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 may 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 may be calculated in a variety of different ways, including, but not limited to, cosine similarity, dot product, Euclidean distance, etc.

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 process automation equipment. The design document hierarchy may reflect the level of abstraction or detail included in design documents provided at various stages of designing and/or constructing the process automation equipment. Each level in the design document hierarchy may reflect documents having 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, e.g., the amount of detail that may be found in a PFD created for the reference process automation equipment, or more generally, the amount of detail corresponding to a first level in the design document hierarchy.

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 contained in the federated information model associated with the reference process automation equipment.

Once one or more first-level reference embeddings have been 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.

As one example, the second-level reference embeddings may include more detail than the 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) for 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.

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 the field equipment rooms (FERs) at the reference process automation facility. The second-level reference embeddings may then be used to generate template designs, I/O summaries, and/or lists for the FERs at the requested process automation facility.

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 that which 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. The 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 that are mapped by one or more first-level embeddings.

In some implementations, the customer may provide information incrementally, and at each increment, additional searches may be performed. For example, the 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 used, for example, to further narrow the search space of first-level embeddings or to narrow the search space of second-level embeddings. For example, the customer may provide natural language input describing additional details of the process automation equipment the customer desires, or may indicate specific portions of the required process automation equipment (e.g., CCR, FER) that the customer wants to design or has initially designed.

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 graph's nodes but also the relationships between the graph's nodes. Thus, by representing the first level of information provided by the 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 allows for more accurate comparisons of the various embeddings described herein.

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 multiple nodes representing, for example, multiple processes to be implemented in a required process automation facility. Multiple edges may also be included, defining relationships between multiple processes. Such a graph may have a level of detail corresponding to a particular level in the design document hierarchy, such as the level including the PFD and other similarly detailed documents.

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., DCN, 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.

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 can 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.

The examples described herein primarily involve first finding more abstract and/or less detailed (e.g., first-level) embeddings and then mapping those abstract embeddings to less abstract and more detailed second-level embeddings. 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 a more abstract embedding (e.g., representing a PFD, CCR, control safety narrative, etc.). As another example, an embedding may map to another embedding 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.

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 would like incorporated into the customer's 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 a semantically rich embedding that may be mapped to a reference embedding that can be used to design a CCR 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.

FIG. 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).

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., implemented 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."

The process automation design system 20 may also include one or more databases for storing various information used, modified, or created by 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 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.

In some implementations, the federated information model may organize information about the reference process automation equipment as a graph, 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, e.g., 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, e.g., 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, e.g., 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.

The 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, the ML database 32 may store machine learning models used by the 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 the encoder module 24 to generate semantic embeddings from different design inputs; by the matcher 26 to match semantic embeddings with other similar semantic embeddings; by the template module 28 to retrieve information stored in the reference PAF database 30 as part of the federated information model; etc.

The 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. The intake module 22 may then process this captured information into a federated information model. The intake module 22 may store this federated information model in the reference PAF database 30. Individual data points or collections of data points may then be readily retrieved from this federated information model.

The 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.

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 the 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 implemented to train the weights of the machine learning model.

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 may 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.

Once trained, the machine learning model can be used, for example, by intake module 22, to process unlabeled, unstructured documents and extract relevant information and/or features. For example, feature elements illustrated in FIG. 2, such as a central control room (CCR) 201, one or more field equipment rooms (FERs) 202 _1-N , junction boxes, instruments 204 _1-N , and/or connections or edges between them, can be extracted. These features can be used, for example, by intake module 22, to generate reference embeddings that can be easily compared to other embeddings (e.g., by matcher 26). Mapping from these reference embeddings can lead to other reference embeddings representing 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.

The encoder module 24 may be configured to obtain information, such as data extracted from design inputs or other reference process automation equipment information by the intake module 22, and encode this information into semantic embeddings (or simply "embeddings"). In the context of reference information stored in the reference PAF database 30, the 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. The encoder module 24 may encode this hierarchy of graphs into one or more embeddings, for example, using a machine learning model, such as a GNN, stored in the ML database 32. Such embeddings may be readily compared, for example, by the 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.

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 documentation created for one of the pieces of process automation equipment can be leveraged to provide template design documentation 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.

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

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.

Starting from the top, the central control room (CCR) 201 may include various equipment that may be used to control process automation equipment. These equipment 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.

Multiple field equipment rooms (FERs) 202 _1-N (N is a positive integer) are shown in network communication with CCR 201 via one or more process automation networks 206. The process automation networks 206 may include one or more personal area networks (PANs), such as Bluetooth networks, one or more local area networks (LANs), such as Wi-Fi networks, one or more mesh networks (e.g., Z-Wave, ZigBee), and/or one or more wide area networks (WANs), such as the Internet. If the process automation equipment is viewed as a hierarchy, FERs 202 _1-N may be viewed as subordinate to and/or at a lower level than CCR 201. In various implementations, FERs 202 may include a subset of the HMIs available in CCR 201, such that the HMIs in FERs 202 may be operated to control only a portion of the process automation equipment. For example, FER202 does not necessarily include an OPC server or an HMI for an asset management system, but this is not intended to be limiting.

Each FER202 may be operably coupled to a respective instrument 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 instrument 204 associated with the FER202 (e.g., controllable using the FER202's HMI) may include, for example, input/output elements such as actuators or sensors, as well as other process automation nodes such as the DCN210.

Some non-limiting examples of actuators include, but are not limited to, valves, pistons, rotors, switches, heaters, coolers, stirrers, injectors, devices for creating vacuums, 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.

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 cycle 310 because the process often involves multiple iterations in which various types of design input are received from various entities, such as the end customer who 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, for example, because various entities have come up with 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.

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 explicit and/or descriptive those levels are.

For purposes of explanation, it is assumed that the first design input provided by the end customer is a high-level project specification 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 specification 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 a control safety narrative 314. These data may include, for example, free-form prose, flowcharts, requirements, and/or other information that communicates how aspects of the process automation system are controlled and/or how safety protocols are implemented.

Another design input that may be received as part of cycle 310, before or after 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.

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 will be 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.

The instrumentation database design input 322 may include, for example, a wiring module 320 ₁ , an instrument index 320 ₂ , and/or a plant hierarchy 320 _3. The wiring module 320 ₁ 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 320 ₂ may include, for example, a list or database of instruments such as sensors, actuators, DCNs, etc. The plant hierarchy 320 ₃ may indicate, for example, particular areas of the desired process automation plant and the units and/or equipment in those areas. Finally, in the 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.

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 the design document hierarchy. These mappings may be leveraged as described herein to automate aspects of process automation system design.

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 the design document hierarchy. The first embedding may be compared to multiple first-level reference embeddings to select one or more first-level reference embeddings that meet first criteria. The multiple first-level reference embeddings may encode aspects of a respective one of multiple existing process automation equipment at a level of detail or abstraction corresponding to the same level in the design document hierarchy.

Based on mappings 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 greater 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.

In some implementations, the design inputs illustrated in FIG. 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.

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, #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.

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 subsea 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.

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.

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 remainder 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/enhancement system process unit, and block 430N corresponds to a flare vent system process unit.

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

Each process unit 430 illustrated in FIG. 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 PFDs and/or P&IDs. The arrows extending from the liquefaction process unit 430I in the right-hand process train point to a representation of a PFD 432 and corresponding P&IDs 434 _1-N for implementing that liquefaction process unit. These arrows indicate how the PFD 432 may correspond to (e.g., include) multiple different P&IDs 434 _1-N . In other words, the PFD 432 may belong to a higher level in the design document hierarchy than the P&IDs 434 _1-N .

In some implementations, all or portions of the process flow 400 may be leveraged to provide a template design document. For example, information about the process units 430A-S of the process flow 400 may be extracted from a structured or unstructured document to generate a graph, e.g., by the intake module 22. The encoder module 24 may encode this graph into a reference semantic embedding at a first level of abstraction. The matcher 26 may 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 may lead to reference embeddings at different levels. The template module may 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.

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. 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. 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. 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 mapping between embeddings and embedding clusters are intended to be limiting. Rather, they are presented for illustrative purposes.

The first embedding space 540 includes embeddings (small white circles) representing 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 in 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.

In FIG. 5 , a first embedding space 540 includes multiple clusters of embeddings 540 _1-4 . Each cluster may include embeddings that encode information about process automation equipment that is similar in various respects. 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, or dot product. For example, first cluster 540 ₁ may include embeddings generated based on a first level of information about a natural gas refinery. Second cluster 540 ₂ may include embeddings generated based on a first level of information about an offshore oil extraction and processing facility. Third cluster 540 ₃ may include embeddings generated based on a first level of information about a hydraulic fracking facility. Fourth cluster 540 ₄ may include embeddings generated based on a first level of information about a nuclear fuel processing facility.

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., a narrative, a 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, the embeddings are grouped into clusters of embeddings _542-1-4 . In some cases, the clusters of embeddings may represent PFDs that are semantically similar to each other (e.g., may represent similar PFDs). Additionally or alternatively, in some implementations, a cluster 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.

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.

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 _542-1 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 _542-2 of embeddings representing multiple PFDs associated with (e.g., describing portions of) that same piece of process automation equipment.

A third mapping 541C maps embeddings representing first level information for a third piece of process automation equipment to a third cluster 542 ₃ 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 (540 ₄ ) to a fourth cluster 542 ₄ 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.

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 embeddings of second cluster _{540_2} 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 _{542_3} of embeddings in second embedding space 542. Thus, one or more of the PFDs represented by the embeddings of the third cluster 542 ₃ of embeddings in the second embedding space 542 may be retrieved and provided to the user as templates, either “as is” or after some form of pre-processing has been performed (e.g., to remove sensitive, transient, or irrelevant information).

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.

Referring again to FIG. 5 , the third embedding space 544 may include embeddings representing a third level of information, such as P&IDs 324 used in past process automation facilities. The third embedding space 544 includes three clusters of embeddings 544 _1-3 . Each cluster may include 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 facility, are controlled by the same FER, were used in semantically similar process automation facilities, etc. As before, mappings 543A and 543B may represent a similarity function learned between embeddings (representing individual PFDs) in the second embedding space 542 and third-level embeddings (representing P&IDs) in the third embedding space 544. Thus, as before, the PFD represented by the embedding in the second cluster 542_2 of the second embedding space ₅₄₂ may be connected via mapping 543B to the first cluster _{544_1} of the third embedding space 544. The four embeddings in the first cluster _{544_1} may represent four P&IDs 324 that may be provided to a user as template P&IDs.

The fourth embedding space 546 may include, for example, embeddings (white circles) that represent network topologies used in past process automation facilities. The fourth embedding space 546 includes 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 facilities), etc.

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 546 ₁ 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.

The other mapping 545B between the third embedded space 544 and the fourth embedded space 546 is between a cluster ₅₄₄₃ of embeddings representing four different P&IDs in the third embedded space 544 and individual embeddings representing individual network topologies in a 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.

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

Mapping 549A extends between a first cluster _548-1 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 _548-1 all contained the same PFDs for at least some portion of the process automation equipment. Mapping 549B extends between a second cluster _548-2 of embeddings representing physical plant layouts and a fourth cluster _542-4 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 _548-2 all contained the same four PFDs represented by the embeddings of cluster _542-4 .

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.

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.

6 schematically illustrates one example of how design inputs may be processed to generate a template design document. Starting from the left, the design inputs take the form of one or more input/output (I/O) summaries 670 for one or more FERs (see 202 _1-N in FIG. 2 ). In block 672, the quantity of process automation nodes, such as DCNs, 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 quantity of DCN for a given FER may be estimated in block 672 as follows:

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...).

In block 673, an embedding may be created, for example by the encoder module 24, based on the amount of DCN determined in block 672 and all or a portion of the FER I/O summary 670. In block 674, the embedding may be matched, for example by the matcher 26, with reference embeddings in the reference PAF database 30 that represent one or more reference process automation equipment. Based on the matched reference embeddings, the 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.

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.

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 a template generated and/or retrieved using the techniques described herein.

Similar to FIG. 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 within the same group may be assigned to the same DCN.

In block 773, the encoder module 24 may generate embeddings representing, for example, the DCN quantity calculated in block 772 and all or a portion of the I/O instrument index 782 and P&ID 784 (and possibly the tag group identified in block 786). In block 774, the embeddings may be matched, for example, by the matcher 26, to reference embeddings in the reference PAF database 30 representing one or more reference process automation equipment. Based on the matched reference embeddings, the 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. In block 788, the DCN allocation information determined in block 772 may be used to update the I/O instrument index 782.

FIG. 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.

In block 802, the system may process one or more first-level design inputs for the required process automation equipment, e.g., 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, such as word2vec, transformer networks, and various types of RNNs, may be used. 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 where 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.

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 input 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 exchanged between stakeholders (e.g., letters, emails, text messages) 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.

However, first-level design inputs are 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.

Referring again to FIG. 8 , at block 804, the system may compare the first embedding to multiple first-level reference embeddings, e.g., 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 the 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.

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.

Based on the identified one or more second-level reference embeddings, in block 808, the system may provide one or more template design documents for the requested process automation equipment. 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 retrieved 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.

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.

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 aspect. 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.

Figure 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.

User interface input devices 922 may include pointing devices such as a keyboard, mouse, trackball, touchpad, or graphics tablet, scanner, touchscreen integrated into a display, audio input devices such as a voice recognition system, 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 computing device 910 or over a communications network.

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.

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

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 can 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.

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.

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 FIG. 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 FIG. 9.

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 deemed 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. Additionally, 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.

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, 202 ₁ , 202 ₂ , 202 ₃ , 202 _N Field equipment room (FER)
204, 204 ₁ , 204 ₂ , 204 ₃ , 204 _N instrument
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
320 ₁ wiring module
320 ₂ instrument index
320 ₃ plant floors
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
434 ₁ , 434 _N P&ID
539 Semantic Embedding
540 First Embedding Space
540 ₁ First Cluster
540 ₂ Second Cluster
540 ₃ Third Cluster
540 ₄ Fourth Cluster
541A First Mapping
541B Second Mapping
541C Third Mapping
541D Fourth Mapping
542 Second Embedding Space
542 ₁ First Cluster
542 _2nd Cluster
542 ₃ Third Cluster
542 ₄ Fourth Cluster
543A Mapping
543B Mapping
544 The third embedding space
544 ₁ First Cluster
544 ₂ Second Cluster
544 ₃ Third Cluster
545A Mapping
545B Mapping
546 The Fourth Embedding Space
547 Mapping
548 The fifth embedding space
548 ₁ First Cluster
548 ₂ Second Cluster
548 ₃ 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 (60)

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;
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. The method of claim 1, 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. The method of claim 1, wherein the first-level design input for the requested process automation equipment includes natural language input, and the one or more template design documents for the requested process automation equipment include 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. 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 for a field equipment room (FER) for the requested process automation facility. 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;
and processing the graph based on one or more machine learning models to generate the first embedding. The method of claim 5, wherein one or more of the machine learning models includes a graph neural network (GNN). The method of claim 5, 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. 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. 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. 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. 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 the processing includes calculating the number of distributed control nodes (DCNs) for the process unit. 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;
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. 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. The system of claim 12, wherein the first-level design input for the requested process automation equipment includes natural language input, and the one or more template design documents for the requested process automation equipment include 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. 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 for a field equipment room (FER) for the requested process automation facility. processing the first level design input to generate the first embedding;
generating a graph based on the first level design input;
and processing the graph based on one or more machine learning models to generate the first embedding. The system of claim 16, wherein one or more of the machine learning models includes a graph neural network (GNN). 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. 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 equipment, and a plurality of edges representing network communication channels between the plurality of process automation nodes. 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;
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. 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;
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. 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 in a hierarchy of design documents associated with designing the 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 in the hierarchy of design documents. 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. The method of any one of claims 21 to 23, wherein the providing step includes 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. The method of any one of claims 21 to 23, wherein the one or more reference process automation facilities include a plurality of reference process automation facilities. The method of claim 25, wherein the one or more additional designs include a persistent design shared among the plurality of reference process automation equipment. 24. The method of any one of claims 21 to 23, further comprising: comparing a first embedding generated based on the set of required process automation equipment designs with reference embeddings generated from multiple candidate reference process automation equipment designs, wherein the one or more reference process automation equipment are selected from the multiple candidate reference process automation equipment designs based on a measure of similarity between the first embedding and the reference embedding. 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 designs of one or more of the reference process automation equipment via one or more output devices;
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. 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 the 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. 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. The system of any one of claims 28 to 30, 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. The system of claim 28 , wherein the one or more reference process automation facilities include a plurality of reference process automation facilities. The system of claim 32, wherein the one or more additional designs include a persistent design shared among the plurality of reference process automation equipment. The system of claim 28, further comprising instructions for comparing a first embedding generated based on the set of design aspects 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. 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 equipment via one or more output devices;
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. 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 the 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. 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. 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. The non-transitory computer-readable medium of claim 35 , wherein the one or more reference process automation facilities include a plurality of reference process automation facilities. The non-transitory computer-readable medium of claim 39, wherein the one or more additional designs include a persistent design shared among the plurality of reference process automation equipment. 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;
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. The method of claim 41, wherein one or more of the machine learning models includes a graph neural network (GNN). The method of claim 41 or 42, 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. 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 required process automation equipment and a plurality of edges representing network communication channels between the plurality of process automation nodes. 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 equipment and a plurality of edges defining relationships between the one or more modular automated process assemblies and other elements of the requested process automation equipment. The method of claim 41, wherein the providing step includes 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. The method of claim 41 , wherein the one or more reference process automation facilities include a plurality of reference process automation facilities. The method of claim 46, wherein the one or more additional designs include a persistent design shared among multiple reference process automation facilities. The method of claim 41 further includes a step of comparing a first embedding generated based on the set of design aspects of the required process automation equipment using one or more of the machine learning models with reference embeddings generated based on the design aspects 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. 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 designs of one or more of the reference process automation equipment via one or more output devices;
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. The system of claim 50, wherein one or more of the machine learning models includes a graph neural network (GNN). The system described in claim 50 or 51, 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. 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 equipment and a plurality of edges representing network communication channels between the plurality of process automation nodes. 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 equipment, and a plurality of edges defining relationships between the one or more modular automated process assemblies and other elements of the requested process automation equipment. 52. 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. 51. The system of claim 50, wherein the one or more reference process automation facilities include a plurality of reference process automation facilities. The system of claim 56, wherein the one or more additional designs include a persistent design shared among the plurality of reference process automation equipment. The system of claim 50, further comprising instructions for comparing a first embedding generated based on the set of design aspects of the requested process automation equipment using one or more of the machine learning models with reference embeddings generated based on design aspects 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. 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 designs of one or more of the reference process automation equipment via one or more output devices;
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. The non-transitory computer-readable medium of claim 59, wherein one or more of the machine learning models includes a graph neural network (GNN).