An implicit multi-segment trigger chain method and apparatus

Abstract

The present application relates to the technical field of data processing, and provides a kind of implicit multi-section trigger chain method and device.In the present application, user submits task demand, task management module in system is activated, and a set of task label representing load power expectation that task demand is started is written in system state table, and task management module enters weak disturbance state;Energy consumption evaluation module in system identifies that energy consumption label fragment in system state table has changed, then updates system state table;Energy consumption label fragment is FB-Type data label of frequency variation type, and system state table is stored in time series database;Device state module switches data label type according to system state table, and stores the data collected according to the type of data label.The present application solves the problem that the prior art is more complex to coordinate each module based on explicit control, the amount of data required for transmission is large, resulting in poor system practicability.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, in particular to an implicit multi-segment trigger chain method and device. BACKGROUND

[0002] In task-driven intelligent systems, the combination mode of functional modules is evolving from fixed sequence calling to dynamic excitation based on state sensing. Traditional logic flow often performs linear distribution at the module level through explicit control chain, which is difficult to adapt to system task flow involving multi-state coupling, multi-node triggering and multi-factor nonlinear evolution.

[0003] With the independence of module capabilities, the structure of multiple functional modules with local responsiveness on standby and asynchronous collaboration frequently occurs in system operation. In an asynchronous collaboration environment, multiple functional modules need to coordinate their actions to ensure the consistency and correctness of the system as a whole. However, due to the independent operation of each module, coordinating their actions becomes extremely complex, and the amount of data required for transmission is also large, which is not practical.

[0004] In view of this, overcoming the defects of the prior art is a problem urgently to be solved in the technical field. SUMMARY

[0005] The technical problem to be solved by the present application is to provide an implicit multi-segment trigger chain method and device.

[0006] The present application adopts the following technical solutions:

[0007] In a first aspect, the present application provides an implicit multi-segment trigger chain method, a user submits a task requirement, the task requirement content includes one or more of sampling point, time window and task type, the method comprising:

[0008] A task management module in the system is activated and writes a set of task tags representing the expected load power of the task requirement started in the system state table, and the task management module enters a weak disturbance state;

[0009] An energy consumption evaluation module in the system identifies that the energy consumption tag segment in the system state table has changed, and then updates the system state table; wherein the energy consumption tag segment is located in the task tag subset of the corresponding load power expectation; the energy consumption tag segment is a frequency variable FB-Type data tag, and the system state table is stored in a time series database;

[0010] A device state module switches the data tag type of the energy consumption tag segment according to the system state table, and stores the collected data according to the type of the data tag.

[0011] Further, the energy consumption evaluation module in the system identifies that the energy consumption label segment in the system state table has changed, and then updates the system state table to include:

[0012] When the energy consumption evaluation module identifies that the energy consumption label segment in the system state table has changed, the built-in rule model is combined to trigger evaluation;

[0013] The evaluation is not explicitly initiated by the task management module, but the energy consumption evaluation module determines whether to respond based on its preset response rules due to the energy consumption label segment as a residual feature in the system state table;

[0014] After the energy consumption evaluation module completes processing, it records a set of temporary labels in the system state table, including load estimated power value and execution feasibility suggestion. The temporary labels can be read by other modules in the short-term cache to update the system state table.

[0015] Further, the energy consumption evaluation module determines whether to respond based on its preset response rules includes:

[0016] If the change value of the changed energy consumption label segment is greater than the preset threshold, the energy consumption evaluation module needs to respond;

[0017] If the change value of the changed energy consumption label segment is less than or equal to the preset threshold, the energy consumption evaluation module does not need to respond.

[0018] Further, the device state module switches the data label type of the energy consumption label segment according to the system state table, and stores the collected data according to the type of the data label, which includes:

[0019] When the device state module continuously reads the energy consumption label segment, it detects that the load estimated power value of the temporary label and the device load trend have a short-term overlap, and then the device state module enters a passive observation mode;

[0020] When the device state module enters the passive observation mode, the device state module periodically determines whether the device load trend in the energy consumption label segment falls below the safety threshold to selectively perform or not perform the data label type switching process;

[0021] The data label type switching process is used to switch the data label type of the energy consumption label segment and switch the storage database type of the collected data.

[0022] Further, the device state module periodically determines whether the device load trend in the energy consumption label segment falls below the safety threshold to selectively perform or not perform the data label type switching process, which includes:

[0023] If the device load trend in the energy consumption label segment falls back to a safety threshold, a data label type switching process is started.

[0024] If continuous anomalies are detected, or the device load trend in the energy consumption label segment does not fall back to a safety threshold, the data label type switching process is not started.

[0025] Further, the data label type switching process specifically includes:

[0026] The task management module switches the energy consumption label segment from the frequency-variable type FB-Type to the stable type ST-Type, and causes the collected data to be stored in a relational database.

[0027] Further, for a task priority lower than a preset level, and a task requirement involving a strongly associated sensor, when a difference between a network bandwidth load and a load limiting factor is less than a first preset value, the energy consumption label segment is switched from the frequency-variable type FB-Type to the slow-variable type MB-Type, and the collected data is stored in a document type database.

