Body intelligent robot application side message classification and storage method and device and medium

Abstract

The application discloses a kind of body intelligent robot application side message classification warehouse entry method, device and medium.The method separates application side message interpretation boundary and database execution boundary as target, receives the publish-subscribe protocol message corresponding to multiple product types, carries out field extraction and integrity check to message and is packaged as uniform message structure;Message is grouped according to product type and is classified according to message method type;For corresponding classification, call plug-in to generate database operation instruction and parameter result, and by main program in write execution layer complete result contract verification, write action legality verification and key field integrity check, when not meet the requirement, block database write;When product type set changes, restore consistent with current plug-in set subscription relationship.

Description

Technical Field

[0001] This invention relates to the field of application-side business message interpretation and data management technology for embodied intelligent robots, specifically to a method, apparatus, and medium for classifying and storing application-side messages of embodied intelligent robots. Background Technology

[0002] Embossed intelligent robots typically need to receive messages from multiple sources during operation, including device controllers, sensing units, host systems, or access gateways, and write these messages into corresponding data tables. For robot systems that simultaneously access multiple product types of devices, different messages often exhibit significant differences in topic expression, field structure, method type, and database entry target. These issues mainly occur during the interpretation, classification, and database execution control stages after the messages reach the application processing side.

[0003] In existing message storage solutions, a common approach is to write fixed parsing logic for each type of message or to centrally maintain a large number of conditional judgments in the main program. This approach works when there are few product types, but as the number of access objects continues to increase, the message method types expand, and the target data table structure changes frequently, the main program can easily swell rapidly, leading to increased maintenance costs, decreased expansion efficiency, and an increased probability of errors in subsequent adjustments.

[0004] Although messages for different product types all enter the system through the publish-subscribe protocol, their field names, field levels, status representations, and database entry targets are not uniform. If a unified message structure and standardized verification mechanism are lacking at the access point, problems such as some messages being received but failing to be stably entered into the database, some missing fields still being incorrectly written, or the same type of business message behaving inconsistently across different product types can easily occur.

[0005] When a system needs to add new product types, replace plugin implementations, switch plugin versions, or restore the original access relationships after a restart without interrupting business operations, traditional fixed implementations often lack the corresponding configuration recovery and hot update capabilities. This results in the need to modify the main program or manually reorganize the subscription relationships for each adjustment, affecting the system's continuous operation capability.

[0006] Existing application-side message ingestion solutions often couple product type identification, field interpretation, target table mapping, and database write operations into the same process. When the message structure changes, plugin implementations switch, or the product type set is adjusted, the interpretation entry point, plugin input boundaries, and pre-write validation responsibilities are prone to shift simultaneously, and abnormal results are more likely to directly reach the database execution layer. Therefore, the key issue is not communication link switching or on-site object location maintenance, but the lack of controlled isolation between application-side message interpretation and database execution. Summary of the Invention

[0007] The purpose of this invention is to provide a method, apparatus, and medium for classifying and storing application-side messages in an embodied intelligent robot, so as to establish a controlled storage link that separates application-side message interpretation from database execution, thereby solving the problems of inconsistent message interpretation entry points for different product types, unstable plug-in input boundaries, and abnormal results easily entering the database execution layer directly.

[0008] To achieve the above objectives, the present invention adopts the following technical solution: receiving publish / subscribe agreement messages corresponding to multiple product types, performing field extraction and integrity verification on the messages, and encapsulating the verified messages into a unified message structure; filtering the messages corresponding to the unified message structure according to preset topic or operation identifier filtering rules and device name filtering rules; grouping the filtered messages according to product type, and classifying them into attribute reporting message class, request / response message class, and event log message class according to message method type; calling the corresponding plugin for each product type and message category, and generating database operation instructions and parameter results using the unified message structure and processing context as the controlled input boundary of the plugin; the main program performs result contract verification, write action legality verification, and key field integrity verification on the database operation instructions and parameter results in the write execution layer, and blocks database writing when the corresponding requirements are not met.

[0009] The unified message structure includes at least a timestamp, a unique message identifier, a message method type, a device name, a message content, a message status, and a topic or operation identifier. It is also associated with the product type and the message category determined by the message method type at the outer layer. Through this unified message structure, original protocol messages from different product types obtain a consistent data organization form before entering subsequent processing stages, thereby reducing disagreements in multi-source message parsing and establishing a unified pre-write verification boundary for the execution layer.

[0010] Integrity verification can determine the corresponding set of required fields based on different message method types. When a message lacks a corresponding required field, a field is empty, or the status transition of a request-response message fails, the message is determined to be invalid and removed before entering the plugin for processing, in order to reduce the risk of abnormal database entry caused by invalid messages entering the database writing process.

[0011] When a plugin with the same name has at least two valid implementations, the version number is compared first. If the version numbers are the same, the modification time is then compared with a preset time difference threshold to determine the currently effective plugin. When only one implementation is valid, that valid implementation is selected. This selection rule is used to determine the unique effective plugin while maintaining stable write execution boundaries.

[0012] A plugin is only considered as a candidate plugin when it exists, matches the corresponding product type, and can be loaded to return version and function information usable for message processing. The plugin, also referred to as the parsing implementation below, receives a unified message structure, product type context, and message category context according to a preset input / output protocol, and outputs database operation instructions, key location fields, and parameter result lists consistent with the target data table requirements. The result contract verification refers to the main program performing the following checks on the database operation instructions and parameter results at the execution layer: whether the database operation instructions are non-empty strings and conform to the preset structured query language syntax; whether the parameter result list is a non-empty list and whether each parameter type corresponds one-to-one with the placeholder order and type in the database operation instructions; and whether the key location fields contain the primary key field or unique index field of the target data table. This stabilizes the differential message interpretation, result contract verification, and database execution boundaries within a controllable chain.

