Marine cabin equipment state monitoring method based on React framework and related device

Abstract

The invention discloses a React framework-based marine engine room equipment state monitoring method and a related device. The method comprises the following steps of: acquiring a working condition point list of equipment mounted in an engine room of a target ship serving as a monitoring target; assigning different working condition point numbers to different working condition points according to the working condition point list; extracting each SVG graph from a configuration file uploaded to the React framework, converting each SVG graph into each React function component according to a JS script in the configuration file, and drawing according to each React function component to obtain a cabin equipment graph formed by a plurality of programmable graphs; according to the actual equipment state monitoring requirement, in the visual binding window, the binding relation between each programmable graph in the cabin equipment graph and each corresponding working condition point number is established; and in response to successful establishment of the binding relationship, displaying the pushed real-time operation state data of the corresponding working condition point at the corresponding position of the corresponding programmable graph in the cabin equipment graph according to the rendering display logic in the JS script.

Description

Technical Field

[0001] This application relates to the field of data monitoring, and in particular to a method, device, electronic equipment, and computer-readable storage medium for monitoring the status of ship engine room equipment based on the React framework. Background Technology

[0002] Currently, ships have many sensor devices that collect data on various operating conditions, such as those in the engine room and during navigation. Crew members can monitor this data through the ship's sensor devices, but there is no unified way to view the equipment's operating conditions, and shore-based management personnel cannot see the operating status data of the engine room equipment.

[0003] While existing ship engine room equipment diagrams allow monitoring of operational status values ​​on a webpage, the workload for R&D personnel is substantial for each ship connected to the system. Furthermore, UI (user interface) design engineers must first create abstract graphics of the ship's engine room equipment before R&D personnel can proceed with development. This development involves a large number of personnel and has a long development cycle.

[0004] Furthermore, since the existing monitoring solution hardcodes the binding relationship into the backend code, any subsequent addition of new cabin equipment or adjustment of the binding relationship requires code-level modifications. This not only makes later maintenance difficult but also results in greater bandwidth consumption and costs when deployed on board. Summary of the Invention

[0005] The purpose of this application is to provide a method, device, electronic equipment, and computer-readable storage medium for monitoring the status of ship engine room equipment based on the React framework.

[0006] To achieve the above objectives, this application provides a method for monitoring the status of ship engine room equipment based on the React framework in its first aspect. The method includes: obtaining a list of operating points for each piece of equipment installed in the engine room of the target ship; assigning different operating point numbers to different operating points based on the register addresses of different sensors corresponding to each operating point in the operating point list; extracting SVG graphics pre-drawn for each piece of equipment installed in the engine room of the target ship from a configuration file uploaded to the React framework, converting each SVG graphics into React function components according to the JS script in the configuration file, and drawing an engine room equipment diagram composed of multiple programmable graphics based on each React function component; establishing a binding relationship between each programmable graphic in the engine room equipment diagram and its corresponding operating point number in a visual binding window provided by the operation interface presenting the engine room equipment diagram, according to the actual equipment status monitoring requirements; and, in response to the successful establishment of the binding relationship, obtaining real-time operating status data of the corresponding operating points pushed from the Redis database based on the WebSocket protocol, and displaying the real-time operating status data at the corresponding position of the corresponding programmable graphic in the engine room equipment diagram according to the rendering display logic in the JS script.

[0007] Optionally, extract the SVG graphics pre-drawn for each piece of equipment installed in the engine room of the target ship from the configuration file uploaded to the React framework, convert each SVG image into a React functional component according to the JS script in the configuration file, and draw an engine room equipment diagram composed of multiple programmable graphics based on each React functional component, including:

[0008] Extract the SVG graphics package from the configuration file uploaded to the React framework from the configuration object;

[0009] Filter out the target SVG graphics corresponding to each piece of equipment installed in the engine room of the target ship from the SVG graphics package;

[0010] Extract the JS script from the configuration file, and convert each target SVG graphic into a React functional component that supports Props style passing by executing the pre-written code logic in the JS script;

[0011] From the component library composed of various React functional components, move the component to the target position on the canvas according to the drag operation passed in by the editing object, and obtain the cabin equipment diagram composed of multiple programmable graphics.

[0012] Optionally, the method further includes:

[0013] Extract new JS scripts from a new configuration file uploaded to the React framework from a configuration object;

[0014] Adjust the graphic styles of the programmable graphics in the cabin equipment diagram, which are acted by various React functional components, according to the graphic styles recorded in the new JS script; the graphic style adjustment is achieved by passing styles through Props.

[0015] Optionally, the real-time operating status data can be displayed in the corresponding programmable graphic position in the cabin equipment diagram according to the rendering logic in the JS script, including:

[0016] The real-time operating status data is displayed in the corresponding programmable graphic position in the cabin equipment diagram according to the rendering logic in the JS script, and the corresponding animation effect is presented in the corresponding position.

[0017] Optionally, the method further includes:

[0018] Pre-set corresponding operating status parameter thresholds for each programmable graphic in the engine room equipment diagram;

[0019] In response to the actual operating status parameters of the real-time motion status data presented by the programmable graphics exceeding the corresponding operating status parameter threshold, an abnormal alarm is issued through a preset path; wherein, the preset path includes at least one of the following: interface pop-up window, SMS, email, sound / light alarm, and graphic style of programmable graphics.

[0020] Optionally, in response to the actual operating state parameters of the real-time motion state data presented by the programmable graphics exceeding the corresponding operating state parameter threshold, an abnormal alarm is issued through a preset path, including:

[0021] In response to the preset path including the graphic style of the programmable graphic, for the target programmable graphic that presents real-time running status parameters that exceed the corresponding status parameter threshold, the abnormal graphic style and style change rules recorded for the target programmable graphic in the JS script are used. If it is determined that the style change rules are met, the original graphic style of the target programmable graphic is adjusted to the abnormal graphic style.

[0022] Optionally, the method further includes:

[0023] Based on the received binding relationship editing request initiated by the target programmable graphic in the engine room equipment diagram, determine whether the target programmable graphic is bound to the original working point number;

