Nuclear power plant multi-platform function block code display method and device, equipment and medium

Abstract

The application is suitable for the field of digital control technology of nuclear power plants, and provides a nuclear power plant multi-platform function block code display method, device, equipment and medium. The method comprises the following steps: obtaining a function block definition file corresponding to a target DCS platform; performing node analysis on the function block definition file to obtain target description information of the function block; generating a universal function block object based on the target description information according to a preset universal mapping rule; and performing visual display on the universal function block object. Through the analysis and universal processing of the function block definition files of the heterogeneous DCS platforms, the unified visual display of the function blocks can be realized without the original development environment of each DCS platform, the software authorization needs to be purchased for each platform, and the development and maintenance cost of the nuclear power plant DCS project is reduced.

Description

Technical Field

[0001] This application belongs to the field of digital control technology for nuclear power plants, and in particular relates to a method, device, equipment and medium for displaying multi-platform function block codes in nuclear power plants. Background Technology

[0002] Digital distributed control systems (DCS) are widely used in process control and operation monitoring in nuclear power plants. During the implementation of DCS projects in nuclear power plants, control logic is usually organized in the form of function blocks, and multiple function blocks are combined with each other according to specific connection relationships to form a complete control strategy.

[0003] In related technologies, different DCS platforms use different function block definition formats and different development environments. Each development environment can usually only recognize and load its own function block library, which makes it impossible to load and display function blocks from other DCS platforms in the same development program. Engineers need to switch frequently between multiple development environments and pay software license fees for each development environment, resulting in high project implementation and later maintenance costs. Summary of the Invention

[0004] This application provides a method, apparatus, device, and medium for displaying multi-platform function block codes in nuclear power plants. It can solve the problem that function blocks of heterogeneous DCS platforms cannot be parsed and displayed in the same environment in the prior art, and that they need to rely on the original platform development environment for authorization, which results in high costs.

[0005] The first aspect of this application provides a method for displaying function block codes across multiple platforms in a nuclear power plant, including: Obtain the function block definition file corresponding to the target distributed control system (DCS) platform; the function block definition file is a tree structure file with a set node format, and different types of nodes in the tree structure file are configured to define different function block description information, the function block description information including the function block's attribute information, variable information and / or code information; The function block definition file is parsed to obtain the target description information of the function block. The target description information includes at least one of the attribute information, the variable information, and the code information. The node type of the function block definition file includes at least one of the root node, the interface node, and the code node. The attribute information corresponds to the root node, the variable information corresponds to the interface node, and the code information corresponds to the code node. Based on the preset generalized mapping rules, a generalized function block object is generated based on the target description information; The generalized function block object is visualized.

[0006] A second aspect of this application provides a multi-platform function block code display device for nuclear power plants, comprising: The acquisition module is used to acquire the function block definition file corresponding to the target DCS platform; the function block definition file is a tree structure file with a set node format, and different types of nodes in the tree structure file are configured to define different function block description information, the function block description information including the function block attribute information, variable information and / or code information; The parsing module is used to parse the function block definition file into nodes to obtain the target description information of the function block. The target description information includes at least one of the attribute information, the variable information, and the code information. The nodes of the function block definition file include at least one of the root node, the interface node, and the code node. The attribute information corresponds to the root node, the variable information corresponds to the interface node, and the code information corresponds to the code node. A generalization module is used to generate a generalized function block object based on the target description information according to a preset generalization mapping rule; The display module is used to visualize the generalized function block object.

[0007] A third aspect of this application provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method described in the first aspect.

[0008] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method described in the first aspect.

[0009] The fifth aspect of this application provides a computer program product including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in an electronic device, a processor in the electronic device performs the steps of the method described in the first aspect above.

[0010] The beneficial effects of the embodiments in this application compared with the prior art are: This application embodiment parses the nodes of a tree-structured function block definition file to obtain different function block description information defined in different node areas of the tree-structured file. The target description information includes at least one of attribute information, variable information, and code information. Based on a preset generalized mapping rule, this information is mapped into platform-independent generalized function block objects. This enables the unified organization of function blocks from heterogeneous DCS platforms under the same data structure, and then the visualization of generalized function block objects. This unified parsing and display of function blocks from multiple platforms is independent of the original development environment of each DCS platform, facilitating display and intuitive viewing, and significantly reducing the implementation and maintenance costs of nuclear power plant DCS projects. Attached Figure Description

[0011] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the preferred embodiments below. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a general flowchart of a method for displaying multi-platform function block codes in a nuclear power plant according to an embodiment of this application; Figure 2 This is a flowchart of the steps for visualizing and drawing FBD element information according to an embodiment of this application; Figure 3 This is a schematic diagram of the display interface in an application provided in an embodiment of this application; Figure 4 This is a schematic diagram of a logic diagram drawn according to an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a multi-platform function block code display device for nuclear power plants provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0012] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

[0013] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0014] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0015] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0016] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0017] To facilitate understanding of the technical solution of this application, the following explanations are provided for several terms used in this application: DCS: Distributed Control System. It is a control system that adopts the basic design concept of decentralized control and centralized operation and management. It adopts a multi-level, hierarchical, cooperative and autonomous structure and is widely used in the process control of the conventional island and nuclear island of nuclear power plants.

[0018] Function block: A code unit in a DCS platform used to implement a specific control function. It usually contains several input terminals, several output terminals and internal algorithms. Multiple function blocks are combined into a complete control strategy through the connection between the terminals.

[0019] POU: Program Organization Unit, a control program organization unit defined according to the IEC 61131-3 standard. Common types include functions (FUN), function blocks (FB), and programs (PROG).