[0028] The task requirement involving a strongly associated sensor is a task requirement with a degree of dependence on other sensors greater than a second preset value.

[0029] Further, the input mode of the task requirement includes front-end interface manual configuration and / or batch import of structured parameters.

[0030] In a second aspect, the present application further provides an implicit multi-segment trigger chain device for implementing the implicit multi-segment trigger chain method of the first aspect, and the device includes:

[0031] At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the processor to execute the implicit multi-segment trigger chain method of the first aspect.

[0032] In a third aspect, the present application further provides a non-volatile computer storage medium, and the computer storage medium stores computer executable instructions, and the computer executable instructions are executed by one or more processors to complete the implicit multi-segment trigger chain method of the first aspect.

[0033] The application provides a task-driven intelligent system architecture based on an implicit trigger mechanism, a system state space is represented by a task label in a system state table, and a data acquisition and storage strategy is adjusted based on the system state table and a change of the task label, so that chain triggering between modules is realized, flexible appearance and logical evolution of the modules under time drift are supported, a state sensing effect is achieved, each module in the system does not need to rely on intervention of an explicit central controller for coordination, balance between decentralization and chain evolution is realized. Since the explicit central controller does not need to intervene, single-point failure and communication delay are avoided, meanwhile, logical coherence of a task flow can be maintained, and an effect of target conflict caused by independent action of the modules is avoided. The system is switched from program driving to environment driving, and a complex task processing capability closer to human intuition is realized through implicit rules. BRIEF DESCRIPTION OF DRAWINGS

[0034] In order to more clearly illustrate the technical solutions of the embodiments of the application, the following will briefly introduce the drawings needed to be used in the embodiments of the application. Obviously, the drawings described below are only some of the embodiments of the application, and other drawings can be obtained by those skilled in the art without creative labor on the basis of these drawings.

[0035] Figure 1 is a flowchart of an implicit multi-segment trigger chain method provided by the embodiments of the application;

[0036] Figure 2 is a specific example diagram of a system state table including five task labels provided by the embodiments of the application;

[0037] Figure 3 is a flowchart of system state switching based on an implicit trigger mechanism provided by the embodiments of the application;

[0038] Figure 4 is a flowchart of step 20 provided by the embodiments of the application;

[0039] Figure 5 is a specific example diagram of a system state table including a temporary label provided by the embodiments of the application;

[0040] Figure 6 is a specific example diagram of a device load trend provided by the embodiments of the application;

[0041] Figure 7 is a flowchart of step 201 provided by the embodiments of the application;

[0042] Figure 8 is a flowchart of step 30 provided by the embodiments of the application;

[0043] Figure 9 is a flowchart of step 302 provided by an embodiment of the present application.

[0044] Figure 10 is a schematic diagram of a symbol dynamic allocation device of a communication system in a marine engine room environment provided by an embodiment of the present application. DETAILED DESCRIPTION

[0045] In order to make the objects, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and should not be used to limit the present application.

[0046] In the description of the present application, the terms “inner”, “outer”, “longitudinal”, “transverse”, “upper”, “lower”, “top”, “bottom” and the like indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, and are only used to facilitate the description of the present application and do not require the present application to be constructed and operated in a particular orientation, therefore should not be understood as a limitation on the present application.

[0047] In the present application, the terms “first”, “second” and the like are only used for descriptive purposes, and should not be understood as indicating or implying relative importance or implicitly indicating the number of the technical features indicated. Therefore, the features defined with “first”, “second” and the like can explicitly or implicitly include one or more of the features. In the description of the present application, unless otherwise specified, the meaning of “a plurality of” is two or more.

[0048] In the present application, unless otherwise specified and limited, the term “connection” should be understood broadly, for example, “connection” can be fixed connection, or detachable connection, or integral; can be directly connected, or indirectly connected through intermediate medium. In addition, the term “coupling” can be an electrically connected manner for realizing signal transmission.

[0049] In addition, the technical features involved in each embodiment of the present application described below can be combined with each other as long as there is no conflict.

[0050] Embodiment 1:

[0051] Traditional task-driven intelligent systems use a module calling mode of explicit control chain, that is, tasks are dispatched through preset processes (such as a fixed sequence of "A to B, B to C"); this mode is effective in simple scenarios, but has major problems when facing complex tasks: (1) when multiple state variables (such as environmental perception, user preferences, and device status) interact with each other, it is difficult for the fixed process to dynamically adjust the priority; (2) multiple functional modules may simultaneously meet the triggering conditions, but the traditional architecture cannot handle them in parallel; (3) the task flow may need to backtrack or jump due to sudden state changes (such as the user modifying the task goal midway), and the mode of dispatching tasks through preset processes is prone to logical conflicts.

[0052] As the module capability develops towards independence, each module can autonomously complete a local task, and the system gradually forms a structure of multiple modules on standby and asynchronous cooperation. For example, in an autonomous driving system, the path planning, obstacle avoidance, and vehicle distance maintenance modules need to respond to different sensor data in real time. This structure requires the system to have an implicit triggering mechanism, that is, to automatically activate related modules through state sensing, rather than relying on a central controller to explicitly schedule, in order to flexibly coordinate independently running modules.