[0024] In response to the target programmable graphic being bound to the original operating point number, a binding relationship adjustment window that includes both the original operating point number and the new operating point number pops up.

[0025] To achieve the above objectives, this application provides a second aspect of a ship engine room equipment status monitoring device based on the React framework. The device includes: a condition point list acquisition unit configured to acquire a condition point list of each piece of equipment installed in the engine room of a target ship; a condition point number assignment unit configured to assign different condition point numbers to different condition points based on the register addresses of different sensors corresponding to each condition point in the condition point list; and an engine room equipment diagram generation unit configured to extract pre-drawn SVG graphics of each piece of equipment installed in the engine room of the target ship from a configuration file uploaded to the React framework, and convert each SVG graphic into a React function based on the JS script in the configuration file. The system comprises several components, and draws a cabin equipment diagram consisting of multiple programmable graphics based on each React functional component; a binding relationship establishment unit is configured to establish binding relationships between each programmable graphic in the cabin equipment diagram and its corresponding operating point number in the visual binding window provided by the operation interface that presents the cabin equipment diagram, according to the actual equipment status monitoring requirements; and a real-time running status data acquisition and presentation unit is configured to, in response to the successful establishment of the binding relationship, acquire the real-time running status data of the corresponding operating point pushed from the Redis database based on the WebSocket protocol, and display the real-time running status data at the corresponding position of the corresponding programmable graphic in the cabin equipment diagram according to the rendering display logic in the JS script.

[0026] Optionally, the cabin equipment drawing generation unit is further configured to:

[0027] Extract the SVG graphics package from the configuration file uploaded to the React framework from the configuration object;

[0028] Filter out the target SVG graphics corresponding to each piece of equipment installed in the engine room of the target ship from the SVG graphics package;

[0029] Extract the JS script from the configuration file, and convert each target SVG graphic into a React functional component that supports Props style passing by executing the pre-written code logic in the JS script;

[0030] From the component library composed of various React functional components, move the component to the target position on the canvas according to the drag operation passed in by the editing object, and obtain the cabin equipment diagram composed of multiple programmable graphics.

[0031] Optionally, the device may also include:

[0032] The new JS script extraction unit is configured to extract new JS scripts from the new configuration file uploaded to the React framework from the configuration object;

[0033] The graphic style adjustment unit is configured to adjust the graphic style of the programmable graphics in the cabin equipment diagram, which are each acted by a React functional component, according to the graphic style recorded in the new JS script; wherein, the graphic style adjustment is achieved by passing styles through Props.

[0034] Optionally, the real-time operational status data acquisition and presentation unit includes a rendering display subunit configured to display the real-time operational status data at the corresponding position of the corresponding programmable graphic in the cabin equipment diagram according to the rendering display logic in the JS script. The rendering display subunit is further configured to:

[0035] The real-time operating status data is displayed in the corresponding programmable graphic position in the cabin equipment diagram according to the rendering logic in the JS script, and the corresponding animation effect is presented in the corresponding position.

[0036] Optionally, the device may also include:

[0037] The threshold setting unit is configured to pre-set the corresponding operating status parameter thresholds for each programmable graphic in the engine room equipment diagram.

[0038] The alarm sending unit is configured to issue an abnormal alarm through a preset path in response to the actual running status parameters of the real-time motion status data presented by the programmable graphics exceeding the corresponding running status parameter threshold; wherein the preset path includes at least one of the following: interface pop-up window, SMS, email, sound / light alarm, and graphic style of programmable graphics.

[0039] Optionally, the alarm sending unit is further configured to:

[0040] In response to the preset path including the graphic style of the programmable graphic, for the target programmable graphic that presents real-time running status parameters that exceed the corresponding status parameter threshold, the abnormal graphic style and style change rules recorded for the target programmable graphic in the JS script are used. If it is determined that the style change rules are met, the original graphic style of the target programmable graphic is adjusted to the abnormal graphic style.

[0041] Optionally, the device may also include:

[0042] The edit request processing unit is configured to determine whether the target programmable graphic is bound to an original working point number based on the received editing request for the binding relationship initiated by the target programmable graphic in the cabin equipment diagram.

[0043] The binding relationship adjustment unit is configured to pop up a binding relationship adjustment window that simultaneously contains the original operating point number and the new operating point number in response to the target programmable graphic being bound to the original operating point number.

[0044] To achieve the above objectives, this application provides an electronic device in a third aspect, the electronic device comprising:

[0045] Memory, used to store computer programs;

[0046] A processor is configured to implement, when executing a computer program stored in memory, the steps of the React-based ship engine room equipment status monitoring method as described in any of the embodiments of the first aspect above.

[0047] To achieve the above objectives, this application provides a computer-readable storage medium in a fourth aspect, on which a computer program is stored, which, when executed by a processor, implements the steps of monitoring the status of ship engine room equipment based on the React framework as described in any of the embodiments of the first aspect above.

[0048] The React-based ship engine room equipment status monitoring solution provided in this application first obtains a list of operating points for each piece of equipment installed in the ship's engine room and determines different operating point numbers based on the corresponding sensor register addresses. Then, based on the React framework, it retrieves scalable vector graphics corresponding to each piece of equipment from the configuration file and uses the JS script in the configuration file to convert them into React function components that are easy to program. Based on each React function component, it draws an engine room equipment diagram composed of multiple programmable graphics. Next, through the visual binding window provided in the operation interface, it establishes a binding relationship between each vector graphic and each target operating point number according to the actual equipment status monitoring requirements. When the binding relationship is successfully established, it can obtain the actual operating status data of the corresponding operating points pushed from the Redis database via the WebSocket protocol, so as to present it in the corresponding position of the corresponding programmable graphics according to the rendering display logic recorded in the JS in the configuration file for easy viewing and monitoring by the user.

[0049] Compared to existing technologies, the technical means provided by this solution, with the help of the React framework, change the process of establishing the binding relationship between graphical cabin equipment and corresponding operating point data from the conventional method of directly hard-writing in the background running code to a method in which boundary objects can be directly set and adjusted through the visual operation interface provided by the front end. This reduces the difficulty of development and subsequent operation and maintenance, making the deployment of the status monitoring system on the ship more convenient.