[0020] ST language: Structured Text, is a high-level programming language similar to Pascal, defined by the IEC 61131-3 standard, and is suitable for writing complex algorithms.

[0021] FBD (Function Block Diagram) is a graphical programming language defined by the IEC 61131-3 standard. It represents control logic by drawing function blocks and connecting lines in a graphical interface.

[0022] In the implementation of DCS engineering in nuclear power plants, control logic is usually organized in the form of function blocks. Each function block defines several input terminals, output terminals and internal control algorithms. Multiple function blocks are combined with each other according to specific connection relationships to form a complete control strategy.

[0023] Currently, there are various DCS platform vendors both domestically and internationally, such as HOLLiAS-N and SH_N. Different DCS platform vendors typically have their own independent function block development environments and use their own custom file formats to store function block definition information. This heterogeneity brings several challenges to the implementation of nuclear power plant DCS projects: First, different DCS platforms use different function block development environments. Each development environment can usually only open and load one function block library corresponding to its own platform, and cannot load and display function blocks from other DCS platforms in the same development program. Second, the function block definition files of different platforms are not recognizable due to their inconsistent formats, and cannot be parsed and visualized on other DCS platforms; Third, each DCS platform development environment usually requires a separate software license purchase. When engineers need to view the functional blocks of multiple platforms, they need to frequently switch between multiple development environments and pay license fees for each development environment, resulting in high project implementation and subsequent maintenance costs.

[0024] Therefore, how to uniformly parse and visualize the functional blocks of heterogeneous DCS platforms without relying on the original development environments of each DCS platform has become an urgent technical problem to be solved.

[0025] To address this issue, this application embodiment parses the nodes of the function block definition file to obtain attribute information, variable information, and code information. Based on a preset generalized mapping rule, this information is mapped into platform-independent generalized function block objects, which are then visualized. This achieves the following effect: First, by parsing the function block definition file of the DCS platform by node, attribute information, variable information and code information are obtained, and they are mapped into platform-independent generalized function block objects. This allows function blocks of heterogeneous DCS platforms to be organized in the same data structure, thereby enabling unified loading and display of function blocks from multiple platforms in the same application. Second, since the generalized function block object does not depend on the development environment of any specific DCS platform, engineers do not need to install the development software of the corresponding DCS platform, nor do they need to purchase the software license of the corresponding platform to view and analyze the function block, which significantly reduces the implementation and maintenance costs of nuclear power plant DCS projects. Third, when visualizing generalized function block objects, diverse display methods can be used. For example, tree view, list view, rich text, and graphical drawing interface can be used to display different types of information. Visualization allows engineers to intuitively view the directory structure, variable definitions, ST code text, and FBD logic diagram of the function block, improving the efficiency of function block review.

[0026] To illustrate the technical solution described in this application, specific embodiments are provided below.

[0027] Combination Figure 1 As shown, in some embodiments, a method for displaying multi-platform function block codes in nuclear power plants is proposed. The execution subject of the method can be a computer device with data processing capabilities, such as a personal computer or an engineer's workstation. The method includes the following steps: Step 101: Obtain the function block definition file corresponding to the target DCS platform.

[0028] The function block definition file is a tree structure file with a defined node format. Different types of nodes in this tree structure file are configured to define different function block description information, which includes the function block's attribute information, variable information, and / or code information.

[0029] The node types in a function block definition file include at least one of the following: root node, interface node, and code node. Attribute information corresponds to the root node, variable information corresponds to the interface node, and code information corresponds to the code node.

[0030] In some embodiments of this application, the function block definition file can be a structured file conforming to XML format. This file is organized in a tree structure and includes various node types such as root nodes, interface nodes, and code nodes. Optionally, each DCS platform generates a function block definition file according to its own defined XML schema and saves the function block definition file in a specific algorithm library directory.

[0031] In one example, the function block definition file can be obtained in response to a function block library loading command. This can be achieved by determining the target algorithm library path corresponding to the command, traversing all files within that path, and identifying XML files conforming to the DCS platform function block definition file format as the function block definition file. Specifically, when the user clicks the "Open AT Algorithm Library" button in the application's menu bar and selects the folder containing the target algorithm library, the application automatically traverses all files in that folder and identifies XML files conforming to the DCS platform function block definition format as the function block definition file to be parsed.

[0032] It should be noted that the target DCS platform may include at least two different types of DCS platforms, such as the HOLLiAS-N platform and the SH_N platform. The function block definition files corresponding to different types of DCS platforms may have different configuration node formats, such as different label names for root nodes, different child node structures for interface nodes, and so on. During subsequent node parsing of the function block definition file, the parsing rules matching the DCS platform type can be invoked to parse the function block definition file, thereby achieving compatibility with multiple heterogeneous platforms.

[0033] Step 102: Perform node parsing on the function block definition file to obtain the target description information of the function block.

[0034] The target description information includes at least one of attribute information, variable information, and code information.

[0035] When implementing step 102, the process may include: parsing the root node of the function block definition file to obtain the attribute information of the function block, parsing the interface node of the function block definition file to obtain the variable information of the function block, and parsing the code node of the function block definition file to obtain the code information of the function block.