[0053] Therefore, such a system urgently needs an implicit triggering mechanism without the intervention of an explicit central controller, but still has potential chain evolution characteristics, to support the flexible appearance and logical evolution of each functional node under temporal drift.

[0054] To solve the above problems, an embodiment of the present application provides an implicit multi-segment triggering chain method, in which a user submits a task requirement, and the task requirement content includes one or more of a sampling point, a time window, and a task type.

[0055] First, the practical application scenarios of the embodiments of the present application are described as follows:

[0056] In the scenario of a marine research vessel, in order to complete various research tasks (for example, measuring ocean currents), various target devices (for example, ship-borne sensors) are often configured for the research vessel according to different task requirements. In an embodiment, the task requirement content can be: collecting data of sampling point 1 within time window A. These target devices can be located inside the research vessel or set on the research vessel, and vary according to specific use scenarios. In an embodiment, the scenario of the research task can be: the research vessel measures the ice thickness and related parameters of an ice-covered river A by crossing the river A; or, a submarine starts diving at position C in sea B, collects multi-dimensional marine biological data at the position after diving to a first depth, etc.

[0057] In an embodiment, the task requirement further comprises offshore sampling and observation; and the task requirement content can also be used to automatically generate a task list for the layer data. In the offshore sampling and observation, various instruments are used to collect original data of marine hydrology, biology, geology, etc., and through processing and analysis, the biological distribution of a certain sea area is obtained, and then the biological distribution layer data is generated after data cleaning, calibration and analysis; the task list for the layer data is generated according to the task requirement of the offshore sampling and observation, and is used to determine the type of data to be collected, the observation area, the sampling frequency and other information, so as to determine the specific task of generating the layer data.

[0058] In an optional embodiment, the input mode of the task requirement comprises front-end interface manual configuration and / or batch import of structured parameters.

[0059] Based on the above scenarios, specifically, as shown in Figure 1 The method comprises the following steps:

[0060] Step 10: The task management module in the system is activated, and a set of task tags representing the load power expectation of the task requirement being started is written in the system state table, and the task management module enters the weak disturbance state.

[0061] The system of the embodiment needs to process various types of data (for example, continuous time series data) collected by the target device, structured instruction data formed by task scheduling, and cache state data of temporary response type; and the forms and formats of various collected data of different target devices are different. Since the energy consumption for obtaining these data often differs, and the corresponding energy consumption in different task stages or time intervals also greatly differs, the embodiment uses different access strategies and storage modes for these data based on the system state table according to the energy consumption. Through the cooperation between the task management module, the energy consumption evaluation module and the device state module, the system behavior is adjusted in an implicit triggering manner, and then the storage mode of the data is adjusted according to the energy consumption, so as to reduce the data transmission amount for coordinating the modules of the system and reduce the bandwidth occupation.

[0062] In an embodiment, a common system state table is used to record the state space of the system in advance; as shown in Figure 2 A specific example of a system state table including five task tags is shown. The task management module, the energy consumption evaluation module and the device state module can read the data in the system state table.

[0063] As shown in Figure 3 When the user submits the task requirement, the task management module is activated, and the task management module writes a set of task tags representing the "high load power expectation" (for example, "high") in the system state table. Figure 2The system uses task tags A, B, C, D, and E to form a "weakly disturbed dynamic." Task tags record the current state of each module (including the task management module, energy consumption assessment module, and device status module) during task execution. This embodiment implicitly triggers state changes between modules through task tags, which will be explained in detail below. Real-time collection of energy consumption data related to task execution is used to characterize state changes through changes in energy consumption data. High load power expectation means that the user allows a large range of state changes corresponding to the task tag. Weakly disturbed dynamic is equivalent to the system currently being in a dormant state for data collection and storage, which will be further explained below.

[0064] Step 20: The energy consumption assessment module in the system identifies that the energy consumption label segment in the system status table has changed, and then updates the system status table.

[0065] The energy consumption tag fragment is located in the task tag subset corresponding to the expected load power; the energy consumption tag fragment is a frequency-varying FB-Type data tag; and the system status table is stored in a time-series database.

[0066] Each task tag corresponds to at least one energy consumption tag segment, and each energy consumption tag segment is a subset of the corresponding task tag. The value of the energy consumption tag segment under each task tag is the real-time energy consumption data collected for that task tag. The task tag is used to record the current state of the module, and the energy consumption tag segment is equivalent to a state interval.

[0067] In one embodiment, such as Figure 2 As shown, task tag A includes energy consumption tag fragments A1, A2, A3, A4, A5, A6, and A7; task tag B includes energy consumption tag fragments B1, B2, B3, B4, B5, and B6, and so on. Further details will not be provided here.

[0068] The specific implementation method of the time series database shall be selected by those skilled in the art according to the specific use case; in an optional embodiment, the time series database may be the Quest Database (abbreviated as QuestDB).