[0050] This application also provides a ship engine room equipment status monitoring device, electronic device, and computer-readable storage medium based on the React framework, which have the above-mentioned beneficial effects, and will not be elaborated here. Attached Figure Description

[0051] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0052] Figure 1 A flowchart illustrating a method for monitoring the status of ship engine room equipment based on the React framework, provided in this application embodiment;

[0053] Figure 2 A flowchart illustrating a method for drawing an engine room equipment diagram composed of programmable graphics, as provided in the embodiments of this application for monitoring the status of ship engine room equipment;

[0054] Figure 3 A flowchart illustrating a method for processing a binding relationship editing request initiated by a target programmable graphic in a ship engine room equipment status monitoring method provided in this application embodiment;

[0055] Figure 4-1 , Figure 4-2 and Figure 4-3 These are schematic diagrams provided in the embodiments of this application for describing programmable graphics components, drawing cabin equipment diagrams, and binding operating points;

[0056] Figure 5 This is a structural block diagram of a ship engine room equipment status monitoring device based on the React framework, provided in an embodiment of this application. Detailed Implementation

[0057] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0058] Please see Figure 1 , Figure 1 A flowchart for monitoring the status of ship engine room equipment based on the React framework, provided in this application embodiment, includes the following steps:

[0059] Step 101: Obtain a list of operating points for each piece of equipment installed in the engine room of the target vessel, which is the monitoring target.

[0060] This step aims to have an entity suitable for implementing the ship engine room equipment status monitoring method provided in this application (e.g., local or cloud-based equipment for data processing) obtain a list of operating points for each piece of equipment installed in the engine room of the target ship from the target ship's manufacturer or the equipment provider supplying the equipment to the target ship. Each piece of equipment may correspond to only one operating point, or it may correspond to multiple different operating points. Typically, each operating point corresponds to a specific sensor; therefore, this list of operating points effectively records the correspondence between each piece of engine room equipment and each operating point.

[0061] Step 102: Assign different working point numbers to different working points according to the register addresses of different sensors corresponding to each working point in the working point list;

[0062] Based on step 101, this step aims to assign different operating point numbers to each operating point by the aforementioned executing entity according to the different sensor register addresses in the operating point list.

[0063] This process typically includes the following steps:

[0064] Creating a list of operating points: First, you need to create a list of operating points, which includes detailed information about each operating point, such as the sensors involved and their register addresses. This list is usually a table or document containing a physical description of the operating point, sensor type, and relevant information about the register addresses.

[0065] Assign a unique number to each operating point: Each operating point needs to be assigned a unique operating point number. This number is usually an integer or a string used to identify the operating point. This can be any numbering system, as long as uniqueness is guaranteed;

[0066] Associating operating points with sensor register addresses: In the list of operating points, associate each operating point with its corresponding sensor register address. This is typically done by recording this information in columns of the list;

[0067] Create a mapping table: Create a mapping table that associates operating point numbers with sensor register addresses. This mapping table will be used in the system to quickly find the sensor register address corresponding to a specific operating point;

[0068] Programming Implementation: In data acquisition or control systems, programs or scripts need to be written to look up the corresponding sensor register address based on the operating point number. This typically involves associating the operating point number with register addresses in a mapping table to read or write data from the sensor.

[0069] To make it easier to understand, an example is given here:

[0070] Suppose there is an industrial automation system that needs to monitor different temperature sensors and read the register address of the corresponding sensor based on the operating point number. Here is an example:

[0071] Table 1. List of Operating Points:

[0072] Operating point description Sensor type Register address Raw material heating temperature Temperature sensor 0x1000 Reactor temperature Temperature sensor 0x2000 Cooling water temperature Temperature sensor 0x3000

[0073] Based on the different storage addresses, the working point numbers can be assigned in the following manner:

[0074] Raw material heating temperature: Operating point number 1, Reactor temperature: Operating point number 2, Cooling water temperature: Operating point number 3.

[0075] Then create a mapping table (see Table 2 below) to associate the operating point number with the sensor register address:

[0076] Table 2 Mapping Table

[0077]

[0078]

[0079] Within the system's program or control logic, the operating point number can be used to look up the corresponding sensor register address, and then the relevant data can be read or written. For example, to obtain the raw material heating temperature data, the system can look up the mapping table based on operating point number 1, find register address 0x1000, and then access that address to read the temperature data. This process allows the system to easily manage and monitor sensor data at different operating points, ensuring that each operating point has a unique identifier and can be accurately associated with the sensor register address.

[0080] Step 103: Extract the SVG graphics of each device pre-drawn for the engine room of the target ship from the configuration file uploaded to the React framework, convert each SVG graphics into each React functional component according to the JS script in the configuration file, and draw the engine room equipment diagram composed of multiple programmable graphics according to each React functional component.

[0081] Building upon step 102, this step aims to have the aforementioned executing entity extract a scalable vector graphics package from the configuration file uploaded to the React framework, and extract scalable vector graphics (i.e., SVG graphics) pre-drawn for each piece of equipment installed in the engine room of the target ship from the vector graphics package. Based on the JS script in the configuration file, each SVG graphic is converted into a React function component that is easy to programmatically process, and an engine room equipment diagram composed of multiple programmable graphics (i.e., React function components with programmable capabilities) is drawn based on each React function component.

[0082] The following sections will elaborate on the specific implementation processes described in this step.

[0083] 1. Configuration file parsing stage

[0084] This stage receives a structured configuration file (JSON / YAML) containing information about the ship's engine room equipment and parses the three core elements that the configuration file may contain: 1) SVG graphic resource library: stores the original SVG graphic data of each device; 2) Device topology relationship: defines the spatial location and connection relationship of the devices in the engine room; 3) JS conversion script: contains the conversion logic from SVG to React components.

[0085] 2. Graphic Conversion Stage

[0086] This stage involves dynamically loading a JS transformation script and executing the transformation functions within the script to parse static SVG code into a programmable DOM tree, injecting device state response mechanisms, and encapsulating each SVG graphic into a React functional component.

[0087] 3. Dynamic rendering stage