[0036] In some embodiments of this application, the root node is the outermost node of the function block definition file, recording the overall attributes of the function block. The root node of the function block definition file can be read to obtain the attribute information of the function block. Specifically, this can be achieved by reading the attribute fields of the root node or its direct child nodes. The attribute information includes the name as a unique identifier for the function block, and may also include, but is not limited to: name, alias, description, POU type, drawing size, and programming language. Name: Represents the unique name of the function block. After the name is parsed, it can be used as the unique identifier of the function block to distinguish different function blocks in subsequent storage and query processes. Alias: Represents another name for a function block, which can be used for display or retrieval; Description: A textual description of the function block's functionality; POU type: Indicates the POU type corresponding to the function block, such as FUN, FB or PROG; Drawing size: Indicates the size of the drawing canvas for the logic diagram of the function block, including width and height; Programming language: Indicates the programming language used by the function block, such as ST or FBD. The programming language determines the subsequent parsing method of the code nodes.

[0037] In some embodiments of this application, an interface node is a node in the function block definition file used to define function block terminals and internal variables. The interface node of the function block definition file can be read to obtain the variable information of the function block. Specifically, the variable information can be obtained by reading the interface node or its child nodes. The variable information may include at least one of the following types of variables: input variables, output variables, input-output variables, and local variables.

[0038] Among them, input variables represent the input terminals of the function block, and their values ​​are passed in from the outside; output variables represent the output terminals of the function block, and their values ​​are passed out to the outside; input and output variables are variables that have both input and output characteristics; local variables are temporary variables used inside the function block.

[0039] For each type of variable, variable attributes can be further obtained, including but not limited to one or more of the following: Variable name: Represents the name of the variable within the function block; Variable declaration: A textual description of the meaning of a variable; Variable type: Indicates the data type of the variable, such as BOOL, INT, REAL, etc.; Initial value: Represents the value of a variable in its initial state; Data synchronization: Indicates whether the variable needs to be synchronized across multiple controllers; Power-down retention: Indicates whether the variable needs to retain its current value after the controller loses power; Parameter alignment: Indicates whether the variable participates in parameter alignment. Whether it can be manually assigned a value: Indicates whether the variable is allowed to be manually assigned a value; Internet access status: This indicates whether the variable is publicly disclosed to the monitoring system. Display: Indicates whether the variable is displayed on the display interface.

[0040] In some embodiments of this application, the code node is a node in the function block definition file used to record the body of the control algorithm. The specific structure of the code node is closely related to the programming language. When the obtained programming language is ST, the content of the code node is usually a continuous text string; when the obtained programming language is FBD, the content of the code node is usually composed of multiple child nodes, each child node representing a graphical element.

[0041] Therefore, we can first identify the programming language type corresponding to the code node, and then adopt different parsing methods according to different programming language types.

[0042] When the programming language type is ST, the code node is read to obtain the complete ST code text, and the ST code text is used as code information.

[0043] When the programming language is FBD, the child nodes of the code nodes are parsed, and the parsing results are used as FBD element information. The FBD element information includes at least one of the following four types of element information: logical function block information, logical input information, logical output information, and descriptive information.

[0044] In one specific embodiment of this application, the logic function block information includes: the coordinate position of the logic function block, the block type, the block name, the execution sequence number, the function block input information, and the function block output information; the function block input information includes the identifier and invert identifier of the corresponding input terminal, and the function block output information includes the identifier and invert identifier of the corresponding output terminal; wherein, the block type indicates what kind of operation or function the logic function block belongs to, such as AND, OR, NOT, etc. It should be noted that some logic function blocks may not have a block name attribute.

[0045] The logical input information includes: the coordinate position of the input terminal, the variable name, and the inverting identifier, wherein the variable name is used to associate the input terminal with the input variable defined in the interface node.

[0046] The logic output information includes: the coordinate position of the output terminal, the variable name, the execution order, and the inversion flag. The execution order is used to determine the execution order of the output terminal in the overall logic.

[0047] The descriptive information includes the coordinate position of the descriptive text on the canvas and the specific content of the descriptive text.

[0048] Step 103: Generate a generalized function block object based on the target description information according to the preset generalized mapping rules.

[0049] The generalized mapping rule specifies how raw data from different DCS platforms should be standardized and transformed into a unified, generalized function block object within the system. This generalized mapping rule can contain the following five types of mapping sub-rules: The structure mapping sub-rule is used to define the correspondence between the paths of each node in the function block definition file of each target DCS platform and the attribute fields in the generalized function block object. For example, the root node name field of platform A is mapped to the unique identifier field of the generalized function block object, and the variable list of the interface node is mapped to the terminal attribute set of the generalized function block object.

[0050] Data type conversion sub-rules are used to define the conversion relationship between the data types used by each target DCS platform and the data types inside the generalized function block object, including unified mapping of data type names, normalization conversion of data formats, and standardization of default values.

[0051] Semantic standardization sub-rules are used to eliminate semantic differences caused by different naming of the same function or concept between different target DCS platforms. This includes alias mapping and standardization of identifiers such as function block names, variable names, and keywords, so that similar elements from different platforms have a unified semantic expression in a generalized function block object.

[0052] Conditional branch mapping rules are used to select the corresponding mapping branch based on the context conditions in the function block definition file. For example, when the programming language type of the identified code node is Structured Text (ST), the text extraction mapping branch is executed; when the programming language type is Function Block Graph (FBD), the graph element parsing mapping branch is executed.

[0053] The exception handling sub-rules are used to define fallback strategies for handling exceptions such as missing source data, incorrect formatting, invalid references, or data conflicts. These strategies include default value filling, boundary value correction, conflict resolution, and exception logging to ensure the integrity and stability of the mapping process.

[0054] Among them, the generalized function block object generated based on the attribute information, the variable information and the code information according to the preset generalized mapping rules is a platform-independent generalized function block object.

