A printing method, device and system in a nuclear power plant DCS system

Abstract

A printing method, apparatus, and system for a nuclear power plant DCS system, wherein the DCS system comprises multiple functional screens, and the method is applied to a printing device decoupled from the multiple functional screens; wherein: in response to a print command triggered by any functional screen, the data to be printed is obtained from the historical records of the functional screen; the data to be printed is structured to generate intermediate data, and the nuclear power plant operating status flags carried by each record in the data to be printed are identified; corresponding data feature tags are automatically generated based on the identified nuclear power plant operating status flags, and the data feature tags are associated with the corresponding records and injected into the intermediate data; based on the data feature tags in the intermediate data, different differentiated display rules are assigned to different tags to generate an intermediate file carrying display style information; the intermediate file is used to respond to print commands, eliminating code redundancy in the functional screens, reducing the maintenance cost of printing operations, and ensuring the identifiability of key status data in the printed document.

Description

Technical Field

[0001] This article relates to data processing technology, and in particular to a printing method, apparatus and system in a nuclear power plant DCS system. Background Technology

[0002] Nuclear power plant DCS systems are equipped with numerous human-machine interfaces (HMIs) for operators to monitor and control the unit's operating status. These HMIs include multiple functional screens with independent business operations, including but not limited to: a full log screen (for viewing system operation logs), an alarm list screen (for real-time display and querying of alarm information, such as categorized alarm tables, instrumentation alarm tables, idle alarm tables, test alarm tables, limit alarms, comparison alarms, etc.), a numerical trend screen (for displaying parameter change curves), a notepad screen (for recording operational events), and list screens (mandatory tables, basic system lists, analog quantity lists, switch lists, etc.). Each functional screen typically has the ability to print the currently displayed data into a paper document to meet the nuclear safety requirements for daily recording, archiving, and accident tracing.

[0003] In traditional nuclear power DCS systems, the printing functions of each of the aforementioned functional screens are implemented independently. Specifically, the code for each functional screen includes both data query and processing logic, as well as code directly related to print output, such as print style layout, pagination calculation, and printer driver calls.

[0004] Because each functional screen has its own printing design specifications, the entire printing process must be implemented from scratch for each screen. When there are dozens of functional screens in the system, the large amount of repetitive printing code makes the system bloated and difficult to maintain. When adding a new functional screen, developers must redevelop the entire printing logic, resulting in low development efficiency.

[0005] Therefore, it is urgent to systematically optimize the printing function of the nuclear power DCS system to solve the long-standing problem of code redundancy. Summary of the Invention

[0006] This application provides a printing method, apparatus, and system in a nuclear power plant DCS system.

[0007] A printing method in a nuclear power plant DCS system, wherein the DCS system includes multiple functional screens, and the method is applied to a printing device decoupled from the multiple functional screens; wherein: In response to a print command triggered by any function screen, the system obtains the data to be printed from the records in the function screen; it performs structured processing on the data to be printed to generate intermediate data, identifies the nuclear power plant operation status flag carried by each record in the data to be printed, automatically generates corresponding data feature tags based on the identified nuclear power plant operation status flags, and associates the data feature tags with the corresponding records and injects them into the intermediate data. Based on the data feature tags in the intermediate data, different differentiated display rules are assigned to different tags to generate an intermediate file carrying display style information. The differentiated display rules enable records with different nuclear power plant operating status flags to be distinguished in the printed document in the printing environment. The intermediate file is used to respond to the print command.

[0008] A printing device in a nuclear power plant DCS system, wherein a computer program is stored in a memory, and a processor is configured to run the computer program to perform the method described above.

[0009] A nuclear power plant DCS system includes: The human-computer interaction device has multiple function screens, each of which is configured to send a print command. The printing device described above.

[0010] This application's embodiments centralize data acquisition and status recognition into a unified print processor and generate standardized data feature tags for each record. This eliminates the redundancy of repeatedly writing data query and status judgment code for each functional screen in traditional solutions. When adding a new functional screen, only the print processor interface needs to be called to pass the query conditions; no printing-related code needs to be developed, significantly shortening the development cycle. Furthermore, based on the differentiated display rules assigned by tags, complete decoupling of print style and business code is achieved. When modifying the print format, only the style information needs to be adjusted, without modifying the source code of any functional screen, avoiding the workload and error risks of modifying each screen individually. In addition, based on the differentiated display rules and the method of distinguishing display effects in the printing environment, records in different operating states can be quickly distinguished, solving the problem of difficult-to-identify key data in traditional printing and greatly improving the efficiency of accident tracing.

[0011] Furthermore, because it can independently acquire the data to be printed and generate structured intermediate files, and complete the intermediate file generation and print command response in the background, the entire process does not occupy the main thread resources of the DCS system HMI screen, nor does it interfere with the real-time data refresh and display logic of the HMI screen. Even if the data to be printed contains multiple pages, after the operator performs the print operation, the HMI screen can still continuously and without delay display the latest collected nuclear power plant operation data (such as alarm updates, parameter changes, etc.), ensuring that the operator's monitoring of the current system status is not affected by any printing task, and avoiding the risk of human-machine interaction lag or omission of key information due to batch printing.

[0012] Other features and advantages of this application will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the application. Other advantages of this application can be realized and obtained by means of the embodiments described in the description and the accompanying drawings. Attached Figure Description

[0013] The accompanying drawings are used to provide an understanding of the technical solutions of this application and constitute a part of the specification. They are used together with the embodiments of this application to explain the technical solutions of this application and do not constitute a limitation on the technical solutions of this application.

[0014] Figure 1 A flowchart illustrating a printing method in a nuclear power plant DCS system provided in this application embodiment; Figure 2 This is a schematic diagram of the structure of a nuclear power plant DCS system provided in an embodiment of this application. Detailed Implementation

[0015] This application describes several embodiments, but these descriptions are exemplary and not limiting, and it will be apparent to those skilled in the art that many more embodiments and implementations are possible within the scope of the embodiments described herein. Although many possible combinations of features are shown in the drawings and discussed in the detailed description, many other combinations of the disclosed features are also possible. Unless specifically limited, any feature or element of any embodiment may be used in combination with, or may replace, any feature or element of any other embodiment.

[0016] This application includes and contemplates combinations of features and elements known to those skilled in the art. The embodiments, features, and elements disclosed in this application can also be combined with any conventional features or elements to form unique inventive solutions. Any feature or element of any embodiment can also be combined with features or elements from other inventive solutions to form another unique inventive solution. Therefore, it should be understood that any feature shown and / or discussed in this application can be implemented individually or in any suitable combination. Therefore, the embodiments are not limited except by the limitations imposed by the appended claims and their equivalents. Furthermore, various modifications and changes can be made within the scope of the appended claims.