[0013] In an optional implementation, the system can detect changes to plugin files during operation; when a plugin change does not affect the product type set, a hot update is performed; when a plugin change affects the product type set, a temporary configuration is recorded, and after a system restart, the subscription relationship consistent with the current product type set is restored based on the temporary configuration. The former scenario corresponds to plugin updates within the existing access range, and the latter scenario corresponds to recovery processing after a change in the access range.

[0014] In an optional implementation, upon receiving a request to add a new product type, the product type to be added is first written to a temporary configuration. Then, it is checked whether there is a plugin that corresponds to the product type and meets the validity requirements. If a corresponding plugin exists, the current access set is updated. If no corresponding plugin exists or the plugin does not meet the requirements, the current access set remains unchanged. Adding a new product type is contingent upon a change in the product type set.

[0015] This invention also provides a message classification and database entry device for an embodied intelligent robot application, including a message receiving module, a message standardization module, a filtering control module, a classification and distribution module, a plug-in processing module, a write execution module, and a configuration recovery module. The plug-in processing module is responsible for receiving a unified message structure and classification context and generating database operation instructions and parameter results. The write execution module is responsible for having the main program verify that the database operation instructions and parameter results meet the preset result contract, that the write action is legal, and that the key fields are complete before uniformly executing the database write. The configuration recovery module is responsible for restoring the access set and subscription relationship in optional plug-in change and system restart scenarios.

[0016] The present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the above-described method for classifying and storing application-side messages of an embodied intelligent robot.

[0017] Field extraction, integrity verification, product type grouping, and message method type classification together form a unified interpretation entry point, enabling protocol messages from different sources to be converted into consistent input before entering the plugin, reducing interpretation discrepancies before entering the database execution layer.

[0018] The plugin only generates the results of operations on the target table. The main program has exclusive responsibility for database connection, transaction and legality verification at the write execution layer. Therefore, illegal write operations, results with missing key fields and outputs that do not meet the result contract will be intercepted before writing to the database.

[0019] When the product type set changes, the selection of the only effective plugin and the restoration of temporary configuration limit the subscription scope adjustment to the current plugin set to avoid mismatch between receiveable messages and executable write rules after system restart. Attached Figure Description

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

[0021] Figure 1 This is a schematic diagram of the overall process of message classification and storage in this invention.

[0022] Figure 2 This is a schematic diagram illustrating the relationship between the unified message structure and field standardization of this invention.

[0023] Figure 3 This is a schematic diagram illustrating the relationship between product type grouping and message method type classification in this invention.

[0024] Figure 4 This is a schematic diagram of the plugin validity verification and activation selection process of the present invention.

[0025] Figure 5 This is a schematic diagram of the hot update and subscription relationship restoration process for the plugin of this invention.

[0026] Figure 6 This is a schematic diagram of the process for determining the access of new product types in this invention.

[0027] Figure 7 This is a schematic diagram of the module composition of the application-side message classification and storage device for the embodied intelligent robot of the present invention.

[0028] Figure 8 This is a schematic diagram illustrating the relationship between the unified message structure, plugin processing results, and database writing in this invention.

[0029] Figure 9 This is a schematic diagram illustrating the input, output, and processing relationships of the message classification and warehousing device for the embodied intelligent robot application side of the present invention. Detailed Implementation

[0030] The present invention will be further described below with reference to the accompanying drawings and specific embodiments. It should be understood that the following embodiments are used to illustrate the technical solutions of the present invention, and are not intended to limit the scope of protection of the present invention.

[0031] The embodied intelligent robot field system receives publish-subscribe protocol messages corresponding to multiple product types. Here, "application side" refers to the processing layer where the embodied intelligent robot performs business interpretation, data classification, format conversion, and database write control after message reception, distinct from the physical communication access layer and protocol parsing layer. The product type refers to the business object classification identifier of the publish-subscribe protocol message source, which can be any of the following: device model identifier, business object category identifier, or protocol access point identifier. Within the same system, each message source determines its product type based on a pre-configured classification mapping relationship. Before the message reaches the processing link of this invention, it has typically already been received and forwarded by the communication access side; this invention begins its operation from the application side's message interpretation, classification and distribution, and database write control stages.

[0032] After a publish / subscribe agreement message enters the system, it first enters the message standardization unit to perform field extraction. Field extraction separates and organizes the time information, status information, device information, topic information, and business content in the original message based on the protocol hierarchy, message body nesting, and the location of business fields, forming the interpretive input required for subsequent classification and database writing. Specifically, the message method type can be obtained by parsing the method type identifier from the topic field, reading it from the method name field in the message body, or mapping it based on the protocol opcode. During the message standardization phase, the system uniformly converts the method type identifier in the original message into an internal message method type value according to pre-configured mapping rules.

[0033] After field extraction, the system performs an integrity check on the message. The integrity check can predetermine the required field set based on the message method type. For example, for attribute reporting messages, it checks whether they contain attribute identifier and value fields; for request-response messages, it checks whether they contain request identifier, response result, or status fields; for event log messages, it checks whether they contain event category, event content, or event result fields. If any relevant fields are missing, empty, or the status transition relationship is invalid, the message can be determined as invalid and removed before entering the plugin for processing.