[0055] In the embodiments of this application, "platform independent" means that the generalized functional block object constructed by the solution in this application does not depend on the native development environment, file format or runtime library of any specific DCS platform (such as HOLLiAS-N, SH_N, etc.), and can be uniformly parsed, processed and displayed without the need for platform-specific tools.

[0056] Specifically, it can include three levels of independence: file format independence, development environment independence, and data representation independence.

[0057] The function block definition files (such as XML, binary, and proprietary formats) of different DCS platforms differ in physical structure. This application extracts semantic information (such as algorithm names, variables, and logical elements) from these files using a unified parser and converts them into standardized, generalized objects, thereby shielding the differences in underlying file formats. Secondly, the native function block editors of each platform typically require the installation of specific software and obtaining commercial licenses. The display method implemented in this application does not rely on any native integrated development environment; parsing and visualization can be completed simply by accessing the function block definition file itself, achieving independent operation without a development environment. Furthermore, the representation of function block coordinates, connections, pin inversions, etc., in native platforms may use different coordinate systems or encoding rules. This application maps these heterogeneous information into unified, generalized attributes (such as position, negate, and inputId), eliminating the need to write separate adaptation code for each platform for the upper-level drawing and display logic.

[0058] In some embodiments of this application, the generalized mapping rule is used to map function block definition information from different DCS platforms to a unified data structure. Through this mapping, function block definition information from different DCS platforms can be reduced to the same object model, thereby eliminating differences between platforms.

[0059] In one example, the generalized function block object can be composed of the following types of objects: generalized input objects, generalized output objects, and generalized logic block objects.

[0060] A generalized input object is used to represent the input terminals of a function block. Its attributes include identifier, coordinates, variable name, variable description, invert identifier, terminal type, and initial value identifier. The generalized output object is used to represent the output terminal of a function block. Its attributes include identifier, coordinates, variable name, variable description, associated input identifier, associated input index, invert identifier, terminal type, and execution sequence number. A generalized logic block object is used to represent the logic operation block inside a function block. Its attributes include identifier, coordinates, block type, text description, execution sequence number, set of input sub-items, and set of output sub-items. Each input sub-item in the set of input sub-items includes an associated input identifier, an associated input index, a negation identifier, and a pin name. Each output sub-item in the set of output sub-items includes a negation identifier and a pin name.

[0061] When generating a generic function block object, the mapping can be performed as follows: map attribute information to the object identifier and object attributes of the generic function block object; map variable information to the terminal attribute set of the generic function block object; map code information to the code attribute set of the generic function block object; and finally, construct a platform-independent generic function block object based on the above parts.

[0062] To facilitate understanding by those skilled in the art, the process of generalized mapping is illustrated below with a specific example. Suppose that a DCS platform's function block definition file contains a logic function block node representing an AND gate operation, with the following content: <element type="box"> <id> 1700< / id> <AT_position> 21.3< / AT_position><AT_type> AND< / AT_type> <typetext> BT_OPERATOR< / typetext> <AT_isen> false< / AT_isen><AT_iseno> false< / AT_iseno> <sortid> 3< / sortid> <input inputid="2036" inputidx="0" negate="false" visible="true" pinname=""> <input inputid="1974" inputidx="0" negate="true" visible="true" pinname=""> <output negate="false" visible="true" pinname="">< / output> < / element> After generalization mapping, the resulting generalized logical block object `box` can be represented as: `box.id=1700; box.position=(21,3); box.type=AND; box.text=""; box.sortid=3; box.inputs.add(inputid=2036,inputidx=0,negate=0,pinname=""); box.inputs.add(inputid=1974,inputidx=0,negate=1,pinname=""); box.outputs.add(negate=0,pinname="")`.

[0063] Similarly, for a node representing an input terminal in the function block definition file of a certain DCS platform: <element type="input"> <id> 1974< / id> <AT_position>19,7< / AT_position> <text> CP< / text> <comment> Stop status feedback< / comment> <negate> false< / negate> <ttype> 4< / ttype> <flag> FALSE< / flag> < / element> After generalization mapping, the resulting generalized input object can be represented as: input.id=1974; input.position=(19,7); input.text="CP"; input.comment="Stop status feedback"; input.negate=0; input.ttype=4; input.flag=0.

[0064] For a node representing an output terminal in the function block definition file of a certain DCS platform: <element type="output"> <id> 1701< / id> <position> 27,4< / position> <text> DRN.RP< / text> <comment> Equipment operating status< / comment> <ttype> 4< / ttype> <inputid> 1700< / inputid> <inputidx> 0< / inputidx> <negate> false< / negate> <sortid> 4< / sortid> < / element> After generalization mapping, the resulting generalized output object can be represented as: output.id=1701; output.position=(27,4); output.text="DRN.RP"; output.comment="Device running status"; output.inputId=1700; output.inputIdx=0; output.negate=0; output.ttype=4; output.sortid=4.

[0065] It should be noted that while the tag names, attribute names, and hierarchical structures in the original XML nodes may differ across different DCS platforms, after processing with the generalized mapping rules, the final generated generalized object will have a unified set of fields and their meanings. This ensures that downstream visualization modules only need to deal with a unified object model, without needing to concern themselves with the specific differences between the original DCS platforms.

[0066] Step 104: Visualize the generalized function block object.

[0067] In some embodiments of this application, the visualization display may include three forms: directory display, variable display, and code display.

[0068] The directory display uses a tree view control to list multiple generic function block objects in a directory structure. Specifically, the object identifier (i.e., the function block name) of the generic function block object can be used as the label of the tree node, and the directory structure of the folder can be used as the parent-child relationship of the tree node. All the parsed function blocks are organized in a tree structure and presented in the left panel of the application.