[0017] Furthermore, in describing representative embodiments, the specification may have presented methods and / or processes as a specific sequence of steps. However, the method or process should not be limited to the specific order of steps described herein, to the extent that it does not depend on such a specific order. As will be understood by those skilled in the art, other sequences of steps are also possible. Therefore, the specific order of steps set forth in the specification should not be construed as a limitation of the claims. Moreover, the claims concerning the method and / or process should not be limited to the steps performed in the written order, and those skilled in the art will readily understand that these orders can be varied and still remain within the spirit and scope of the embodiments of this application.

[0018] To address the problems with the printing function of traditional nuclear power DCS systems, this application embodiment provides a printing device that is decoupled from and independent of each function screen. The reason and purpose of providing this printing device are: First, it eliminates code redundancy and reduces maintenance costs. In traditional solutions, each functional screen needs to independently implement complete printing logic, resulting in a large amount of repetitive code. By setting up a unified printing device, the printing function is separated from each functional screen, and all functional screens share the same printing processing flow, eliminating the need to repeatedly write printing code in each screen. This fundamentally solves the code redundancy problem, significantly reduces the total amount of code in the system, and lowers the difficulty of maintenance.

[0019] Secondly, it decouples printing logic from business logic. In traditional solutions, code for data querying, style layout, pagination calculation, and driver calls are mixed together in the same functional screen, hindering each other. This invention sets up an independent printing device, allowing the functional screen to focus only on querying and displaying business data, while all printing-related processing (including data formatting, style application, pagination, and output) is handled by the printing device. In this way, the business code in the functional screen is no longer affected by changes in printing logic, and modifications to the printing device will not affect the functional screen.

[0020] Third, it supports the rapid development of new feature screens. When a new feature screen needs to be added, developers do not need to redevelop the printing function. They only need to pass the query conditions and printing parameters according to the interface agreed upon by the printing device to automatically obtain the complete printing capabilities. This greatly shortens the development cycle of new feature screens and improves the scalability of the system.

[0021] Fourth, it enables centralized management and unified modification of print styles. In traditional solutions, modifying the print format requires modifying the code of each functional screen individually. This invention centrally manages print styles through the printing device, with all functional screens sharing the same set of style rules. When adjustments are needed to fonts, margins, paper sizes, or other formats, only a single modification is required within the printing device, and the print output of all functional screens is automatically updated synchronously, avoiding the workload and error risks associated with individual modifications.

[0022] In summary, the embodiments of this application aim to solve the technical problems of redundant printing function code, difficult maintenance, and poor scalability in traditional nuclear power DCS systems by setting up a printing device that is decoupled from and independent of the functional screen, in a unified and reusable manner.

[0023] Furthermore, the printing device operates independently of the main thread of the HMI screen in the DCS system, where the main thread is used at least to refresh and display data on the HMI screen.

[0024] Because this printing device can independently acquire the data to be printed and generate a structured intermediate file, and complete the intermediate file generation and print command response in the background, the entire process does not occupy the main thread resources of the DCS system HMI screen, nor does it interfere with the real-time data refresh and display logic of the HMI screen. Even if the data to be printed contains multiple pages, after the operator performs the print operation, the HMI screen can still continuously and without delay display the latest collected nuclear power plant operation data (such as alarm updates, parameter changes, etc.), ensuring that the operator's monitoring of the current system status is not affected by any printing task, and avoiding the risk of human-machine interaction lag or omission of key information due to batch printing.

[0025] In practical applications, each record in the data to be printed from a nuclear power plant's DCS system typically carries an operating status flag (such as equipment invalidation flag, forced output flag, test mode flag, isolation flag, alarm level value, etc.). In traditional printing methods, these status information lacks effective visual differentiation during printing, especially in black and white printing environments, where data of different statuses are almost indistinguishable on the paper. Operators or accident investigators must manually read each line of text to identify key information, resulting in low efficiency and a high risk of omissions in accident tracing.

[0026] In view of this, this embodiment provides a printing method in a nuclear power plant DCS system, which aims to eliminate code redundancy, decouple printing style from business logic, and automatically highlight key data of different operating states in the print output through a centralized and standardized printing process.

[0027] The core of this method lies in proposing a differentiated printing processing mechanism based on data feature tags. This mechanism is based on completely separating the printing function from various function screens, forming an independent printing processing flow. Its core methods include: First, the operator triggers the printing process via a button on the function screen. Based on the number of pages to print and the query conditions on the function screen, the data to be printed is retrieved from the server and processed in a structured manner. During this process, the running status flags carried in each data record are automatically identified, and a corresponding data feature tag is generated for each status flag. The tag is then associated with the record and injected into the intermediate data. Second, based on the feature tags in the intermediate data, a separate style rule module assigns differentiated display rules (e.g., different line types, outline styles, fill patterns, etc.) to different tags, generating an intermediate file carrying display style information. This intermediate file ensures that records with different tags can still be clearly distinguished in the printing environment. Finally, the intermediate file is uniformly printed. Through the above mechanism, the three stages of data acquisition, style control, and output execution are separated. All functional screens share the same printing process, thereby reducing code redundancy in the functional screens, reducing the maintenance cost of printing operations, and ensuring the recognizability of key status data in the printed document.

[0028] See Figure 1 The method includes steps 101 to 103.

[0029] Step 101: In response to a print command triggered by any function screen, obtain the data to be printed from the records in the function screen; perform structured processing on the data to be printed to generate intermediate data, and identify the nuclear power operation status flag carried by each record in the data to be printed. Automatically generate the corresponding data feature tag according to the identified nuclear power operation status flag, and associate the data feature tag with the corresponding record and inject it into the intermediate data.

[0030] The purpose of this step is to centralize the data query and status judgment logic that is scattered across various functional screens, and to establish a standardized data representation format so that subsequent style processing can be independent of specific business screens.

[0031] In this application, the term "nuclear power plant operating status flag" refers to a status attribute field in a nuclear power plant's DCS system used to identify the current operating characteristics of equipment, signals, or alarm records. These status flags are inherent fields in the data records of the nuclear power plant's DCS system, typically automatically generated by the underlying instrumentation and control system based on the actual status of the equipment or signal quality and stored in a database. Before printing, the method of this application identifies the status characteristics of each record by reading these inherent fields.

[0032] The aforementioned "nuclear power plant operating status indicators" include, but are not limited to, the following: (1) Invalid state: refers to the invalid or unreliable state of a signal in the DCS system due to equipment failure, communication interruption, data timeout, etc. In the field of nuclear power DCS, when an abnormal signal is detected, the system will mark the signal as "invalid" or "signal quality bit failure".

[0033] (2) Forced state: refers to the operating state in which the operator forces a signal to a specific value through the DCS system during equipment commissioning, maintenance, or special operating conditions, temporarily deviating it from the actual physical state. The nuclear power field has related technologies for "instrumentation and control signal forcing," used to control signal output under specific operating conditions.