[0069] By default, high-frequency data is not remotely synchronized between the research vessel and its land-based server; it is only cached in the time-series database of the research vessel's local node.

[0070] Under weak disturbance, unless there is a new task demand submission, and the energy consumption label segment of the corresponding other function module changes to an abnormal state, the data currently collected by the system is stored as a frequency variation type FB-Type to the time sequence database.

[0071] Step 30: The device state module switches the data label type of the energy consumption label segment according to the system state table, and stores the collected data according to the type of the data label.

[0072] As shown in Figure 3 After the energy consumption label segment changes, it may trigger the update of the system state table under certain conditions; the specific operation steps of updating the system state table after the energy consumption label segment changes will be described below. After the system state table is updated, the data label type of the energy consumption label segment is switched, and the type of the switched data label is used to determine which database the collected data is stored in. A specific embodiment will be given below.

[0073] In an embodiment, in an actual application scenario, the research ship performs the operation procedures of steps 10 to 20 before it leaves the shore to perform a task, to collect data, and then simulates the values of the energy consumption label segment corresponding to the task label during the task execution after the research ship leaves the shore, to preview the state of the research ship during the task execution. In this process, in order to record all the simulated values, all the collected data are frequency variation type FB-Type data labels, and are recorded to the time sequence database according to the storage mode of the frequency variation type data, so that only the values that are greatly different from the simulated values before leaving the shore need to be stored and transmitted in the subsequent process, thereby reducing the amount of data to be transmitted, saving bandwidth, and improving the practicability of the system.

[0074] The present application provides a task-driven intelligent system architecture based on an implicit trigger mechanism, which represents the system state space through a task label in a system state table, and adjusts the data collection and storage strategy based on the system state table and the change of the task label, thereby realizing chain triggering between modules to support flexible appearance and logical evolution of each module under temporal drift, achieving the effect of state sensing without relying on the intervention of an explicit central controller to coordinate each module in the system, and realizing the balance between decentralization and chain evolution. Since there is no need for explicit central controller intervention, single point failure and communication delay are avoided, while the logical coherence of the task flow can be maintained, avoiding the effect of target conflict caused by independent action of the modules. The system is converted from program-driven to environment-driven, and through implicit rules, the complex task processing ability closer to human intuition is realized.

[0075] The implicit triggering mechanism automatically adjusts the system behavior without explicit instructions by perceiving the environmental context (e.g., user behavior, module state, network condition, etc.), combining historical data to predict user demand. The user behavior can be that the user submits a task demand through manual configuration and / or batch import of structured parameters through the front-end interface. The module state can be that the task management module is activated and writes a set of task labels representing the expected load power of the task demand in the system state table, and the task management module enters the weak disturbance state. The network condition is that the load of the network bandwidth reaches a certain value.

[0076] Unlike the explicit triggering (which requires user active operation) of the prior art, the implicit triggering automatically triggers the operation by perceiving the environmental context and analyzing the user behavior or environmental state, and can dynamically adjust the triggering condition according to real-time data. For example, when the energy consumption evaluation module identifies that the energy consumption label segment in the system state table has changed, the system state table is updated, and the data label type of the energy consumption label segment is selectively switched according to the updated system state table, and the collected data is stored according to the type of the data label. In the system of the embodiment of the present application, the output of the activated module changes the system state, thereby triggering the chain response of other modules. For example, after the task management module is activated, a set of task labels are written in the system state table. These task labels, as the output of the task management module operation, change the system state, thereby triggering the chain response of the energy consumption evaluation module and the device state module in turn. The implicit triggering mechanism is similar to the intuitive reaction of human beings. What the user perceives is that the system automatically adjusts the running state of each module according to the current environmental context without human intervention.

[0077] In order to further illustrate the implicit multi-segment triggering chain method of the embodiment of the present application, as shown in Figure 4 The step 20 includes:

[0078] Step 201: When the energy consumption evaluation module identifies that the energy consumption label segment in the system state table has changed, the built-in rule model is triggered for evaluation.

[0079] The built-in rule model is a system default operation process written in the system in advance without the need for online downloading or temporary configuration. The built-in rule model is determined by a person skilled in the art according to the specific use scenario, which is not limited here. In one embodiment, the built-in rule model is already fixed in the code or chip at the time of factory shipment, and does not depend on external files. After reading the built-in rule model, it can be known that the system should respond in what scenario (including user action and module state, etc.) and get the result.

[0080] In an embodiment, in an actual application scenario, when the research vessel is about to set sail, all the target devices for collecting data are in a running state, and the research vessel will set sail only after confirming that the running state of the target devices is normal. The operation process of step 20 can be applied to the state rehearsal data collection process before setting sail and can also be applied to the data collection process after setting sail.

[0081] Before setting sail, through the operation processes of steps 10 and 20, the approximate numerical interval of the real-time energy consumption data corresponding to various tasks can be analyzed, determined, and recorded in advance, so that only the numerical values deviating greatly from the approximate numerical interval need to be stored and transmitted subsequently. At this time, step 20 is used to determine, by using the current real-time collected data and through big data analysis and learning, in which case the change value of the energy consumption label segment needs to adjust the data collection and storage strategy (for example, adjusting the data label of the collected data and recording to the corresponding database according to the adjusted storage mode) to determine a reasonable approximate numerical interval without adjusting the data collection and storage strategy.

[0082] Before setting sail, the state of the research vessel when performing a task is rehearsed, and all the simulated numerical values are recorded. In order to reduce the amount of data to be transmitted and save bandwidth, all the collected data are frequency-variable FB-Type data labels, and are recorded to the time sequence database according to the storage mode of the frequency-variable data. After setting sail, according to the operation process of step 20, when the energy consumption label segment changes, it indicates that the running state of the target device is fluctuating, and the running state needs to be evaluated to consider whether to adjust the data collection and storage strategy. At this time, step 20 is used to adjust the data collection and storage strategy when the current real-time collected data exceeds the approximate numerical interval.

[0083] The evaluation is not explicitly initiated by the task management module, but because the energy consumption label segment exists as a residual feature in the system state table, the energy consumption evaluation module judges whether it needs to respond based on its preset response rules.

[0084] The preset response rules are selected by a person skilled in the art according to a specific use scenario; one specific example will be given below.

[0085] As shown in Figure 3 , the energy consumption evaluation module of the embodiment of the present application judges whether it needs to intervene through the real-time data of the system state table. For example, as shown in Figure 5 , the energy consumption evaluation module identifies that the numerical value of the energy consumption label segment D2 shown by the dashed box in the system state table changes, and at this time, the evaluation process is triggered.

[0086] Step 202: After the energy consumption assessment module completes the processing, it records a set of temporary tags in the system status table. The temporary tags include the estimated load power value and the feasibility suggestion. The temporary tags can be read by other modules within a short-term cache to update the system status table.

[0087] In this embodiment of the invention, the energy consumption data related to task execution collected in real time is divided into multiple intervals by estimating the power value. Different intervals represent the current energy consumption status. The meaning of the estimated power value is: an estimated value of the energy consumption data related to task execution collected in real time.

[0088] like Figure 6 As shown, in one embodiment, multiple estimated power values ​​can be set, including estimated load power values ​​and estimated danger power values; all estimated power values ​​are used for simulation before the research vessel sets sail; the estimated load power values ​​and estimated danger power values ​​can be assigned ranges by those skilled in the art according to the specific application scenario. The estimated load power values ​​and estimated danger power values ​​constitute a numerical range.

[0089] The load estimate power value means: a value that indicates that the current energy consumption exceeds the load based on real-time energy consumption data related to task execution.

[0090] The energy consumption assessment module of this invention needs to perform the following processing: assessing whether it needs to respond to the changed energy consumption label segment; and when it determines that a response is needed, such as... Figure 3 As shown, a set of temporary labels is recorded in the system status table. These temporary labels include the estimated load power value and execution feasibility suggestions. At this time, the energy consumption assessment module does not actually call other modules, but it constitutes a perceptible next-state signal when the system status changes. For example, as... Figure 5 As shown, the energy consumption assessment module detects a change in the value of the energy consumption tag segment D2. After assessment, it finds that a response is needed, so it adds the estimated load power value of the energy consumption tag segment D2 and an execution feasibility suggestion to the system status table.

[0091] Among them, such as Figure 7 As shown, in step 201, the energy consumption assessment module determines whether a response is needed based on its preset response rules, including:

[0092] Step 2011: If the change value of the changed energy consumption tag segment is greater than a preset threshold, the energy consumption assessment module needs to respond.

[0093] The preset threshold is selected by those skilled in the art based on the specific use case, and is not limited here.

[0094] Step 2012: If the change value of the changed energy consumption tag fragment is less than or equal to the preset threshold value, the energy consumption evaluation module does not need to respond.

[0095] In an actual application scenario, after the scientific research ship sets sail, various energy consumption conditions of task execution can change greatly, and at this time, the data collection and storage strategy needs to be adjusted according to the change. The energy consumption evaluation module continuously works before and after the scientific research ship sets sail; because the pre-rehearsal has been performed before setting sail, and the device state module is used to adjust the data collection and storage strategy, the device state module is initially in a dormant state, and only when the energy consumption evaluation module detects that the load estimated power value exceeds, the device state module changes state and adjusts the data collection and storage strategy. Specifically, as shown in Figure 8 , the step 30 comprises:

[0096] Step 301: When the device state module continuously reads the energy consumption tag fragment, the device state module detects that the load estimated power value of the temporary tag and the device load trend have short-time overlap, and then the device state module enters the passive observation mode.

[0097] As shown in Figure 6 , the device load trend refers to a coherent curve formed by the data value detected by the real energy consumption evaluation module.

[0098] In an embodiment, the load estimated power value can be a, and the dangerous estimated power value can be b; the numerical interval in which the data value can be located can be divided into three intervals by the load estimated power value and the dangerous estimated power value, that is, the normal estimated power value interval [0, a], the load estimated power value interval [a, b], and the dangerous estimated power value interval [b, +].

[0099] Detecting that the load estimated power value of the temporary tag and the device load trend have short-time overlap refers to that the curve has overlap with the interval in which the load estimated power value is located, that is, as shown in Figure 6 , the curve enters the load estimated power value interval [a, b] in the time interval [t1, t2].

[0100] In the embodiment of the application, whether the device state module responds or not depends on the matching threshold of the state residual image, not on the explicit link call; in the passive observation mode, the data tag of the collected data is always in the frequency-variable type FB-Type, and the frequency-variable data is only used for evaluation in a specific period.

[0101] Step 302: When the device state module enters the passive observation mode, the device state module will periodically judge whether the device load trend in the energy consumption tag fragment falls back to the safety threshold value, so as to selectively perform or not perform the data tag type switching process. ​

[0102] The energy consumption tag segment is used to characterize the real-time collected energy consumption data. Energy consumption data is collected in real-time from the target device (i.e., the device involved in the energy consumption tag segment), and the corresponding device load trend is the device load trend, for example, such as... Figure 6 The curve shown. Where, as... Figure 5 As shown, the estimated power value of the temporary tag is based on a certain energy consumption tag segment (e.g., Figure 5 The energy consumption tag segment (D2) is divided into units; the value of the energy consumption tag segment represents the real-time energy consumption data collected for a certain task tag; the target device involved in the energy consumption tag segment is: the device related to real-time data collection; the device load trend periodically judged by the device status module is: the device load trend of the target device involved in the energy consumption tag segment corresponding to the temporary tag.

[0103] The safety threshold and the period for determining whether a load trend has fallen back to the safety threshold shall be selected by those skilled in the art based on the specific application scenario, and are not limited here.

[0104] In one embodiment, the safety threshold can be an estimated value of the target equipment under normal operating conditions at a corresponding stage, determined before the research vessel departs from shore; in an optional embodiment, the safety threshold can be an estimated load power value, or a value within a range of estimated load power values. Figure 6 As shown, at time t1, the device load has exceeded the safety threshold. The device status module observes whether it has fallen back below the safety threshold. At time t2, the device load falls back below the safety threshold.

[0105] In one embodiment, when the research vessel conducts a rehearsal before setting sail, it records the values ​​of the energy consumption tag segments corresponding to the data collected by each target device at each moment. The pre-specified thresholds such as the load estimated power value and the danger estimated power value are the corresponding values ​​of each target device at each moment, rather than a specific fixed value.

[0106] The data tag type switching process is used to: switch the data tag type of the energy consumption tag segment and switch the storage database type of the collected data.

[0107] Before switching, the energy consumption label segment is kept in the frequency variant FB-Type, and the corresponding collected data is stored in the time sequence database; as long as the current real-time collected data energy consumption label segment value is within the safety threshold, the data label type switching process can be performed at this time. In an embodiment, the data label type switching process is specifically: the task management module switches the energy consumption label segment from the frequency variant FB-Type to the stable type ST-Type, and makes the collected data be stored in the relational database. Wherein, the specific implementation of the relational database is selected by the person skilled in the art according to the specific use scene; in an optional embodiment, the relational database can be a MySQL database.

[0108] After switching, the real-time collected data is stored in the relational database according to the data storage mode of the stable type ST-Type.

[0109] The embodiment of the application makes the load trend of the device involved in the energy consumption label segment maintain within the safety threshold, and stores the collected data through the relational database in the stable type ST-Type mode when the load trend of the device involved in the energy consumption label segment maintains within the safety threshold.

[0110] In an embodiment, as shown in Figure 9 , the step 302 includes:

[0111] Step 3021: If the device load trend in the energy consumption label segment falls back to the safety threshold, start the data label type switching process.

[0112] Step 3022: If continuous abnormalities are detected, or the device load trend in the energy consumption label segment does not fall back to the safety threshold, do not start the data label type switching process.

[0113] In an embodiment, detecting continuous abnormalities means that the curve of the device load trend frequently exceeds the safety threshold, but each time it exceeds the safety threshold, it will immediately fall back to within the safety threshold; in this case, it is indicated that the energy consumption of the device may cause data fluctuation in the future, and immediate monitoring is required.

[0114] A specific example in which the device load trend in the energy consumption label segment does not fall back to the safety threshold is shown in the curve in the time interval [t1, t2] in Figure 6 .

[0115] Do not start the data label type switching process, that is, always observe and do not change the storage mode of the current real-time collected data (that is, keep the corresponding energy consumption label segment in the frequency variant FB-Type). In an optional embodiment, when the safety threshold is not fallen back for a certain time and / or continuous abnormalities are detected, a reminder can be sent to the user.

[0116] The embodiment of the present application allows the module to flexibly "appear" on the time axis, for example, delaying the response of non-urgent tasks to prioritize critical operations. Specifically, in one embodiment, for tasks with a priority lower than a preset level, and task requirements involving strongly associated sensors, when the difference between the load of the network bandwidth and the load limiting factor is less than a first preset value, the corresponding energy consumption tag fragment is switched from the frequency variant FB-Type to the slow variant MB-Type, and the collected data is stored in the document type database; wherein the task requirements involving strongly associated sensors are task requirements with a degree of dependence on other sensors greater than a second preset value.

[0117] The preset level, the first preset value, the load limiting factor, and the second preset value are determined by a person skilled in the art according to the specific use scenario, and are not limited herein. In the embodiment of the present application, the importance of each task requirement can be represented by the task priority, and the preset level is a threshold of a pre-specified task priority. In actual application scenarios, there are often many task requirements that need to be based on the data collected by other sensors, wherein the other sensors refer to sensors other than the target device executing the current task; the degree of dependence on other sensors can be represented by a dependence level, and the second preset value is a threshold of a pre-specified dependence level. The load limiting factor is a threshold of network bandwidth.

[0118] In order to reduce the data update frequency, the frequency variant FB-Type is switched to the slow variant MB-Type, thereby reducing the occupation of network bandwidth and avoiding network overload. At the same time, the system stores the current system state table in the document type database for subsequent query and analysis. By optimizing the use of network resources, the system can still run stably under high load, while retaining system state information for subsequent reference.

[0119] It should be noted that if the network bandwidth in the system is limited, and the task involving strongly associated sensors needs to update data frequently, it may occupy a large amount of network resources. Therefore, in this case, when the network load is high, the normal operation of other tasks (such as high-priority tasks) can be prioritized, and the task involving strongly associated sensors can be temporarily suspended to avoid network congestion. When the network bandwidth is almost full, the system will preferentially "cut off" those data collection tasks that are neither important nor dependent on other sensors, because the absence of this part of the collected data will not cause the overall data chain to break (for example, it can be indirectly calculated or compensated by other sensors), so pausing their upload can free up bandwidth to ensure that critical task data (such as alarms and control instructions) is delivered in real time, avoiding system crashes or delays.

[0120] In addition, there is a case that when the task does not explicitly declare the power requirement (i.e., the load estimation power value of the energy consumption label segment under a certain task label is not determined), the energy consumption evaluation module cannot be triggered, and the device state module also cannot receive a valid residual signal (i.e., it cannot be judged whether the data label type switching process is to be performed). In an embodiment, in this state, the system will enter an empty state waiting period, and the corresponding energy consumption label segment continues to remain in the frequency-variable FB-Type, avoiding chain mis-touch and improving system stability.

[0121] It is worth noting that the system state table of the embodiment of the present application records the set interval in advance through the estimation power value, and then determines whether the energy consumption label segment belongs to the frequency-variable data or the stable data under the current state according to the value of the energy consumption label segment, and switches between various data types, so as to flexibly adjust the data storage mode (for example, stored in which type of database) according to the running state.

[0122] The present application realizes the construction of potential collaborative channels between modules through cross-excitation without relying on the central task scheduling structure, which is suitable for complex environments with multiple task entrances, multiple submodule feedbacks, and multiple data perception driving.

[0123] The embodiment of the present application provides a highly dynamic and adaptive system, which realizes weak coupling between modules through fuzzy response bands and space-time residual structures, and realizes non-explicit wake-up. The system establishes dynamic node relationships through the system state table and the label, and supports asynchronous loading and self-organization iteration. The overall behavior of the system is the result of the interaction between modules, rather than being directly controlled by a central controller. This enables the system to flexibly adjust its behavior in a complex and variable environment and adapt to different operating conditions. Compared with the traditional way of calling modules in series through a central scheduler, the response chain of each module of the system of the embodiment of the present application is dynamically generated according to the running signal, supporting module-level asynchronous perception and response; the state projection and behavior residual mechanism can realize delayed propagation of information and secondary state linkage; when a new module is added, it only needs to add a perception label to access, without the need to change the existing link. Therefore, it is especially suitable for complex scenarios such as ship-shore cooperation and multi-source data prediction tasks, where there are multiple rounds of asynchronous judgment and iterative optimization before task execution.

[0124] The mechanism of the present application emphasizes signal driving, state sensitivity, and behavior return, and provides a dynamic chain response structure suitable for nonlinear evolution environment of multiple tasks and multiple modules, which has good engineering scalability and algorithm universality.

[0125] As Figure 10Fig. 1 is a schematic diagram of an architecture of an implicit multi-stage trigger chain device according to an embodiment of the present application. The implicit multi-stage trigger chain device according to the embodiment includes one or more processors 21 and a memory 22. In the embodiment, the processor 21 is taken as an example. Figure 10

[0126] The processor 21 and the memory 22 can be connected through a bus or other means, Figure 10

[0127] The memory 22 is a non-volatile computer readable storage medium and can be used to store non-volatile software programs and non-volatile computer executable programs, such as the implicit multi-stage trigger chain method in Embodiment 1. The processor 21 executes the implicit multi-stage trigger chain method by running the non-volatile software programs and instructions stored in the memory 22.

[0128] The memory 22 can include a high-speed random access memory and can also include a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, or other non-volatile solid-state memory device. In some embodiments, the memory 22 can optionally include a memory remotely disposed relative to the processor 21, and these remote memories can be connected to the processor 21 through a network. Examples of the network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0129] The program instructions / modules are stored in the memory 22 and, when executed by the one or more processors 21, perform the implicit multi-stage trigger chain method in Embodiment 1 described above, for example, perform each step of the implicit multi-stage trigger chain method described above.

[0130] It is worth noting that the information interaction, execution process, and the like between the modules and units in the above-described device and system are based on the same concept as the processing method embodiments of the present application, and the specific content can be referred to the description in the method embodiments of the present application, which will not be described here.

[0131] Those of ordinary skill in the art can understand that all or part of the steps in the various methods of the embodiments can be completed by a program instructing relevant hardware, and the program can be stored in a computer readable storage medium, which can include a read only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and the like.

[0132] The above only describes the preferred embodiments of the present application and should not be used to limit the present application. Any modifications, equivalent replacements, and improvements made within the spirit and principle of the present application shall be included in the protection scope of the present application.​​

Claims

1. An implicit multi-segment trigger chain method, characterized in that, Users submit task requirements, which may include one or more of the following: sampling points, time window, and task type. Methods include: The task management module in the system is activated, and a set of task tags representing the expected load power of the task requirement is written into the system status table. The task management module then enters a weak disturbance dynamic. The energy consumption assessment module in the system identifies changes in the energy consumption tag segment in the system status table and updates the system status table accordingly. The energy consumption tag segment is located in the task tag subset corresponding to the expected load power. The energy consumption tag segment is a frequency-varying FB-Type data tag. The system status table is stored in a time-series database. The device status module switches the data tag type of the energy consumption tag segment according to the system status table, and stores the collected data according to the data tag type; For tasks with a priority lower than a preset level and involving strongly correlated sensors, when the difference between the network bandwidth load and the load limiting factor is less than a first preset value, the corresponding energy consumption tag segment is switched from frequency-varying FB-Type to slowly varying MB-Type, and the collected data is stored in a document-type database; wherein, the task requirement involving strongly correlated sensors is a task requirement whose dependence on other sensors is greater than a second preset value.