[0069] Variable Display: In response to the selection of a target generic function block object (e.g., double-clicking a function block name in a tree view), a list view control is used to display the variable information corresponding to that target generic function block object. Specifically, the variable name, variable type, initial value, variable description, and other attributes of each variable can be used as column fields of the list view, and all variables are listed and displayed row by row in the right panel of the application.

[0070] Code display: Processing is done according to the programming language type corresponding to the target generalized function block object. When the programming language type is ST, a rich text control is used to display the ST code text of the target generalized function block object, and different keywords can be highlighted with different colors for easy reading; when the programming language type is FBD, a graphical drawing interface is used to draw and display the FBD element information of the target generalized function block object, resulting in a logic diagram equivalent to that in the original development environment.

[0071] The following is an exemplary description of the process of drawing an FBD logic diagram using a graphical drawing interface, with reference to specific embodiments.

[0072] like Figure 2 As shown, the step of drawing and displaying the FBD element information of the target function block using a graphical drawing interface may specifically include the following steps: Step 201: Traverse each element in the FBD element information.

[0073] In some embodiments of this application, the FBD element information includes four types of elements: logical input, logical output, logical function block, and description. Each type of element is stored in the form of a generic object. During drawing, each element is retrieved sequentially and its type is determined. Different drawing methods are used according to different element types.

[0074] Step 202: Draw the elements according to their respective element types, and overlay the invert symbol on the corresponding pin position for elements with invert indicators.

[0075] Element types include logical input elements, logical output elements, and logical function block elements. Optionally, a description element may also be included.

[0076] In some embodiments of this application, different types of elements can be drawn in the following ways: For logical input elements, draw the geometry of the input terminal (e.g., a rectangle or a directional arrow) on the canvas according to its coordinate position, and label the variable name and variable description next to the terminal; For logical output elements, draw the geometry of the output terminals on the canvas according to their coordinate positions, and label the variable name, variable description and execution sequence number next to the terminals; For a logic function block element, draw the outer frame of the function block (e.g., a rectangle with rounded corners) on the canvas according to its coordinate position and block type, and mark its block type (e.g., AND, OR, etc.) inside the outer frame. Draw the corresponding number of input pins on both sides of the outer frame according to the number of input sub-items, and draw the output pins on the other side of the outer frame. For a description element, draw the description content as text on the canvas based on its coordinate position.

[0077] In addition, for each element's invert flag (including the invert flag in the input sub-item of the logic function block, the invert flag in the output sub-item of the logic function block, the invert flag of the logic input element, and the invert flag of the logic output element), if the invert flag is true, a small circle symbol indicating inversion can be drawn superimposed on the corresponding terminal or pin position.

[0078] Step 203: For each logical function block element and logical output element, determine the first coordinate position of its associated logical input element, and draw a line with the first coordinate position as the starting point and the second coordinate position of the current logical function block element or logical output element as the ending point to form a logic diagram and display it.

[0079] During implementation, for each logical function block and logical output, the coordinate position of the corresponding logical input element can be queried based on the associated input identifier and associated input index carried in its input sub-item.

[0080] In some embodiments of this application, each logical function block object contains several input sub-items, and each input sub-item records an associated input identifier (inputid) and an associated input index (inputidx). The associated input identifier uniquely points to its predecessor element, which can be a logical input element or a logical function block element; the associated input index is used to specify the index of its output pin when the predecessor element is a logical function block.

[0081] When drawing connections, for each input sub-item of each logic function block, the corresponding predecessor element is retrieved from all elements based on its associated input identifier, and the connection start point is determined according to the element type of the predecessor element: if the predecessor element is a logic input element, the connection start point is the terminal position of the logic input element; if the predecessor element is a logic function block element, the connection start point is the position of the inputidx-th output pin of the logic function block element.

[0082] Similarly, for each logical output element, the coordinates of the corresponding predecessor element are queried based on its associated input identifier and associated input index to determine the starting point of the connection.

[0083] In some embodiments of this application, the endpoint of the connection is the corresponding input pin position of the current logic function block or the terminal position of the current logic output. Based on the start and end points of the connection, a straight line segment or a connection line with bends can be drawn using a graphics drawing interface to represent the signal flow between the previous element and the current element.

[0084] It should be noted that, in order to obtain a clear and well-organized logic diagram in the display interface, the coordinate position of any element in the FBD element information can be scaled and transformed according to a preset scaling factor to obtain the actual drawing coordinates of the element in the display canvas. Based on the element type and the actual drawing coordinates, the outer frame size and pin positions of the element are determined, with the pin positions arranged according to a preset pin spacing constant. For example, the vertical spacing between two input pins of a logic function block can be uniformly controlled according to the pin spacing constant to avoid pin misalignment between different elements. Finally, the corresponding element is drawn at the actual drawing coordinates according to the outer frame size and pin positions.

[0085] The implementation process of multi-platform support will be illustrated below with specific embodiments.

[0086] In one possible embodiment of this application, the target DCS platform includes at least two different types of DCS platforms, such as the HOLLiAS-N platform and the SH_N platform. The function block definition files of these two types of platforms use their own different XML formats; for example, the root node tag names are different, the input and output variable tag names in the interface nodes are different, the tag names representing logical function blocks in the code nodes are different, and so on.

[0087] To ensure compatibility across multiple platforms, a set of parsing rules can be pre-configured for each type of DCS platform within the application. These rules define how to extract attribute, variable, and code information from the platform's XML format. After obtaining the function block definition file, the DCS platform type to which the file belongs is first identified (e.g., by the root node's tag name, file extension, or folder path). Then, the corresponding parsing rules are invoked to parse the nodes. Finally, the parsed information is mapped to generic function block objects according to a unified, generalized mapping rule.