[0034] For messages that pass verification, the system encapsulates them into a unified message structure. This unified message structure may include fields such as timestamp, unique message identifier, message method type, device name, message content, message status, and topic or operation identifier, and is associated with the product type and message category determined by the message method type. Through this unified encapsulation, messages under different protocol topics share a consistent data entry point in subsequent processing stages.

[0035] The unified message structure can also be supplemented with auxiliary fields such as reception time, access source, parsing status, device identifier, or target table prompt information to enhance the ability to locate subsequent anomalies and verify write results, while maintaining the stability of the interface between field extraction, classification and distribution, and write control.

[0036] For messages corresponding to a unified message structure, the system can filter them according to preset topic or operation identifier filtering rules and device name filtering rules. These filtering rules can be used to exclude debugging messages that do not need to be entered into the database, duplicate messages, messages from non-target devices, or messages that do not belong to the current access set. Through filtering control, messages that truly need to enter classification processing and database writing can be selected.

[0037] For messages that pass the filter, the system first groups them according to product type. The purpose of grouping by product type is to distinguish the parsing logic, target table structure, and call relationships corresponding to different product objects, so that subsequent interpretation and processing can directly revolve around the current product type. After completing product type grouping, the system further categorizes messages based on message method type.

[0038] Based on message method type, messages can be divided into attribute reporting messages, request / response messages, and event log messages. Attribute reporting messages typically carry status parameters, numerical samples, or attribute change information; request / response messages typically carry command execution results, interactive feedback, or confirmation status; and event log messages typically carry business events, exception events, or process records.

[0039] By following the processing order of "grouping by product type first, and then classifying by message method type", the system can simultaneously determine the product scope and business category to which the message belongs, thereby establishing a clear context for subsequent parsing, selection, result generation, and target data table mapping.

[0040] For each product type and message category, the system calls the corresponding parsing implementation to generate database operation instructions and parameter results. The parsing implementation can be a message interpretation plugin or a parsing plugin. It does not directly undertake the final database write action, but is responsible for receiving a unified message structure and the processing context of the corresponding product type and message category, and generating processing results corresponding to the write to the target data table. For example, it determines the target table name, field mapping relationship, field value method, write action type, and set of parameters to be written.

[0041] The main program executes database writes based on the database operation instructions and parameter results in the write execution layer. By centralizing database connection management, transaction control, rollback processing, exception handling, and write log recording in the same execution layer, and only proceeding to the database write action when the corresponding processing result meets the unified result contract, the write action is legal, and the key fields pass the validation, the interpretation boundary and the database execution boundary can be kept separate.

[0042] After completing field extraction and integrity verification, the system first establishes a processing context based on product type, then establishes a classification context based on message method type, and finally calls the corresponding parser to generate database operation instructions and parameter results based on the two-layer context. The aforementioned processing order is used to simultaneously limit the product scope, message business semantic scope, and interpretation boundaries of the message before entering the database write process.

[0043] The parsing implementation interprets the meaning of differentiated fields only within a unified message structure and outputs the target data table, write action type, key location fields, and parameter results. The main program, at the write execution layer, is responsible for common execution controls such as database connection management, transaction control, exception handling, and result recording. The system only allows the corresponding write action when the returned result meets the preset input / output protocol and the key fields are complete, in order to maintain the separation between message interpretation boundaries and database execution boundaries.

[0044] Attribute reporting messages, request-response messages, and event log messages under the same product type typically correspond to different target data tables, different field mapping standards, and different status update rules. Even if different product types use the same message method type, their field interpretation methods and target table structures may differ. Therefore, this invention adopts a processing order of "product type grouping first, message method type classification second" to provide stable input boundaries for parsing implementation selection, result contract verification, and write control based on a unified message structure.

[0045] During the result contract verification phase, after receiving the return result at the write execution layer, the main program can perform a secondary validity check on the database operation instructions and parameter results. The result contract verification refers to: the database operation instructions being non-empty strings and conforming to the preset structured query language syntax; the parameter result list being a non-empty list, with each parameter type corresponding one-to-one with the placeholder order and type in the database operation instructions; and the key positioning field containing the primary key field or unique index field of the target data table. In addition, the main program can also check whether the target data table identifier exists, whether the write action type is within a preset range, and whether the parameter results meet the mandatory requirements. Thus, the system forms a layered control boundary with integrity verification layer blocking, result contract verification layer blocking, and abnormal termination at the database execution layer. Only when the return result satisfies the unified result contract and passes the above validity checks will the system execute subsequent database writes; if the verification fails, the system blocks the corresponding write action at the write execution layer and records the abnormal result. By adding this layer of verification, illegal write actions, missing key field results, or outputs that do not meet action constraints can be restricted before the database execution layer.

[0046] Database operation commands and parameter results can include different write actions such as insert, update, replace, or ignore, and different target tables can be selected according to message type. For example, attribute reporting messages can correspond to the status data table, request response messages can correspond to the interaction result table, and event log messages can correspond to the event record table.

[0047] Before the corresponding parsing implementation participates in processing, the system may first perform a validity check. This validity check may include at least checking whether the implementation file exists, whether it matches the current product type, whether it can be loaded, and whether it can return version information and function information usable for message processing. Only candidate implementations that meet the aforementioned conditions will enter the candidate set.

[0048] When at least two valid implementations exist for the same name resolution, the system prioritizes comparing version numbers. If version numbers are the same, it then compares the modification time with a preset time difference threshold to determine the currently effective implementation. When only one implementation is valid, that valid implementation is directly selected. This selection mechanism is used to avoid the problem of unclear effective objects when implementation files coexist.

[0049] The parsing implementation can be implemented using either an interpretable module or a compileable module. Regardless of the form, as long as it can parse the unified message structure according to the preset input / output protocol and output database operation instructions and parameter results consistent with the requirements of the target data table, it can be incorporated into the current processing framework.

[0050] In an optional implementation, the system can continuously monitor changes to the plugin implementation files during operation. When a plugin implementation change does not affect the product type set, the system can perform a hot update, updating the currently effective implementation to the new effective implementation without changing the product type set, and without interrupting the message access link.

[0051] In an optional implementation, when a plugin implementation change affects a set of product types, the system records a temporary configuration and restores the subscription relationship consistent with the current set of product types based on the temporary configuration after a system restart. The temporary configuration is a configuration record file or configuration data table entry stored in non-volatile storage media, and includes at least the set of product types before the change, the set of product types after the change, a change timestamp, a list of affected plugin identifiers, and a snapshot of the current access subscription relationship. Upon system restart, the configuration recovery module reads the temporary configuration, re-establishes the message subscription relationship based on the set of product types contained therein, and clears or archives the corresponding temporary configuration record after successful recovery.

[0052] In an optional implementation, when the system receives a request to add a new product type, it first writes the product type to be added into a temporary configuration, and then checks whether there is a corresponding plugin implementation that meets the validity requirements. If a corresponding implementation exists, the current access set is updated; if no corresponding implementation exists or the implementation does not meet the requirements, the current access set remains unchanged. Following this processing order, the system first completes the feasibility judgment for adding a new product type, and then decides whether to update the access set.

[0053] For a product type attribute reporting message, the corresponding parsing implementation can map the status field in the unified message structure to the measurement point field and value field in the status data table; for a request-response message of the same product type, the message unique identifier, result status, and return content can be mapped to the request identifier, processing status, and result description fields in the interaction result table; for an event log message, the event category, event time, and event description can be mapped to the corresponding fields in the event record table.

[0054] In the device implementation, the message receiving module receives business messages from the embodied intelligent robot application side and outputs them to the message standardization module; the message standardization module extracts fields from the received messages, performs integrity checks, and encapsulates them into a unified message structure; the filtering control module filters messages corresponding to the structure according to preset rules; the classification and distribution module receives the structure and filtering results, groups the filtered messages according to product type, and completes the classification path division according to message method type; the plug-in processing module receives the structure and classification path, and generates database operation instructions and parameter results; the write execution module is used by the main program to maintain database connections, transaction control, and blocking processing at the write execution layer, and executes database writing after verifying that the database operation instructions and parameter results meet the preset result contract, the write action is legal, and the key fields are complete; the configuration recovery module is used to restore the access relationship consistent with the current product type set in the case of system restart or implementation change.

[0055] like Figure 7 As shown, the embodied intelligent robot application-side message classification and database entry device may include a message receiving module, a message standardization module, a filtering control module, a classification and distribution module, a plug-in processing module, a write execution module, and a configuration recovery module. The message receiving module receives publish-subscribe agreement messages from the embodied intelligent robot application side and outputs them to the message standardization module. The message standardization module performs field extraction, integrity verification, and unified structure encapsulation on the received publish-subscribe agreement messages. The filtering control module filters messages corresponding to the unified message structure according to preset rules. The classification and distribution module completes the classification path division by combining product type context and message category. The plug-in processing module receives the unified message structure according to the classification results and generates database operation instructions and parameter results. The write execution module performs result contract verification, write action legality verification, and key field integrity verification on the returned results at the write execution layer before executing database writing. The configuration recovery module restores the access relationship in optional system restart or implementation change scenarios.

[0056] like Figure 9 As shown, Figure 9 Can be regarded as Figure 7The schematic diagram of the message classification and warehousing device module for the embodied intelligent robot application side is shown in the input-output and processing relationship dimensions. The message standardization unit corresponds to the standardization processing stage of the message standardization module, the classification determination unit corresponds to the classification determination stage of the classification distribution module, the plug-in execution unit corresponds to the rule execution stage of the plug-in processing module, and the unified warehousing unit corresponds to the unified writing stage of the write execution module. After the incoming message source enters the message standardization unit, a unified message structure is formed. The classification support data provides the product context and rule entry to the classification determination unit. The classification determination unit distributes the unified message structure and classification results to the plug-in execution unit. The plug-in execution results are sent back to the unified warehousing unit. The unified warehousing unit, after the main program verifies the legality of the result contract, key fields, and writing action at the write execution layer, executes the database write.

[0057] In one embodiment of the medium, a computer-readable storage medium stores a computer program that, when executed by a processor, can implement the steps of the above-described message classification and storage method.

[0058] In the field standardization implementation, the system can extract the subject field, method field, payload field, device field, and status field from the original protocol message and write them into the corresponding positions in the unified message structure. For fields that already exist in the original message but have inconsistent naming conventions, they can be renamed during the standardization stage using field mapping rules to ensure they meet the unified structure requirements before entering subsequent processing stages. This field standardization is used to unify messages of different product types into the same main program parsing framework.

[0059] In the message verification implementation, the system first loads the corresponding verification template according to the message method type, and then checks item by item according to the template to see if the required fields of the message exist, whether the field values ​​are empty, and whether the constraints between the fields are valid. For request-response messages, it can further check whether the request identifier and the response identifier can form a corresponding relationship; for event log messages, it can further check whether the event time and event content exist simultaneously. The verification template is used to adapt to the verification requirements of different product types under a unified verification process.

[0060] In the rule-based filtering implementation, topic or operation identifier filtering rules can be used to determine whether a message belongs to the current database entry scope, and device name filtering rules can be used to determine whether the message source belongs to the current set of accessed devices. If a message passes the field integrity check, but its topic is not in the target topic set, its device name is not in the access list, or it belongs to an excluded object, then the message can be directly filtered before entering the product type group. The rule filtering is used to block non-target messages before plugin processing and database writing.

[0061] In the grouping and classification implementation, the system can first establish a classification context using product type as the primary processing dimension and then using message method type as the secondary processing dimension. For the same product type, the attribute reporting message processing path, request-response message processing path, and event log message processing path can be maintained in parallel; for different product types, their respective corresponding plugins are invoked. This grouping and classification method ensures that the processing of different message categories within the same product type unfolds in an orderly manner and separates the processing between different product types.

[0062] In one implementation of the plugin output, the database operation instructions and parameter results output by the plugin can indicate not only the target table and field value method, but also the write action type, primary key positioning field, conflict update field, or additional explanatory information. After receiving the processing results, the main program can complete database connection acquisition, write action selection, exception capture, and result recording in the write execution layer according to unified execution rules. When a key positioning field is missing, the write action is invalid, or the parameter result is inconsistent with the placeholder constraint, the main program blocks the corresponding database write in the result contract verification stage of the write execution layer to prevent the exception message from entering the database execution layer.

[0063] In the plugin input constraint implementation, the plugin does not directly receive the original publish-subscribe protocol messages, but instead receives a set of messages after the main program has completed field extraction, integrity verification, and unified structure encapsulation. The unified message structure includes at least a timestamp, a unique message identifier, a message method type, a device name, a message body content, a status result, and an operation identifier. The product type context is provided by the main program after grouping by product type, while the message category information is provided by the main program selecting the corresponding processing entry point within the plugin. The input constraints are used to retain the responsibility for original message access and basic verification on the main program side.

[0064] In one implementation of the plugin output contract, the minimum common result structure of the plugin output may include database operation instructions, key location fields, and a parameter result list in the same order as the placeholders for the instructions. After receiving the plugin output result, the main program can first verify in the write execution layer whether the target data table identifier, write action type, key location fields, and parameter result list satisfy the unified contract; only when the contract is satisfied will the database execution phase in the write execution layer be opened.

[0065] In one version selection implementation, when multiple candidate files for a plugin with the same name exist simultaneously, the system can first determine the higher version candidate based on the version number. If multiple candidate files have the same version number, the modification time is further compared, and a preset time difference threshold is used to determine whether there is a significant difference between the old and new versions. If the time difference exceeds the threshold, the candidate with the more recent modification time is selected first. If the time difference does not exceed the threshold, the established effective object remains unchanged, and the processing entry and subscription status corresponding to the current product type are retained to reduce the processing chain jitter caused by repeatedly switching plugins with the same name in a short period of time.

[0066] In the implementation of plugin hot update, when the system detects a change in the plugin file that only involves adjustments to the parsing logic for existing product types without altering the product type set, the system can reload the plugin without interrupting message reception, allowing subsequent messages to directly enter the updated plugin processing chain. Hot update is only used when the product type set remains unchanged.

[0067] In one implementation of subscription relationship restoration, when a plugin change affects the product type set, the system can write the current set of accessed product types, the status of product types to be added, the status of product types to be removed, and associated subscription object information into a temporary configuration. This temporary configuration serves as restoration input after a restart, used to rebuild the target access scope and verify whether it remains consistent with the current product type set, thus avoiding manual reorganization of access relationships. The restoration input may also include differences in product types before and after the change and corresponding subscription object identifiers, so as to rebuild the access scope according to a predetermined restoration order.

[0068] In one implementation of adding a new product type, upon receiving a new request, the system does not immediately include the product type in the current access set. Instead, it first completes a temporary configuration record and plugin existence check. If the plugin exists and meets the validity requirements, the new product type is merged into the current access set, and the system begins receiving its corresponding publish / subscribe protocol messages. If the plugin does not exist, cannot be loaded, or returns incomplete information, the system maintains the original access set. This scenario corresponds to access control when the product type set changes.

[0069] In one message writing scenario, within the same time period, it's possible to simultaneously receive attribute reporting messages from one product type, request / response messages from another product type, and event log messages from a third product type. The system first performs standardized processing, then sends the three types of messages to their respective plugins and writes them to different target data tables. This implementation primarily illustrates a parallel access scenario for different message types.

[0070] In one implementation of classification context governance, the system can maintain an independent classification context object for each product type. This classification context object records at least the currently available plugin set, message category mapping rules, the most recent loading result, and the corresponding subscription source information. When the same product type receives messages of different message method types consecutively within a short period, the system can directly reuse the established classification context without repeatedly constructing the plugin selection range and rule matching range, thereby reducing the context reconstruction overhead in high-frequency access scenarios. If the corresponding classification context is detected to be invalid, the system reloads the corresponding plugin status and classification rules for that product type.

[0071] In the implementation of execution result logging, after the main program completes the database write at the execution layer, it can record the product type, message category, target data table, execution action, execution time, execution status, and a summary of the failure reason. This result summary is used to stably associate the plugin interpretation result with the final database write result, and provides a basis for subsequent verification, cause confirmation before manual replay, and rule correction. For messages of successful execution, this summary can be used to verify whether the target database write result has been formed; for messages of failed execution, this summary can be used to limit the entry point for subsequent manual investigation or rule revision.