2. The implicit multi-segment trigger chain method according to claim 1, characterized in that, The energy consumption assessment module in the system identifies changes to the energy consumption label segment in the system status table, and then updates the system status table by: When the energy consumption assessment module identifies a change in the energy consumption label segment in the system status table, it triggers an assessment in conjunction with the built-in rule model. The assessment was not explicitly initiated by the task management module, but because there was an energy consumption tag fragment in the system status table as a residual feature, the energy consumption assessment module determined whether a response was needed based on its preset response rules. After the energy consumption assessment module completes its processing, it records a set of temporary tags in the system status table. The temporary tags include the estimated load power value and the feasibility suggestion. The temporary tags can be read by other modules within a short-term cache to update the system status table.

3. The implicit multi-segment trigger chain method according to claim 2, characterized in that, The energy consumption assessment module determines whether a response is needed based on its preset response rules, including: If the change value of the modified energy consumption tag segment is greater than a preset threshold, the energy consumption assessment module needs to respond. If the change value of the modified energy consumption label segment is less than or equal to a preset threshold, the energy consumption assessment module does not need to respond.

4. The implicit multi-segment trigger chain method according to claim 2, characterized in that, The device status module switches the data tag type of the energy consumption tag segment according to the system status table, and stores the collected data according to the data tag type, including: When the device status module continuously reads energy consumption tag fragments, if it detects that the estimated load power value of the temporary tag and the device load trend overlap briefly, the device status module enters passive observation mode. When the device status module enters passive observation mode, it will periodically determine whether the device load trend in the energy consumption tag segment has fallen back to the safe threshold, so as to selectively perform or not perform the data tag type switching process. The data tag type switching process is used to: switch the data tag type of the energy consumption tag segment and switch the storage database type of the collected data.

5. The implicit multi-segment trigger chain method according to claim 4, characterized in that, The device status module periodically determines whether the device load trend in the energy consumption tag segment has fallen back to a safe threshold, and selectively performs or does not perform data tag type switching. The process includes: If the device load trend in the energy consumption tag segment falls back to the safe threshold, the data tag type switching process is initiated. If continuous anomalies are detected, or if the device load trend in the energy consumption tag segment does not fall back to the safe threshold, the data tag type switching process will not be initiated.

6. The implicit multi-segment trigger chain method according to claim 4, characterized in that, The specific process for switching data tag types is as follows: The task management module switches the energy consumption tag segment from the frequency-varying FB-Type to the stable ST-Type and stores the collected data in a relational database.

7. The implicit multi-segment trigger chain method according to any one of claims 1-6, characterized in that, The input methods for the task requirements include: manual configuration via the front-end interface and / or batch import of structured parameters.

8. A non-volatile computer storage medium, characterized in that, The computer storage medium stores computer-executable instructions, which are executed by one or more processors to perform the implicit multi-segment trigger chain method according to any one of claims 1-7.

9. An implicit multi-segment trigger chain device, characterized in that, include: At least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the processor for performing the implicit multi-segment trigger chain method according to any one of claims 1-7.

Images