Academia.eduAcademia.edu

Figure 9 – uploaded by Esteban Arroyo

See full PDFdownloadDownload figure
Figure 2.8: Excerpt of a piping and instrumentation diagram (P&ID)

Figure 2 8: Excerpt of a piping and instrumentation diagram (P&ID)

Related Figures (95)

Figure 1.1: Luyben’s regulatory control structure. Source [Luy9€ Due to its topological and algorithmic simplicity, Luyben’s basic regulatory structure |Luy96| was chosen as the T] EP control scheme to be used in this work. The reason for the selection of a simple control structure relies on the fact that the validation of the proposed method for plant abnormal behavior analysis (—> |6)) requires a detailed manual observation of simulation signals to explain observed symptoms and determine whether identified propagation paths are correct or incorrect. A simple contro 1 structure can facilitate this task by not obscuring the traceability of events. A simple control structure can facilitate this task by not obscuring the traceability of events.
Figure 1.1: Luyben’s regulatory control structure. Source [Luy9€ Due to its topological and algorithmic simplicity, Luyben’s basic regulatory structure |Luy96| was chosen as the T] EP control scheme to be used in this work. The reason for the selection of a simple control structure relies on the fact that the validation of the proposed method for plant abnormal behavior analysis (—> |6)) requires a detailed manual observation of simulation signals to explain observed symptoms and determine whether identified propagation paths are correct or incorrect. A simple contro 1 structure can facilitate this task by not obscuring the traceability of events. A simple control structure can facilitate this task by not obscuring the traceability of events.
\ piping and instrumentation diagram also referred to as piping and instrument diagram (P&ID) s a document representing the technical realization of a process by means of graphical symbols DIN EN ISO 10628, 2001]*. P&IDs typically include information regarding function or type of quipment, process measurements and control functions, identification numbers for equipment and nstrumentation (tags), indication of nominal diameters and pressure ratings, and specifications of naterial and type of piping. Figure [2.1] illustrates two examples of P&IDs. Figure 2.1: Excerpts of P&IDs found in the process industry. (a) Fragment of a chemical facility [Wikipedia Foundation, 2017|° (b) Segment of a power plant
\ piping and instrumentation diagram also referred to as piping and instrument diagram (P&ID) s a document representing the technical realization of a process by means of graphical symbols DIN EN ISO 10628, 2001]*. P&IDs typically include information regarding function or type of quipment, process measurements and control functions, identification numbers for equipment and nstrumentation (tags), indication of nominal diameters and pressure ratings, and specifications of naterial and type of piping. Figure [2.1] illustrates two examples of P&IDs. Figure 2.1: Excerpts of P&IDs found in the process industry. (a) Fragment of a chemical facility [Wikipedia Foundation, 2017|° (b) Segment of a power plant
A Control Logic Diagram (CLD) commonly referred to as Block Diagram (BD) is a graphical schematic providing a simple representation of the operation of individual equipment controls us- ing basic symbols [LANL, 2006]#. These symbols functionally relate control input-output actions without implying a specific hardware realization or describing involved low-level instrument signals. without implying a specific hardware realization or describing involved low-level instrument signals. Figure 2.2: Representation of a single flow control loop in different CLD standards. (a) ISA diagram (b) SAMA diagram (c) Company-specific diagram
A Control Logic Diagram (CLD) commonly referred to as Block Diagram (BD) is a graphical schematic providing a simple representation of the operation of individual equipment controls us- ing basic symbols [LANL, 2006]#. These symbols functionally relate control input-output actions without implying a specific hardware realization or describing involved low-level instrument signals. without implying a specific hardware realization or describing involved low-level instrument signals. Figure 2.2: Representation of a single flow control loop in different CLD standards. (a) ISA diagram (b) SAMA diagram (c) Company-specific diagram
Figure 2.3: Structures of raster and vector graphic images. (a) Raster image (b) Vector graphics image. Source [Pagin, 2016]°
Figure 2.3: Structures of raster and vector graphic images. (a) Raster image (b) Vector graphics image. Source [Pagin, 2016]°
Figure 2.5: Generalized Hough Transform. (a) Edge description (b) R-table All those accumulator cells, whose values are larger than one, represent a straight line which contains at least two pixels of the original image. The larger the cell value, the more pixels are contained in the line represented by the cell. The aim of the analysis is to determine the maxima in P, as those cells indicate the position of significant straight lines in the image |BFRRO1|. An analogous algorithm is used for locating other parametric shapes such as circles and ellipses. Based on Hough’s findings, Ballard proposed years later an algorithm generalizing the H7 for matching arbitrary non-parametric shapes. Ballard observed that the key for generalizatior was the use of directional information, and that this could be best described in form of R-tables Accordingly, in the generalized Hough Transform (GHT), every point (x,y) in the contour of the shape has a gradient ¢ and can be described by a magnitude (r) and an angle (0) with respect t« a reference point (Zc, yc), usually defined as the centroid of the shape. In this way, the informatior of every contour pixel can be indexed under discretized gradient values ¢@; in an R-table, as de picted in Figure [2.5] Thus, the resulting R-table fully characterizes the particular shape and allow: recomputing the location of the reference point during matching.
Figure 2.5: Generalized Hough Transform. (a) Edge description (b) R-table All those accumulator cells, whose values are larger than one, represent a straight line which contains at least two pixels of the original image. The larger the cell value, the more pixels are contained in the line represented by the cell. The aim of the analysis is to determine the maxima in P, as those cells indicate the position of significant straight lines in the image |BFRRO1|. An analogous algorithm is used for locating other parametric shapes such as circles and ellipses. Based on Hough’s findings, Ballard proposed years later an algorithm generalizing the H7 for matching arbitrary non-parametric shapes. Ballard observed that the key for generalizatior was the use of directional information, and that this could be best described in form of R-tables Accordingly, in the generalized Hough Transform (GHT), every point (x,y) in the contour of the shape has a gradient ¢ and can be described by a magnitude (r) and an angle (0) with respect t« a reference point (Zc, yc), usually defined as the centroid of the shape. In this way, the informatior of every contour pixel can be indexed under discretized gradient values ¢@; in an R-table, as de picted in Figure [2.5] Thus, the resulting R-table fully characterizes the particular shape and allow: recomputing the location of the reference point during matching.
Table 2.1: Morphological operations
Table 2.1: Morphological operations
Table 2.2: Example of Regular Expression (RegEx)
Table 2.2: Example of Regular Expression (RegEx)
Figure 2.6: Overview of methods for digitization of legacy documentation code to identify underlying graphic and text content. As depicted in Figure whereas Method 2 is 2.6 Method 1 allows for the analysis of (scanned) papers and bitmap PDFs, par ticularly suited for processing digital documents such as vector graphics PDFs or exported CAD files. Both methods have the ultimate aim of generating a computer- interpretable description of the analyzed document and comprise three general steps, respectively: Method 1: Optical Recognition, Semantic Analysis, and Representation; and Method 2: Code Pat- tern Recognition, Semantic Analysis, and Representation. As shown in the upper part of Figure 2.6] both proposed methods can be potentially interconnected by vectorization and rasterization
Figure 2.6: Overview of methods for digitization of legacy documentation code to identify underlying graphic and text content. As depicted in Figure whereas Method 2 is 2.6 Method 1 allows for the analysis of (scanned) papers and bitmap PDFs, par ticularly suited for processing digital documents such as vector graphics PDFs or exported CAD files. Both methods have the ultimate aim of generating a computer- interpretable description of the analyzed document and comprise three general steps, respectively: Method 1: Optical Recognition, Semantic Analysis, and Representation; and Method 2: Code Pat- tern Recognition, Semantic Analysis, and Representation. As shown in the upper part of Figure 2.6] both proposed methods can be potentially interconnected by vectorization and rasterization
Figure 2.7: Composition of a typical engineering diagram
Figure 2.7: Composition of a typical engineering diagram
Matching scores quantifying the extent of resemblance between found candidates and respective templates are used to define levels of confidence within the recognition process. Position coordinates of resulting found objects are stored, and their respective curves are suppressed from the image in order to facilitate the recognition of further artifacts.
Matching scores quantifying the extent of resemblance between found candidates and respective templates are used to define levels of confidence within the recognition process. Position coordinates of resulting found objects are stored, and their respective curves are suppressed from the image in order to facilitate the recognition of further artifacts.
Table 2.3: Enhanced Optical Character Recognition. Iterative thinning process Based on the notion that the tag identifier of an object is located in its surrounding area o within it, the coordinates of identified non-parametric objects are used to generate search windows The size of a window is typically proportional to the dimensions of the analyzed image or coul be conveniently defined by the user depending upon the considered diagram. An OCR algorithn (trained with standard fonts commonly used in engineering diagrams) searches for text withi the defined window. The search procedure is enhanced by applying a thinning process based o1 recursive morphological operations, which reduces noise and allows segmenting touching characters The process is repeated until one of the conditions described in Table [2.3] is met, in which even the characters corresponding to the current (0) or previous (-1) iteration are accordingly returnec Resulting characters are collected in a string and assigned as the tag of the respective object. Resulting characters are collected in a string and assigned as the tag of the respective object.
Table 2.3: Enhanced Optical Character Recognition. Iterative thinning process Based on the notion that the tag identifier of an object is located in its surrounding area o within it, the coordinates of identified non-parametric objects are used to generate search windows The size of a window is typically proportional to the dimensions of the analyzed image or coul be conveniently defined by the user depending upon the considered diagram. An OCR algorithn (trained with standard fonts commonly used in engineering diagrams) searches for text withi the defined window. The search procedure is enhanced by applying a thinning process based o1 recursive morphological operations, which reduces noise and allows segmenting touching characters The process is repeated until one of the conditions described in Table [2.3] is met, in which even the characters corresponding to the current (0) or previous (-1) iteration are accordingly returnec Resulting characters are collected in a string and assigned as the tag of the respective object. Resulting characters are collected in a string and assigned as the tag of the respective object.
Table 2.4: Example of incidence matrix Table 2.5: Example of connectivity matrix
Table 2.4: Example of incidence matrix Table 2.5: Example of connectivity matrix
Table 2.6: Example of coordinates table Both incidence and connectivity matrices as well as coordinates tables can be codified as spread- sheets (e.g., on MS Excel or C# Windows Forms) and be recursively accessed for the derivation of object-oriented models, as discussed in more detail in Chapter 3] In addition, they might be used for basic tasks such as the generation of part lists or the solution of queries regarding the presence of specifics items or item types.
Table 2.6: Example of coordinates table Both incidence and connectivity matrices as well as coordinates tables can be codified as spread- sheets (e.g., on MS Excel or C# Windows Forms) and be recursively accessed for the derivation of object-oriented models, as discussed in more detail in Chapter 3] In addition, they might be used for basic tasks such as the generation of part lists or the solution of queries regarding the presence of specifics items or item types.
Figure 2.10: (a) Two types of valves (b) Corresponding BS Accordingly, the first step for the database creation is the determination of a basic shape for every model symbol. A BS is defined as the largest number of interconnected primitives of a symbol forming a loop. If the symbo has no loops, the open series of primitives with the largest number is regarded as the BS. Figure 2.10 depicts two different types of valves, both characterized by the BS illustrated in Figure 2.10p.
Figure 2.10: (a) Two types of valves (b) Corresponding BS Accordingly, the first step for the database creation is the determination of a basic shape for every model symbol. A BS is defined as the largest number of interconnected primitives of a symbol forming a loop. If the symbo has no loops, the open series of primitives with the largest number is regarded as the BS. Figure 2.10 depicts two different types of valves, both characterized by the BS illustrated in Figure 2.10p.
Table 2.7: Primitive Information Matrix (PIM) b. Symbol recognition
Table 2.7: Primitive Information Matrix (PIM) b. Symbol recognition
the corresponding Basic Shape Array (BSA). Here, the first two rows represent the inclined line while the last two deno set to NaN since the COGjs and the COGgzg have the same coordinates (i.e., cases the magnitude of te the vertical lines. Note that the reference angles of the inclined lines a1 R| = 0). In suc the NaN angles cannot be considered as a pattern during symbol identifice tion; instead, the position of NaN values in determined cells of the BSA defines the pattern. Th: allows the method to id By way of illustration, entify objects with certain geometric variations such as ununiform scaling two valves whose inclined lines have different slope (e.g., due to ununifort stretching) have the same BSA, and accordingly can be identified based on the same template. Figure 2.11: Basic shape with reference lines and COG
the corresponding Basic Shape Array (BSA). Here, the first two rows represent the inclined line while the last two deno set to NaN since the COGjs and the COGgzg have the same coordinates (i.e., cases the magnitude of te the vertical lines. Note that the reference angles of the inclined lines a1 R| = 0). In suc the NaN angles cannot be considered as a pattern during symbol identifice tion; instead, the position of NaN values in determined cells of the BSA defines the pattern. Th: allows the method to id By way of illustration, entify objects with certain geometric variations such as ununiform scaling two valves whose inclined lines have different slope (e.g., due to ununifort stretching) have the same BSA, and accordingly can be identified based on the same template. Figure 2.11: Basic shape with reference lines and COG
The next step within the database creation is the derivation of the Characteristics Graphs (CGs) associated to the previously extracted BSs. A CG is a star-shaped graph in which exterior nodes represent the symbol primitives not included in the BS, and the edges denote the geometrical relations between those primitives and a reference (center node) defined as the first primitive of the basic shape array. Figure 2.12p depicts a CG example.
The next step within the database creation is the derivation of the Characteristics Graphs (CGs) associated to the previously extracted BSs. A CG is a star-shaped graph in which exterior nodes represent the symbol primitives not included in the BS, and the edges denote the geometrical relations between those primitives and a reference (center node) defined as the first primitive of the basic shape array. Figure 2.12p depicts a CG example.
Table 2.8: Basic shape array of a valve
Table 2.8: Basic shape array of a valve
> —> primitive (ZL) and the projection (Rs) joining the first endpoint of that primitive and the firs > endpoint of the respective external primitive; 1; is the relative length of the projection Rg 1 wit respect to the center primitive, i.e., with respect to the center of gravity directed towards COG'gsg, ‘-1’ when + an [Rsil. and d, is the relative direction of the projection Rg |L| of the BS (COG gs) with values ‘1’ when the projection i the projection is directed away from COGgzg, and ‘0’ whe the relative direction is undetermined (i.e., when the L vector of the center primitive is in lin with the COGgs). The calculation o o2, lz, and dz is analogously done by considering this tim the second endpoints of the center and external primitives.
> —> primitive (ZL) and the projection (Rs) joining the first endpoint of that primitive and the firs > endpoint of the respective external primitive; 1; is the relative length of the projection Rg 1 wit respect to the center primitive, i.e., with respect to the center of gravity directed towards COG'gsg, ‘-1’ when + an [Rsil. and d, is the relative direction of the projection Rg |L| of the BS (COG gs) with values ‘1’ when the projection i the projection is directed away from COGgzg, and ‘0’ whe the relative direction is undetermined (i.e., when the L vector of the center primitive is in lin with the COGgs). The calculation o o2, lz, and dz is analogously done by considering this tim the second endpoints of the center and external primitives.
Figure 2.14: General structure of the a symbol database By way of illustration, consider the valve symbol illustrated in Figure [2.12p, and its respective BS depicted in Figure Assuming that primitive 3 is the reference primitive of the CG, an edge joining primitive 3 and primitive 6 is constructed. Accordingly, the projection is calculated, as shown in Figure [2.13h. From there, the respective angle and the relative length are computed. In addition, the relative direction is found to be ‘0’ as the center primitive (primitive 3) is in line with the COG gg. Following the same methodology, the respective values for the second endpoints are calculated, as depicted in Figure |2.13p. In case the CG should include polyline or circle primitives, specific geometric features must be added to the respective CG nodes. Concretely, for polylines, the Relative Length given by the ratio of the curve length to the distance between its endpoints (magnitude of T), as well as the Start- Angle and End-Angle are stored, whereas for circles, the ratio of the radius to the length of the projection Rs is used to describe the corresponding node.
Figure 2.14: General structure of the a symbol database By way of illustration, consider the valve symbol illustrated in Figure [2.12p, and its respective BS depicted in Figure Assuming that primitive 3 is the reference primitive of the CG, an edge joining primitive 3 and primitive 6 is constructed. Accordingly, the projection is calculated, as shown in Figure [2.13h. From there, the respective angle and the relative length are computed. In addition, the relative direction is found to be ‘0’ as the center primitive (primitive 3) is in line with the COG gg. Following the same methodology, the respective values for the second endpoints are calculated, as depicted in Figure |2.13p. In case the CG should include polyline or circle primitives, specific geometric features must be added to the respective CG nodes. Concretely, for polylines, the Relative Length given by the ratio of the curve length to the distance between its endpoints (magnitude of T), as well as the Start- Angle and End-Angle are stored, whereas for circles, the ratio of the radius to the length of the projection Rs is used to describe the corresponding node.
Figure 2.15: P&ID recognized with the proposed raster-based method
Figure 2.15: P&ID recognized with the proposed raster-based method
Table 2.9: Excerpts of the connectivity matrix (left) and coordinates table (right) obtained in the analysis of a P&ID with the proposed vector-based method Experimental results obtained in this test demonstrated that the vector-based algorithm was also capable of recognizing the totality of trained symbols (equipment and instrumentation), as well as all characters (text identifiers) and connections with respective type. Such results are fundamen- tally the same as those obtained with Method 1 (see Figure no warnings were generated during the recognition process. Table 2.15) wi th the only difference that 2.9 illustrates excerpts of the respective connectivity matrix and coordinates table obtained in this test.
Table 2.9: Excerpts of the connectivity matrix (left) and coordinates table (right) obtained in the analysis of a P&ID with the proposed vector-based method Experimental results obtained in this test demonstrated that the vector-based algorithm was also capable of recognizing the totality of trained symbols (equipment and instrumentation), as well as all characters (text identifiers) and connections with respective type. Such results are fundamen- tally the same as those obtained with Method 1 (see Figure no warnings were generated during the recognition process. Table 2.15) wi th the only difference that 2.9 illustrates excerpts of the respective connectivity matrix and coordinates table obtained in this test.
Table 2.10: Excerpts of the connectivity matrix (left) and coordinates table (right) obtainec in the analysis of a CLD with the proposed raster-based method A test of particular interest during this experiment was the identification of connection types, specifically those related to actuators (valves). Recalling the recognition of a P&ID in Section|2.6.1 valves, as flow objects, were linked to other components through MaterialFlow connections (see Figure [2.15] and Table [2-9). In CLDs, however, valves connect to control elements through logical linking artifacts, and accordingly their connections are to be classified as of type InformationFlow. The method successfully passed the test: without explicitly specifying the class of document (i.e., P&ID or CLD), the connectivity detection algorithm was capable of automatically inferring the semantics of controller-actuator links and correspondingly creating the required InformationFlow connections. These can be observed as “I” entries in the excerpt of the CM presented in Table
Table 2.10: Excerpts of the connectivity matrix (left) and coordinates table (right) obtainec in the analysis of a CLD with the proposed raster-based method A test of particular interest during this experiment was the identification of connection types, specifically those related to actuators (valves). Recalling the recognition of a P&ID in Section|2.6.1 valves, as flow objects, were linked to other components through MaterialFlow connections (see Figure [2.15] and Table [2-9). In CLDs, however, valves connect to control elements through logical linking artifacts, and accordingly their connections are to be classified as of type InformationFlow. The method successfully passed the test: without explicitly specifying the class of document (i.e., P&ID or CLD), the connectivity detection algorithm was capable of automatically inferring the semantics of controller-actuator links and correspondingly creating the required InformationFlow connections. These can be observed as “I” entries in the excerpt of the CM presented in Table
Figure 2.16: CLD recognized with the proposed vector-based method Analogous to the P&ID recognition trial (> 2.6.1.2 , the SVG code of the analyzed CLD was extracted from an existing PDF document. Following the procedure described in Section |2.5.3.1} symbol and character templates were trained and stored in the database. As for recognition toler- ances, tq, , tg, ty and v were respectively set to 10 %, 1%, 1% and 5%.
Figure 2.16: CLD recognized with the proposed vector-based method Analogous to the P&ID recognition trial (> 2.6.1.2 , the SVG code of the analyzed CLD was extracted from an existing PDF document. Following the procedure described in Section |2.5.3.1} symbol and character templates were trained and stored in the database. As for recognition toler- ances, tq, , tg, ty and v were respectively set to 10 %, 1%, 1% and 5%.
Figure 3.1: CAEX modeling elements and structure 3.2.1.3 AutomationML
Figure 3.1: CAEX modeling elements and structure 3.2.1.3 AutomationML
Figure 3.2: Information formalism level of engineering sources
Figure 3.2: Information formalism level of engineering sources
SystemUnitClasses (SUCs) and RoleClasses (RCs) used in this step are based on an extended version} of the object information model (OIM) presented in [HMAF16|* and [|AHFR16]*. Despite being based on the same OO model, an essential difference between SUCs and RCs is that the latter do not deploy all object attributes defined in the information model, as their function is to depict the roles (and if necessary requirements) of created objects and not to fully characterize them by means of properties. The used object information model (see Figure 3.3) has been designed to fulfill two main requir ments: (a) be generic enough to allow the functional description of any production process the process industry, and (b) be extensible to fit the specificities of particular processes and u cases. Within this model, light blue elements represent common classes of plant components (e.; Vessel, ContinuousSensor, and PidController), yellow elements indicate abstract classes used f classification purposes (e.g., FlowObject), and gray elements designate model leaves, i.e., gener classification classes allowing no further derivations (e.g., Unknown).
SystemUnitClasses (SUCs) and RoleClasses (RCs) used in this step are based on an extended version} of the object information model (OIM) presented in [HMAF16|* and [|AHFR16]*. Despite being based on the same OO model, an essential difference between SUCs and RCs is that the latter do not deploy all object attributes defined in the information model, as their function is to depict the roles (and if necessary requirements) of created objects and not to fully characterize them by means of properties. The used object information model (see Figure 3.3) has been designed to fulfill two main requir ments: (a) be generic enough to allow the functional description of any production process the process industry, and (b) be extensible to fit the specificities of particular processes and u cases. Within this model, light blue elements represent common classes of plant components (e.; Vessel, ContinuousSensor, and PidController), yellow elements indicate abstract classes used f classification purposes (e.g., FlowObject), and gray elements designate model leaves, i.e., gener classification classes allowing no further derivations (e.g., Unknown).
Within the second step of the OO modeling procedure, created objects are provided with nozzles (i.e., logical nozzles and measurement points) aimed at characterizing the physical positions where connections occur. Consequently, object interfaces are created within defined nozzles by considering their snecific tvpes.
Within the second step of the OO modeling procedure, created objects are provided with nozzles (i.e., logical nozzles and measurement points) aimed at characterizing the physical positions where connections occur. Consequently, object interfaces are created within defined nozzles by considering their snecific tvpes.
The creation of object interfaces considers the number of connections found for every object (i.e., non-empty entries within a row/column of the connectivity matrix). Corresponding interface classes are specified in accordance to the content of the cells. To illustrate, for vessel E100 (see Table 2.5) two interfaces are created, one of type MaterialFlowConnector (M) and one of type Information- FlowConnector (1). Finally, internal links connecting related objects through consistent interfaces, i.e., interfaces of the same type, are generated (see Figure |3.5] left), and object attributes describing geometrical tion collected from the coordinates table, are added (see object properties, i.e., dimensional informa Figure right). As an ultimate result, an OO model describing the connectivity and semantic information of the analyzed document (P&ID or CLD) is obtained.
The creation of object interfaces considers the number of connections found for every object (i.e., non-empty entries within a row/column of the connectivity matrix). Corresponding interface classes are specified in accordance to the content of the cells. To illustrate, for vessel E100 (see Table 2.5) two interfaces are created, one of type MaterialFlowConnector (M) and one of type Information- FlowConnector (1). Finally, internal links connecting related objects through consistent interfaces, i.e., interfaces of the same type, are generated (see Figure |3.5] left), and object attributes describing geometrical tion collected from the coordinates table, are added (see object properties, i.e., dimensional informa Figure right). As an ultimate result, an OO model describing the connectivity and semantic information of the analyzed document (P&ID or CLD) is obtained.
representing the identified objects and their connections. Thus, users can visualize found elements and compare them with the original document, effecting changes where necessary. Corrections carried out in the graphical interface have a direct effect on the OO model. Warnings generated during the recognition process can be used at this stage to prioritize the crosschecking procedure. Moreover, the user can manually add complementary quantitative information to plant assets, such as their type and power, by completing pre-defined object attributes or by creating new ones depending upon the specific information requirements of envisioned use cases. depending upon the specific information requirements of envisioned use cases. Figure 3.6: Visual inspection process
representing the identified objects and their connections. Thus, users can visualize found elements and compare them with the original document, effecting changes where necessary. Corrections carried out in the graphical interface have a direct effect on the OO model. Warnings generated during the recognition process can be used at this stage to prioritize the crosschecking procedure. Moreover, the user can manually add complementary quantitative information to plant assets, such as their type and power, by completing pre-defined object attributes or by creating new ones depending upon the specific information requirements of envisioned use cases. depending upon the specific information requirements of envisioned use cases. Figure 3.6: Visual inspection process
model parts. Figure 3.7: Inter-model referencing The method described in the previous sections deals with the generation of OO models from single diagrams, whether they be P&IDs or CLDs. In most projects in the process industry, nevertheless, the complete plant topology and its respective control structures are not depicted as a single schematic, but instead as a series of interrelated diagrams. This implies that in order to create an overall view of the plant, single diagrams must be consistently put together and interpreted as a whole. The same principle applies to single OO models, which in this sense can be regarded as model parts.
model parts. Figure 3.7: Inter-model referencing The method described in the previous sections deals with the generation of OO models from single diagrams, whether they be P&IDs or CLDs. In most projects in the process industry, nevertheless, the complete plant topology and its respective control structures are not depicted as a single schematic, but instead as a series of interrelated diagrams. This implies that in order to create an overall view of the plant, single diagrams must be consistently put together and interpreted as a whole. The same principle applies to single OO models, which in this sense can be regarded as model parts.
Following the procedure presented in Section |3.4.1.1} the OO modeling algorithm parsed the con- nectivity matrix corresponding to the analyzed P&ID and generated an object, specifically an InternalElement (IE), for every found plant component. The mapping scheme used during this step is presented in Table [3.1] As depicted in Figure 3.8} every created IE was assigned a SystemUnitClass and a RoleClass in accordance to the types originally defined in the object information model. A brief inspection of the created objects indicates that the rule-based nomenclature approach applied during instantiation allowed the successful specification and reclassification of certain object types. By way of illustra- tion, the instruments LIR106 and PIR108 depicted in F igure [3.8] were respectively instantiated as LevelSensor and PressureSensor, despite the fact of being initially identified as generic sensors by
Following the procedure presented in Section |3.4.1.1} the OO modeling algorithm parsed the con- nectivity matrix corresponding to the analyzed P&ID and generated an object, specifically an InternalElement (IE), for every found plant component. The mapping scheme used during this step is presented in Table [3.1] As depicted in Figure 3.8} every created IE was assigned a SystemUnitClass and a RoleClass in accordance to the types originally defined in the object information model. A brief inspection of the created objects indicates that the rule-based nomenclature approach applied during instantiation allowed the successful specification and reclassification of certain object types. By way of illustra- tion, the instruments LIR106 and PIR108 depicted in F igure [3.8] were respectively instantiated as LevelSensor and PressureSensor, despite the fact of being initially identified as generic sensors by
\ more detailed observation of the generated model allows confirming that nozzles, interfaces, an nternal links were correctly instantiated. This can be observed in Figure 3.9] An important aspec o notice here is the consistency of the established material and information connections. Observ hat internal links only connect interfaces of the same type, and that established connectior re unambiguously described by the references (esp., universal unique identifiers) of the respectir inked connectors (see RefSideA and RefSideB attributes in the right-hand side of Figure[3.9 . Not yesides that although internal links do not contain a direction attribute, the effective directionalit f a given connection can be derived during parsing by interpreting the RefSideA and RefSide roperties as source and destination connectors, respectively. properties as source and destination connectors, respectively.
\ more detailed observation of the generated model allows confirming that nozzles, interfaces, an nternal links were correctly instantiated. This can be observed in Figure 3.9] An important aspec o notice here is the consistency of the established material and information connections. Observ hat internal links only connect interfaces of the same type, and that established connectior re unambiguously described by the references (esp., universal unique identifiers) of the respectir inked connectors (see RefSideA and RefSideB attributes in the right-hand side of Figure[3.9 . Not yesides that although internal links do not contain a direction attribute, the effective directionalit f a given connection can be derived during parsing by interpreting the RefSideA and RefSide roperties as source and destination connectors, respectively. properties as source and destination connectors, respectively.
Figure 3.11: Visual inspection of the generated OO P&ID model for different objects.
Figure 3.11: Visual inspection of the generated OO P&ID model for different objects.
In an analogous fashion, the modeling method was validated on the generation of an OO control logic diagram (CLD). As in the P&ID trial described in the previous section, the corresponding connectivity matrix was used as information source for the generation of objects. Table [3.2| depicts the mapping used in this test.
In an analogous fashion, the modeling method was validated on the generation of an OO control logic diagram (CLD). As in the P&ID trial described in the previous section, the corresponding connectivity matrix was used as information source for the generation of objects. Table [3.2| depicts the mapping used in this test.
Figure 3.12: Objects in the generated OO CLD model. XML visualization
Figure 3.12: Objects in the generated OO CLD model. XML visualization
Figure 3.13: Nozzles, interfaces, and internal links in the O00 CLD model. XML visualizatior with manually added graphical internal links
Figure 3.13: Nozzles, interfaces, and internal links in the O00 CLD model. XML visualizatior with manually added graphical internal links
Figure 3.14: Visual inspection of the generated OO P&ID model Analogous to the visual inspection of the P&ID in the previous trial, the consistency of the created CLD model was verified by using the graphical representation generated by the algorithm (see Figure 3.14). Once again, no corrections were required in this test. The resulting OO CLD model can be found online at http://aut.hsu-hh.de/TEP CLD.
Figure 3.14: Visual inspection of the generated OO P&ID model Analogous to the visual inspection of the P&ID in the previous trial, the consistency of the created CLD model was verified by using the graphical representation generated by the algorithm (see Figure 3.14). Once again, no corrections were required in this test. The resulting OO CLD model can be found online at http://aut.hsu-hh.de/TEP CLD.
The development of NORSOK I-005 is motivated by existing gaps within the plant engineering workflow, specifically between the process design and the control design phases. As discussed in the standard, process engineers specify the production process through the creation of P&IDs during _ front end engineering design (FEED). Throughout this phase, they acquire in-depth understanding of the overall plant behavior, particularly on its functionality and operational aspects. However, such understanding is not thoroughly described in the corresponding P&IDs, owing to the fact In the context of I EF, engineering tools and analysis algorithms are called to gain the maximum profit of interdisciplinary knowledge and improve thereby the efficiency and reliability of offered tasks and services |KG13]. Plant diagnosis systems in the process industry, for instance, are called to integrate plant data, historical informa tion, process know-how, and plant structure as a key for enhanced root-cause analysis [[AEA-T! HCDOC-1252, 2001]*. Likewise, functional diagnostics must be based on models which should preferably stem from engineering tools, be available in object-oriented formats, and provide effective means for information access and exchange.
The development of NORSOK I-005 is motivated by existing gaps within the plant engineering workflow, specifically between the process design and the control design phases. As discussed in the standard, process engineers specify the production process through the creation of P&IDs during _ front end engineering design (FEED). Throughout this phase, they acquire in-depth understanding of the overall plant behavior, particularly on its functionality and operational aspects. However, such understanding is not thoroughly described in the corresponding P&IDs, owing to the fact In the context of I EF, engineering tools and analysis algorithms are called to gain the maximum profit of interdisciplinary knowledge and improve thereby the efficiency and reliability of offered tasks and services |KG13]. Plant diagnosis systems in the process industry, for instance, are called to integrate plant data, historical informa tion, process know-how, and plant structure as a key for enhanced root-cause analysis [[AEA-T! HCDOC-1252, 2001]*. Likewise, functional diagnostics must be based on models which should preferably stem from engineering tools, be available in object-oriented formats, and provide effective means for information access and exchange.
Figure 4.2: Excerpt of a DOM tree structure for a CAEX document
Figure 4.2: Excerpt of a DOM tree structure for a CAEX document
As next step, the algorithm parses Tpgj;p searching for Og_» objects in the P&ID. Recall here that Oc_, objects represent linking artifacts (sensors and actuators), and as such they are also contained in the P&ID. Notice, however, that in some cases the tags of corresponding Og_p objects may differ between CLDs and P&IDs owing to document designation rules. Accordingly, the search algorithm incorporates knowledge on used nomenclature conventions by means of user-defined regular expressions (2.2.3.5 . For every found Oc_» object, new nozzles and interfaces are created in accordance to the connectivity defined in C;. The respective IDs of new created interfaces are stored for further use during the definition of connections in a later step of the method. stored for further use during the definition of connections in a later step of the method. The routine continues by creating instances Oy in Tpgyp for every object in C;, except Oc_,s objects. Note that the latter already exist in Tpyrp and accordingly must not be created anew. Should this no t be the case and one or more Og_y objects do not exist in Tpgyrp, the inconsis- tency will be identified during the creation of object connections in a later step of the method? Within the ins tantiation process the algorithm preserves class-specific data and object interfaces, but recomputes the values of geometric attributes including diagram coordinates and dimensions. The determina can be address perspective, es tion of the coordinates at which Oy objects are to be placed in the integrated model ed by considering different functional and visualization criteria. From a functional tablishing the required connectivity of new and existing objects essentially suffices the requirements of the object placing problem. Thus, Oy objects could be simply placed in the neighborhood of those objects to which they must connect. From a visualization perspective, in contrast, the appearance and readability of objects in the diagram plays a fundamental role in determining insertion coordinates. In this case, optimal locations can be found by minimizing the lengths of new connection lines and the degree of overlap between new and existing objects. As the
As next step, the algorithm parses Tpgj;p searching for Og_» objects in the P&ID. Recall here that Oc_, objects represent linking artifacts (sensors and actuators), and as such they are also contained in the P&ID. Notice, however, that in some cases the tags of corresponding Og_p objects may differ between CLDs and P&IDs owing to document designation rules. Accordingly, the search algorithm incorporates knowledge on used nomenclature conventions by means of user-defined regular expressions (2.2.3.5 . For every found Oc_» object, new nozzles and interfaces are created in accordance to the connectivity defined in C;. The respective IDs of new created interfaces are stored for further use during the definition of connections in a later step of the method. stored for further use during the definition of connections in a later step of the method. The routine continues by creating instances Oy in Tpgyp for every object in C;, except Oc_,s objects. Note that the latter already exist in Tpyrp and accordingly must not be created anew. Should this no t be the case and one or more Og_y objects do not exist in Tpgyrp, the inconsis- tency will be identified during the creation of object connections in a later step of the method? Within the ins tantiation process the algorithm preserves class-specific data and object interfaces, but recomputes the values of geometric attributes including diagram coordinates and dimensions. The determina can be address perspective, es tion of the coordinates at which Oy objects are to be placed in the integrated model ed by considering different functional and visualization criteria. From a functional tablishing the required connectivity of new and existing objects essentially suffices the requirements of the object placing problem. Thus, Oy objects could be simply placed in the neighborhood of those objects to which they must connect. From a visualization perspective, in contrast, the appearance and readability of objects in the diagram plays a fundamental role in determining insertion coordinates. In this case, optimal locations can be found by minimizing the lengths of new connection lines and the degree of overlap between new and existing objects. As the
Table 4.1: AFDD AUC information excerpt their containing sources and respective availability, as well as individual priorities and requirements. In the particular case of plant abnormal situation analysis, relevant information is collected in the AFDD AUC as shown in the data excerpt of Table [4.1] For further information on automation use cases, the reader is referred to [ACHF14]*.
Table 4.1: AFDD AUC information excerpt their containing sources and respective availability, as well as individual priorities and requirements. In the particular case of plant abnormal situation analysis, relevant information is collected in the AFDD AUC as shown in the data excerpt of Table [4.1] For further information on automation use cases, the reader is referred to [ACHF14]*.
The syntax and semantics of defined attributes are not constrained to a specific implementatio In fact, they can adopt different forms depending upon the particular modeling requirements « the considered use case or target application. The interpretation of the aggregated data is a tas of external applications, which should have knowledge on the format and underlying meaning « the retrieved attributes. Observe that attributes considered at this stage are in general not part « the object information model (OIM) presented in Chapter 3 The reason for this is that the OI] aims at providing a general information structure for generating plant models serving as a base fe several AoA use-cases but not tailored to any in particular. Defining use-case-specific attributes i the OIM would result in unnecessarily large plant models and reduce modeling flexibility.
The syntax and semantics of defined attributes are not constrained to a specific implementatio In fact, they can adopt different forms depending upon the particular modeling requirements « the considered use case or target application. The interpretation of the aggregated data is a tas of external applications, which should have knowledge on the format and underlying meaning « the retrieved attributes. Observe that attributes considered at this stage are in general not part « the object information model (OIM) presented in Chapter 3 The reason for this is that the OI] aims at providing a general information structure for generating plant models serving as a base fe several AoA use-cases but not tailored to any in particular. Defining use-case-specific attributes i the OIM would result in unnecessarily large plant models and reduce modeling flexibility.
Table 4.2: Classified AFDD AUC data
Table 4.2: Classified AFDD AUC data
Figure 4.5: Applied AML facet and group concepts
Figure 4.5: Applied AML facet and group concepts
In accordance to the model integration method presented in Section 4.4.1] the implemented algo- rithm successfully loaded the analyzed P&ID and CLD AML models into memory and computed their respective node-trees (T¢_p and Tpyrp) by using DOM (-+}4.2.1). Subsequently, it recursively proceeded to get the next objects in T¢yzp and calculated their full connectivity chains. Figure illustrates two of the chains captured within this process. 4.6 Figure 4.6: Example of connectivity chains computed within the analysis of a CLD
In accordance to the model integration method presented in Section 4.4.1] the implemented algo- rithm successfully loaded the analyzed P&ID and CLD AML models into memory and computed their respective node-trees (T¢_p and Tpyrp) by using DOM (-+}4.2.1). Subsequently, it recursively proceeded to get the next objects in T¢yzp and calculated their full connectivity chains. Figure illustrates two of the chains captured within this process. 4.6 Figure 4.6: Example of connectivity chains computed within the analysis of a CLD
Figure 4.7: Excerpt of the resulting integrated topology model
Figure 4.7: Excerpt of the resulting integrated topology model
Figure 4.8: Graphical depiction of the resulting integrated topology model
Figure 4.8: Graphical depiction of the resulting integrated topology model
Subsequently, sorted information was manually aggregated in the topology model in form of at- tributes following the general provisions discussed in Section 4.4.2.2 Figure A.9 depicts an excerpt of the resulting integrated model with aggregated AFDD data (i.e., propagation-related factors). Observe here that created attributes are associated to model objects representing plant assets, instrumentation devices, and control equipment. Notice besides that added information is charac- terized by metadata in form of descriptive properties (i.e., names, descriptions, units, values, and data types), which enable external applications to retrieve and interpret content unambiguously.
Subsequently, sorted information was manually aggregated in the topology model in form of at- tributes following the general provisions discussed in Section 4.4.2.2 Figure A.9 depicts an excerpt of the resulting integrated model with aggregated AFDD data (i.e., propagation-related factors). Observe here that created attributes are associated to model objects representing plant assets, instrumentation devices, and control equipment. Notice besides that added information is charac- terized by metadata in form of descriptive properties (i.e., names, descriptions, units, values, and data types), which enable external applications to retrieve and interpret content unambiguously.
Table 5.1: Necessary assumptions for the automatic creation of a simulation model
Table 5.1: Necessary assumptions for the automatic creation of a simulation model
the respective instance constructors, as depicted in the upper part of Figure In this way, all parameters required for dynamic simulation are set during the object instantiation process. The second construct, in turn, is used for connecting objects and thus enabling flow dynamics within the network. As shown in the lower part of Figure 5.1] connections among objects are implemented by linking consistent object ports through so-called connectivity equations.
the respective instance constructors, as depicted in the upper part of Figure In this way, all parameters required for dynamic simulation are set during the object instantiation process. The second construct, in turn, is used for connecting objects and thus enabling flow dynamics within the network. As shown in the lower part of Figure 5.1] connections among objects are implemented by linking consistent object ports through so-called connectivity equations.
As a first step for the generation of a simulation model, the algorithm examines the topolog: model identifying object instances that can be simulated based on existing (predefined and user defined) Modelica simulation objects. Every identified simulable object is subsequently converte: into a simulation instance, where the respective instance-specific attributes are completed in t corresponding code template. In this fashion, every created simulation object implicitly generat its own Modelica code and stores it internally. It is important to observe that Modelica speci naming conventions must be followed at this stage. For example, instance names are neither allowec to include the characters “-” and “/” nor to start with a numerical character. Therefore, t algorithm replaces forbidden characters with empty strings and places an underscore in front each instance name to ensure that no name starts with a number (see e.g., Tank in Figure 5.3). at ‘a li at Oo
As a first step for the generation of a simulation model, the algorithm examines the topolog: model identifying object instances that can be simulated based on existing (predefined and user defined) Modelica simulation objects. Every identified simulable object is subsequently converte: into a simulation instance, where the respective instance-specific attributes are completed in t corresponding code template. In this fashion, every created simulation object implicitly generat its own Modelica code and stores it internally. It is important to observe that Modelica speci naming conventions must be followed at this stage. For example, instance names are neither allowec to include the characters “-” and “/” nor to start with a numerical character. Therefore, t algorithm replaces forbidden characters with empty strings and places an underscore in front each instance name to ensure that no name starts with a number (see e.g., Tank in Figure 5.3). at ‘a li at Oo
Figure 5.4: Communication structure used for process control in the model 5.4.4 Control execution
Figure 5.4: Communication structure used for process control in the model 5.4.4 Control execution
Based on the T] EP integrated topology model presented in Chapter [4] and by using the algorithm described in Sec ated?| Here, con tion[5.4] the process simulation model shown in Figure[5.6]was automatically gener- nection blocks (i.e., sensing, actuation, and feedback points) as well as information links and switches have been omitted for the sake of readability. These objects, however, are part of the model (i.e., they are instantiated in the actual Modelica code, but without visualization pa- rameters) and are accordingly used during simulation. The depicted model forms the testbed used in the sequel for several applications including the analysis of open-loop and closed-loop process behaviors, and the verification of controller actions. behaviors, and the verification of controller actions. Figure 5.6: Simplified low-fidelity simulation model of the TEP 5.5.2 Application examples
Based on the T] EP integrated topology model presented in Chapter [4] and by using the algorithm described in Sec ated?| Here, con tion[5.4] the process simulation model shown in Figure[5.6]was automatically gener- nection blocks (i.e., sensing, actuation, and feedback points) as well as information links and switches have been omitted for the sake of readability. These objects, however, are part of the model (i.e., they are instantiated in the actual Modelica code, but without visualization pa- rameters) and are accordingly used during simulation. The depicted model forms the testbed used in the sequel for several applications including the analysis of open-loop and closed-loop process behaviors, and the verification of controller actions. behaviors, and the verification of controller actions. Figure 5.6: Simplified low-fidelity simulation model of the TEP 5.5.2 Application examples
Figure 5.7: Levels of the separator S012 and stripping column E005 for different valve aper- tures. 10 % (black and brown), 50 % (green and purple), 90 % (red and blue) A more detailed analysis of Figure|5.7/allows observing a flatter curvature in the trends correspond- ing to the stripper level (see brown, purple, and blue curves). This behavior reveals a concurrent outflow leaving the stripper base and accumulating in the holdup of reboiler G111 as the stripper ic heine filled.
Figure 5.7: Levels of the separator S012 and stripping column E005 for different valve aper- tures. 10 % (black and brown), 50 % (green and purple), 90 % (red and blue) A more detailed analysis of Figure|5.7/allows observing a flatter curvature in the trends correspond- ing to the stripper level (see brown, purple, and blue curves). This behavior reveals a concurrent outflow leaving the stripper base and accumulating in the holdup of reboiler G111 as the stripper ic heine filled.
Figure 5.8: Closed-loop process responses. PI temperature control.
Figure 5.8: Closed-loop process responses. PI temperature control.
Figure 5.9: Closed-loop process responses. P-only temperature control. Obviating the different observed response times, which can be influenced by adjusting the control parameters, a quick inspection of the results reveals that the main difference between both controller responses is the existence of a permanent error or steady state offset in the response of the P-only controller. Yet, the small magnitude of this error supports the claim of Luyben |Luy96|, who stated that for the control of the TEP, PI controllers do not offer significant advantages over P-only controllers owing to the intrinsic integrating nature of the process.
Figure 5.9: Closed-loop process responses. P-only temperature control. Obviating the different observed response times, which can be influenced by adjusting the control parameters, a quick inspection of the results reveals that the main difference between both controller responses is the existence of a permanent error or steady state offset in the response of the P-only controller. Yet, the small magnitude of this error supports the claim of Luyben |Luy96|, who stated that for the control of the TEP, PI controllers do not offer significant advantages over P-only controllers owing to the intrinsic integrating nature of the process.
Figure 5.10: Simulated controller actions. Detection of a wrong cascade configuration With the system in steady state, the cascade loop was activated with a local set point of 36.85 °C, i.e., 10 °C higher than the initial value of the controlled process variable. Figure 5. 10]illustrates the output of both controllers as well as the respective responses of the separator and reactor temper- atures. A quick inspection of the obtained trends allows observing a decrease of both temperatures (blue and magenta curves) instead of the aimed increase. This behavior indicates that the acting direction of the control loop has been mistakenly configured, which implies that the proportional constant of one of the controllers has the wrong sign. But which one? the master or the slave?
Figure 5.10: Simulated controller actions. Detection of a wrong cascade configuration With the system in steady state, the cascade loop was activated with a local set point of 36.85 °C, i.e., 10 °C higher than the initial value of the controlled process variable. Figure 5. 10]illustrates the output of both controllers as well as the respective responses of the separator and reactor temper- atures. A quick inspection of the obtained trends allows observing a decrease of both temperatures (blue and magenta curves) instead of the aimed increase. This behavior indicates that the acting direction of the control loop has been mistakenly configured, which implies that the proportional constant of one of the controllers has the wrong sign. But which one? the master or the slave?
After the loss of cooling water supply in condenser C115 at t=1h, the stream entering the separator S012 increases sharply in temperature. As a consequence, both separator temperature (3,1) and pressure (3,2) increase in accordance with the ideal gas law (IGL). The differential pressure driving the flow between the reactor R003 and the separator S012 (unmeasured) decreases as the separator pressure increases. This reduces the outflow from R003 without altering its inflow, leading to a reactor pressure increase occurring in parallel (2,2). Temperature in the reactor decreases (2,1) due to the action of a control loop which increases reactor cooling water to counteract the separator temperature increase. This effect outweighs the IGL effect of the reactor pressure increment. The
After the loss of cooling water supply in condenser C115 at t=1h, the stream entering the separator S012 increases sharply in temperature. As a consequence, both separator temperature (3,1) and pressure (3,2) increase in accordance with the ideal gas law (IGL). The differential pressure driving the flow between the reactor R003 and the separator S012 (unmeasured) decreases as the separator pressure increases. This reduces the outflow from R003 without altering its inflow, leading to a reactor pressure increase occurring in parallel (2,2). Temperature in the reactor decreases (2,1) due to the action of a control loop which increases reactor cooling water to counteract the separator temperature increase. This effect outweighs the IGL effect of the reactor pressure increment. The
A signed directed graph or signed digraph (SDG) is a qualitative model approach to fault diag- nosis that incorporates causal analysis to represent process behavior. It is a map reflecting causal associations between variables by means of nodes and directed arcs. In general, nodes can repre- sent process parameters such as physical magnitudes, sensors, system faults, component failures, or subsystem failures |CRBO1|, whereas directed arcs represent causal relationships between nodes. A node can take values normal “0”, high “+”, or low “-” representing its qualitative state. In turn, directed arcs are characterized by values “-” and “+”, which represent direct or inverse relationships (resp. reinforcement and suppression) between cause and effect nodes. Figure topology of a SDG. 6.2 depicts the basic The fundamental premise of digraph techniques is that cause and effect linkages must connect the fault origin to the observed symptoms of the underlying fault [KP87]. Accordingly, during diagnosis measured deviations are propagated from the effect node (symptom) to the cause nodes through consistent arcs until the root-node is identified [CRBO1).
A signed directed graph or signed digraph (SDG) is a qualitative model approach to fault diag- nosis that incorporates causal analysis to represent process behavior. It is a map reflecting causal associations between variables by means of nodes and directed arcs. In general, nodes can repre- sent process parameters such as physical magnitudes, sensors, system faults, component failures, or subsystem failures |CRBO1|, whereas directed arcs represent causal relationships between nodes. A node can take values normal “0”, high “+”, or low “-” representing its qualitative state. In turn, directed arcs are characterized by values “-” and “+”, which represent direct or inverse relationships (resp. reinforcement and suppression) between cause and effect nodes. Figure topology of a SDG. 6.2 depicts the basic The fundamental premise of digraph techniques is that cause and effect linkages must connect the fault origin to the observed symptoms of the underlying fault [KP87]. Accordingly, during diagnosis measured deviations are propagated from the effect node (symptom) to the cause nodes through consistent arcs until the root-node is identified [CRBO1).
Although SDGs are a suitable approach to causal modeling, their capabilities for detailed process descriptions may result insufficient in some cases. Consider for instance the SDG segment illustrated in Figure 6.3} which depicts some of the causal relations occurring in a typical reactor. As it is known from first physical principles, the cooling water (CW) flow causes a suppression effect (-) on the process temperature, whereas the temperatures of the reactant feeds produce a reinforcement influence (+) on the same variable. In the event of a disturbance, the behavior of the process temperature will largely depend on whether the cooling water flow or the reactants temperatures have the stronger influence, as well as on the time constants of the underlying causalities. Suck relations, however, cannot be represented through SDGs, as these neither quantify the extent tc which a node affects its successor nor describe temporal causalities. Another limitation of SDGs is their incapability to model qualitative relationships between process variables that cannot be simply described as “suppression” or “reinforcement” effects. Take as an example the case in which the magnitude “feed composition” is modeled as a node in a SDG. One may naturally expect that the composition has a direct influence, among other variables, on the process temperature, implying thereby the existence of a direct arc in the causal graph. Nevertheless, due to the vagueness of the term “feed composition” —understanding this as the concentrations of different chemical components in the feed— it is not possible to clearly determine wether the relation is of type “-” or “+”. While the increase of the concentration of a certain component may imply an increase of process temperature and thus a “+” relation, the same increase involves the reduction of the concentration of another component, which in turn can be seen as the cause of the observed 6699 temperature increase and therefore suggests a “-” relation. Although one could argue that this
Although SDGs are a suitable approach to causal modeling, their capabilities for detailed process descriptions may result insufficient in some cases. Consider for instance the SDG segment illustrated in Figure 6.3} which depicts some of the causal relations occurring in a typical reactor. As it is known from first physical principles, the cooling water (CW) flow causes a suppression effect (-) on the process temperature, whereas the temperatures of the reactant feeds produce a reinforcement influence (+) on the same variable. In the event of a disturbance, the behavior of the process temperature will largely depend on whether the cooling water flow or the reactants temperatures have the stronger influence, as well as on the time constants of the underlying causalities. Suck relations, however, cannot be represented through SDGs, as these neither quantify the extent tc which a node affects its successor nor describe temporal causalities. Another limitation of SDGs is their incapability to model qualitative relationships between process variables that cannot be simply described as “suppression” or “reinforcement” effects. Take as an example the case in which the magnitude “feed composition” is modeled as a node in a SDG. One may naturally expect that the composition has a direct influence, among other variables, on the process temperature, implying thereby the existence of a direct arc in the causal graph. Nevertheless, due to the vagueness of the term “feed composition” —understanding this as the concentrations of different chemical components in the feed— it is not possible to clearly determine wether the relation is of type “-” or “+”. While the increase of the concentration of a certain component may imply an increase of process temperature and thus a “+” relation, the same increase involves the reduction of the concentration of another component, which in turn can be seen as the cause of the observed 6699 temperature increase and therefore suggests a “-” relation. Although one could argue that this
Figure 6.4: Considered propagation carriers in process systems
Figure 6.4: Considered propagation carriers in process systems
The linkage between topology information and causal process knowledge (i.e., first principles, heuristics, and static and dynamic process data) is accomplished by storing the causal relations of plant components such as heat exchangers, pumps, and reactors as templates in a knowledge repository or library (see propagation look-up table > |6.5.2.2)). When one of these components is identified during model generation, the corresponding causal relations of the asset are consulted in the library and instantiated in the DCDG. Should causal relations contain expressions or functions in terms of plant or process data (e.g., types, dimensions, or states), the algorithm retrieves this information from the topology model by exploiting fit-to-purpose data access methods, specifically AFDD PDS, PKS, and PS model facets (> 4.4.3.1 . Once all causal relations have been evaluated and instantiated, the resulting component causal models (modules) are interconnected based on the connectivity information described in the topology model. In order to illustrate the dynamic generation of the DCDG, consider the following brief example.
The linkage between topology information and causal process knowledge (i.e., first principles, heuristics, and static and dynamic process data) is accomplished by storing the causal relations of plant components such as heat exchangers, pumps, and reactors as templates in a knowledge repository or library (see propagation look-up table > |6.5.2.2)). When one of these components is identified during model generation, the corresponding causal relations of the asset are consulted in the library and instantiated in the DCDG. Should causal relations contain expressions or functions in terms of plant or process data (e.g., types, dimensions, or states), the algorithm retrieves this information from the topology model by exploiting fit-to-purpose data access methods, specifically AFDD PDS, PKS, and PS model facets (> 4.4.3.1 . Once all causal relations have been evaluated and instantiated, the resulting component causal models (modules) are interconnected based on the connectivity information described in the topology model. In order to illustrate the dynamic generation of the DCDG, consider the following brief example.
Table 6.1: General structure of a propagation look-up table (PLUT)
Table 6.1: General structure of a propagation look-up table (PLUT)
In many occasions, however, no explicit graphic symbols are used in the process schematic to depict alarm functions. Instead, these are described by additional characters in the tags of the measure- ments to which they are associated. The tag “LICA+-”, for instance, indicates a level controller with value indication (LIC) and high/low alarm functions (A+-). In these cases, the mapping is derived from the syntactical analysis of the tags —based on regular expressions— alongside the con- sideration of the connectivity between plant assets and instruments. Once the alarm functionalities have been identified, Algorithm 6.1 can be applied to generate the required mappings.
In many occasions, however, no explicit graphic symbols are used in the process schematic to depict alarm functions. Instead, these are described by additional characters in the tags of the measure- ments to which they are associated. The tag “LICA+-”, for instance, indicates a level controller with value indication (LIC) and high/low alarm functions (A+-). In these cases, the mapping is derived from the syntactical analysis of the tags —based on regular expressions— alongside the con- sideration of the connectivity between plant assets and instruments. Once the alarm functionalities have been identified, Algorithm 6.1 can be applied to generate the required mappings.
Figure 6.9: Example ACMs for an alarm log with three entries. Colors illustrate the alarms belonging to the same alarm group Once the analyzed log has been initially filtered, a search algorithm computes potential paths between every pair of alarms by considering graph connectivity and predefined stop criteria, as well as by applying penalization and filtering strategies (> [6.5.3.3] . Search results are stored in form of an alarm connectivity matrix (ACM) describing the directional causality among inspected alarms. If the algorithm finds a feasible propagation path connecting one alarm to another, this result is stored as a “1” in a specific row and column of the ACM, meaning the alarm associated with that row was found to cause the alarm associated with the respective column.
Figure 6.9: Example ACMs for an alarm log with three entries. Colors illustrate the alarms belonging to the same alarm group Once the analyzed log has been initially filtered, a search algorithm computes potential paths between every pair of alarms by considering graph connectivity and predefined stop criteria, as well as by applying penalization and filtering strategies (> [6.5.3.3] . Search results are stored in form of an alarm connectivity matrix (ACM) describing the directional causality among inspected alarms. If the algorithm finds a feasible propagation path connecting one alarm to another, this result is stored as a “1” in a specific row and column of the ACM, meaning the alarm associated with that row was found to cause the alarm associated with the respective column.
Table 6.3: Quantitative penalization of propagation paths based on deviation magnitude. Ex ample of possible deviations ranges and associated penalty factors (pl < p2 < p3 < p4 < 1)
Table 6.3: Quantitative penalization of propagation paths based on deviation magnitude. Ex ample of possible deviations ranges and associated penalty factors (pl < p2 < p3 < p4 < 1)
with time delays differing significantly —in relative terms— from those predicted by the DCDG are penalized. If the accumulated strength of potential propagation paths was already low, the time penalization may force those paths to be rejected or ranked as less likely. The number of time bins and the magnitudes of the respective penalization factors may be defined based on the statistic analysis of previous process alarms or by considering heuristic rules. The user can decide whether time penalization is to be applied or not based on the properties of the system and the particular monitoring objectives. Figure [6.10] illustrates the proposed time penalization concept. Figure 6.10: Graphical representation of the time penalization concept
with time delays differing significantly —in relative terms— from those predicted by the DCDG are penalized. If the accumulated strength of potential propagation paths was already low, the time penalization may force those paths to be rejected or ranked as less likely. The number of time bins and the magnitudes of the respective penalization factors may be defined based on the statistic analysis of previous process alarms or by considering heuristic rules. The user can decide whether time penalization is to be applied or not based on the properties of the system and the particular monitoring objectives. Figure [6.10] illustrates the proposed time penalization concept. Figure 6.10: Graphical representation of the time penalization concept
Table 6.4: Penalization strategies used during conducted experimental tests
Table 6.4: Penalization strategies used during conducted experimental tests
Table 6.5: Experimental diagnosis results. In this report successful detections (v) refer to those in which the correct alarm groups were identified and the right causal alarms diagnosed, partially successful detections (©)) make reference to those in which more than one causal alarm hypothesis was found for a given alarm group, and failure detections (X) are those in which alarms were mis-grouped or causal alarms were not detected
Table 6.5: Experimental diagnosis results. In this report successful detections (v) refer to those in which the correct alarm groups were identified and the right causal alarms diagnosed, partially successful detections (©)) make reference to those in which more than one causal alarm hypothesis was found for a given alarm group, and failure detections (X) are those in which alarms were mis-grouped or causal alarms were not detected
Figure 6.11: Summary of obtained diagnosis results Experimental results presented in Table [6.5] revealed 19 successful detections, 6 partial detections, and 5 mis-detections. As summarized in Figure 6.11] these absolute figures evidentiate that the algorithm successfully or partially successfully diagnosed 83 % of the analyzed cases, while failed at finding the causal alarm for 17 % of the fault scenarios. The causes of partial and failed detections are various: detailed accounts on these cases are presented in the next subsection.
Figure 6.11: Summary of obtained diagnosis results Experimental results presented in Table [6.5] revealed 19 successful detections, 6 partial detections, and 5 mis-detections. As summarized in Figure 6.11] these absolute figures evidentiate that the algorithm successfully or partially successfully diagnosed 83 % of the analyzed cases, while failed at finding the causal alarm for 17 % of the fault scenarios. The causes of partial and failed detections are various: detailed accounts on these cases are presented in the next subsection.
UD: User Defined
UD: User Defined
D2: Block diagram depicting the main classes, inputs, and outputs of the method
D2: Block diagram depicting the main classes, inputs, and outputs of the method
Appendix H: TEP disturbances
Appendix H: TEP disturbances
Related topics:
Process industryIndustry 4.0
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved