A ship monitoring system and a ship failure alarm method

Abstract

The present application relates to ship monitoring technology, in particular to a kind of ship monitoring system and ship fault alarm method.The ship monitoring system includes sequentially communicatively connected data acquisition layer, data management layer, business logic layer and user page layer;Data acquisition layer is used to obtain the monitoring data of each detection component in ship hardware device in real time and upload to data management layer;Data management layer is used to manage monitoring data, business logic layer at least includes energy efficiency index calculation unit, fault diagnosis unit;Energy index calculation unit is used to analyze the energy consumption of each ship hardware device according to monitoring data, and provides the suggestion of energy efficiency optimization strategy;Fault diagnosis unit is used to analyze the condition of each ship hardware device according to monitoring data and diagnose whether fault;User page layer is used to provide visual interactive interface.Through the above setting, the hierarchical division of system is effectively realized, and it is conducive to the flexibility and scalability of system.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of ship monitoring, in particular to a ship monitoring system and a ship fault alarm method. BACKGROUND

[0002] In the current shipping field, intelligentization and digitization have become the mainstream trend of development. The ship intelligent system can significantly improve the operation efficiency and safety of the ship through real-time monitoring, data analysis and automatic control.

[0003] However, the existing technology faces some challenges: first, the customization of ship projects and the closedness of software systems limit the data sharing and software portability between different projects. The software specially customized for a specific ship project generally lacks universality and is difficult to share and reuse in different projects, which leads to waste of resources and repeated development. Secondly, the diverse communication protocols and data transmission methods in the ship system make it difficult for the system to adapt to changes in hardware configuration. Thirdly, the existing system mostly adopts a single-layer software structure, which makes it difficult for the numerous subsystems in the ship monitoring system to share and interact with data. Therefore, the current existing technology has obvious deficiencies in dealing with the diversified needs of ship projects and improving the flexibility of the system, and it is difficult to meet the long-term development needs of ship project intelligentization and digitization. SUMMARY

[0004] In view of at least one deficiency of the above-mentioned existing technology in lacking adaptability to the diversity and rapid change of software requirements of ship intelligent systems, the present application aims to provide a ship monitoring system that improves the portability and flexibility of software through software layered design, modularization division and standardization of module basic functions, so that software modules can be quickly transplanted and reused in different ship projects, reducing development cost and time.

[0005] In a first aspect, the present application provides a ship monitoring system, comprising at least a data acquisition layer, a data management layer, a business logic layer and a user page layer connected in sequence in communication;

[0006] The data acquisition layer is used to acquire monitoring data of each detection component in the ship hardware device in real time and upload it to the data management layer;

[0007] The data management layer is used to store, read and backup the monitoring data uploaded by the data acquisition layer, and also used to provide the monitoring data required for calculation to the business logic layer and receive and store the result data and fault information processed by the business logic layer, so that different modules in the business logic layer can access the result data through the data management layer;

[0008] The business logic layer is used to obtain the monitoring data stored in the data management layer, and then perform calculation and analysis and provide auxiliary decision-making; the business logic layer at least includes an energy efficiency index calculation unit and a fault diagnosis unit; the energy efficiency index calculation unit includes a plurality of calculation modules for analyzing the energy consumption of each ship hardware device according to the monitoring data and providing suggestions for energy efficiency optimization strategies; the fault diagnosis unit includes a plurality of diagnosis modules for analyzing the condition of each ship hardware device according to the monitoring data and diagnosing whether it is faulty.

[0009] The user page layer is used to provide a visual interactive interface for human-computer interaction with the ship monitoring system.

[0010] In an embodiment, the data acquisition layer at least includes a CAN server, a serial port server, a high-frequency signal collector and a low-frequency signal collector which are directly or indirectly connected with each detection component in the ship hardware device through a communication protocol, so as to obtain the monitoring data of the detection component in real time and convert the monitoring data from a physical parameter into a digital signal.

[0011] In an embodiment, the data acquisition layer further includes a data processor, and the data processor at least includes any one or more of a data acquisition module, a data analysis module, a data preprocessing module and a data uploading module; the data acquisition module is used to obtain the monitoring data and verify the accuracy and integrity of the monitoring data; the data analysis module is used to analyze the monitoring data in different formats or protocols into a data format that can be processed by the system; the data preprocessing module is used to preprocess the monitoring data, including at least one of data filtering, data smoothing and outlier detection; the data uploading module is used to match the processed monitoring data with the monitoring parameter code and upload it to the data management layer; the monitoring parameter code is a unique identification code for each type of monitoring data.

[0012] In an embodiment, the data management layer at least includes a centralized data management platform for centralized management of monitoring data and control of access rights; the centralized data management platform is designed based on a service-oriented architecture and runs as a server, and is connected with the business logic layer and the data acquisition layer through an HTTP protocol, and uses a JSON data format as a standard format for data exchange; the centralized data management platform also has a number of standardized interfaces to provide data exchange functions with other layers and modules.

[0013] In an embodiment, the data management layer further includes a database for storing result data and fault information, and also for storing and managing configuration information of the business logic layer and the data acquisition layer.

[0014] The database is at least configured with a data coding table module, a fault coding table module, a storage rule module, and a data access rule configuration module. The data coding table module is used to define and store coding standards and mapping relationships of various types of monitoring data and monitoring parameter coding. The fault coding table module is used to define and store coding standards and mapping relationships of various types of fault information and fault codes. The storage rule module is used to set rules of storage formats, encryption methods, storage locations, and storage periods of monitoring data. The data access rule configuration module is used to set data access permissions, access frequency limits, and data access ranges of each module.

[0015] In an embodiment, the storage period includes at least one of the following rules: determining different storage period rules according to different types of monitoring data; shortening the storage period of monitoring data of a device when a fault of the device is detected according to associated fault information; and shortening the storage period of a type of monitoring data when the type of monitoring data is in a preset high-frequency change according to the working condition requirements of each ship hardware device.

[0016] In an embodiment, the data management layer further configures a buffer area with a locking mechanism for each type of monitoring data, and the buffer area is used to record and temporarily store monitoring data. The database regularly stores data in the buffer area into the database according to the storage rules of the storage rule module.

[0017] When the data management layer receives a request to submit monitoring data, the data access rule configuration module verifies whether the request meets the preset access rule. If the verification is passed, the monitoring data in the buffer area is updated according to the request. When the data management layer receives a request to obtain monitoring data, the data access rule configuration module also verifies whether the request meets the preset access rule. If the verification is passed, the monitoring data is read from the buffer area according to the request and the monitoring data is responded.

[0018] In an embodiment, the database further includes a configuration file management module for managing configuration information of newly added function modules in the business logic layer and the data acquisition layer. The configuration file management module updates the contents of the data coding table module, the fault coding table module, the storage rule module, and the data access rule configuration module according to the configuration information of the newly added function modules in the business logic layer and the data acquisition layer, and automatically deploys the newly added function modules in the business logic layer and the data acquisition layer based on the configuration information.

[0019] In an embodiment, the specific steps of adding a function module to the business logic layer are as follows: determining a unique identification code for the newly added function module and a unique data code for the newly added monitoring data of the newly added function module, the specific position of the data code being used to identify a monitoring position; completing related configurations of the newly added function module in the database based on the identification code and the newly added data code; and automatically deploying the newly added function module on the business logic layer based on the related configurations of the newly added monitoring data in the database.

[0020] The specific steps of adding a function module to the data collection layer are: determining a unique identification code for the added function module and determining a unique data code for the added monitoring data of the added function module, the specific position of the data code being used to identify the monitoring position; completing the configuration of the added monitoring data in the database based on the identification code and the added data code; automatically deploying the added function module on the data collection layer based on the configuration information; the configuration of the added monitoring data in the database at least includes the following information: the association between the added monitoring data and the fault information, the byte length required by the added monitoring data, the storage rule of the added monitoring data, and the identification code of the detection component from which the added monitoring data is derived.

[0021] In a second aspect, the present application also provides a ship fault alarm method, which adopts the ship monitoring system according to any one of the above embodiments, and includes the following steps:

[0022] A data collection step, in which the data collection layer acquires the monitoring data of each detection component in the ship hardware device in real time and uploads the monitoring data to the data management layer;

[0023] A data management step, in which the data management layer stores the uploaded monitoring data;

[0024] A logical judgment step, in which the fault diagnosis unit of the business logic layer sends a request for obtaining relevant monitoring data to the data management layer, and analyzes and diagnoses based on the relevant monitoring data obtained based on the request; if a fault occurs in the diagnosis, the fault information is submitted to the data management layer;

[0025] An alarm step, in which the user page layer visually displays the fault information and the relevant monitoring data.

[0026] Based on the above, compared with the prior art, the ship monitoring system provided by the present application effectively realizes the hierarchical division of the system through the design of the data collection layer, the data management layer, the business logic layer and the user page layer; and only data transmission exists between each layer and the layer, without process coupling, which facilitates the addition, collection and data sharing of various modules, devices, protocols, business functions and fault types in the ship system, is beneficial to the flexibility and scalability of the system, and enables the software modules at different levels to be independently developed, tested, deployed and migrated.

[0027] Other features and advantages of the present application will be set forth in the following description, and in part will become apparent to those skilled in the art from the description, or can be learned by practice of the present application. The objects and other advantages of the present application can be realized and achieved by the structure specifically pointed out in the specification, claims and drawings. BRIEF DESCRIPTION OF DRAWINGS

[0028] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained from these drawings without creative labor; in the following description, the positional relationship described in the drawings is the direction of the components drawn in the drawings as the reference, unless otherwise specified.

[0029] Figure 1 The structural block diagram of the ship monitoring system provided by an embodiment of the present application is shown in the figure.

[0030] Figure 2 The structural block diagram of the ship monitoring system provided by another embodiment of the present application is shown in the figure.

[0031] Figure 3 The step flow chart of the ship fault alarm method provided by an embodiment of the present application is shown in the figure. DETAILED DESCRIPTION

[0032] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the following will combine the drawings in the embodiments of the present application to make a clear and complete description of the technical solutions in the embodiments of the present application. Obviously, the described embodiments are some embodiments of the present application, not all the embodiments; the technical features designed in different embodiments of the present application can be combined with each other as long as there is no conflict; based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the protection scope of the present application.

[0033] In the description of the present application, it should be noted that all the terms (including technical terms and scientific terms) used in the present application have the same meaning as that generally understood by those skilled in the art to which the present application belongs, and should not be understood as a limitation of the present application; it should be further understood that the terms used in the present application should be understood as having the same meaning as the terms in the context of the present application and the related field, and should not be understood in an idealized or overly formal sense, unless otherwise defined in the present application.

[0034] To solve the problem of lack of adaptability of the prior art to the diversity of ship monitoring systems and rapidly changing software requirements, the present application provides a ship monitoring system and a ship fault alarm method. Through software layering design, modular division and standardization of module basic functions, the software portability and flexibility are improved, so that the software modules can be quickly transplanted and reused in different ship projects, reducing development cost and time. At the same time, the standardization of the interface and the data coding rules enhance the openness of the system data, facilitate data sharing and interoperation between various systems of the ship, and improve the overall performance and efficiency of the system.

[0035] Referring to Figure 1 The ship monitoring system provided by the embodiment of the present application comprises a data acquisition layer, a data management layer, a business logic layer and a user page layer which are sequentially connected in communication.

[0036] The data acquisition layer is used to acquire monitoring data of each detection component in the ship hardware device in real time and upload the monitoring data to the data management layer.

[0037] Specifically, the data acquisition layer is in communication connection with the detection components at the bottom layer, and the communication protocol and communication mode thereof depend on the type of each detection component, for example, MODBUS, CAN, analog current, etc. The detection components include various sensor devices for monitoring parameters of each hardware device in the ship, such as exhaust temperature sensors, air pressure sensors, oil viscosity sensors, ferromagnetic particle sensors, torsional vibration sensors, vibration sensors, etc., which are specifically designed according to the actual working requirements of the ship.

[0038] The data acquisition layer is responsible for real-time acquisition of various sensor data in the ship. Preferably, the data acquisition layer can also use hardware and software to convert, preprocess, analyze and perform other operations on the sensor data.

[0039] In specific implementation, the data acquisition layer at least includes a CAN server, a serial port server, a high-frequency signal collector and a low-frequency signal collector which are in direct or indirect communication connection with each detection component in the ship hardware device through a communication protocol, so as to acquire monitoring data of the detection components in real time and convert the monitoring data from physical parameters to digital signals.

[0040] The CAN server is a device based on CAN (Controller Area Network) bus technology. Therefore, the CAN server is connected with detection components supporting CAN bus in the ship hardware device for data transmission through the CAN bus to realize real-time collection and transmission of monitoring data. The serial port server is a network device allowing serial port (COM port) devices to be shared with multiple users or application programs through network connection. The serial port server can support multiple serial port protocols (such as RS-232, RS-422, RS-485, etc.) and can be compatible with various serial port devices. Therefore, the serial port server is used to connect detection components supporting serial port communication to the network, so that the monitoring data on the detection components can be transmitted to the data collection layer in real time through the network. The high-frequency signal collector is used to collect high-frequency signals and can accurately capture and convert high-frequency signals into digital signals. The low-frequency signal collector is used to collect low-frequency signals and can convert these weak low-frequency signals into analyzable digital signals through precise sensors and signal processing circuits. It should be noted that the specific models of the high-frequency signal collector and the low-frequency signal collector can be reasonably selected according to actual work requirements.

[0041] In a preferred embodiment, referring to Figure 2 The data collection layer further includes a data processor, which includes at least any one or more of a data acquisition module, a data analysis module, a data preprocessing module, and a data uploading module. The data processor is the core component of the data collection layer and includes but is not limited to the data acquisition module, the data analysis module, the data preprocessing module, and the data uploading module. These modules can be flexibly combined according to actual needs to realize customized data collection and processing procedures.

[0042] The data acquisition module is used to acquire monitoring data and verify the accuracy and integrity of the monitoring data. Specifically, the data acquisition module is used to acquire monitoring data from the CAN server, the serial port server, the high-frequency signal collector, the low-frequency signal collector, and other devices. The data acquisition module has a built-in data verification mechanism that verifies the accuracy and integrity of the acquired data, including checking whether the monitoring data is complete, whether it conforms to the expected format and range, etc.

[0043] The data analysis module is used to analyze monitoring data in different formats or protocols into a data format that can be processed by the system. Specifically, for diversified data formats and communication protocols from different devices or systems, the module can intelligently identify, decode, format convert, etc. to convert raw data into a data format that can be uniformly processed by the system, eliminating the processing obstacles caused by data format differences.

[0044] The data preprocessing module is configured to preprocess the monitoring data, including at least one of data filtering, data smoothing, and outlier detection. Before uploading the monitoring data, the module performs in-depth processing on the parsed monitoring data, including but not limited to data filtering (removing noise data), data smoothing (reducing data fluctuations), outlier detection (identifying and processing abnormal data points), etc., to improve the quality and consistency of the data, and provide a more accurate data basis for subsequent analysis.

[0045] The data uploading module is configured to match the processed monitoring data with monitoring parameter codes and upload them to the data management layer. The monitoring parameter code is a unique identification code for each type of monitoring data, which is used to identify different monitoring parameters and data types. Specifically, the preprocessed monitoring data is accurately matched with the monitoring parameter code, which can ensure that each type of monitoring data can be uniquely identified. Subsequently, the data is uploaded to the data management layer through a secure and reliable transmission protocol (such as HTTP protocol) for subsequent data analysis, storage, and management. In addition, the matching of monitoring data and monitoring parameter codes is beneficial for the classified storage and quick retrieval of data, allowing the system to quickly identify which type of monitoring parameter the received data belongs to, and thus perform corresponding processing and analysis. At the same time, it also provides a favorable basis for subsequent addition or modification of functional modules.

[0046] The data management layer is configured to store, read, and backup the monitoring data uploaded by the data acquisition layer, and also provides the business logic layer with the monitoring data required for calculation and receives and stores the result data and fault information processed and analyzed by the business logic layer, so that different modules in the business logic layer can access the result data through the data management layer. In a specific embodiment, please refer to Figure 2 , the data management layer at least includes a centralized data management platform and a database. The centralized data management platform is used to centrally manage monitoring data and control access permissions. The database is used to store result data and fault information, as well as to store and manage configuration information of the business logic layer and the data acquisition layer.

[0047] Specifically, the centralized data management platform adopts a service-oriented architecture design (SOA), which can support encapsulating various functions of the centralized data management platform into a series of reusable service components. These service components are independently deployed and run, supporting loose coupling system expansion and maintenance. Through flexible combination and invocation of service components, complex data processing and management tasks can be achieved. At the same time, as a service end, it supports concurrent access and efficient processing. By establishing communication connections with other levels or modules such as the business logic layer and the data acquisition layer, real-time data transmission and interaction can be achieved. In addition, the service end running mode also has load balancing and fault tolerance processing mechanism, ensuring stable data service under high load conditions.

[0048] The centralized data management platform is further connected in communication with the business logic layer and the data collection layer through an HTTP protocol, and uses a JSON data format as a standard format for data exchange. The JSON format has the characteristics of lightweight, easy to read and write, can support the representation and transmission of complex data structures, and effectively ensures the convenience and compatibility of data exchange.

[0049] Further, the centralized data management platform also formulates a plurality of standardized interfaces to provide data exchange functions with other levels and modules, to realize data query, upload, download and update operations, and to facilitate the integration and docking of the centralized data management platform with other levels and modules. The standardized interfaces can provide the following functions: 1. Obtain or submit real-time values of specified monitoring data according to monitoring parameter codes. 2. Obtain all parameters related to a monitored device according to monitoring location information contained in the monitoring parameter code. 3. Submit fault information according to fault codes. 4. Include the unique identification code of the module in the request, so that the data management layer can verify the legality of data access in combination with configuration information and IP whitelist.

[0050] Preferably, the data management layer determines the TCP connection mode according to the acquisition / submission frequency configured by each module, and supports TCP long connection for modules with high data interaction frequency, to optimize the performance of network communication.

[0051] Specifically, the data management layer collects data interaction information between modules in real time through listening to network ports or querying internal logs, including interaction times, data volume, time stamps, etc., and determines the data interaction frequency of each module according to a preset threshold or algorithm. At the same time, the data management layer compares the calculated data interaction frequency with the preset threshold. If the data interaction frequency of a module exceeds the high threshold, the data management layer sends an instruction to the network communication interface to adjust the TCP connection mode of the module to long connection, to reduce the overhead caused by frequent connection and disconnection, and to optimize the performance of network communication. If the data interaction frequency of a module is lower than the low threshold and lasts for a period of time (such as within a preset time window), the data management layer also sends an instruction to the network communication interface to adjust the TCP connection mode of the module to short connection, to release unnecessary network resources. The network communication interface dynamically adjusts the TCP connection mode of the corresponding module according to the received instruction, effectively solving the performance bottleneck problem of the traditional TCP communication mode in complex data processing systems. This method not only improves the efficiency and stability of network communication, but also enhances the flexibility and scalability of the system.

[0052] The database is at least configured with a data code table module, a fault code table module, a storage rule module, and a data access rule configuration module.

[0053] The data coding table module is used to define and store the coding standards and mapping relationships of various types of monitoring data and monitoring parameter codes. During specific implementation, first design a complete set of coding specifications based on the actual needs of ship monitoring, including data type coding, parameter coding, etc. Then, enter these coding standards into the data coding table module, and establish a corresponding mapping relationship table so that the system can automatically convert the original monitoring data into standardized coded data. Through unified coding standards, it is ensured that monitoring data from different sources and of different types can be accurately and quickly identified, processed and transmitted, thereby improving operational efficiency. As far as JSON data transmission is concerned, monitoring parameter codes are used in the transmitted data packets to replace the original complex codes, and the monitoring parameter codes are converted back to the original complex codes during parsing, which can greatly reduce the space occupied by transmission and improve transmission efficiency.

[0054] The fault coding table module is used to define and store the coding standards and mapping relationships between various types of fault information and fault codes. In specific implementation, various possible fault information on the ship is first collected and a unique fault code is assigned to each. These fault codes are then entered into the fault coding table module, along with the corresponding fault description, treatment suggestions, and other fault information. Of course, a separate fault knowledge base can also be established within the database to record the relevant fault knowledge and treatment suggestions corresponding to the fault information. This allows the system to submit fault information containing fault diagnosis results based on the fault code and respond to relevant information in the fault knowledge base. When the system detects a device fault, it automatically converts the fault information into the corresponding fault code and queries the fault coding table module to obtain a detailed fault description and treatment suggestions. This not only improves the efficiency of troubleshooting but also facilitates subsequent fault statistics, analysis, and repair work. Furthermore, the module supports custom expansion of fault codes to meet the specific needs of different ships.

[0055] The storage rule module is used to set rules for the storage format, encryption method, storage location, and storage period of monitoring data. During implementation, different storage strategies can be formulated for different types of monitoring data, and can be dynamically adjusted according to business needs. For storage format and encryption method, appropriate storage format and encryption method can be selected based on the sensitivity and importance of the data. For example, for critical data related to ship safety, encrypted storage can be used to ensure data security. For storage location, data can be stored in an appropriate physical location based on data access frequency and storage space requirements. For example, frequently accessed data can be stored in a high-speed storage database to improve data access efficiency. For storage period, it can be flexibly configured according to the needs of the actual ship system.

[0056] Optionally, the storage period includes at least one of the following rules: 1. Different storage period rules are determined according to different types of monitoring data to optimize storage space utilization. For example, for regular monitoring data such as ship position, heading, etc., a longer storage period can be set, such as storing once a day or once a week. For example, the temperature and pressure data related to the ship diesel generator should be determined according to the working condition of the diesel engine. 2. According to the associated fault information, the storage period of the monitoring data of the device being detected is shortened when a fault of the device is monitored, so as to trace the fault cause when the fault occurs; for example, the storage period is shortened to every hour or every minute, so as to analyze the fault cause in time. 3. According to the working condition requirement of each ship hardware device, when the monitoring data of a certain type is in a preset high frequency change, the storage period of the monitoring data of the type is shortened to ensure the timeliness and accuracy of the data. For example, for a tugboat, when the load changes greatly at a high frequency during towing operation, the storage period should be appropriately shortened to reduce the occupation of storage resources. It should be noted that based on the above rules about the storage period, the person skilled in the art can pre-set the initial storage period value and the storage period value changed after reaching the rule condition according to the actual situation.

[0057] The data access rule configuration module is used to set the data access permission, access frequency limit and data access range of each module. In specific implementation, different modules can be allocated corresponding data access permissions according to their needs and responsibilities. Through fine-grained permission control, the safety and privacy of data are ensured. At the same time, the access frequency is flexibly adjusted to balance the data access efficiency and system load, prevent the system load from being too high due to excessive data access, and reduce the running and storage burden of the data management layer.

[0058] Through the above modular design of the database, comprehensive and fine-grained management of ship monitoring data is realized. Not only the efficiency and accuracy of data processing are improved, but also the safety and privacy of data are enhanced. At the same time, flexible storage rules and access permission configuration make the system able to be customized according to the specific needs of different ships under different working conditions, meeting various monitoring needs.

[0059] Further, the data management layer also configures a buffer with a lock mechanism for each type of monitoring data, which is used to record and temporarily store the monitoring data; the database stores the data in the buffer into the database according to the storage rules of the storage rule module. In specific implementation, a fine-grained lock mechanism such as a read-write lock (Read-Write Lock) is used inside the buffer to optimize concurrent access performance. When data is written, a write lock is automatically added to prevent other read and write operations; when data is read, a read lock can be added to allow multiple read operations to be performed simultaneously, but prevent write operations, thereby ensuring data consistency while improving system throughput. The buffer can be designed as a circular queue or a linked list structure to record new monitoring data in a fixed size of memory space. When the buffer is full, old data is discarded or stored permanently according to a preset strategy (such as FIFO, priority, etc.) to ensure that new data can be recorded in time.

[0060] When the data management layer receives a request to submit monitoring data, the data access rule configuration module verifies whether the request meets the preset access rules, and if the verification is passed, the monitoring data in the buffer is updated according to the request; when the data management layer receives a request to obtain monitoring data, the data access rule configuration module also verifies whether the request meets the preset access rules, and if the verification is passed, the monitoring data is read from the buffer according to the request and responded. The verification content includes but is not limited to the identity, authority, request data type, time range, etc. of the request module. All operations are performed under the condition that the verification is passed and the lock mechanism is allowed to ensure the safety of the data and the compliance of the access. In addition, whenever the preset storage period is reached or the buffer reaches a certain threshold, the data management layer triggers a data migration task to write the valid data in the buffer to the database in batches according to the configuration of the storage rule module.

[0061] By introducing a buffer with a lock mechanism, the efficiency and safety of the system in data processing and storage are effectively improved.

[0062] In some preferred embodiments, the database further includes a configuration file management module for managing the configuration information of the newly added functional modules in the business logic layer and the data collection layer; the configuration file management module updates the contents of the data encoding table module, the fault encoding table module, the storage rule module, and the data access rule configuration module according to the configuration information of the newly added functional modules in the business logic layer and the data collection layer, and automatically deploys the newly added functional modules in the business logic layer and the data collection layer based on the configuration information.

[0063] During specific implementation, the configuration file management module receives the client's new functional module configuration requirements and configuration information through a standardized interface. The configuration information may include the location information of the newly added monitored equipment, the newly added monitoring data and the corresponding monitoring parameter codes, the data access rules of the newly added modules, the storage rules of the newly added modules, and the relevant fault information and fault codes of the newly added monitored equipment, etc.

[0064] In some embodiments, the specific steps for adding a new functional module to the business logic layer are: determining a unique identification code for the new functional module and determining a unique data code for the new monitoring data of the new functional module, wherein a specific bit of the data code is used to identify the monitoring location to facilitate subsequent data analysis and processing. Based on the identification code and the new data code, the relevant configuration of the new functional module is completed in the database; based on the relevant configuration of the new monitoring data in the database, the new functional module is automatically deployed on the business logic layer;

[0065] The specific steps for adding a new functional module to the data acquisition layer are: determining a unique identification code for the new functional module and a unique data code for the new monitoring data of the new functional module, and a specific bit of the data code is used to identify the monitoring location; completing the configuration of the new monitoring data in the database based on the identification code and the new data code; automatically deploying the new functional module on the data acquisition layer based on the configuration information; the configuration of the new monitoring data in the database includes at least the following information: the correlation between the new monitoring data and the fault information, the byte length required for the new monitoring data, the storage rules of the new monitoring data, and the identification code of the detection component from which the new monitoring data comes.

[0066] Through the above settings, the automatic and efficient configuration and deployment of new functional modules in the business logic layer and data acquisition layer of the system can be achieved, greatly improving the scalability and flexibility of the system.

[0067] The business logic layer is used to obtain the monitoring data stored in the data management layer, and then perform calculations and analysis to provide auxiliary decision-making; please refer to Figure 1 、 Figure 2 The business logic layer includes at least an energy efficiency index calculation unit and a fault diagnosis unit; the energy index calculation unit includes multiple calculation modules for analyzing the energy consumption of each ship hardware device according to the monitoring data and providing suggestions for energy efficiency optimization strategies; the fault diagnosis unit includes multiple diagnosis modules for analyzing the status of each ship hardware device according to the monitoring data and diagnosing whether there is a fault.

[0068] Specifically, the business logic layer contains a series of modules responsible for handling the core functions of the software system, such as energy efficiency index calculation, fault diagnosis, and decision support. This layer communicates with the data management layer through the HTTP protocol to obtain monitoring parameter data for calculation and analysis. Each monitoring parameter is assigned a unique code based on elements such as device type and device serial number, and a fault code is formulated based on the fault type and fault-related monitoring parameters. This allows different systems to quickly request and send data through data coding tables and fault coding tables, achieving unified data access and fault alarms. The calculation results can be written to the data management layer or displayed in the user page layer. The modules at this layer adopt a modular design to provide system flexibility and scalability.

[0069] The energy efficiency index calculation unit is used to acquire and analyze energy consumption data of hardware equipment such as diesel engines, battery packs, and propulsion motors in real time; evaluate the ship's emissions, effective energy utilization efficiency ratio, and power consumption of various parts of the power system; optimize energy utilization efficiency, reduce emissions, and provide recommendations for energy efficiency optimization strategies. The fault diagnosis unit includes multiple modules, such as the diesel engine fault diagnosis module and the power system fault diagnosis module. The diesel engine fault diagnosis module is used to acquire data such as cylinder exhaust temperature, torsion angle, vibration acceleration, and load, analyze the unit's operating status, and detect faults such as cylinder scuffing and flameout. The power system fault diagnosis module is used to acquire power system-related data such as voltage, current, power, and frequency, analyze the load of the ship's power system, and detect whether there is an overload or imbalance in the power load.

[0070] The user page layer is used to provide a visual interactive interface for human-computer interaction with the ship monitoring system.

[0071] Specifically, the user interface layer is the system's outermost layer, providing users with a graphical user interface (GUI) for interacting with the ship monitoring system. This layer is primarily responsible for receiving user input, displaying information, providing user requirements to the business logic layer, and presenting calculation results. The user interface layer communicates with the business logic layer. The user interface layer presents monitoring parameters and diagnostic results visually, allowing operators to intuitively understand the system status. Furthermore, the user interface layer requires authentication and role-based access control for operations involving configuration modifications. Administrator identity is required to modify important configuration information to enhance system security.

[0072] In order to effectively illustrate the working principle of the above-mentioned system, the process of completing the oil monitoring is taken as an example, and the complete data monitoring process is as follows: according to the temperature, pressure sensor and viscosity, metal particle number acquisition data in the detection component, output 4-20mA analog current signal to the low frequency signal collector of the data acquisition layer, and the low frequency signal collector outputs the digitized measurement result to the data processor in MODBUS protocol. After analysis and preprocessing, the data processor submits the data to the data management layer. After verifying the access permission, the data management layer writes the current monitoring parameter value to the buffer and completes the timing storage. The oil analysis diagnosis module in the fault diagnosis unit of the business logic layer sends a request to the data management layer to obtain the monitoring data of oil temperature, pressure, viscosity, metal particle number and the like monitored by the above-mentioned module, and analyzes and diagnoses the fused multiple data. If the oil pollution, mechanical part wear and the like are diagnosed, the fault information with fault code index is submitted to the data management layer, and the recommended treatment measures and the like information are obtained from the fault knowledge base or fault coding table module, and finally the alarm information is displayed on the user interface layer.

[0073] In summary, the embodiment of the present application proposes a hierarchical and modular design method of the ship monitoring system, realizes only data transmission between layers without process coupling, determines the basic requirements in functionality in each layer, and designs a standardized interface for data transmission, thereby improving the portability and flexibility of the software project, facilitating the needs of different ships, and providing a more flexible and efficient scheme for the development of the ship monitoring system.

[0074] Please refer to Figure 3 The present application also provides a ship fault alarm method, which adopts the ship monitoring system of any one of the above embodiments, and comprises the following steps:

[0075] The data acquisition step, the data acquisition layer acquires the monitoring data of each detection component in the ship hardware device in real time and uploads to the data management layer.

[0076] Among them, each detection component is respectively installed on the key hardware device (such as engine, generator, rudder, pump, etc.) of the ship, for real-time acquisition of temperature, pressure, current, voltage, speed, vibration and other key parameters. Each detection component has independent data acquisition capability, and acquires related data through timing or triggering mode, and transmits these data to the data acquisition layer to convert into digital signals for preliminary processing. The processed data is uploaded to the data management layer in real time through the ship internal network, wired or wireless communication technology, ensuring the timeliness and accuracy of the data.

[0077] The data management step, the data management layer stores the uploaded monitoring data. Among them, the data management layer is used for storing, reading and backing up the monitoring data uploaded by the data acquisition layer based on the corresponding storage rules and data access rules.

[0078] Logical judgment step, the fault diagnosis unit of the business logic layer sends a request to the data management layer to obtain relevant monitoring data, and analyzes and diagnoses based on the relevant monitoring data obtained by the request; if a fault occurs in the diagnosis, the fault information is submitted to the data management layer; the data management layer provides a standardized interface for the business logic layer to access, and supports querying and retrieving data in various ways such as time, equipment, and parameters.

[0079] Alarm step, the user page layer visually displays the fault information and relevant monitoring data. That is, the user page layer displays the fault information and relevant monitoring data to the user in an intuitive and easy-to-understand manner through a graphical user interface (GUI), and the user can perform operations such as fault confirmation, alarm silencing, and fault diagnosis report generation through the user page layer. Of course, the system can also be set to support user-defined alarm thresholds, set fault notification methods (such as email, SMS, voice notification, etc.), and other advanced functions.

[0080] Among them, the principle, function and role of the specific steps can refer to the foregoing embodiment of the ship monitoring system, and will not be repeated here.

[0081] In summary, the ship fault alarm method of the present application realizes real-time monitoring of ship hardware devices and rapid response to faults by constructing an efficient data acquisition, storage, analysis and visualization display mechanism, and provides a strong guarantee for the safe operation of the ship.

[0082] In addition, those skilled in the art should understand that although there are many problems in the prior art, each embodiment or technical solution of the present application can only improve in one or several aspects, and it is not necessary to solve all the technical problems listed in the prior art or background art at the same time. Those skilled in the art should understand that the content not mentioned in a claim should not be regarded as a limitation of the claim.

[0083] Although terms such as data acquisition layer, data management layer, business logic layer, user page layer, etc. are used more frequently in this document, the possibility of using other terms is not excluded. The use of these terms is only to facilitate the description and explanation of the essence of the present application; any additional limitation is contrary to the spirit of the present application; the terms "first", "second", etc. (if any) in the specification and claims of the embodiment of the present application and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily describe a specific order or sequence.