[0088] Based on this, regardless of the DCS platform from which the original function block file originates, the function block objects ultimately loaded into the application all have a unified data structure and can be displayed and compared simultaneously within the same application. For example, engineers can browse function blocks from both the HOLLiAS-N and SH_N platforms within the same directory tree, facilitating cross-platform logical comparisons.

[0089] Combination Figure 3As shown, in a specific use case of this application, the engineer clicks the "Open AT Algorithm Library" button in the application's menu bar and selects the algorithm folder corresponding to a certain DCS platform. The application automatically traverses the function block definition files in this folder, and executes steps 102 to 105 sequentially for each function block definition file to obtain the corresponding generalized function block object. All generalized function block objects are organized in a tree view control according to the directory structure and presented in the left panel of the application. When the engineer double-clicks a function block name in the tree view control, the application displays the variable information of the function block in the list view control of the right panel; when the function block is written in ST language, its ST code text is displayed in the rich text control on the right; when the function block is written in FBD language, the complete FBD logic diagram is drawn in the canvas on the right.

[0090] Taking a simple function block with 2 inputs, 1 output, and 1 AND operation as an example: During the parsing phase, combined with... Figure 4 As shown, following the aforementioned steps, an AND-type logic function block object, two logic input objects (CP and RP), and a logic output object (DRN.RP) are obtained through parsing. In the generalization stage, the parsed objects are mapped into a generalized logic block object, a generalized input object, and a generalized output object according to the generalization mapping rules. In the visualization stage, two input terminals CP and RP, an AND function block, and an output terminal DRN.RP are drawn on the canvas, and an inversion symbol is drawn at the connection point between the CP terminal and the AND function block according to the inversion symbol of the input terminal CP, thereby fully presenting the logic structure of the original function block.

[0091] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0092] In the above embodiments of this application, the various embodiments and implementation methods can be combined with each other, and there is no obstacle to their combination due to the separate description of the embodiments and implementation methods. The implementation processes of the various embodiments and implementation methods can be referred to each other, and features can be integrated to form an overall solution that includes the technical features of the various embodiments or implementation methods.

[0093] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0094] This embodiment can divide the computing side into functional modules based on the above method and the same inventive concept. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The specific limitations of the divided functional modules can be found in the limitations of the method above, and will not be repeated here to avoid repetition.

[0095] The following description, in conjunction with specific embodiments, provides an exemplary description of the nuclear power plant multi-platform function block code display device provided in this application.

[0096] like Figure 5 As shown, an embodiment of this application provides a multi-platform function block code display device for nuclear power plants. The multi-platform function block code display device 500 for nuclear power plants includes: The acquisition module 501 is used to acquire the function block definition file corresponding to the target DCS platform; the function block definition file is a tree structure file with a set node format, and different types of nodes in the tree structure file are configured to define different function block description information, the function block description information including the function block attribute information, variable information and / or code information; The parsing module 502 is used to parse the function block definition file into nodes to obtain the target description information of the function block. The target description information includes at least one of the attribute information, the variable information, and the code information. The node type of the function block definition file includes at least one of the root node, the interface node, and the code node. The attribute information corresponds to the root node, the variable information corresponds to the interface node, and the code information corresponds to the code node. The generalization module 503 is used to generate a generalized function block object based on the target description information according to a preset generalization mapping rule; Display module 504 is used to visualize the generalized function block object.

[0097] Optionally, the parsing module 502 is specifically used to: read the root node of the function block definition file to obtain the attribute information of the function block, the attribute information including the name as the unique identifier of the function block, and at least one of the following: alias, description, program organization unit (POU) type, drawing size, and programming language.

[0098] Optionally, the parsing module 502 is specifically used to: read the interface node of the function block definition file to obtain at least one type of variable among the input variables, output variables, input-output variables and local variables of the function block; and obtain variable attributes for each type of variable, wherein the variable attributes include at least one of the following: variable name, variable description, variable type, initial value, data synchronization, power failure retention, parameter alignment, whether it can be forced, whether it is connected to the Internet and whether it is displayed.

[0099] Optionally, the parsing module 502 includes: an identification unit for identifying the programming language type corresponding to the code node; an ST parsing unit for reading the text of the code node to obtain ST code text as the code information when the programming language type is ST language; and an FBD parsing unit for parsing the child nodes of the code node to obtain FBD element information as the code information when the programming language type is FBD language, wherein the FBD element information includes at least one of logical function block information, logical input information, logical output information, and descriptive information.

[0100] Optionally, the logic function block information includes: the coordinate position of the logic function block, block type, block name, execution sequence number, function block input information and function block output information, wherein the function block input information includes the identifier and invert identifier of the corresponding input terminal, and the function block output information includes the identifier and invert identifier of the corresponding output terminal; The logical input information includes: the coordinate position of the input terminal, the variable name, and the inverting identifier; The logical output information includes: the coordinate position of the output terminal, the variable name, the execution order, and the inverting flag.

[0101] Optionally, the generalization module 503 is specifically used to map the attribute information to the object identifier and object attributes of the generalized function block object according to a preset generalization mapping rule; to map the variable information to the terminal attribute set of the generalized function block object according to the generalization mapping rule; to map the code information to the code attribute set of the generalized function block object according to the generalization mapping rule; and to construct the generalized function block object based on the object identifier, the object attributes, the terminal attribute set, and the code attribute set.

[0102] Optionally, the generalized function block object includes a generalized input object, a generalized output object, and a generalized logic block object; wherein: The generalized input object includes identifier, coordinates, variable name, variable description, invert identifier, terminal type, and initial value identifier; The generalized output object includes an identifier, coordinates, variable name, variable description, associated input identifier, associated input index, invert identifier, terminal type, and execution sequence number; The generalized logic block object includes an identifier, coordinates, block type, text description, execution sequence number, input sub-item set, and output sub-item set. Each input sub-item in the input sub-item set includes an associated input identifier, an associated input index, a negation identifier, and a pin name. Each output sub-item in the output sub-item set includes a negation identifier and a pin name.

[0103] Optionally, the display module 504 includes: a directory display unit, used to list multiple generalized function block objects in a directory structure using a tree view control; a variable display unit, used to display variable information corresponding to the target generalized function block object using a list view control in response to a selection operation on the target generalized function block object; an ST display unit, used to display the ST code text of the target generalized function block object using a rich text control when the programming language type of the target generalized function block object is ST language; and an FBD drawing unit, used to draw and display the FBD element information of the target generalized function block object using a graphics drawing interface when the programming language type of the target generalized function block object is FBD language.

[0104] Optionally, the FBD drawing unit is specifically used to traverse each element in the FBD element information, draw elements according to the element type corresponding to each element, the element type including logical input elements, logical output elements, and logical function block elements; for elements with inverted symbols, inverted symbols are superimposed on the corresponding pin positions; for each logical function block element and logical output element, the first coordinate position of its associated logical input element is determined, and a line is drawn with the first coordinate position as the starting point and the second coordinate position of the current logical function block element or logical output element as the ending point to form a logic diagram and display it.

[0105] Optionally, the FBD drawing unit is more specifically configured to, for any one of the elements, scale and transform the coordinate position of the element in combination with a preset scaling factor to obtain the actual drawing coordinates of the element in the display canvas; determine the outer frame size and pin position of the element according to the element type and the actual drawing coordinates, wherein the pin positions are arranged according to a preset pin spacing constant; and draw the corresponding element at the actual drawing coordinates according to the outer frame size and the pin position.

[0106] Optionally, the acquisition module 501 is used to, in response to the function block library loading instruction, determine the target algorithm library path corresponding to the function block library loading instruction; traverse all files under the target algorithm library path, and use the XML file that conforms to the DCS platform function block definition file format as the function block definition file; wherein, the target DCS platform includes at least two different types of DCS platforms, and the function block definition files corresponding to different types of DCS platforms have different set node formats; Accordingly, the parsing module 502 is specifically used for: Based on the DCS platform type corresponding to the function block definition file, the parsing rules that match the DCS platform type are invoked to parse the nodes of the function block definition file.

[0107] It should be noted that the information interaction and execution process between the above-mentioned devices / modules / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0108] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0109] In one embodiment, such as Figure 6 As shown, a computer device is provided. The computer device 6 of this embodiment includes: at least one processor 600 (… Figure 6(Only one is shown in the diagram), memory 601, and computer program 602 stored in said memory 601 and executable on said at least one processor 600, wherein the processor 600 executes said computer program 602 to implement the steps in any of the above method embodiments.

[0110] The computer device 6 may be a personal computer, laptop, handheld computer, or other computing device. The computer device 6 may include, but is not limited to, a processor 600 and a memory 601. Those skilled in the art will understand that... Figure 6 This is merely an example of computer device 6 and does not constitute a limitation on computer device 6. It may include more or fewer components than shown, or combine certain components, or different components. For example, the computer device may also include input / output devices, network access devices, buses, etc.

[0111] The processor 600 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0112] The memory 601 can be an internal storage unit of the computer device 6, such as a hard disk or memory of the computer device 6. The memory 601 can also be an external storage device of the computer device 6, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card equipped on the computer device 6. Furthermore, the memory 601 can include both internal and external storage units of the computer device 6. The memory 601 is used to store the computer program and other programs and data required by the computer device. The memory 601 can also be used to temporarily store data that has been output or will be output.

[0113] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0114] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0115] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0116] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer devices and methods can be implemented in other ways. For example, the apparatus / computer device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0117] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0118] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0119] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0120] The methods described in this application can be implemented in whole or in part by a computer program product. When the computer program product is run on a computer device, the computer device executes the steps in the various method embodiments described above.

[0121] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for displaying multi-platform function block codes in a nuclear power plant, characterized in that, include: Obtain the function block definition file corresponding to the target distributed control system (DCS) platform; The function block definition file is a tree structure file with a set node format. Different types of nodes in the tree structure file are configured to define different function block description information. The function block description information includes the function block's attribute information, variable information, and / or code information. The function block definition file is parsed to obtain the target description information of the function block. The target description information includes at least one of the attribute information, the variable information, and the code information. The node type of the function block definition file includes at least one of the root node, the interface node, and the code node. The attribute information corresponds to the root node, the variable information corresponds to the interface node, and the code information corresponds to the code node. Based on the preset generalized mapping rules, a generalized function block object is generated based on the target description information; The generalized function block object is visualized.

2. The method according to claim 1, characterized in that, The step of parsing the function block definition file to obtain the target description information of the function block includes: Read the root node of the function block definition file to obtain the attribute information of the function block. The attribute information includes the name that serves as the unique identifier of the function block, and at least one of the following: alias, description, program organization unit (POU) type, drawing size, and programming language.

3. The method according to claim 1, characterized in that, The step of parsing the function block definition file to obtain the target description information of the function block includes: Read the interface node of the function block definition file to obtain at least one type of variable among the function block's input variables, output variables, input-output variables, and local variables; For each type of variable, obtain the variable attributes, which include at least one of the following: variable name, variable description, variable type, initial value, data synchronization, power failure retention, parameter alignment, whether it can be forced, whether it is connected to the Internet, and whether it is displayed.

4. The method according to claim 1, characterized in that, The step of parsing the function block definition file to obtain the target description information of the function block includes: Identify the programming language type corresponding to the code node; When the programming language type is Structured Text (ST) language, the code node is read to obtain the ST code text as the code information; When the programming language type is Function Block Graph (FBD) language, the child nodes of the code node are parsed to obtain FBD element information as the code information. The FBD element information includes at least one of logical function block information, logical input information, logical output information, and description information.

5. The method according to claim 4, characterized in that, The logic function block information includes: the coordinate position of the logic function block, block type, block name, execution sequence number, function block input information, and function block output information, wherein the function block input information includes the identifier and invert identifier of the corresponding input terminal, and the function block output information includes the identifier and invert identifier of the corresponding output terminal; The logical input information includes: the coordinate position of the input terminal, the variable name, and the inverting identifier; The logical output information includes: the coordinate position of the output terminal, the variable name, the execution order, and the inverting flag.

6. The method according to claim 1, characterized in that, The step of generating a generalized function block object based on the target description information according to a preset generalized mapping rule includes: According to the preset generalized mapping rules, the attribute information is mapped to the object identifier and object attributes of the generalized function block object; According to the generalized mapping rule, the variable information is mapped to the terminal attribute set of the generalized function block object; According to the generalized mapping rules, the code information is mapped to the code attribute set of the generalized function block object; The generalized function block object is constructed based on the object identifier, the object attributes, the terminal attribute set, and the code attribute set.

7. The method according to claim 6, characterized in that, The generalized function block object includes a generalized input object, a generalized output object, and a generalized logic block object; wherein: The generalized input object includes identifier, coordinates, variable name, variable description, invert identifier, terminal type, and initial value identifier; The generalized output object includes an identifier, coordinates, variable name, variable description, associated input identifier, associated input index, invert identifier, terminal type, and execution sequence number; The generalized logic block object includes an identifier, coordinates, block type, text description, execution sequence number, input sub-item set, and output sub-item set. Each input sub-item in the input sub-item set includes an associated input identifier, an associated input index, a negation identifier, and a pin name. Each output sub-item in the output sub-item set includes a negation identifier and a pin name.

8. The method according to claim 1, characterized in that, The visualization of the generalized function block object includes: A tree view control is used to list multiple generalized function block objects in a directory structure; In response to the selection operation of the target generalized function block object, a list view control is used to display the variable information corresponding to the target generalized function block object; When the programming language type of the target generalized function block object is ST language, the ST code text of the target generalized function block object is displayed using a rich text control; When the programming language type of the target generalized function block object is FBD language, the FBD element information of the target generalized function block object is drawn and displayed using a graphical drawing interface.

9. The method according to claim 8, characterized in that, The step of drawing and displaying the FBD element information of the target generalized function block object using a graphical drawing interface includes: The elements in the FBD element information are traversed, and the elements are drawn according to the element type corresponding to each element. The element type includes logical input elements, logical output elements, and logical function block elements. For elements with an inverted flag, an inverted symbol is overlaid at the corresponding pin position; For each logical function block element and logical output element, determine the first coordinate position of its associated logical input element, and draw a line with the first coordinate position as the starting point and the second coordinate position of the current logical function block element or logical output element as the ending point to form a logic diagram and display it.

10. The method according to claim 9, characterized in that, The step of traversing each element in the FBD element information and drawing the elements according to their corresponding element types includes: For any of the elements, the coordinate position of the element is scaled and transformed by a preset scaling factor to obtain the actual drawing coordinates of the element in the display canvas. Based on the element type and the actual drawing coordinates, the outer frame size and pin positions of the element are determined, wherein the pin positions are arranged according to a preset pin spacing constant. Draw the corresponding elements at the actual drawing coordinates according to the outer frame size and the pin position.

11. The method according to claim 1, characterized in that, Obtain the function block definition file corresponding to the target DCS platform, including: In response to a function block library loading instruction, determine the target algorithm library path corresponding to the function block library loading instruction; Traverse all files under the target algorithm library path and use the XML file that conforms to the DCS platform function block definition file format as the function block definition file; The target DCS platform includes at least two different types of DCS platforms, and the function block definition files corresponding to the different types of DCS platforms have different setting node formats. The node parsing of the function block definition file includes: Based on the DCS platform type corresponding to the function block definition file, the parsing rules that match the DCS platform type are invoked to parse the nodes of the function block definition file.

12. A multi-platform function block code display device for nuclear power plants, characterized in that, include: The acquisition module is used to acquire the function block definition file corresponding to the target DCS platform; The function block definition file is a tree structure file with a set node format. Different types of nodes in the tree structure file are configured to define different function block description information. The function block description information includes the function block's attribute information, variable information, and / or code information. The parsing module is used to parse the function block definition file into nodes to obtain the target description information of the function block. The target description information includes at least one of the attribute information, the variable information, and the code information. The node type of the function block definition file includes at least one of the root node, the interface node, and the code node. The attribute information corresponds to the root node, the variable information corresponds to the interface node, and the code information corresponds to the code node. A generalization module is used to generate a generalized function block object based on the target description information according to a preset generalization mapping rule; The display module is used to visualize the generalized function block object.

13. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the nuclear power plant multi-platform function block code display method as described in any one of claims 1 to 11.

14. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the nuclear power plant multi-platform function block code display method as described in any one of claims 1 to 11.

Images