[0072] In one implementation of message re-entry governance, when the same message re-enters the system due to network replay, repeated device reporting, or manual reprocessing, the main program at the write execution layer can first compare the message's unique identifier, product type, message category, and target action summary to determine whether the message belongs to the duplicate processing object. For messages that have been completed and are not allowed to be written repeatedly, the processed status can be returned directly; for messages that are allowed to be overwritten according to idempotent rules, the write execution path continues.

[0073] In a runtime isolation implementation, the system can record message reception, classification processing, plugin generation results, and database writing results in their respective runtime stages. When an anomaly occurs in any stage, only the processing path corresponding to the current message or the current product type is blocked, rather than directly escalating to a complete halt in all incoming messages.

[0074] In one exception handling implementation, if a message is identified as invalid during the integrity verification phase, the system directly terminates its subsequent processing path and records the reason for the integrity failure. If a message cannot generate a valid database operation instruction during the plugin processing phase due to a missing plugin, an abnormal plugin return result, or incomplete parameter results, the main program terminates the current write operation at the write execution layer and retains the plugin failure information. This layered interception method is used to cut off the error path before the message enters the database execution layer.

[0075] In one refined implementation of failure boundaries, the system can classify exception handling into at least three control boundaries: integrity failure, plugin failure, and write failure. Integrity failure corresponds to situations where a message lacks required fields, field values ​​are empty, or state transitions fail. Plugin failure corresponds to situations where a plugin is missing, a plugin cannot be loaded, the plugin's return result structure is invalid, or parameter results are incomplete. Write failure corresponds to situations where the target table is unavailable, target fields do not match, or database exceptions occur during execution. These three types of failures correspond to the validation layer boundary, plugin layer boundary, and execution layer boundary, respectively.

[0076] In a closed-loop recovery implementation, for messages of plugin failure or write failure, the system can retain a unified message structure, product type, message category, plugin generation result, and failure reason information to support subsequent verification, rule correction, plugin replacement, or reprocessing. For system restart scenarios triggered by plugin changes affecting the product type set, the configuration recovery module restores only the access range consistent with the currently valid plugin set when restoring subscription relationships.

[0077] In one implementation, the current implementation does not have an automatic rewrite queue or an automatic retry queue. Therefore, historical failure messages can be re-entered into the processing chain as needed after plugin, rule configuration, or database environment repair. For messages that re-enter the processing chain, the system still executes them in the order of product type grouping, message method type classification, plugin output result verification, and the main program completing database writes at the write execution layer.

[0078] In one implementation corresponding to the device module composition, the message standardization module and the classification and distribution module can transmit the unified message structure and its source information after standardization of the original protocol message; the classification and distribution module and the plug-in processing module can transmit the processing context associated with the product type and message category; the plug-in processing module and the write execution module can transmit database operation instructions and parameter results; and the configuration recovery module provides access relationship recovery support in target data table or business database table write scenarios and system restart scenarios. This module collaboration relationship is used to explain the implementation logic of the present invention from the device level.

[0079] In one business instance, a certain product type can correspond to a field I / O acquisition device, an edge acquisition node, or an input / output control unit. This type of object can periodically report attribute data such as input point status, output point status, sampled values, temperature values, or location values. Upon receiving such messages, the system identifies them as attribute reporting messages and the corresponding plugin generates database operation instructions and parameter results to be written into the attribute data table. This implementation mainly illustrates the processing path of attribute reporting messages.

[0080] In another business example, a product type can correspond to a workstation device, machine tool control unit, or process execution node. Besides status reporting, this type of object also generates request-response messages such as attribute retrieval responses, attribute setting responses, or service call responses. After receiving these messages, the system categorizes them into the request-response message processing path and passes them to the corresponding plugin to generate database operation instructions and parameter results. This implementation mainly describes the processing path of request-response messages.

[0081] In another business example, a certain product type can also correspond to a robot peripheral sub-module, edge control node, vision node, or alarm node. This type of object can report event messages, exception messages, or log messages. After receiving such messages, the system categorizes them into the event log message processing path, and the corresponding plugin generates database operation instructions and parameter results. This implementation mainly describes the event log message processing path.

[0082] In one implementation of attribute reporting mapping, when a raw attribute message enters the system, it may contain product type, device name, operation identifier, message unique identifier, message body, attribute publishing method, and time information. The main program, on the receiving side, standardizes this type of message into a unified message structure, forming at least the following fields: timestamp, unique identifier, message method type, device name, message body, status value, and operation identifier, while retaining the context of the product type in the outer layer. Subsequently, the system classifies it into attribute reporting message classes and uses the corresponding plugin to generate database insertion instructions and parameter results for the attribute table. These parameter results must correspond one-to-one with at least the time field, unique identifier field, method field, device field, message body field, status field, and operation field.

[0083] In one request-response mapping implementation, if the system receives an attribute retrieval response, attribute setting response, or service response message, the main program first converts the response status to a unified status value, then categorizes the message into the request-response message class path, and hands it over to the corresponding plugin to generate database operation instructions and parameter results. After the main program completes the database write at the execution layer, it can retain the association between the message's unique identifier, device name, response status, and message body, thereby supporting subsequent tracking and verification based on the interaction result dimension.

[0084] In a closed-loop recovery instance, if a plugin under the same product type only undergoes an implementation version update without changing the set of connected product types, the system can enable the new plugin version via hot update without rebuilding the subscription set. If the plugin change causes a change in the monitored product type set, such as adding a plugin for a new product type or removing an existing plugin, the system first writes the change to a temporary configuration, and then restores the latest access set and subscription relationship based on the temporary configuration after a restart. The former scenario corresponds to plugin updates when the product type set remains unchanged, while the latter scenario corresponds to access recovery after a change in the product type set.