[0088] In this stage, a cabin layout container is generated based on the topology, and then the converted equipment components are mounted, which facilitates the establishment of a real-time data channel to connect equipment sensors.

[0089] In terms of componentization of SVG graphics, the technical principles include: 1) DOM tree conversion technology, which uses the DOMParser API to convert SVG strings into in-memory DOM, and then recursively traverses the SVG node tree to map XML elements to React.createElement calls; 2) Attribute dynamic processing technology, which identifies graphic attributes that need to be responsive (such as color / rotation angle), and then replaces static values ​​with dynamic variables passed in by props, so as to achieve the purpose of passing graphic styles through props.

[0090] In terms of the programmable graphics implementation mechanism, its technical principles include: 1) State-driven rendering technology, which listens to the device state in the component using useState / useEffect and triggers SVG attribute updates through state changes; 2) Interactive event bridging technology, which can bind React events to SVG elements and convert them to absolutely positioned styles; 3) Pipeline connection algorithm, which can parse the device connection graph and use D3.js to calculate the pipeline path.

[0091] To achieve the above objectives, the following key technologies can be used: 1) Configure a secure execution environment, such as creating a JS script sandbox environment, isolating the execution of transformation scripts through Web Workers, and restricting access to sensitive APIs; 2) Incremental update optimization, such as adding React.memo to each device component, redrawing only the affected components when the device state changes, and using requestAnimationFrame for throttling rendering; 3) Real-time data integration, such as establishing a WebSocket data channel and achieving unified management of device state.

[0092] It should be noted that in the React framework, the JS script used in conjunction with SVG graphics mainly undertakes core functions such as graphics loading, dynamic rendering, interactive control, and performance optimization. Especially in scenarios such as device monitoring data visualization, JS script can implement complex logic by manipulating the SVG DOM. Its advantages in this regard are the reason and starting point for choosing the React framework compared to the Vue framework in this application.

[0093] Step 104: According to the actual equipment status monitoring requirements, in the visual binding window provided by the operation interface that presents the engine room equipment diagram, establish the binding relationship between each programmable graphic in the engine room equipment diagram and each corresponding operating point number;

[0094] Based on step 103, in order to help operators quickly understand the equipment status, perform fault diagnosis and take necessary actions, this step aims to have the aforementioned executing entity establish the binding relationship between each programmable graphic in the engine room equipment diagram and its corresponding operating point number in the visual binding window provided by the operation interface that presents the engine room equipment diagram, according to the actual equipment status monitoring needs.

[0095] The following are the steps in detail for this process:

[0096] 1) First, the monitoring requirements need to be clearly defined. This may include determining the equipment parameters to be monitored, the operating point numbers, and the required operational and feedback information under different operating conditions. This is the basis for establishing binding relationships, as it determines what information needs to be displayed on the programmable graphic; 2) Prepare the programmable graphic: Use an SVG editing tool or a generated SVG file to prepare the cabin equipment diagram. Ensure that the diagram includes all the equipment to be monitored, along with their identification, location, and status; 3) Identify operating point numbers: Each target operating point should have a unique number or identifier. This can be a number, letter, or other symbol used to identify different operating conditions or statuses. These identifiers are typically associated with the database or configuration file of the equipment status monitoring system; 4) Establish a binding window: Create a visual binding window on the user interface, which is the area where the user interacts with the cabin equipment diagram. This window typically includes the following components: Equipment graphic: Displays the programmable graphic representing the equipment in the cabin; Operating point number list: Lists the numbers of all target operating points for the user to select; Status display area: Displays status information related to the selected operating point; Establish binding relationships: In the binding window, establish the binding relationship between the programmable graphic and the operating point number. This typically involves the following steps: the user selects a condition point number; the user clicks or drags the selected condition point number to the associated programmable graphic; and the condition point number or status information is displayed on the programmable graphic, such as an arrow, text, or color change. For each device, the above steps are repeated to bind the condition point number to the associated programmable graphic.

[0097] Finally, once the binding relationship is established, it is usually necessary to ensure that status information can be promptly reflected in the binding window. This can be achieved through data communication with the monitoring system. When the device status changes, the corresponding programmable graphics should be updated in a timely manner to reflect these changes, such as changing colors or displaying alarms. This can be achieved by changing the graphic style according to preset graphic style change conditions. This can be implemented through the JS scripts included in the configuration files used by the React framework. For example, when the JS script converts each SVG image into a React functional component, it can specifically convert it into a React functional component that supports passing styles via props. Thus, the relevant information recorded in the JS script can be used to pass various graphic styles that are expected to be displayed via props.

[0098] It also allows users to interact with the device through the binding window, such as clicking on the device graphic to view more details, execute control commands, or view historical data. Ensure the user interface is user-friendly and easy to use. After establishing the binding relationship, conduct testing and verification to ensure everything works correctly. Simulate different operating conditions to check whether relevant information is displayed correctly and user actions are responded to.

[0099] Step 105: In response to the successful establishment of the binding relationship, obtain the real-time running status data of the corresponding working point pushed by the Redis database based on the WebSocket protocol, and display the real-time running status data in the corresponding position of the corresponding programmable graphic in the cabin equipment diagram according to the rendering display logic in the JS script;

[0100] Based on step 104, this step aims to have the aforementioned executing entity obtain the real-time operating status data of the corresponding working points pushed by the Redis database based on the WebSocket protocol after the binding relationship is successfully established, and display the real-time operating status data at the corresponding position of the corresponding programmable graphic in the cabin equipment diagram according to the rendering display logic in the JS script.

[0101] WebSocket is a bidirectional communication protocol well-suited for real-time data transmission in monitoring systems. When a user logs in or the monitoring system starts, a WebSocket connection is established with the front-end interface to the WebSocket server. On the WebSocket server, a listener is set up to subscribe to data updates from the Redis database. When new data becomes available, Redis pushes the data to the WebSocket server. To ensure that the Redis database can promptly obtain real-time operational status data from the operational points, Redis's publish / subscribe mechanism can be used. Once the WebSocket server receives the data push from Redis, it broadcasts this data to all connected front-end clients, including the interface displaying the cabin equipment diagram. Simultaneously, on the front-end, after the WebSocket connection receives the data, JavaScript code parses the data and matches it with the corresponding operational point number. Once a match is found, the data is updated to the corresponding position in the SVG graphic. This can be achieved by updating text labels, changing colors, and displaying alarms.

[0102] In addition, real-time operating status data of each working point collected by sensors are written to the Redis database via a distributed publish / subscribe messaging system (such as Kafka).

[0103] In addition to recording information related to converting SVG graphics into functional components, the JavaScript script can further record the rendering and display logic of how the React functional component acts as a programmable graphic. This includes details such as whether there are specific display animations, display methods for different data values, and graphic styles. One specific implementation could be: displaying real-time running status data at the corresponding positions of the programmable graphics in the cabin equipment diagram according to the rendering logic in the JavaScript script, and presenting corresponding animation effects at those positions, such as data value increment animations or data flow animations.

[0104] The React-based method for monitoring the status of ship engine room equipment provided in this application first obtains a list of operating points for each piece of equipment installed in the ship's engine room and determines different operating point numbers based on the corresponding sensor register addresses. Then, based on the React framework, it retrieves scalable vector graphics corresponding to each piece of equipment from the configuration file and uses the JS script in the configuration file to convert them into React function components that are easy to program. Based on each React function component, it draws an engine room equipment diagram composed of multiple programmable graphics. Next, through the visual binding window provided in the operation interface, it establishes a binding relationship between each vector graphic and each target operating point number according to the actual equipment status monitoring requirements. When the binding relationship is successfully established, it can obtain the actual operating status data of the corresponding operating points pushed from the Redis database via the WebSocket protocol, so as to present it in the corresponding position of the corresponding programmable graphics according to the rendering display logic recorded in the JS in the configuration file for easy viewing and monitoring by the user.

[0105] Compared to existing technologies, the technical means provided in this embodiment, with the help of the capabilities provided by the React framework, changes the process of establishing the binding relationship between the graphical cabin equipment and the corresponding operating point data from the conventional method of directly hard-writing in the background running code to a method in which boundary objects can be directly set and adjusted by themselves through the visual operation interface provided by the front end. Therefore, it reduces the difficulty of development and subsequent operation and maintenance, making the deployment of the status monitoring system on the ship more convenient.

[0106] Based on the above embodiments, corresponding operating status parameter thresholds can be pre-set for each programmable graphic in the cabin equipment diagram. When the actual operating status parameters of the real-time motion status data presented by the programmable graphic exceed the corresponding operating status parameter thresholds, an abnormal alarm can be issued through a preset path. The preset path includes at least one of the following: interface pop-up, SMS, email, sound / light alarm, and graphic style of the programmable graphic, so as to achieve effective feedback of abnormal alarms through multiple channels.

[0107] One specific method for presenting anomaly alerts by adjusting the graphic style of a programmable graphic can be as follows: For a target programmable graphic that exhibits real-time operating status parameters exceeding the corresponding status parameter threshold, the abnormal graphic style and style change rules recorded for the target programmable graphic in the JS script are used. When it is determined that the style change rules are met because the real-time operating status parameters exceed the corresponding status parameter threshold, the original graphic style of the target programmable graphic is adjusted to the abnormal graphic style, thereby achieving anomaly alerts at the visualization level through the adjustment of the graphic style.

[0108] To deepen the understanding of how the cabin equipment diagram is constructed, this embodiment uses... Figure 2 A flowchart is provided for a method of drawing a cabin equipment diagram composed of programmable graphics, specifically including the following steps:

[0109] Step 201: Extract the SVG graphics package from the configuration file uploaded to the React framework from the configuration object;

[0110] This step aims to extract the SVG graphics package from the configuration file uploaded to the React framework by the aforementioned execution entity. The configuration file typically contains at least two parts: the SVG graphics package and the JS script. This step aims to extract the SVG graphics package from the configuration file first.

[0111] Step 202: Filter out the target SVG graphics corresponding to each piece of equipment installed in the engine room of the target ship from the SVG graphics package;

[0112] Building upon step 201, this step aims to have the aforementioned executing entity select target SVG graphics from the SVG graphics package that correspond to the various devices installed in the engine room of the target vessel.

[0113] The first step involves data acquisition and information gathering for the equipment within the engine room. This may include obtaining information from ship design drawings, equipment manuals, sensor data, or on-site inspections. This information includes the type, location, size, connection method, and status of the equipment. Then, target SVG graphics corresponding to each piece of equipment installed in the engine room of the target ship are selected from all available SVG graphic packages.

[0114] Step 203: Extract the JS script from the configuration file, and convert each target SVG graphic into a React functional component that supports style passing through Props by executing the pre-written code logic in the JS script;

[0115] Building upon step 202, this step aims to have the aforementioned execution entity further extract JS scripts from the configuration file and convert each target SVG graphic into a React functional component that supports Props (properties, a way to pass data between components. They are passed from parent components to child components, allowing child components to receive and use data from parent components) by executing the pre-written code logic in the JS scripts.

[0116] Furthermore, the graphical styles of each React functional component can be adjusted as needed using the following methods:

[0117] First, extract the new JS script from the new configuration file uploaded to the React framework from the configuration object. Then, adjust the graphic style of the programmable graphics in the cabin equipment diagram, which are acted by each React functional component, according to the graphic style recorded in the new JS script. That is, the graphic style adjustment is achieved by passing styles through Props.

[0118] Step 204: From the component library composed of various React functional components, move the component to the target position on the canvas according to the drag operation passed in by the editing object to obtain the cabin equipment diagram composed of multiple programmable graphics.

[0119] Building upon step 203, this step aims to have the aforementioned execution entity move components from the component library comprised of various React functional components to the target position on the canvas according to the drag-and-drop operation passed in by the editing object, thereby obtaining a cabin equipment diagram composed of multiple programmable graphics. In other words, by providing users with a customizable icon drag-and-drop function, users can arrange the positional relationships of each graphic on the canvas themselves.

[0120] Furthermore, considering the positional relationships between user-defined graphic components, and the fact that the operational precision dimension does not match the actual situation well, this step will also correct the current relative positional relationship of each programmable graphic component in the cabin equipment diagram according to the corresponding target position, based on the actual relative positional relationship of the corresponding equipment installed in the cabin. This will make the corrected positional relationship more in line with the actual situation, and ensure that the adjusted programmable graphics present the correct connection and data communication relationships between the devices.

[0121] To deepen the understanding of how to construct and adjust the binding relationship, Figure 3 A flowchart of a method for processing a binding relationship editing request initiated by a target programmable graphics, provided in an embodiment of this application, specifically includes the following steps:

[0122] Step 301: Based on the received binding relationship editing request initiated by the target programmable graphic in the engine room equipment diagram, determine whether the target programmable graphic is bound to the original working point number;

[0123] Step 302: In response to the target programmable graphic being bound to the original working point number, a binding relationship adjustment window that contains both the original working point number and the new working point number pops up;

[0124] Step 303: In response to the fact that the target programmable graphic is not bound to the original working point number, a window for establishing a binding relationship containing only the working point number pops up.

[0125] When a binding relationship editing request is received, the system first determines whether the target programmable graphic has already been bound to the original working point number. If it has, then step 302 pops up a binding relationship adjustment window for the user, which includes both the original working point number and the new working point number, so that the user can clearly see the original working point number and the new working point number to be adjusted in the binding relationship adjustment window. If no binding relationship has been established, then step 303 pops up a binding relationship establishment window for the user, which only includes the working point number, so that the user only needs to fill in the working point number to complete the establishment of the first binding relationship.

[0126] To enhance understanding of the overall solution, this application also provides a complete and specific implementation scheme through the following embodiments:

[0127] Figure 4-1 , Figure 4-2 and Figure 4-3 These are schematic diagrams provided in the embodiments of this application for describing SVG graphic components, drawing machine equipment diagrams, and binding operating points.

[0128] The intelligent engine room can comprehensively utilize various information and data obtained from condition monitoring to perform timely maintenance and processing of equipment and systems within the engine room. This embodiment first obtains information and data about various equipment components collected by onboard sensors from the manufacturer or supplier of the ship's engine room equipment. This includes the name and type of the component's operating point (some points are alarm information to indicate whether a specific part of the equipment is alarming, while others simply display the detection value of a specific device, such as the main propulsion diesel engine speed), and the range of minimum and maximum values. Some of these values ​​need to be displayed in the corresponding positions on the engine room equipment SVG diagram, and need to change in real time based on the collected values. Information that the crew or shipowner wants to be aware of is displayed on the page to monitor changes in equipment information in a timely manner.

[0129] Next, the developers will collect the basic graphics of the cabin equipment SVG diagrams, combine them into the required cabin equipment SVG diagrams through custom drag-and-drop methods, and then bind equipment condition point IDs to the areas in the diagrams where equipment data needs to be displayed through clicking methods. These IDs are used to retrieve the collected data. The specific process execution principle is as follows:

[0130] Step 1: Obtain a list of equipment component operating points from the equipment manufacturer, assign operating point numbers according to sensor register addresses, and the developers will write the collected operating point data to Redis via Kafka and then push it into WebSocket.

[0131] Step 2: The front-end is developed using the React framework to create a web-based graphical configuration system. It utilizes SVG graphics to build a primitive library, and uploads the SVG and a JS file that drives changes in the monitoring points. For example, the ZIP package shown below contains an SVG file of a rectangle and a JS file (the function of this JS file can be modified according to different requirements). Figure 4-1 In the example, the values ​​inside the checkbox bound to the monitoring point are dynamically changed by JS. After uploading, both the SVG file and the JS file are saved in the database and generated in the component library on the left.

[0132] Step 3: Generate the desired ship engine room diagram by dragging and dropping SVG graphics online. (See also...) Figure 4-2 ;

[0133] Step 4: Bind the work point number of the corresponding location data by clicking the pop-up window. Write this number as the ID attribute value of the DOM into the SVG DOM structure, save the SVG image to the database, and save the work point configured in this component to the database (see [link to documentation]). Figure 4-3 );

[0134] Step 5: Real-time data publishing and acquisition: A middleware service was written using Node.js to connect to Redis, read data from Redis and push it to WebSocket, and the front end retrieves the data from WebSocket in real time;

[0135] If you need to change the content of the cabin equipment diagram, such as its location, size, or other related attributes, you can directly click on the diagram and use the mouse to drag, zoom in, and zoom out. If you need to change other related attributes such as font color, font size, or background color, you can click on the diagram, and the component for changing attributes will appear on the right. You can then change it to the desired value.

[0136] Step 6: Obtain the corresponding cabin SVG diagram, JS file, and operating point configuration from the file server. The JS file manipulates the SVG DOM structure according to the operating point configuration, enabling it to dynamically and in real-time obtain cabin data from WebSocket and modify it as needed. The SVG DOM structure is only manipulated when a certain monitoring point changes, saving browser resources, avoiding memory consumption, page lag, and affecting user experience.

[0137] Step 7: If you need to change the cabin condition number, you can start from step 3 again;

[0138] Step 8: This function can continuously expand the SVG primitive library by uploading SVG and JS to enrich the configuration and add different cabin equipment images. It can combine more cabin equipment images without changing the code or redeploying, thereby achieving the purpose of monitoring equipment data. Repeat from step 2.

[0139] The solution provided in this embodiment allows for the generation of engine room equipment diagrams through custom drag-and-drop configuration, and the binding of corresponding operating points to the diagrams for real-time monitoring of equipment values. Furthermore, it enables dynamic updates of application logic without the need to release new versions. This is particularly relevant for shipboard applications, where ocean-going vessels often face situations without network connectivity. In such cases, it reduces maintenance time costs and minimizes network costs associated with limited onboard bandwidth for code transmission. In essence, the core invention of this embodiment is the ability to generate engine room equipment diagrams through configuration and dynamically display engine room data and update application logic in real time without deploying new versions of code.

[0140] Due to the complexity of the situation, it is impossible to list and elaborate on them all. Those skilled in the art should realize that there are many examples based on the basic method principles provided in this application and in combination with actual situations. Without sufficient creative effort, they should all be within the protection scope of this application.