[0084] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, and are not intended to limit the present application; although the present application has been described in detail with reference to the above embodiments, those skilled in the art should understand that the technical solutions recorded in the above embodiments can be modified, or some or all of the technical features can be replaced by equivalents; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A ship monitoring system, characterized in that: include: The data acquisition layer, data management layer, business logic layer and user page layer are connected in sequence; The data acquisition layer is used to obtain the monitoring data of each detection component in the ship's hardware equipment in real time and upload it to the data management layer; The data management layer is used to store, read and back up the monitoring data uploaded by the data acquisition layer, and is also used to provide the monitoring data required for calculation to the business logic layer and receive and store the result data and fault information after calculation and analysis by the business logic layer, so that different modules in the business logic layer can access the result data through the data management layer. The data management layer also includes a database, which is used to store the result data and fault information and also to store and manage the configuration information of the business logic layer and the data acquisition layer. The database is configured with at least a data coding table module, a fault coding table module, a storage rule module, and a data access rule configuration module; the database also includes a configuration file management module for managing configuration information of newly added functional modules in the business logic layer and the data acquisition layer; the configuration file management module updates the contents of the data coding table module, the fault coding table module, the storage rule module, and the data access rule configuration module according to the configuration information of the newly added functional modules in the business logic layer and the data acquisition layer, and automatically deploys the newly added functional modules in the business logic layer and the data acquisition layer based on the configuration information; The specific steps of adding a new functional module to the business logic layer are: determining a unique identification code for the new functional module and determining a unique data code for the new monitoring data of the new functional module, wherein a specific bit of the data code is used to identify the monitoring location; completing the relevant configuration of the new functional module in the database based on the identification code and the new data code; and automatically deploying the new functional module on the business logic layer based on the relevant configuration of the new monitoring data in the database; The specific steps of adding a new functional module to the data acquisition layer are: determining a unique identification code for the new functional module and determining a unique data code for the new monitoring data of the new functional module, wherein a specific bit of the data code is used to identify the monitoring location; and completing the configuration of the new monitoring data in the database based on the identification code and the new data code; Automatically deploying new functional modules on the data collection layer based on the configuration information; configuring the new monitoring data in the database includes at least the following information: the association between the new monitoring data and the fault information, the byte length required for the new monitoring data, the storage rules for the new monitoring data, and the identification code of the detection component from which the new monitoring data comes; The business logic layer is used to obtain the monitoring data stored in the data management layer, and then perform calculations and analysis to provide auxiliary decision-making; the business logic layer includes at least an energy efficiency index calculation unit and a fault diagnosis unit; the energy efficiency index calculation unit includes multiple calculation modules for analyzing the energy consumption of each ship hardware device based on the monitoring data and providing suggestions for energy efficiency optimization strategies; the fault diagnosis unit includes multiple diagnosis modules for analyzing the status of each ship hardware device based on the monitoring data and diagnosing whether there is a fault; The user page layer is used to provide a visual interactive interface for human-computer interaction with the ship monitoring system.

2. The ship monitoring system according to claim 1, characterized in that: The data acquisition layer includes at least a CAN server, a serial port server, a high-frequency signal collector, and a low-frequency signal collector that are directly or indirectly connected to each of the detection components in the ship hardware equipment through a communication protocol to obtain the monitoring data of the detection components in real time and convert the monitoring data from physical parameters into digital signals.

3. The ship monitoring system according to claim 2, characterized in that: The data acquisition layer also includes a data processor, which includes at least one or more of a data acquisition module, a data analysis module, a data preprocessing module, and a data upload module; the data acquisition module is used to acquire monitoring data and verify the accuracy and completeness of the monitoring data; the data analysis module is used to parse monitoring data of different formats or protocols into a data format that can be processed by the system; the data preprocessing module is used to preprocess the monitoring data, including at least one of data filtering, data smoothing, and outlier detection; the data upload module is used to match the processed monitoring data with the monitoring parameter code and upload it to the data management layer; the monitoring parameter code is a unique identification code for each type of monitoring data.

4. The ship monitoring system according to claim 1, characterized in that: The data management layer includes at least a centralized data management platform for centrally managing monitoring data and controlling access rights; the centralized data management platform adopts a service-oriented architecture design and operates as a server, and communicates with the business logic layer and the data acquisition layer via the HTTP protocol, using the JSON data format as the standard format for data exchange; The centralized data management platform also develops several standardized interfaces to provide data exchange functions with other levels and modules.

5. The ship monitoring system according to claim 4, characterized in that: The data coding table module is used to define and store the coding standards and mapping relationships between various monitoring data and monitoring parameter codes; the fault coding table module is used to define and store the coding standards and mapping relationships between various fault information and fault codes; The storage rule module is used to set the storage format, encryption method, storage location and storage period rules of the monitoring data; the data access rule configuration module is used to set the data access rights, access frequency limit and data access scope of each module.

6. The ship monitoring system according to claim 5, characterized in that: The storage period includes at least one of the following rules: Determine different storage cycle rules based on different types of monitoring data; According to the associated fault information, when a device fault is detected, the storage period of the monitoring data of the device being detected is shortened; According to the working condition requirements of each ship's hardware equipment, the storage period of a certain type of monitoring data is shortened when the monitoring data changes at a preset high frequency.

7. The ship monitoring system according to claim 5, characterized in that: The data management layer further configures a buffer with a lock mechanism for each type of monitoring data, the buffer being used to record and temporarily store monitoring data; the database regularly stores the data in the buffer permanently in the database according to the storage rules of the storage rule module; When the data management layer receives a request to submit monitoring data, the data access rule configuration module verifies whether the request complies with the preset access rules. If the verification is successful, the monitoring data in the buffer is updated according to the request; when the data management layer receives a request to obtain monitoring data, the data access rule configuration module also verifies whether the request complies with the preset access rules. If the verification is successful, the monitoring data is read from the buffer and responded to according to the request.

8. A ship fault alarm method, characterized in that: The ship monitoring system according to any one of claims 1 to 7 comprises the following steps: Data collection step, the data collection layer acquires monitoring data of each detection component in the ship's hardware equipment in real time and uploads it to the data management layer; Data management step, wherein the data management layer stores the uploaded monitoring data; In a logical judgment step, the fault diagnosis unit of the business logic layer sends a request to the data management layer to obtain relevant monitoring data, and performs analysis and diagnosis based on the relevant monitoring data obtained in the request; if a fault is diagnosed, the fault information is submitted to the data management layer; In the alarm step, the user page layer visually displays the fault information and related monitoring data.

Images