[0085] In a new access closed-loop instance, after receiving a request to add a new product type, the system does not immediately add the product type to the current access set. Instead, it first writes the product type information to be added into a temporary configuration. Subsequently, the system checks whether a plugin file corresponding to the product type exists, and further determines whether the plugin can be loaded, whether version information is returned, and whether function information for message processing is returned. Only when the above conditions are met will the system add the product type to the current access set and expand the corresponding message receiving range; if the conditions are not met, the original access set remains unchanged.

[0086] In a failure boundary instance, if the original message lacks a required field corresponding to its message method type, or if the field value is empty, the system will determine it as an invalid message during the integrity verification phase and terminate its subsequent plugin processing and database write path. This situation corresponds to the integrity verification layer blocking. If the plugin has been loaded but has not returned complete database operation instructions and parameter results, the main program will also not execute this database write action in the write execution layer. This situation corresponds to the plugin output contract verification layer blocking.

[0087] In one parameterized implementation, topic filtering rules, device name filtering rules, message category classification rules, plugin version comparison rules, and modification time difference thresholds can all be pre-configured or dynamically adjusted according to the actual deployment environment. This implementation mainly illustrates how, while maintaining a unified message structure and plugin processing framework, rule parameters can be adjusted to adapt to different access ranges and business requirements.

[0088] In one deployment variation, the system can be deployed locally on the embodied intelligent robot controller, or on an edge gateway, industrial control node, or message processing node close to the device. Regardless of the deployment location, as long as it can receive target publish-subscribe protocol messages and has the conditions to access the target database or database proxy, the unified message structure encapsulation, classification processing, plugin generation and database writing instructions, and the database writing scheme completed by the main program at the write execution layer described in this invention can be implemented.

[0089] In an implementation example of a protocol message to a unified message structure, the system receives an attribute message reported by a device corresponding to a certain product type. The original message includes at least a unique message identifier, message method type, device name, operation identifier, status value, and message body. After the main program extracts the fields, it can retain the context of the product type in the outer layer and form a unified message structure in the inner layer, consisting of a timestamp, unique message identifier, message method type, device name, message content, message status, and subject or operation identifier. This implementation example mainly illustrates the formation method of the unified message structure.

[0090] In one example of plug-in input constraints, the main program does not directly pass the original publish-subscribe protocol message to the plug-in. Instead, it passes a list of standard parameter tuples organized in a fixed order. Each tuple includes at least seven items: timestamp, unique identifier, method, device name, message body, uniform status value, and operation identifier. The product type context is determined by the main program beforehand and used for plug-in selection. This implementation example primarily illustrates plug-in input boundary constraints.

[0091] In one example of plugin output results, the plugin returns a tuple consisting of a database operation instruction and a parameter result list. The database operation instruction indicates the target table and the write action, while the parameter result list corresponds one-to-one with the placeholders in the operation instruction. Before executing the database write, the main program checks at the write execution layer whether the plugin return value constitutes a valid tuple, whether the database operation instruction is empty, and whether the parameter result list is complete. If the status code of a request-response message cannot be standardized into a uniform status value by the main program, or if the plugin return structure does not satisfy the aforementioned result contract, the corresponding message is terminated before entering the database execution layer. This implementation example primarily illustrates the boundaries of the plugin output contract.

[0092] In one example of recovery and access continuity, when plugin loading, unloading, or version switching only changes the parsing logic under the existing product type without changing the product type set, the system can perform hot updates without interrupting message access. When plugin changes cause changes to the product type set, the system switches to a restart recovery path based on temporary configuration. The former scenario maintains the existing access scope unchanged, while the latter scenario recalibrates the target access scope with the recovered valid plugin set. This implementation mainly illustrates the separation of hot update boundaries and access scope change boundaries.

[0093] In a detailed implementation of the result contract, the main program can further check at the write execution layer whether the database operation instructions, the number of parameters, and the order of parameters in the result returned by the plugin meet the preset result contract; if not, the corresponding message will be judged as a plugin output failure and subsequent database writing will be terminated.

[0094] In one subscription recovery implementation, when plugin changes affect the product type set, the system can read the product types to be added, product types to be removed, and hot-reload status in the temporary configuration, and then verify whether each product type still has valid plugins and processing entry points. Only for product types that pass verification, subscription items are rebuilt, and invalid access ranges are cleaned up. For product types that fail verification, only the disabled state is retained without restoring the corresponding subscription items, providing a calibration basis for subsequent manual restoration of access ranges or reactivation of product types, and recording the restoration order. This implementation primarily undertakes access set calibration after a restart.

[0095] In a write-to-library boundary implementation, the main program can write an execution log for each database maintenance operation at the write execution layer. This log records at least the unique message identifier, target action summary, target data table, transaction start and end times, and execution result. This execution log primarily supports transaction anomaly location, write verification, and idempotent coverage strategy selection, but does not assume the responsibility of a unified result log summary. If necessary, the execution log can also record parameter batch information or target action retry results corresponding to this execution, in order to form a layered log with the result summary.

[0096] In a multi-site adaptation implementation, different deployment environments can configure different filtering rules, classification rules, and target database writing strategies for attribute reporting messages, request-response messages, and event log messages. However, the system still maintains the main processing line of "forming a unified message structure first, determining product type groupings, further classifying message categories, and having the plugin results validated by the main program at the write execution layer before being written to the database." In other words, the differences in deployment environments mainly lie in the rule parameters, plugin content, and target table structure, without changing the basic division of labor: the main program maintains a unified control boundary, the plugin is only responsible for generating results, and the database writing is completed by the main program at the write execution layer.

[0097] In one example of failure boundary supplementation, the system can retain differentiated failure records for different control boundaries. The integrity verification layer records the original message summary and missing field information; the plugin output contract verification layer records the plugin identifier, target action summary, and parameter exception information; and the database execution layer records the target table identifier, transaction execution result, and database exception information. During subsequent review, the system selects to re-verify, re-call the plugin, or re-enter the write execution layer based on the aforementioned records, and restricts failure handling to the corresponding control layer, rather than uniformly rewriting the library path for all failure messages.

Claims

1. A method for classifying and storing application-side messages of an embodied intelligent robot, characterized in that, include: Receive publish / subscribe protocol messages corresponding to multiple product types, wherein the product type is used to identify the device type, object type, or protocol access category to which the corresponding message belongs; Perform field extraction and integrity verification on the received publish-subscribe protocol messages, and encapsulate the verified messages into a unified message structure; The messages corresponding to the unified message structure are filtered according to preset topic or operation identifier filtering rules and device name filtering rules; The filtered messages are first grouped according to product type, and then classified into attribute reporting message class, request response message class, and event log message class according to message method type. For each product type and message category, the corresponding plugin is called so that the plugin generates database operation instructions and parameter results with a unified message structure and corresponding processing context as controlled input boundaries. The main program performs contract verification, legality verification of write actions, and integrity verification of key fields on the database operation instructions and parameter results at the write execution layer, and blocks database writing if the corresponding requirements are not met.

2. The method according to claim 1, characterized in that, The unified message structure includes at least a timestamp, a unique message identifier, a message method type, a device name, a message content, a message status, and a topic or operation identifier, and is associated with the product type and the message category determined according to the message method type in the outer layer.

3. The method according to claim 1, characterized in that, The integrity verification includes determining the corresponding set of required fields based on different message method types, and determining the message as invalid and removing it before it enters the plugin processing if the message lacks the corresponding required fields, the fields are empty, or the request-response message state transition fails.

4. The method according to claim 1, characterized in that, include: If a plugin with the same name has at least two implementation forms and both are effective, the version number is compared first, and if the version numbers are the same, the modification time is compared with a preset time difference threshold to determine the currently effective plugin. If only one implementation form is valid, select that valid implementation form.

5. The method according to claim 4, characterized in that, If a plugin file exists and matches the corresponding product type, and the plugin can be loaded and return version information and function information that can be used for message processing, it will be considered as a candidate plugin for selection.

6. The method according to claim 1, characterized in that, The plugin adopts either an interpretable module or a compileable module implementation, and receives a unified message structure and outputs database operation instructions and parameter results according to a preset input / output protocol; the database operation instructions and parameter results include at least the target data table identifier, write action type, key positioning fields, and a list of parameter results in the same order as the placeholders of the database operation instructions.

7. The method according to claim 1, characterized in that, include: During operation, detect changes to plugin files and perform hot updates when plugin changes do not affect the product type set. When a plugin change affects a set of product types, a temporary configuration is recorded, and after a system restart, the subscription relationship is restored to be consistent with the current set of product types based on the temporary configuration.

8. The method according to claim 7, characterized in that, include: When a request to add a new product type is received, first check if there is a plugin that corresponds to the product type and meets the validity requirements; If a corresponding plugin exists, update the current access set; If there is no corresponding plugin or the plugin does not meet the requirements, keep the current access set unchanged.

9. A message classification and storage device for an embodied intelligent robot application side, characterized in that, include: The module includes a message receiving module, a message standardization module, a filtering control module, a classification and distribution module, a plugin processing module, a write execution module, and a configuration recovery module. The message receiving module is used to receive publish-subscribe agreement messages corresponding to multiple product types, wherein the product type refers to the business object classification identifier to which the publish-subscribe agreement message source belongs, and outputs the received publish-subscribe agreement messages to the message standardization module; The message standardization module is used to perform field extraction and integrity verification on the received publish-subscribe protocol messages, encapsulate the verified messages into a unified message structure, and output the unified message structure to the filtering control module and the classification and distribution module. The filtering control module is used to filter the messages corresponding to the unified message structure according to preset topic or operation identifier filtering rules and device name filtering rules, and output the filtering pass result. The classification and distribution module is used to receive the unified message structure and the filtering results. The filtered messages are first grouped according to product type, and then divided into attribute reporting message class, request response message class and event log message class according to message method type. The module also outputs the processing context corresponding to the product type and message category. The plugin processing module is used to receive the processing context and the unified message structure, call the corresponding plugin for each product type and message category, so that the plugin generates database operation instructions and parameter results with the unified message structure and the corresponding processing context as controlled input boundaries, and outputs the database operation instructions and parameter results to the write execution module. The write execution module is used by the main program to perform result contract verification, write action legality verification, and key field integrity verification on the database operation instructions and parameter results at the write execution layer. It executes database writing when the corresponding requirements are met and blocks database writing when the corresponding requirements are not met. The configuration recovery module is used to record temporary configurations when plugin changes affect the product type set, and restore the subscription relationship consistent with the current product type set based on the temporary configurations after the system restarts.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program; When the computer program is executed by the processor, the processor performs the embodied intelligent robot application-side message classification and storage method according to any one of claims 1 to 8.

Images