[0141] Please see below. Figure 5 , Figure 5 This application provides a structural block diagram of a ship engine room equipment status monitoring device 500 based on the React framework. This embodiment is a device embodiment corresponding to the above method embodiment. The ship engine room equipment status monitoring device 500 based on the React framework may include:

[0142] The operating condition point list acquisition unit 501 is configured to acquire the operating condition point list of each piece of equipment installed in the engine room of the target ship, which is the monitoring target.

[0143] The working point numbering unit 502 is configured to assign different working point numbers to different working points according to the register addresses of different sensors corresponding to each working point in the working point list.

[0144] The engine room equipment diagram generation unit 503 is configured to extract each SVG graphic pre-drawn for each piece of equipment installed in the engine room of the target ship from the configuration file uploaded to the React framework, convert each SVG graphic into each React functional component according to the JS script in the configuration file, and draw an engine room equipment diagram composed of multiple programmable graphics according to each React functional component.

[0145] The binding relationship establishment unit 504 is configured to establish a binding relationship between each programmable graphic in the engine room equipment diagram and its corresponding operating point number in the visual binding window provided by the operation interface that presents the engine room equipment diagram, according to the actual equipment status monitoring requirements.

[0146] The real-time operation status data acquisition and presentation unit 505 is configured to, in response to the successful establishment of the binding relationship, acquire the real-time operation status data of the corresponding working point pushed by the Redis database based on the WebSocket protocol, and display the real-time operation status data at the corresponding position of the corresponding programmable graphic in the cabin equipment diagram according to the rendering display logic in the JS script.

[0147] In some other optional implementations of this embodiment, the cabin equipment drawing generation unit 503 can be further configured to:

[0148] Extract the SVG graphics package from the configuration file uploaded to the React framework from the configuration object;

[0149] Filter out the target SVG graphics corresponding to each piece of equipment installed in the engine room of the target ship from the SVG graphics package;

[0150] Extract the JS script from the configuration file, and convert each target SVG graphic into a React functional component that supports Props style passing by executing the pre-written code logic in the JS script;

[0151] From the component library composed of various React functional components, move the component to the target position on the canvas according to the drag operation passed in by the editing object, and obtain the cabin equipment diagram composed of multiple programmable graphics.

[0152] In some other optional implementations of this embodiment, the ship engine room equipment status monitoring device 500 based on the React framework may further include:

[0153] The new JS script extraction unit is configured to extract new JS scripts from the new configuration file uploaded to the React framework from the configuration object;

[0154] The graphic style adjustment unit is configured to adjust the graphic style of the programmable graphics in the cabin equipment diagram, which are each acted by a React functional component, according to the graphic style recorded in the new JS script; wherein, the graphic style adjustment is achieved by passing styles through Props.

[0155] In some other optional implementations of this embodiment, the real-time operation status data acquisition and presentation unit 505 may include a rendering display subunit configured to display the real-time operation status data at the corresponding position of the corresponding programmable graphic in the cabin equipment diagram according to the rendering display logic in the JS script. The rendering display subunit may be further configured to:

[0156] The real-time operating status data is displayed in the corresponding programmable graphic position in the cabin equipment diagram according to the rendering logic in the JS script, and the corresponding animation effect is presented in the corresponding position.

[0157] In some other optional implementations of this embodiment, the ship engine room equipment status monitoring device 500 based on the React framework may further include:

[0158] The threshold setting unit is configured to pre-set the corresponding operating status parameter thresholds for each programmable graphic in the engine room equipment diagram.

[0159] The alarm sending unit is configured to issue an abnormal alarm through a preset path in response to the actual running status parameters of the real-time motion status data presented by the programmable graphics exceeding the corresponding running status parameter threshold; wherein the preset path includes at least one of the following: interface pop-up window, SMS, email, sound / light alarm, and graphic style of programmable graphics.

[0160] In some other optional implementations of this embodiment, the alarm sending unit can be further configured to:

[0161] In response to the preset path including the graphic style of the programmable graphic, for the target programmable graphic that presents real-time running status parameters that exceed the corresponding status parameter threshold, the abnormal graphic style and style change rules recorded for the target programmable graphic in the JS script are used. If it is determined that the style change rules are met, the original graphic style of the target programmable graphic is adjusted to the abnormal graphic style.

[0162] In some other optional implementations of this embodiment, the ship engine room equipment status monitoring device 500 based on the React framework may further include:

[0163] The edit request processing unit is configured to determine whether the target programmable graphic is bound to an original working point number based on the received editing request for the binding relationship initiated by the target programmable graphic in the cabin equipment diagram.

[0164] The binding relationship adjustment unit is configured to pop up a binding relationship adjustment window that simultaneously contains the original operating point number and the new operating point number in response to the target programmable graphic being bound to the original operating point number.

[0165] This embodiment exists as a device embodiment corresponding to the above method embodiment.

[0166] The ship engine room equipment status monitoring device based on the React framework provided in this embodiment

[0167] First, a list of operating points for each piece of equipment installed in the ship's engine room is obtained, and different operating point numbers are determined based on the corresponding sensor register addresses. Then, based on the React framework, scalable vector graphics corresponding to each piece of equipment are obtained from the configuration file, and the JS scripts in the configuration file are used to convert them into React function components that are easy to program. Based on each React function component, an engine room equipment diagram composed of multiple programmable graphics is drawn. Next, through the visual binding window provided by the operation interface, according to the actual equipment status monitoring requirements, the binding relationship between each vector graphic and each target operating point number is established. When the binding relationship is successfully established, the actual operating status data of the corresponding operating point pushed from the Redis database can be obtained through the WebSocket protocol, so that it can be presented in the corresponding position of the corresponding programmable graphics according to the rendering display logic recorded in the JS in the configuration file, so that it can be viewed and monitored by the user. Compared to existing technologies, the solution provided in this embodiment leverages the capabilities of the React framework to change the process of establishing the binding relationship between graphical cabin equipment and corresponding operating point data with the help of configuration files. This change is from the conventional method of directly hard-coding the data in the background running code to a method where boundary objects can be set and adjusted directly through the visual operation interface provided by the front end. This reduces the difficulty of development and subsequent operation and maintenance, making the deployment of the status monitoring system on the ship more convenient.