[0034] (3) Test status: refers to the operating status of the DCS system or related equipment when it is in functional testing or periodic testing mode. Nuclear power plants can put the system into "maintenance test status" or "functional test status" according to operation and maintenance requirements.

[0035] (4) Isolation state: refers to the state in which equipment or system is physically or logically separated from the operating system due to maintenance, repair or other reasons. Nuclear power plant systems may be placed in "shutdown isolation state" or "isolation maintenance state".

[0036] (5) Alarm Level Status: This refers to the level identifier of alarm records according to their urgency and importance, such as different levels like "Severe", "Warning", and "Alert". The nuclear power plant alarm system has a comprehensive alarm level determination mechanism to distinguish the importance of different alarms.

[0037] The aforementioned status flags are known technical concepts in nuclear power DCS systems.

[0038] The specific implementation method for this step is as follows: Taking the alarm function screen as an example, the operator sets the query conditions on this screen: the time range is "2025-01-01 00:00:00 to 2025-01-01 23:59:59", the alarm level is "Critical", and the alarm name contains "RCP001". After the operator clicks the "Print" button, the function screen does not process the data itself, but instead passes the above query conditions to the execution entity of this method (hereinafter referred to as the print processor) through a predefined interface. After receiving the query conditions, the print processor sends a data request to the DCS historical server or real-time server. The dataset returned by the server is usually in tabular form, with each row corresponding to one alarm record and each column corresponding to one field. The fields include at least: alarm occurrence time, alarm name, alarm description, alarm level value (e.g., level 1-5), invalid flag (TRUE / FALSE), mandatory flag (TRUE / FALSE), test flag (TRUE / FALSE), isolation flag (TRUE / FALSE), etc.

[0039] After obtaining the raw dataset, the print processor performs structured processing. This processing includes converting the raw data into a unified in-memory data object, for example, mapping each row of records to a set of key-value pairs, and determining the field types and value ranges for each record. During structured processing, the print processor simultaneously performs status flag recognition: it reads each status flag field in each record one by one, and for each flag with a value of "valid" or "requires special attention," it generates a corresponding data feature label. The label generation rules are predefined: for example, when the invalid flag field is TRUE, a label object named "STATUS_INVALID" is generated; when the forced flag field is TRUE, a label named "STATUS_FORCED" is generated; when the test flag is TRUE, a label named "STATUS_TEST" is generated; when the isolation flag is TRUE, a label named "STATUS_ISOLATED" is generated; and for the alarm level field, labels such as "ALARM_LEVEL_1" to "ALARM_LEVEL_5" are generated based on the level value. Each tag object contains at least two attributes: a tag type identifier (such as "INVALID") and a tag source (indicating which field the tag originates from). The print processor then associates these tag objects with their corresponding records, storing the tag list as an additional attribute of that record in an intermediate data object. The intermediate data object can be represented in memory as an array of records, where each record element contains the original field value and an array of "tags".

[0040] Through the above processing, the status judgment logic that was originally scattered in various function screens is centralized in the data acquisition stage of the print processor, and the judgment result is expressed in a standardized label form, no longer bound to any specific display style.

[0041] The improvements in this step are as follows: First, data querying and status recognition are removed from the function screens, so the function screens no longer contain any code related to data acquisition and status judgment. Second, a unified label generation mechanism is introduced, abstracting various status flags into typed label objects, thus decoupling status information from display style. In the traditional solution, if a new status flag (such as "maintenance status") is added, each function screen needs to modify the conditional judgment branch in its printing code. In this step, only one mapping needs to be added to the label generation rules of the print processor, and all function screens automatically gain the ability to recognize the new status.

[0042] This step, through the aforementioned improvements, transforms the raw data into labeled intermediate data, completely separating the functional screens from the data acquisition logic. Because all functional screens share the same set of data acquisition and label generation code, the code in the functional screens is redundant. At the same time, since the label is an abstract representation independent of the display style, subsequent style control steps can flexibly assign display rules to different labels without modifying the code in the data acquisition stage, reducing the maintenance cost of printing operations.

[0043] Step 102: Based on the data feature tags in the intermediate data, assign different differentiated display rules to different tags and generate an intermediate file carrying display style information; wherein, the differentiated display rules enable records with different nuclear power plant operating status flags to be distinguished in the printed document in the printing environment.

[0044] The purpose of this step is to transform the abstract label into a concrete, printable visual style and generate a self-contained intermediate file, which can be directly submitted to the printer driver or used for electronic archiving. The specific implementation is as follows: For example, based on the specific configuration of the project, a mapping table is established from original state flags (such as test flag "@", isolation flag "#", invalid flag "U" or "I", etc.) to unified feature labels (such as TEST, ISOLATED, INVALID). The same logical state is allowed to use different flag characters in different projects. The system loads this mapping relationship through the configuration file to achieve multi-project adaptation.

[0045] The print processor internally maintains a style mapping table. This mapping table is a data structure whose keys are tag type identifiers (such as "INVALID", "FORCED", "TEST", "ISOLATED", "ALARM_LEVEL_1", etc.), and whose values ​​are a set of display attributes. Display attributes include, but are not limited to: border styles (such as solid lines, dashed lines, double lines, and border colors), background fill patterns (such as diagonal lines, halftone dots, and cross lines), font decorations (such as bold and italics), and foreground colors.

[0046] For color printers, the differentiated display rules make full use of color coding to distinguish different key states, including but not limited to: Mandatory indicator: Displayed in royal blue (RGB 0,0,255); Poor quality (invalid data): Displayed in red (RGB 255,0,0); Alarm levels: Based on the actual configuration of the project, red, yellow, orange, and white colors are used for hierarchical identification (e.g., emergency alarms are red, high-level alarms are orange, general alarms are yellow, and warning alarms are white). Test status: can be distinguished by green or gray; Isolation status: Purple or brown can be used.

[0047] The color rules mentioned above can be predefined in CSS stylesheets and can be dynamically adjusted by project via configuration files.

[0048] Specifically, to adapt to black and white printing environments, each entry in the mapping table must contain at least one color-independent distinguishing feature. For example, the "INVALID" label corresponds to a red inner border with a double-line border, the "FORCED" label corresponds to a blue outer border with a single-line border, the "TEST" label corresponds to a yellow marker with a dotted-dash border, the "ISOLATED" label corresponds to a gray fill with a diagonal pattern, the "ALARM_LEVEL_1" label corresponds to a red background with bold font, and the "ALARM_LEVEL_2" label corresponds to an orange background with bold font. The border style and fill pattern remain visible during black and white printing; for example, the line width changes.

[0049] When generating intermediate files, the print processor iterates through each record in the intermediate data. For each record, it retrieves its associated tag array. Then, it queries the style mapping table to obtain the corresponding display attributes for each tag. When a record is associated with multiple tags (e.g., an alarm record has both "critical alarm level" and "invalid status"), the print processor merges the display attributes according to predefined priority rules. For example, the display rules for higher alarm levels override those for invalid status, or a combination method is used (applying both borders and background patterns). The merged display attributes are converted into style tags for the intermediate file. The intermediate file can be in XML or HTML format. For example, for a record with the "INVALID" tag, its corresponding table row (tr) or cell (td) will have a class attribute "status-invalid" added, and the CSS style rule ".status-invalid { border: 2px double red;}" will be defined in the header of the intermediate file. For the printing environment, the CSS rules will also include color-independent styles such as "border-style: double;" and "background-image:repeating-linear-gradient(45deg, ...)". The final intermediate file contains the complete table structure, data content, and embedded or referenced style rules.

[0050] The improvements in this step are as follows: First, the display rules are centrally managed by an independent style mapping table. Modifying the display effect only requires updating the mapping table, without modifying the code of any functional screen. Second, the design of the display rules is required to include distinguishable features (line type, fill pattern, etc.) in a black and white printing environment, while traditional solutions usually only consider color display, resulting in information loss during black and white printing. Third, generating intermediate files (instead of directly calling the drawing API) allows the printed output and electronic archive to share the same data source, ensuring output consistency.

[0051] This step, through the improvements described above, generates an intermediate file containing complete data and style information. This file is independent of any functional screen, and its style rules can be centrally modified. Due to the adoption of multimodal display rules (color + line type / pattern), even when output on a black and white printer, records corresponding to different labels can still be quickly distinguished by features such as border shape, line density, and fill texture, thus significantly improving the efficiency of identifying key data during accident tracing.

[0052] Step 103: Perform a print operation on the intermediate file.

[0053] The purpose of this step is to physically output the intermediate file as a paper document. Since the intermediate file already contains all the data and formatting information, the printing operation can be performed in a standard, business-independent manner. Specifically, the print processor calls the print service interface provided by the operating system or the printer driver's API, takes the intermediate file (e.g., HTML or XML format) as input, sets the print parameters (such as paper size, number of copies, single / double-sided printing, etc., which can be pre-specified by the user in the print settings interface), and then submits the print job. The operating system or printer driver is responsible for rendering the intermediate file into a page description language (such as PostScript or PCL) and sending it to the printer hardware. Simultaneously with submitting the print job, the print processor can also, according to the user's choice, copy the same intermediate file to a specified file path, or store it on an archiving server over a network as an electronic document archive. Because paper printing and electronic archiving use the exact same intermediate file, they naturally maintain consistency in data content and formatting layout.

[0054] The improvements in this step are as follows: First, the printing output of all function screens is completed through the same intermediate file generation process, ensuring the consistency of the output results; Second, the code of the function screens does not contain any printer driver calls or printing parameter setting code, and all low-level operations related to printing output are encapsulated in the print processor.

[0055] Through the improvements described above, this step ultimately achieves a complete printing process from data to paper documents. Function screens only need to provide query conditions and trigger signals; everything else is handled automatically by the print processor. Because print styles are centrally managed and intermediate files can be reused, the print output of all function screens is automatically updated after modifying the print format, eliminating the need to modify the screen code individually.

[0056] By centralizing data acquisition and status recognition into a unified print processor and generating standardized data feature labels for each record, this embodiment eliminates the redundancy of repeatedly writing data query and status judgment code for each functional screen in traditional solutions. When adding a new functional screen, only the print processor interface needs to be called to pass the query conditions, without developing any print-related code, significantly shortening the development cycle. Furthermore, based on the differentiated display rules assigned by the labels, complete decoupling of print style and business code is achieved. When modifying the print format (font, margins, border styles, etc.), only the style information needs to be adjusted, without modifying the source code of any functional screen, avoiding the workload and error risks associated with modifying each one individually. In addition, based on the differentiated display rules and forcibly using these color-independent differentiation methods in a black-and-white printing environment, the problem of difficult-to-quickly identify key data in traditional printing is solved. Records in different operating states (invalid, forced, experimental, isolated, different alarm levels) can be quickly distinguished on paper documents through features such as border shape, line density, and fill texture, greatly improving the efficiency of accident tracing. Furthermore, by generating a unified intermediate file and performing printing operations based on that file, the printing output of all functional screens follows the exact same process, ensuring consistency and repeatability of the output. This intermediate file can also be used for electronic archiving, ensuring that the paper printouts and electronic documents are completely consistent in data content and format layout, meeting the legal requirements for nuclear safety review.

[0057] In one specific embodiment, instructions for post-printing maintenance are provided.

[0058] During the long-term operation of a nuclear power plant's DCS system, operators or safety auditors often need to retrospectively print alarm or log data generated within a specific time period. For example, after a nuclear safety incident, investigators need to retrieve alarm records from several hours before and after the incident and reprint them in the original printing format to reconstruct the original record at the time of the incident. However, in traditional nuclear power plant DCS systems, the query conditions (such as time range, name, alarm level, etc.) and printing style parameters (such as paper size, font, margins, border style, etc.) used for each printing operation are not recorded or saved by the system. When the same historical data needs to be reprinted, the operator must manually re-enter the query conditions and style settings, which is not only inefficient but also often results in discrepancies in data range or format layout between the reprinted document and the original due to memory bias or parameter loss. This inconsistency may raise questions about the authenticity and completeness of the data during nuclear safety audits, posing legal risks.

[0059] Therefore, this embodiment proposes to save the context information (including query conditions and style parameters) of each printing task, and to be able to regenerate a print output that is completely consistent with the original print result based on historical data at any subsequent time, thereby ensuring the accuracy and repeatability of data traceability.

[0060] Specifically, after performing a print operation on the intermediate file, the query conditions and style parameters used in this print operation are associated with the intermediate file and stored in the historical database; When it is necessary to reproduce and print historical alarm data or log data, the corresponding historical data is retrieved from the historical database according to the stored query conditions and style parameters, and the stored style is applied to generate an intermediate file to produce an output result consistent with the original print result.

[0061] The above steps are intended to associate and store the key parameters of this printing task with the generated intermediate file, and to provide data sources and style guidelines for subsequent historical reprinting. Specifically, the implementation is as follows: When the print processor completes the generation of intermediate files and is ready to execute the output (paper printing or electronic archiving), the system automatically captures the query conditions and style parameters used for this print job. The query conditions refer to the filtering rules passed to the print processor from the function screen, such as: time range (start and end time), point list (single point name or wildcard expression), alarm level (critical, warning, alert, etc.), basic system number, query area, station number, etc. These query conditions are usually in the form of key-value pairs or Structured Query Language (SQL) fragments. Style parameters refer to the print format options selected by the user in the print settings interface, such as: paper size (A3, A4, Letter, etc.), print orientation (landscape or portrait), font name and size, page margins (top, bottom, left, right), number of records displayed per page, etc.

[0062] These query conditions and style parameters are serialized into a storable format (such as a JSON object or XML fragment) and then associated with the generated intermediate file. This associated storage can be implemented physically in several ways: one approach is to write the query conditions and style parameters as metadata into the header or footer of the intermediate file, making it a self-contained archive unit; another approach is to maintain a print job log table in the system, generating a unique job identifier (UUID) for each print job and storing information such as the intermediate file storage path, query conditions, style parameters, and print time in this table. Both approaches enable subsequent lookups and reproduction.

[0063] When users need to reprint historical alarm data or log data, such as reprinting an alarm list from three months ago during an accident investigation, they can select the corresponding historical print task through the system's historical print task query interface (usually sorted by time or searched by task ID). The system executes the reproduction process based on the stored query conditions and style parameters: First, based on the stored query conditions (such as the original time range "2025-01-01 00:00:00 to 2025-01-01 23:59:59" and the name "RCP001"), it re-initiates a data query request to the historical data server to obtain the historical data still retained at the current time (note: historical data servers usually store the original data for a long time, so the same query conditions can return the exact same set of data records as before, provided that the data has not been cleared). Second, the system applies the stored style parameters (such as paper size A4, portrait orientation, Songti 10pt font, 2cm margins, etc.) and re-executes the feature label recognition and differential display rule allocation process to generate a new intermediate file. Because the query conditions are the same, the retrieved data records are identical to those in the original printout. Since the style parameters are the same and the mapping table from labels to display rules maintains version consistency (the style mapping table itself should also be version-managed as a system configuration), the generated intermediate file is completely consistent with the original printout in terms of data content, layout format, pagination, and visual style. Finally, the user can choose to output the intermediate file as a paper document or an electronic document.

[0064] The improvements in this step are as follows: First, query conditions and style parameters are stored in association with intermediate files, so that all relevant parameters of the print job are automatically recorded by the system, eliminating the need for manual memorization or entry. Second, a complete reproduction mechanism is provided, which can automatically retrieve historical data and apply the original style based on the stored parameters to generate output that is completely consistent with the original print result. In existing technologies, even if some systems can save the electronic documents generated by printing (such as PDF files), they cannot regenerate editable or paginated documents based on the original query conditions, let alone restore the print style of that year after system upgrades or style changes. This step, by storing "query conditions" and "style parameters" separately, ensures that even if the original intermediate file is lost or the style mapping table changes, the print output of that year can still be accurately reproduced based on historical records.

[0065] This embodiment, through the aforementioned improvements, achieves traceability and reproducibility of printing tasks. Operators or safety auditors can recall any historical printing task at any time, obtaining output completely consistent with the original print result without manual intervention. This significantly improves the efficiency and accuracy of accident investigations and nuclear safety reviews. Simultaneously, because the reproduction process is fully automated and based on the original query conditions and style parameters, it avoids data inconsistencies caused by human error, meeting the stringent requirements of nuclear safety regulations for record preservation and traceability. This step adds long-term archiving and historical backtracking capabilities to the entire printing device, making the technical solution of this invention not only suitable for daily printing needs but also adaptable to the data management requirements throughout the entire life cycle of a nuclear power plant (typically 40-60 years).

[0066] In one specific embodiment, a description of the display style information is given for step 102.

[0067] In the printing function of a nuclear power plant's DCS system, print style parameters (such as paper size, print orientation, font name and size, margins, and number of records per page) directly affect the readability and standardization of the output document. In traditional nuclear power DCS systems, these style parameters are usually hard-coded and scattered throughout the business code of various functional screens. For example, the alarm screen code directly defines "paper: A4, orientation: portrait, font: SimSun 10pt", and the log screen code defines "paper: Letter, orientation: landscape, font: Heiti 9pt". This implementation method brings two problems: First, when a certain style parameter needs to be uniformly modified (for example, changing the font of all functional screens from 10pt to 11pt), developers must modify the source code of each functional screen one by one, which is a large workload and easy to miss, resulting in inconsistent print formats across different functional screens; Second, if an operator wants to temporarily adjust a parameter during a print job (for example, changing the margin from the default 2 cm to 1 cm), the traditional system cannot support such dynamic adjustments because the style parameters are fixed in the code.

[0068] Furthermore, even if some traditional systems allow users to temporarily modify parameters in the print settings interface, these modifications are only effective for the current print job and must be reset for subsequent print jobs, failing to establish global default values. More problematic is that when multiple function screens manage their own style parameters, the default values ​​across different screens may be out of sync, resulting in a lack of a unified visual style in the entire DCS system's print output.

[0069] Therefore, this embodiment implements a centralized management mechanism for print style parameters. This mechanism can provide a unified set of default style parameters for all function screens, while allowing users to flexibly override any parameter each time they print. The overridden parameter does not affect other function screens or other printing tasks, thereby meeting the personalized needs of individual printing tasks while maintaining global consistency.

[0070] Specifically, a global print style parameter set is pre-stored, which is independent of each function screen and applies to all function screens; Specifically, based on the print style parameters passed in when the function screen is invoked, the corresponding items in the global print style parameter set are updated, and the display style information of the current print task is generated based on the updated global print style parameter set.

[0071] In this embodiment, a global, dynamically updatable print style parameter management mechanism is established in the printing device, enabling all function screens to share the same set of style parameter benchmarks, while allowing individual print jobs to temporarily override the benchmarks by passing in parameters. The specific implementation is as follows: (a) Storage of the global default style parameter set During initialization, the printing device loads a set of predefined print style parameters from a configuration file or system registry and stores them in an internal data structure called the "global print style parameter set." This parameter set is independent of any single screen and applies to all screens. The parameter set includes at least the following: Paper size: For example, the default value is A4; Print orientation: The default value is portrait. Font name: The default value is SimSun; Font size: The default value is 10. Page margins: 2 cm each for top, bottom, left, and right; Number of records displayed per page: The default value is 20.

[0072] These parameters can be configured during system deployment according to the actual needs of the nuclear power plant, or modified by users with administrator privileges through a dedicated configuration interface during system operation. Once modified, the new default values ​​will be applied to all subsequent print jobs for all functional screens, unless a print job has been overridden by passed parameters.

[0073] (ii) Passing style parameters to the function screen When a user clicks the "Print" button on a function screen (such as an alarm screen), a print settings interface typically pops up. Users can temporarily adjust style parameters on this interface, such as changing the paper size from "A4" to "A3," or changing the page margins from 2 cm to 1 cm. The function screen collects this user input, organizes it into a style parameter object (e.g., a structure containing multiple key-value pairs), and then passes this style parameter object to the printing device through a standardized interface (e.g., the "setStyleParameters" interface).

[0074] (III) Parameter Update and Style Generation After receiving the style parameters from the function screen, the printing device does not directly replace the global default parameter set, but instead performs the following operations: First, a copy of the global default print style parameter set is made, and this copy is used exclusively for the current print job. Then, each parameter item in the style parameter object passed from the function screen (e.g., "paperSize = A3") is found in the copy, and its value is updated from the default value (A4) to the passed value (A3). For parameter items not passed from the function screen (e.g., font name, margins, etc.), the global default value is retained in the copy. In this way, the copy becomes a "hybrid" parameter set: based on the global default value, it is overlaid with the personalized overlay for this print job.

[0075] Finally, the printing device uses the updated set of copy parameters to generate the display style information for the current print job. Specifically, when generating intermediate files, CSS style rules or inline styles are dynamically constructed based on the paper size, orientation, font, margins, and other values ​​in the copy to ensure that the final output document conforms to the format set by the user.

[0076] It is important to note that the above update operation only affects a copy of the current print job; the global default print style parameter set itself will not be modified. Therefore, when another function screen initiates a print job, the original global default parameter set will still be used as the basis, unless the user provides new overwrite parameters again.

[0077] (iv) Persistent user preferences The printing device can also maintain an independent set of user preference parameters for each logged-in user or each function screen; furthermore, it maintains an independent set of user preference parameters for different preferences of each project, allowing users to select according to project requirements. For example, one operator may prefer to print alarm lists on A3 paper, while another operator may prefer A4 paper. The system can save the user's last settings to the database, automatically loading their preference parameters the next time the same user prints, eliminating the need for manual adjustment each time. However, this mechanism is a further extension of the global parameter set and is not the core content of this step.

[0078] The improvements in this step are as follows: First, a global default print style parameter set, independent of all function screens, was established, enabling centralized storage and unified management of style parameters. When the print style of the entire DCS system needs to be adjusted, only the global default parameter set needs to be modified once, and all function screens will automatically take effect, completely eliminating the workload of modifying the code of each function screen individually. Second, a parameter overriding mechanism was introduced, allowing function screens to pass temporary style parameters when called. These parameters only overwrite the copy of the current print job and do not affect the global default value. This design maintains global consistency while meeting the personalized needs of a single print job, whereas in traditional systems, temporary adjustments are either completely impossible or the default cannot be restored after adjustment. Third, parameter competition in a multi-threaded environment is avoided through copy replication. Each print job has an independent copy of the parameters, which do not interfere with each other, ensuring the determinism and repeatability of print output.

[0079] Through the aforementioned improvements, this embodiment ensures the uniformity of print styles by sharing the same global default parameter set across all functional screens. Furthermore, the workload for modifying styles is reduced from "modifying N screens" to "modifying one configuration," significantly lowering development and maintenance costs. Operators can temporarily adjust parameters such as paper size and margins each time they print without waiting for developers to modify the code, greatly improving the flexibility of on-site operations. Temporarily overriding parameters does not pollute global default values; the next print automatically reverts to the default format, avoiding the potential for a temporary modification to affect all subsequent print jobs. Finally, this mechanism provides a unified data foundation for future expansion functions such as user preference storage and historical style reproduction.

[0080] In one specific embodiment, the method for generating intermediate files in step 102 is explained.

[0081] In the printouts of a nuclear power plant's DCS system, log data and alarm data are typically presented in tabular form, with each record occupying one line. When there are many records to be printed, the content needs to be distributed across multiple pages. In traditional nuclear power DCS systems, each function screen implements its own pagination logic. There are two common approaches: one is to simply output all data continuously, with the printer automatically driving pagination. However, this method cannot control the number of records per page, which may result in the last record on a page being truncated to half a line, or a page containing only a title while the data is moved to the next page; the other approach is for the function screen to calculate the number of lines to be displayed per page through hard coding and manually control the page breaks. However, these traditional practices have the following problems: First, when the number of records on a page is not fixed (e.g., due to changes in font size and page margins, the number of records that can be accommodated per page varies), the hard-coded pagination logic is prone to errors, causing records to be truncated across pages, resulting in a complete alarm message being split across two pages, making it difficult to trace the incident; Second, the first page of the printed document usually lacks necessary contextual information, such as query conditions, project information, user information, etc., making it impossible for reviewers to confirm the source and screening scope of the document after receiving the printout; Third, the last page does not have a clear end mark, making it difficult to determine whether each document is complete when multiple printed documents are stacked together, posing a risk of missing or incomplete pages.

[0082] Therefore, this embodiment implements an intelligent pagination mechanism that can automatically calculate the pagination boundary based on the number of records displayed per page, ensuring that each record appears completely on a page without being truncated across pages; at the same time, it provides complete document identification and query condition information on the first page and a clear end mark on the last page, so that the printed document still has self-interpretability and completeness verifiability after being removed from the electronic system.

[0083] For example, during the generation of intermediate files, the table data is divided into pages, and specific content modules are added to the first and last pages, thereby generating a complete and easily traceable multi-page printable document. The specific implementation is as follows: (a) Intelligent pagination calculation Before generating intermediate files, if the operator inputs print parameters of 10 pages and the project requires 20 records per page, but there are actually fewer than 200 records, the system will display a prompt to inform the operator and print the 100 records actually found. Alternatively, it can automatically calculate a recommended value based on a combination of paper size and font size. Let the total number of records be N, and the number of records displayed per page be M. Then, the formula for calculating the total number of pages P is: P = ceil(N / M), which is rounded up.

[0084] For page i (starting from 1), the starting record index is (i-1) * M + 1, and the ending record index is min(i * M, N). The print processor extracts the corresponding subset of records from the intermediate data according to these indices and generates a separate table fragment for each page. When generating each table fragment, it ensures that all records on that page are complete rows of data, and there will be no situation where the first row of a record is at the end of the current page and the remaining rows are at the beginning of the next page. This is because pagination is performed on a record-by-record basis, not on rows or byte-by-byte. For example, an alarm record may contain multiple fields such as alarm time, name, description, and status flags; the entire record will always appear as a complete row on the same page.

[0085] (ii) Homepage content generation The homepage content is divided into two parts: a title area and an information grid area. The title area is located at the top of the page and is used to display the main title of the printed document, such as "Full Log," "Alarm Summary List," or a title dynamically generated based on the function screen (such as "RCP System Critical Alarm Record"). The information grid area is located below the title area and is further divided into fixed information areas and personalized information areas.

[0086] The fixed information area displays static information related to the system environment, including but not limited to: project description (e.g., "Unit 1 of XX Nuclear Power Plant"), database version information (e.g., "DB_V3.2.1"), username (username of the currently logged-in operator), and device code (printer or workstation identifier). This information is obtained from the DCS platform interface by the print processor during initialization and is automatically filled in for each print job without user intervention.

[0087] The personalized information area displays query conditions specific to this print job, and its content is dynamically set according to different function screens. Taking the alarm function screen as an example, personalized information may include: time range ("2025-01-01 00:00:00 to 2025-01-01 23:59:59"), alarm level ("Severe"), name ("RCP001"), basic system ("RCP"), query area ("Reactor Coolant System"), station number ("01"), etc. For the log function screen, personalized information may include log type, operator, etc. For the notepad function screen, since there are no complex query conditions, the personalized information area can be empty or omitted. This personalized information is passed in by the function screen through the personalized information setting interface when calling the print processor. The print processor presents this information as a key-value pair list on the right or bottom of the homepage information grid area, usually arranged in the format of "name: value".

[0088] (III) Generation of last page content The last page is the final page of a printed document, and a print end mark is permanently generated at its bottom. This mark can be a line of text, such as "— End of Print—" or "*** End of Document ***", or it can be a horizontal line or a specific graphic symbol. The purpose of the print end mark is to clearly identify the complete boundary of the document, allowing the reader to immediately determine whether the document was prematurely terminated due to printing interruption, running out of paper, or system failure. When multiple printed documents are stacked or bound together, the print end mark helps to quickly identify the end of each document, preventing two documents from being mistaken for one or one document from being split into two.

[0089] It should be noted that if the total number of records exactly fills the last page, the end marker will still be added below all records on the last page; if the last page has only a few records, the end marker will follow immediately after the last record. This special treatment of the first and last pages, along with the pagination content in between, constitutes a complete, self-describing print document.

[0090] The improvements in this step are as follows: First, an intelligent pagination algorithm based on records is adopted. This algorithm automatically calculates page boundaries based on the number of records displayed per page, ensuring that each record appears completely on a given page, fundamentally avoiding page truncation issues. In traditional solutions, because pagination logic is coupled with specific print output formats (such as fonts and margins), changes in the number of lines per page after style modifications can cause the original pagination code to become invalid, leading to incorrect record truncation. This step separates pagination from style control; pagination relies only on the abstract parameter of "number of records displayed per page," unaffected by changes in specific fonts or margins, ensuring stability and reliability. Second, the personalized information in the first page's information grid area includes the query conditions used for this printing. This makes the printed document itself an independently traceable piece of evidence; anyone who receives the printout can understand the data filtering scope of the document without consulting the electronic system. Third, the print end mark on the last page provides a visual verification method for document integrity, effectively preventing missing pages caused by printing interruptions from being overlooked.

[0091] Through the aforementioned improvements, the intermediate documents generated in this embodiment possess the following technical advantages: First, intelligent pagination ensures the integrity of all records on each page, eliminating the need for accident investigators to piece together alarm information between two pages, thus improving reading efficiency and accuracy. Second, the fixed and personalized information on the first page makes the printed document self-explanatory. Even years after being removed from the original DCS system, reviewers can still understand the document's creation environment, operators, and data selection criteria through the first page content, meeting the long-term traceability requirements for nuclear safety record preservation. Finally, the print end mark on the last page provides a clear indication of document integrity. When errors occur during printing or paper shortages, users can immediately identify document incompleteness and reprint promptly, avoiding the use of incomplete records for nuclear safety-related decisions. These features collectively enhance the human factors engineering quality and legal evidentiary value of the printed output from the nuclear power DCS system.

[0092] In addition, this application embodiment also provides a printing device in a nuclear power plant DCS system, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the method described above.

[0093] Figure 2 This is a schematic diagram of the structure of a nuclear power plant DCS system provided in an embodiment of this application. Figure 2 As shown, the system includes: a human-computer interaction device, a printing device, and an optional user interface device. The following is in conjunction with... Figure 2 A detailed description of each component and its connections is provided.

[0094] (a) Human-computer interaction devices The human-machine interface (HMI) device is the front-end equipment for operators to interact with the DCS system, typically operating on operator or engineer workstations. This device has multiple functional screens, each corresponding to an independent business module. These functional screens include, but are not limited to: a full log screen (for viewing system operation logs), an alarm list screen (for real-time display and querying of alarm information), a numerical trend screen (for displaying parameter change curves), a notepad screen (for recording operation events), and list screens (level system list, over-range list, etc.). Each functional screen has the ability to trigger printing commands and is configured to pass its respective query conditions to the printing device.

[0095] Specifically, when an operator sets query conditions (such as time range, roll call, alarm level, etc.) on a function screen and clicks the "Print" button, the function screen does not perform any printing-related data processing or style generation operations on its own. Instead, it packages the query conditions according to a predefined standardized format (such as a JSON object or XML fragment) and transmits the query conditions to the printing device by calling the data acquisition interface provided by the printing device. The function screen itself does not contain any business logic code related to print style generation, pagination calculation, or printer driver calls. This design achieves complete decoupling between business logic and printing logic.

[0096] (ii) Printing device The printing device is the core component of this invention, and its internal structure and working principle have been described in detail in the method and device embodiments. The printing device is decoupled from the multiple functional screens. The printing device receives a printing command from any functional screen and performs the following operations sequentially: obtains the data to be printed from the records in the functional screen via the server; performs structured processing on the data and generates intermediate data; identifies the nuclear power plant operating status flag carried in each data record and automatically generates corresponding data feature tags; assigns differentiated display rules based on the feature tags; generates an intermediate file carrying display style information; and finally outputs the intermediate file to a designated target (paper printing or electronic archiving). Detailed implementation of the printing device can be found in the aforementioned method and its corresponding specific embodiments, and will not be repeated here.

[0097] Communication between the printing device and the human-machine interface can be achieved through inter-process communication (IPC), remote procedure call (RPC), or HTTP-based web services. Since the printing device operates independently of the function screen, its upgrades or configuration changes will not affect the stability of the human-machine interface, and vice versa.

[0098] (iii) User interface device In a preferred embodiment, the system further includes a user interface device. This user interface device is connected to the human-computer interaction device and its function is to uniformly manage the print settings interface, avoiding the need for each function screen to implement a separate print settings dialog box.

[0099] (iv) Archive server In a preferred embodiment, the system further includes an archive server. The archive server is connected to the printing device and is used to receive and store electronic archive files sent by the printing device.

[0100] Specifically, when a user selects the "electronic archiving" output method, the printing device packages the generated intermediate file (such as an XML file) along with the query conditions used for this printing (such as time range, name, alarm level, etc.) and style parameters (such as paper size, font, font size, margins, color mapping rules, etc.) and sends them to the archiving server. The archiving server categorizes and stores these files according to preset archiving rules (such as by time, function screen type, operator, etc.) and establishes index information for subsequent quick retrieval and reproduction.

[0101] Furthermore, the archiving server supports a history replay function: when it is necessary to reprint or view a document from a specific historical archive, the operator can initiate a request to the archiving server through the human-machine interface, specifying a unique identifier for the historical record (such as a print timestamp or task ID). Based on the query conditions and style parameters stored on the archiving server, the human-machine interface re-invokes the data acquisition interface of the printing device, retrieves the data from the DCS historical server at that time (or a stored snapshot of the original data), and applies the same style rules to generate an intermediate file, ultimately outputting a paper or electronic document completely consistent with the original. This mechanism ensures long-term consistency between electronic archiving and paper printing, meeting the stringent requirements for document integrity in nuclear power plant accident tracing and nuclear safety reviews.

[0102] The physical deployment of the archive server can be a standalone server or integrated with the DCS system's historical server. The communication protocol between the archive server and the printing device supports encrypted transmission to ensure the security of nuclear power plant operation data.

[0103] Specifically, when any function screen triggers a print command, the function screen does not automatically pop up a print settings window. Instead, it invokes standardized services provided by the user interface device. The user interface device then displays a unified print settings interface, which centrally contains all configurable print parameters, such as: output method (paper printing or electronic archiving), print page range, printer selection (when multiple printers are present), electronic archive file name, paper size, print orientation, font, font size, and margins.

[0104] After the operator completes the settings on this interface, the user interface device collects all parameter setting results and sends them to the corresponding function screen. Upon receiving the settings, the function screen transmits them, along with the query conditions, as part of a print request to the printing device. In this way, all function screens share the same print settings interface, ensuring a consistent user experience and avoiding redundant code development of print settings dialog boxes for each function screen.

[0105] It should be noted that the user interface device is an optional component. In embodiments without a user interface device, each function screen can implement a simple print settings dialog box on its own, or directly use the default style parameters of the printing device for printing, without providing the ability to temporarily modify parameters.

[0106] Taking the alarm master list screen as an example, the collaborative workflow of the above system is explained: 1. The operator sets the query conditions on the alarm master list screen: the time range is "last 24 hours", the alarm level is "critical", and the point name is "RCP001".

[0107] 2. The operator clicks the "Print" button.

[0108] 3. The alarm master list screen will invoke the user interface device (if it exists) and pop up a unified print settings interface. In this interface, the operator selects "paper printing" as the output method, "A3" as the paper size, "landscape" as the orientation, and 30 records per page, and then clicks "confirm".

[0109] 4. The user interface device returns the above settings results to the alarm master list screen.

[0110] 5. The alarm master list screen packages the query conditions (time range, alarm level, alarm name) and print style parameters (paper size, orientation, number of records per page) and transmits them to the printing device through the data acquisition interface of the printing device.

[0111] 6. The printing device sequentially performs operations such as data acquisition, feature label injection, style control (generating intermediate files based on the input style parameters), and output scheduling (calling the printer driver), and finally outputs a paper document.

[0112] 7. If the operator selects "electronic archive" as the output method in step 3, the printing device will save the generated intermediate file to the specified path, forming an electronic document in PDF or XML format.

[0113] Through the above system architecture, the nuclear power plant DCS system has achieved the centralization, standardization and scalability of printing functions, effectively solving problems such as code redundancy, maintenance difficulties and complex style modification in traditional solutions, while meeting the stringent requirements of nuclear safety-level accident tracing for printed output.

[0114] It will be understood by those skilled in the art that all or some of the steps, systems, or apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term "computer storage medium" includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

Claims

1. A printing method in a nuclear power plant DCS system, wherein the DCS system includes multiple functional screens, characterized in that, The method is applied to a printing device decoupled from the multiple functional screens; wherein: In response to a print command triggered by any function screen, the system obtains the data to be printed from the history of the function screen; it performs structured processing on the data to be printed to generate intermediate data, identifies the nuclear power plant operation status flag carried by each record in the data to be printed, automatically generates corresponding data feature tags based on the identified nuclear power plant operation status flags, and associates the data feature tags with the corresponding records and injects them into the intermediate data. Based on the data feature tags in the intermediate data, different differentiated display rules are assigned to different tags to generate an intermediate file carrying display style information. The differentiated display rules enable records with different nuclear power plant operating status flags to be distinguished in the printed document in the printing environment. The intermediate file is used to respond to the print command.

2. The method according to claim 1, characterized in that, The nuclear power plant operation status indicators include at least one or more of the following: invalid status, mandatory status, test status, isolation status, and alarm level status.

3. The method according to claim 1 or 2, characterized in that, The differentiated display rules include at least one of border style, fill pattern, color mark, line type difference, and outer frame style difference, and maintain distinguishability in a black and white printing environment through line type difference, outer frame style difference, or fill pattern difference.

4. The method according to claim 1, characterized in that, The method further includes: After the intermediate file is printed, the query conditions and style parameters used in this printing are associated with the intermediate file and stored in the historical database. When it is necessary to reproduce and print historical alarm data or log data, the corresponding historical data is retrieved from the historical database according to the stored query conditions and style parameters, and the stored style is applied to generate an intermediate file to produce an output result consistent with the original print result.

5. The method according to claim 1, characterized in that, A global print style parameter set is pre-stored, which is independent of each function screen and applies to all function screens; Specifically, based on the print style parameters passed in when the function screen is invoked, the corresponding items in the global print style parameter set are updated, and the display style information of the current print task is generated based on the updated global print style parameter set.

6. The method according to claim 1, characterized in that, The step of responding to the print command using the intermediate file includes: Depending on the output method selected by the user, the intermediate file can be selectively sent to the printer driver to output a paper document, or the intermediate file can be saved as is to a specified storage path as an electronic document.

7. The method according to claim 1, characterized in that, The intermediate files are generated in the following ways: Receive the record count parameter per page, calculate the total number of pages in the intermediate file and the start and end record indices of each page based on the total number of records, and ensure that the required records appear completely on the same page; Generate the homepage content of the intermediate file. The homepage includes a title area and an information grid area. The information grid area contains fixed information and personalized information. The fixed information includes project description, database version information, user name, and device code. The personalized information includes the query conditions used for this printing. The personalized information is dynamically set according to different function screens. Generate the last page content of the intermediate file, with the bottom of the last page containing a print end marker.

8. A printing device in a nuclear power plant DCS system, comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method according to any one of claims 1 to 7.

9. A nuclear power plant DCS system, characterized in that, include: The human-computer interaction device has multiple function screens, each of which is configured to send a print command. The printing apparatus as described in claim 8.

10. The system according to claim 9, characterized in that, The system also includes: The user interface device, connected to the human-computer interaction device, is configured to provide a print settings interface after a print command is triggered, obtain the setting results of the print parameters through the print settings interface, and send the setting results to the corresponding function screen.

Images