[0168] Based on the above embodiments, this application also provides an electronic device, which may include a memory and a processor. The memory stores a computer program, and when the processor calls the computer program in the memory, it can implement the steps provided in the above embodiments. Of course, the electronic device may also include various necessary network interfaces, a power supply, and other components.

[0169] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by an execution terminal or processor, can perform the steps provided in the above embodiments. The storage medium may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0170] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0171] Those skilled in the art will further 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, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. 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.

[0172] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this application. For those skilled in the art, various improvements and modifications can be made to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

[0173] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

Claims

1. A method for monitoring the state of a marine engine room equipment based on a React framework, characterized by, The method comprises the following steps: acquiring a list of working points of each device installed in the engine room of a target ship as a monitoring target; assigning different working point numbers to different working points according to the register addresses of different sensors corresponding to each working point in the list of working points; extracting each SVG graph drawn in advance for each device installed in the engine room of the target ship from a configuration file uploaded to a React framework, converting each SVG graph into each React function component according to a JS script in the configuration file, and drawing the engine room device graph composed of a plurality of programmable graphs according to each React function component; establishing a binding relationship between each programmable graph in the engine room device graph and each corresponding working point number in a visual binding window provided by an operation interface presenting the engine room device graph according to actual device state monitoring requirements; in response to successful establishment of the binding relationship, acquiring real-time running state data of the corresponding working point pushed by a Redis database based on a WebSocket protocol, and displaying the real-time running state data in the corresponding position of the corresponding programmable graph in the engine room device graph according to the rendering display logic in the JS script.

2. The method of claim 1, wherein, The method of extracting each SVG graph drawn in advance for each device installed in the engine room of the target ship from a configuration file uploaded to a React framework, converting each SVG image into each React function component according to a JS script in the configuration file, and drawing the engine room device graph composed of a plurality of programmable graphs according to each React function component comprises the following steps: extracting an SVG graph package from a configuration object uploaded to the configuration file of the React framework; screening each target SVG graph corresponding to each device installed in the engine room of the target ship from the SVG graph package; extracting the JS script from the configuration file, and converting each target SVG graph into each React function component supporting a Props transmission style by executing the code logic written in advance in the JS script; moving each React function component to the target position on the canvas according to the drag operation of the editing object to obtain the engine room device graph composed of a plurality of programmable graphs.

3. The method of claim 2, wherein, The method further comprises the following steps: extracting a new JS script from a new configuration file uploaded to the React framework from the configuration object; adjusting the graph style of the programmable graph acted by each React function component in the engine room device graph according to the graph style recorded in the new JS script; wherein the adjustment of the graph style is realized through the Props transmission style.

4. The method of claim 2, wherein, The method of displaying the real-time running state data in the corresponding position of the corresponding programmable graph in the engine room device graph according to the rendering display logic in the JS script comprises the following steps: displaying the real-time running state data in the corresponding position of the corresponding programmable graph in the engine room device graph according to the rendering display logic in the JS script, and presenting a corresponding animation effect in the corresponding position.

5. The method of claim 1, wherein, The method further comprises the following steps: Pre-set corresponding operating state parameter thresholds for each of the programmable graphics in the engine room equipment diagram; In response to actual operating state parameters of real-time motion state data presented by the programmable graphics exceeding corresponding operating state parameter thresholds, issue an abnormality alarm through a pre-set path; wherein the pre-set path includes at least one of an interface pop-up window, a short message, an email, a sound / light alarm and a graphic style of the programmable graphics.

6. The method of claim 5, wherein, The response to actual operating state parameters of real-time motion state data presented by the programmable graphics exceeding corresponding operating state parameter thresholds, and the issuance of an abnormality alarm through a pre-set path, include: In response to the pre-set path including a graphic style of the programmable graphics, for a target programmable graphic presenting real-time operating state parameters exceeding corresponding state parameter thresholds, using an abnormality graphic style and a style changing rule recorded in the JS script for the target programmable graphic, adjust the original graphic style of the target programmable graphic to display as the abnormality graphic style upon determining that the style changing rule is met.

7. The method according to any one of claims 1 to 6, characterized in that, Further include: According to the received binding relationship editing request initiated for a target programmable graphic in the engine room equipment diagram, determine whether the target programmable graphic is bound with an original working condition point number; In response to the target programmable graphic being bound with the original working condition point number, pop up a binding relationship adjustment window containing both the original working condition point number and a new working condition point number.

8. A ship engine room equipment state monitoring device based on a React framework, characterized by, Include: A working condition point list acquisition unit configured to acquire a working condition point list of each device installed in an engine room of a target ship as a monitoring target; A working condition point number assigning unit configured to assign different working condition point numbers to different working condition points according to register addresses of different sensors corresponding to each working condition point in the working condition point list; An engine room equipment diagram generation unit configured to extract each SVG graphic pre-drawn for each device installed in the engine room of the target ship from a configuration file uploaded to a React framework, and convert each SVG graphic into each React function component according to a JS script in the configuration file, and draw an engine room equipment diagram composed of multiple programmable graphics according to each React function component; A binding relationship establishing unit configured to establish a binding relationship between each programmable graphic in the engine room equipment diagram and each corresponding working condition point number in a visual binding window provided by an operation interface presenting the engine room equipment diagram according to actual device state monitoring requirements; A real-time operating state data acquisition and presentation unit configured to, in response to the binding relationship being successfully established, acquire real-time operating state data of corresponding working condition points pushed by a Redis database based on a WebSocket protocol, and display the real-time operating state data in corresponding positions of corresponding programmable graphics in the engine room equipment diagram according to rendering display logic in the JS script.

9. An electronic device, comprising: Include: A memory for a computer program; A processor for implementing the steps of the React framework-based ship engine room equipment state monitoring method according to any one of claims 1 to 7 when executing a computer program stored on the memory.

10. A readable storage medium, characterized by, A computer program stored on the readable storage medium, which, when executed by a processor, can implement the steps of the React framework-based ship engine room equipment state monitoring method according to any one of claims 1 to 7.

Images