Controller Cooperative Communication Method Based on HarmonyOS Distributed Bus

Abstract

This invention discloses a controller collaborative communication method based on the HarmonyOS distributed bus, specifically relating to the field of communication control, to solve the problem of the first control message failing due to inconsistency between service visibility and session readiness. The method involves generating a service visibility identifier and a target identification fragment during the service discovery phase, establishing a temporary entry for the first control message, and generating a control session request. During the session confirmation phase, the method extracts the confirmation feedback fragment and the readiness event fragment, generates a session readiness identifier, and records state transition records. In the initial release phase, the method obtains an initial release permission coefficient based on the fusion of target chain verification and state stability verification, determining whether to send or cancel the first control message. Finally, in the receipt phase, the method extracts the target feedback fragment and the acceptance result fragment to generate a receipt review coefficient, processes the session readiness identifier, and updates the control session request, thereby ensuring that the collaborative communication process is verifiable, reproducible, and consistent.

Description

Technical Field

[0001] This invention relates to the field of communication control, and more specifically, to a controller collaborative communication method based on the HarmonyOS distributed bus. Background Technology

[0002] In controller collaborative communication scenarios based on HarmonyOS distributed bus, the controller typically needs to first discover and identify the target service through the distributed soft bus, then establish a control communication channel with the target side, and subsequently send control messages and receive feedback. Existing solutions can already achieve the aggregation of cross-domain service information, the synchronization of service capability information, and the updating of the local service list, enabling the controller to quickly see available services and initiate subsequent operations. This provides the foundation for cross-device and cross-regional collaborative control and also makes collaborative communication between controllers more convenient and scalable.

[0003] However, when the above process is used for controller collaborative communication, the following situation can easily occur: once the controller sees the target service is visible locally, it directly sends the first collaborative control message. However, at this time, the control communication channel has not yet reached a stable sending state. As a result, the first control message is not effectively processed after being sent, manifesting as message failure, waiting without response, and repeated retransmission. This subsequently triggers repeated link establishment, repeated requests, or error messages, ultimately causing inconsistent responses, mismatched control rhythms, and misjudged link anomalies in the collaborative control process. For users, the service appears available, but control actions cannot be smoothly implemented; for the system, the discovered state is inconsistent with the actual communication availability state, thus affecting the stability and continuity of controller collaborative communication based on the HarmonyOS distributed bus.

[0004] To address the aforementioned problems, a technical solution is provided. Summary of the Invention

[0005] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a controller collaborative communication method based on the HarmonyOS distributed bus. This method generates a service visibility identifier and a target identification fragment during the service discovery phase, establishes a temporary entry for the first control message, and generates a control session request. During the session confirmation phase, it extracts the confirmation feedback fragment and the ready event fragment, generates a session ready identifier, and records state transition records. In the initial release phase, it obtains an initial release permission coefficient based on the fusion of target chain verification and state stability verification, and decides whether to send or cancel the first control message. In the receipt phase, it extracts the target feedback fragment and the acceptance result fragment to generate a receipt review coefficient, processes the session ready identifier, and updates the control session request. This ensures that the collaborative communication process is verifiable, reviewable, and consistent, thereby solving the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] S1: Generate a service visibility identifier based on the target service discovery result returned by the distributed soft bus, extract the target identification fragment from the target service discovery result, form a control session request, temporarily store the first control message and generate the first control message binding information, and associate the first control message with the service visibility identifier and the target identification fragment;

[0008] S2: Send a control session request, receive a session confirmation message, extract the confirmation feedback fragment and ready event fragment from the session confirmation message, generate a session ready identifier based on the ready event fragment, record the state transition records from the generation of the service visibility identifier to the generation of the session ready identifier, and maintain the temporary state of the first control message before the generation of the session ready identifier.

[0009] S3: Before sending the first control message, calculate the chain continuation degree based on the target identification fragment, the confirmation return fragment, and the binding information of the first control message. Calculate the state transition bounce rate based on the state transition record. Combine the chain continuation degree as consistency evidence and the state transition bounce rate as stability evidence to obtain the initial permission coefficient. Determine whether to release or cancel the sending of the first control message based on the initial permission coefficient.

[0010] S4: Receive the first control message processing receipt returned by the target side, extract the target feedback fragment and acceptance result fragment from the processing receipt, generate the receipt review coefficient, process the session ready flag based on the receipt review coefficient, and generate an updated control session request.

[0011] Furthermore, the controller receives the target service discovery result, performs type length value decoding, completes length consistency determination, character decodeability determination, and format matching determination, extracts the target service identifier content and the provider node identifier content, generates the target identification fragment according to the deterministic binary object representation encoding rules, and uses cryptographic hash algorithm No. 3 to generate a service visibility identifier for the target identification fragment.

[0012] Furthermore, the controller establishes a temporary entry for the first control message. This entry stores the content of the first control message, the service visibility identifier, and the target identification fragment. It generates a fingerprint for the first control message according to the deterministic serialization rules and the third cryptographic hash algorithm. Based on the service visibility identifier and the fingerprint of the first control message, it generates a return instruction token. The binding information of the first control message consists of the service visibility identifier, the fingerprint of the first control message, and the return instruction token. The control session request carries the service visibility identifier, the target identification fragment, and the return instruction token. The session index key associates the control session request with the temporary entry for the first control message.

[0013] Furthermore, the controller receives the session confirmation message, performs type length value decoding, outputs the confirmation retrieval fragment and the ready event fragment, completes the length consistency determination, length correspondence determination, and value set determination, confirms that the length of the retrieval fragment is consistent with the length of the retrieval instruction plate, and that the value of the ready event fragment belongs to the ready event fragment encoding set.

[0014] Furthermore, the controller uses a constant-time comparison algorithm to verify that the returned instruction fragment is consistent with the returned instruction plate, generates a session index key to locate the first control message temporary item, the first control message temporary item is kept in a temporary state, and generates a session ready identifier when the ready event fragment is matched and enters the sendable stage encoding, and uses a deterministic finite state automaton to generate and seal the state transition record.

[0015] Furthermore, the controller assembles a decision context, which includes the target identification fragment, service visibility identifier, first control message binding information, confirmation return fragment, and state transition record. A constant time comparison algorithm is used to verify the consistency between the return fragment and the return instruction plate. If they are inconsistent, the first control message is temporarily stored and the initial permission determination is terminated.

[0016] Furthermore, the controller performs cryptographic hash algorithm No. 3 on the target identification fragment to obtain the recalculation service visibility identifier, uses Hamming distance to calculate the identifier similarity, and uses Hamming distance to calculate the return pointer similarity between the confirmed return pointer fragment and the return pointer plate. The chain pointer continuity is determined by the identifier similarity and the return pointer similarity.

[0017] Furthermore, the controller constructs adjacent state pairs and marks the migration direction for the state transition records, counts the number of backtracking migrations and round-trip migrations to obtain the state transition bounce rate, performs boundary regularization and log-likelihood fusion on the chain continuation degree and the state transition bounce rate to obtain the first permission coefficient, and determines whether to release or cancel the sending of the first control message based on the first permission coefficient.

[0018] Furthermore, the controller receives the processing receipt and performs type length value decoding, outputs the target retrieval fragment and the acceptance result fragment, and maps the acceptance result fragment to the acceptance target value; it performs the third cryptographic hash algorithm on the target identification fragment to generate the target retrieval verification value, and uses the constant time comparison algorithm to verify the consistency between the target retrieval fragment and the target retrieval verification value and generate a target consistency flag.

[0019] Furthermore, the controller generates a judgment target value based on the initial permission judgment result. The controller uses a constant time comparison algorithm to verify the consistency between the judgment target value and the acceptance target value and generates a judgment consistency flag. Boundary normalization is performed on the initial permission coefficient to obtain the normalized initial permission coefficient. Based on the acceptance target value, a receipt likelihood value is generated and a receipt review coefficient is generated. Based on the receipt review coefficient and the judgment consistency flag, the session ready flag is processed and an updated control session request is generated.

[0020] This invention discloses a controller collaborative communication method based on HarmonyOS distributed bus, which relates to direct communication technology between devices. Its technical effects and advantages are as follows:

[0021] This invention revolves around a controller collaborative communication link based on the HarmonyOS distributed bus. It integrates service discovery, session confirmation, sending the first control message, and receipt verification into a single verifiable control path. This allows the controller to determine whether to allow a service when it sees that the target service is available. Instead of sending the first control message directly, the controller waits for the target's identity and session status to be confirmed before deciding to allow the service. After receiving a receipt from the target side, the controller verifies the allowance result. This ensures that the control actions are consistent with the target object and avoids situations where the service appears available but the control message fails, there is no response, or the service is misjudged as a link anomaly.

[0022] Through the above-mentioned streamlined process, the controller can transform the sending method of the first control message from relying on a single state trigger to relying on verifiable information and verifiable results. This makes the collaborative communication process more stable and coherent, reduces repeated link establishment and retries caused by state jitter or target mismatch, lowers the probability of missynchronization between the control end and the controlled end, and improves the predictability and consistency of cross-device collaborative control. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating the controller collaborative communication method based on the HarmonyOS distributed bus of this invention. Detailed Implementation

[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] Please see Figure 1 This invention provides a controller collaborative communication method based on HarmonyOS distributed bus, comprising:

[0026] S1: Generate a service visibility identifier based on the target service discovery result returned by the distributed soft bus, extract the target identification fragment from the target service discovery result, form a control session request, temporarily store the first control message and generate the first control message binding information, and associate the first control message with the service visibility identifier and the target identification fragment;

[0027] S2: Send a control session request, receive a session confirmation message, extract the confirmation feedback fragment and ready event fragment from the session confirmation message, generate a session ready identifier based on the ready event fragment, record the state transition records from the generation of the service visibility identifier to the generation of the session ready identifier, and maintain the temporary state of the first control message before the generation of the session ready identifier.

[0028] S3: Before sending the first control message, calculate the chain continuation degree based on the target identification fragment, the confirmation return fragment, and the binding information of the first control message. Calculate the state transition bounce rate based on the state transition record. Combine the chain continuation degree as consistency evidence and the state transition bounce rate as stability evidence to obtain the initial permission coefficient. Determine whether to release or cancel the sending of the first control message based on the initial permission coefficient.

[0029] S4: Receive the first control message processing receipt returned by the target side, extract the target feedback fragment and acceptance result fragment from the processing receipt, generate the receipt review coefficient, process the session ready flag based on the receipt review coefficient, and generate an updated control session request.

[0030] This invention addresses the most common breakpoint in controller collaborative communication under the HarmonyOS distributed bus: a service has been discovered and is available, but the control session has not yet entered a sendable state, causing the first control message to fail or trigger an invalid retry. This solution organizes the collaborative communication process into a verifiable, determinable, and reviewable closed loop: In the service discovery phase, the target identity is solidified into a service visibility identifier and a target identification fragment, and the first control message is temporarily bound to the target identity, while a control session request is generated; in the session confirmation phase, a confirmation feedback fragment binds the session confirmation to the first control message, and a session readiness identifier and state transition record are generated by combining a readiness event fragment, clearly distinguishing between service visibility and session readiness; in the initial release phase, the consistency of the target chain and the stability of the state process are simultaneously checked, and an initial release permission coefficient is formed to determine whether the first control message is sent; in the acknowledgment phase, the initial release determination is reviewed using the target feedback fragment and the acceptance result fragment, forming an acknowledgment review coefficient, which is used to retain or clear the session readiness identifier and update the control session request, ensuring the continuity, consistency, and predictability of controller collaborative communication from the communication process level.

[0031] Step S1 processes the target service discovery results returned by the distributed soft bus. The controller needs to fix the target service identity information at the stage when the service is first discovered, establish a unique binding relationship between the first control message and the target service, and prepare the control session request in a form that can be accurately returned by subsequent session confirmation messages, so as to ensure that the same target is consistently referenced in the three links of discovery, temporary storage and session request.

[0032] S101: Discovery result parsing and available field extraction.

[0033] The target service discovery result returned by the distributed soft bus is a structured byte sequence. Internal fields may be reported repeatedly or have different order in the communication link. The controller needs to extract the available fields into stable identifier objects to avoid inconsistencies between subsequent control session requests and the temporary entries of the first control message.

[0034] After receiving the target service discovery result, the controller performs type-length value decoding. Type-length value decoding scans the byte sequence sequentially, first reading the type identifier, then the length identifier, and then truncating the byte sequence according to the length identifier. The controller truncates the target service identifier content when the type identifier matches the target service identifier field, and truncates the provider node identifier content when the type identifier matches the provider node identifier field. Integrity verification uses three types of judgments: length consistency judgment to confirm that the truncated byte count matches the length identifier; character decodeability judgment to confirm that the target service identifier content can be decoded into a printable character sequence according to a preset character encoding; and format matching judgment to confirm that the provider node identifier content can be matched according to the node identifier format defined by the distributed soft bus. The target service identifier content value range is limited to a non-empty printable character sequence with a length not exceeding a preset upper limit, and the provider node identifier content value range is limited to a non-empty fixed-format identifier sequence with a length not exceeding a preset upper limit. Target service discovery results that fail any of these judgments are not processed further.

[0035] S102: Target identification fragment construction and service visibility identifier generation.

[0036] The target service identifier content and the provider node identifier content belong to the source fields. If the source fields are directly concatenated, they are easily affected by differences in field order and encoding. The controller needs to first convert the source fields into a unique target identification fragment, and then generate a service visibility identifier that can be used for indexing and referencing, so as to ensure that the same target maintains the same representation in different discovery results.

[0037] The controller performs normalization processing on the target service identifier content and the provider node identifier content. Normalization includes character encoding standardization, case sensitivity standardization, and whitespace character regularization. After normalization, normalized target service identifier content and normalized provider node identifier content are formed. The controller constructs the target identification fragment using deterministic binary object representation encoding rules. The deterministic binary object representation encoding rules fix the field order as target service identifier content first, followed by provider node identifier content, use a fixed-length deterministic representation, and use a fixed-string deterministic representation. The output target identification fragment is a reversibly decodeable byte sequence that satisfies the unique representation constraint. The controller executes the third cryptographic hash algorithm on the target identification fragment to generate a service visibility identifier. The process involves taking the target identification fragment as input, performing message padding, grouping, and iterative compression, and outputting a fixed-length hash value as the service visibility identifier. The value range of the service visibility identifier is limited to any fixed-length byte sequence within the output space of the third cryptographic hash algorithm.

[0038] For example, in the target service discovery result, the target service identifier is represented by the name of a control service, and the provider node identifier is represented by the identifier of a device node. After the controller completes the normalization, it constructs the target identification fragment and then generates the service visibility identifier. Even if the target service discovery result is reported again and the field order changes, the service visibility identifier remains consistent.

[0039] S103: The first control message temporary item is established and the binding information for the first control message is generated.

[0040] The first control message cannot be sent directly before the session is ready. The first control message needs to be temporarily stored and needs to have binding information that can be pointed back. The binding information needs to be able to point to both the target service and the content of the first control message. This is to avoid the inability to locate the temporary item of the first control message after receiving the session confirmation message in step two, and to avoid the lack of input for the consistency evidence calculation in step three.

[0041] The controller establishes a temporary entry for the first control message, which includes the content of the first control message, a service visibility identifier, and a target identification fragment. The controller generates a fingerprint of the first control message. The process involves first performing deterministic serialization on the content of the first control message, using rules that fix the field order, field existence, and length representation to obtain a serialized byte sequence. Then, this serialized byte sequence is used as input to execute cryptographic hash algorithm number three to obtain the fingerprint of the first control message. The fingerprint's value range is limited to a fixed-length byte sequence. The controller generates a return instruction plate, and the processing... First, the service visibility identifier and the first control message fingerprint are combined in a fixed order, with the service visibility identifier first and the first control message fingerprint last. The combined structure is then encoded using a deterministic binary object representation rule to obtain a combined byte sequence. This combined byte sequence is then used as input to execute the third cryptographic hash algorithm to obtain a return instruction plate. The value range of the return instruction plate is limited to a fixed-length byte sequence. The controller generates the first control message binding information, which consists of the service visibility identifier, the first control message fingerprint, and the return instruction plate. The value range of the first control message binding information is limited to a structured object representation that can be stably parsed.

[0042] For example, the content of the first control message is a control command. The controller serializes the control command according to a fixed field order to generate the fingerprint of the first control message. Then, it combines the service visibility identifier with the fingerprint of the first control message to generate a command token. Subsequent session confirmation messages only need to include the command token to locate the temporary item of the first control message.

[0043] S104: Controls session request generation and object handover constraints.

[0044] The control session request needs to carry enough information for session confirmation feedback, and it also needs to form a stable index relationship with the temporary item of the first control message to ensure that step two can complete the location after extracting the confirmation feedback fragment from the session confirmation message, and to ensure that step three can obtain consistent evidence input before sending the first control message.

[0045] The controller generates a control session request based on the first control message temporary item. The control session request carries a service visibility identifier, a target identification fragment, and a return instruction plate. The controller establishes a session index key, which uses a fixed combination of the service visibility identifier and the return instruction plate. After combination, a deterministic binary object representation encoding rule is executed to obtain an index byte sequence. The index byte sequence is used as the session index key to associate the control session request with the first control message temporary item. After the controller completes the generation of the control session request, it keeps the first control message temporary item in a queryable state. The query entry is the session index key as the only entry point. After extracting the confirmation return instruction fragment in step two, the confirmation return instruction fragment can be used to point to the same session index key to complete the positioning.

[0046] Step S1 completes the generation of the service visibility identifier and target identification fragment. The first control message temporary storage item saves the content of the first control message, the service visibility identifier, and the target identification fragment. The control session request carries the service visibility identifier, the target identification fragment, and the return instruction card and forms a session index key association. Step S1 ensures that the first control message maintains a locatable and returnable target binding state during the session not ready stage, reducing the first-time failure and erroneous session interference caused by target mismatch.

[0047] Step S2 involves processing the session confirmation message after the control session request is sent. The controller needs to break down the asynchronously returned session confirmation message into confirmation feedback fragments and ready event fragments, complete the consistency verification between the confirmation feedback fragments and the feedback command, and form a replayable state transition record of the session progression process, thereby extending the target binding relationship of the service discovery phase to the session ready judgment phase.

[0048] S201: Receiving and extracting session confirmation messages.

[0049] The session confirmation message is used to send the session status of the target side back to the controller. The confirmation return instruction fragment is used to locate the return instruction plate generated in step one. The ready event fragment is used to indicate that the session has entered the sendable stage. The controller needs to split the session confirmation message into two fragments and complete the basic legality check to avoid sending invalid fragments into the consistency check and session ready identifier generation.

[0050] After receiving the session confirmation message, the controller performs type length value decoding. Type length value decoding sequentially reads the type identifier, reads the length identifier, and extracts a byte sequence of values ​​based on the length identifier. If the type identifier matches the return pointer field, an acknowledgment return pointer fragment is output; if the type identifier matches the ready event field, a ready event fragment is output. Length consistency determination confirms that the number of truncated bytes matches the length identifier. Length correspondence determination confirms that the return pointer fragment length matches the length of the return instruction plate from step one. Value set determination confirms that the ready event fragment value belongs to the ready event fragment encoding set maintained locally by the controller. This ready event fragment encoding set is defined in the controller's fixed configuration and includes codes for entering the transmittable stage and codes for not entering the transmittable stage. The range of confirmed return pointer fragment values ​​is limited to a finite byte sequence consistent with the return instruction plate length, and the range of ready event fragment values ​​is limited to a single encoded value within the ready event fragment encoding set.

[0051] S202: Confirm the consistency verification of the return pointer and locate the temporary item of the first control message.

[0052] The confirmation fragment must be consistent with the confirmation command to prove that the session confirmation message corresponds to the control session request issued in step one. The controller needs to use a constant time comparison algorithm to complete the consistency verification and locate the first control message temporary item to avoid leakage of comparison time due to premature return and to avoid the first control message being disconnected from the target service due to mislocation.

[0053] The controller performs a constant-time comparison algorithm on the acknowledgment retrieval fragment and the retrieval command plate. The constant-time comparison algorithm reads byte by byte from the start byte to the end byte according to the byte sequence length, performs an XOR operation on each byte, and accumulates the XOR result into a single accumulated register value. After all bytes have been processed, it checks whether the accumulated register value is zero. If the accumulated register value is zero, it is considered a match; if the accumulated register value is non-zero, it is considered an inconsistency. When the match determination is successful, the controller uses the service visibility identifier and the retrieval command plate to generate a session index key. The session index key generation adopts a deterministic binary object representation encoding rule. The encoding rule has a fixed field order: service visibility identifier first, retrieval command plate second. The encoding rule has a fixed length representation and a fixed byte order representation. The controller uses the session index key to query the mapping table of the first control message temporary entries and locates the first control message temporary entry. The first control message temporary entry is kept in a temporary state. When the match determination is unsuccessful, the controller discards the session acknowledgment message and keeps the first control message temporary entry unchanged.

[0054] For example, after the controller sends a control session request, it receives a session confirmation message. When it confirms that the returned instruction fragment matches the returned instruction plate, the controller uses the session index key to locate the first control message in the temporary storage. The first control message remains in the temporary storage state to avoid entering the sending process before the session is ready.

[0055] S203: Session ready flag generation and first control message storage constraints.

[0056] The ready event fragment inside the session confirmation message is used to characterize that the session has entered the sendable stage. Step 3 requires a session ready identifier as the session state input. The controller needs to generate a session ready identifier according to unified rules after the consistency verification is passed, and at the same time maintain the temporary storage constraint of the first control message until the first permission determination in step 3 is completed.

[0057] The controller reads ready event fragments and executes branch processing. A session ready identifier is generated when the ready event fragment value matches and enters the sendable stage encoding; otherwise, no session ready identifier is generated. The session ready identifier generation uses deterministic binary object representation encoding rules and cryptographic hash algorithm No. 3. The processing is as follows: the controller encodes the service visibility identifier, return command plate, and ready event fragment into a combined byte sequence in a fixed order according to the deterministic binary object representation encoding rules. The fixed order is: service visibility identifier first, return command plate second, and ready event fragment last. The controller uses this combined byte sequence as input to execute cryptographic hash algorithm No. 3 and outputs a fixed-length byte sequence, which serves as the session ready identifier. The value range of the session ready identifier is limited to a fixed-length byte sequence within the output space of cryptographic hash algorithm No. 3. The first control message temporary entry remains in a temporary state and is not processed for transmission.

[0058] S204: State transition record generation and sealing.

[0059] State transition records are used to depict the trajectory of state changes from the generation of the service visibility flag to the generation of the session ready flag. Step 3, calculating the state transition bounce rate, requires stable and replayable state transition record inputs. The controller needs to use a deterministic finite state automaton to record state transitions and seal the record boundaries.

[0060] The controller uses a deterministic finite state automaton to generate state transition records. The state set includes the service discovery complete state, control session request sent state, session acknowledgment received state, and session ready generated state. The event set includes the service visibility flag generated event, control session request sent event, acknowledgment return consistency determination passed event, and session ready flag generated event. The controller writes the service discovery complete state into the state transition record when the service visibility flag has been generated; writes the control session request sent state when sending a control session request; writes the session acknowledgment received state when the acknowledgment return consistency determination passes; and writes the session ready generated state when generating a session ready flag. The value range of the state transition record is limited to a finite sequence composed of state codes from the above state set. The sequence order is consistent with the event occurrence order, and the sequence length does not exceed the controller's preset upper limit. The controller archives the state transition record and keeps its content read-only to prevent subsequent steps from rewriting it.

[0061] Step S2 extracts the confirmation retrieval fragment and the ready event fragment and completes the consistency verification, generates a session ready identifier and seals the state transition record. The first control message temporary item remains in a temporary state and does not enter the sending process. Step S2 enables the controller to distinguish between the two states of service visibility and session ready, reduces the false sending of the first control message in the session not ready stage, and reduces the probability of invalid retries and repeated connection establishment triggers.

[0062] Step S3 involves processing the release decision before the first control message is sent. The controller needs to simultaneously form quantitative basis in two dimensions: the continuity of the target chain and the stability of state transition. The quantitative basis is then integrated into the first release permission coefficient to determine whether the first control message enters the transmission link or continues to be temporarily stored, thus avoiding the uncertainty of the first release caused by releasing based solely on a single identical identifier.

[0063] S301: Input object assembly and consistency threshold verification.

[0064] Before the first control message enters the release decision, target pointer mismatch needs to be ruled out to avoid building subsequent calculations on erroneous sessions. The controller reads the target identification fragment, service visibility identifier, and the content of the first control message from the first control message's temporary storage item; it reads the return instruction plate and the fingerprint of the first control message from the first control message's binding information; it reads the confirmation return instruction fragment from the session confirmation message; and it reads the state sequence from the state transition record. The controller uses a constant-time comparison algorithm to verify the consistency between the confirmation return instruction fragment and the return instruction plate. The constant-time comparison algorithm performs a byte-by-byte XOR operation and accumulates the XOR results. If the accumulated XOR result is zero, it is considered consistent; if the accumulated XOR result is non-zero, it is considered inconsistent. If the consistency threshold check is inconsistent, the temporary storage state of the first control message is maintained and the current release decision is terminated. If the consistency threshold check is consistent, a decision context is assembled. The decision context includes the target identification fragment, service visibility identifier, first control message binding information, confirmation return instruction fragment, and state transition record.

[0065] S302: Chain finger continuity calculation.

[0066] Before the first control message is allowed, the target service identity needs to be referenced multiple times through three paths: service discovery, session confirmation, and message temporary storage. A single consistency check can only indicate that there is no obvious mismatch in a certain link, and cannot cover the implicit breaks in the link when there are field rearrangements, duplicate reports, or back-pointing crosstalk. Therefore, the approval decision needs to quantify the continuity of the target chain in order to include the target identification fragment in the discovery stage, the confirmation back-pointing fragment in the confirmation stage, and the binding information of the first control message in the binding stage under the same scale for verification, thereby providing the necessary input and clear boundaries for the calculation of chain continuation.

[0067] The continuity of the target chain needs to simultaneously cover the service discovery identifier chain and the session feedback chain to avoid false passage caused by a single path being consistent. The controller first performs cryptographic hash algorithm number 3 on the target identification fragment to obtain the recalculated service visibility identifier. Then, it converts the recalculated service visibility identifier and the service visibility identifier into bit sequences and calculates the Hamming distance. The Hamming distance is calculated by bitwise XOR counting, and the number of bits with a result of 1 is taken as the Hamming distance. The controller divides the Hamming distance by the bit length of the service visibility identifier to obtain the identifier difference rate, and then subtracts the identifier by one. The difference rate yields the identifier similarity, which is a dimensionless real number between zero and one. The controller converts the confirmed retracement fragment and the retracement command plate into bit sequences and calculates the Hamming distance. The Hamming distance is divided by the bit length of the retracement command plate to obtain the retracement difference rate. The retracement similarity is obtained by subtracting the retracement difference rate from one. The retracement similarity is a dimensionless real number between zero and one. The controller takes the smaller value between the identifier similarity and the retracement similarity as the chain continuation degree. The chain continuation degree is a dimensionless real number between zero and one.

[0068] For example, after the controller receives the session confirmation message, it confirms that the bitwise XOR count of the return pointer fragment and the return instruction plate is zero, recalculates the bitwise XOR count of the service visibility identifier and the service visibility identifier and it is zero, takes the maximum value of the chain continuation degree, and calculates the initial license coefficient to proceed to the next sub-step.

[0069] S303: Calculation of state transition bounce rate.

[0070] The release of the first control message depends not only on whether the target is matched, but also on whether the session progress is in a stable range. Especially in scenarios with frequent asynchronous callbacks and state transitions in distributed buses, the session state may experience rollbacks, round trips, and duplicate acknowledgments. Simply relying on the session ready flag can only reflect the ready conclusion at a certain moment and cannot reflect the intensity of process fluctuations before the ready conclusion is generated. Therefore, the release decision needs to quantify the rollback and round trip features in the state transition record in order to transform the degree of fluctuation in the session progress into a metric that can be used for gating judgment, thereby providing a reasonable basis and an interpretable input source for the calculation of the state transition bounce rate.

[0071] State transition records contain a sequence of state codes representing service discovery completion, control session request issuance, session acknowledgment arrival, and session readiness generation. These state codes reflect whether rollback or round trips occurred during the session progression. The controller first converts the state transition records into a sequence of adjacent state pairs, each pair consisting of a preceding and following state. The controller then marks the transition direction according to a preset progression order: service discovery completion points to control session request issuance, control session request issuance points to session acknowledgment arrival, and session acknowledgment arrival points to session readiness generation. If the transition order is followed, a forward transition is marked; otherwise, a rollback transition is marked. The controller counts the number of backtracking transitions and the number of round-trip transitions. A round-trip transition is defined as a state code in an adjacent state pair sequence that is the opposite of the next state code, which is manifested as the state code switching back and forth between two values. The controller adds the number of backtracking transitions to the number of round-trip transitions to obtain the number of bounces. The length of the adjacent state pair sequence is taken as the total number of transitions. The state transition bounce rate is equal to the number of bounces divided by the total number of transitions. The state transition bounce rate is a dimensionless real number between zero and one. The controller subtracts the state transition bounce rate from one to obtain the stability confidence. The stability confidence is a dimensionless real number between zero and one.

[0072] S304: The probability domain regularization and log-likelihood fusion generate the first-release license coefficients.

[0073] Before the first control message enters the transmission link, the controller needs to provide a decision that can directly drive the release or interception. This decision cannot be based solely on the consistency of the target chain or the stability of the session. The former addresses the question of who the message is sent to, while the latter addresses whether it is appropriate to send the message at this moment. The absence of either one may result in the first control message failing, timing out, or triggering repeated chain establishment. Furthermore, the performance of the two metrics is not always synchronized. There are cases where the target chain appears coherent but the session fluctuates significantly, and there are cases where the session is stable but the target chain has minor mismatches. Therefore, the release decision needs to establish a unified decision entry point between the two types of information, converting them into a release basis in the same direction and outputting a single first-order permission coefficient. Subsequently, the release or cancellation of the first control message is completed based on this coefficient, making the decision process interpretable, verifiable, and facilitating consistency verification during the acknowledgment stage.

[0074] The chain continuation degree represents the confidence in the correctness of the target chain, while the stability confidence represents the confidence in the stability of the state progression. For the first control message to be accepted on the target side, both types of confidence must be established simultaneously. The controller uses a fusion of probability domain regularization and log-likelihood to obtain the initial permission coefficient, ensuring that the initial permission coefficient retains its posterior confidence meaning. The controller performs boundary regularization on the chain continuation degree. The boundary regularization strategy is given by the controller's fixed configuration, limiting the chain continuation degree to between a lower bound and an upper bound, where the lower bound is a minimal positive number and the upper bound is one minus a minimal positive number. The controller applies the same boundary regularization strategy to the state transition bounce rate. The controller calculates the log-likelihood term of the chain continuation degree, the calculation process being first regularized... The ratio is obtained by dividing the normalized chain finger continuity by one, and then taking the natural logarithm of the ratio. The controller calculates the stable log-likelihood term by first dividing the normalized state transition bounce rate by one, and then taking the natural logarithm of the ratio. The controller adds the chain finger continuity log-likelihood term to the stable log-likelihood term to obtain the combined log-likelihood. The controller performs a logic function mapping on the combined log-likelihood. The logic function mapping takes the exponent of the negative of the combined log-likelihood, adds one to the exponent, and then takes the reciprocal to obtain the initial license coefficient. The initial license coefficient is a dimensionless real number between zero and one.

[0075] The controller performs first-order permission determination based on the first-order permission coefficient. The first-order permission determination adopts a threshold comparison rule. The threshold is given by the controller's fixed configuration. When the first-order permission coefficient meets the threshold condition, the first control message is released into the transmission link. When the first-order permission coefficient does not meet the threshold condition, the transmission of the first control message is canceled and the first control message is kept in a temporary state. At the same time, the link continuation degree, state transition bounce rate, first-order permission coefficient and determination result are written into the determination context.

[0076] Step S3 calculates the chain continuation degree and state transition bounce rate and outputs the first-order permission coefficient. The first-order permission coefficient drives the first-order permission determination result and determines whether the first control message is released or canceled. Step S3 upgrades the release of the first control message from single-point verification to dual-evidence judgment, reducing the first-order failure, false retransmission and control action loss caused by the discontinuity of the target chain and state fluctuation.

[0077] The first control message is the first effective control action in the collaborative communication link. Once it enters the transmission link, it will trigger the acceptance and processing on the target side, and will also trigger a series of communication behaviors on the controller side, such as waiting for acknowledgment, timeout retry, and re-establishing the session if necessary. Therefore, the transmission of the first control message needs to use the initial permission coefficient as a unified basis for release. By using threshold conditions, the situation where the consistency of the target chain and the stability of the session process are both satisfied is identified as a transmittable state, so that the first control message enters the transmission link with a higher degree of availability. When the initial permission coefficient does not meet the threshold conditions, canceling the transmission and maintaining a temporary state can avoid forced transmission during periods of unclear target or session fluctuation, which may result in failure, false retry, and unnecessary reconstruction. At the same time, the first control message and its binding information are retained to support the continued determination and transmission after the session status is improved, so that the initial control behavior remains controllable, traceable, and verifiable.

[0078] Step S4 involves processing the processing receipt after the first control message is sent. The controller needs to use the target feedback fragment to verify whether the processing receipt points to the target service determined in step S1, and then use the acceptance result fragment to verify whether the acceptance conclusion on the target side matches the initial permission determination in step S3. The matching degree is then converted into a receipt review coefficient, thereby performing retention or clearing of the session ready flag.

[0079] S401: Process receipt reception and extract receipt fields.

[0080] The processing receipt requires both target information and acceptance conclusion information. The controller first extracts the fields and then proceeds to the verification process. After receiving the processing receipt, the controller uses type and length value decoding to read the type identifier and length identifier and extracts the value byte sequence. When the type identifier matches the target index field, the target index fragment is obtained; when the type identifier matches the acceptance result field, the acceptance result fragment is obtained. The value range of the target index fragment is limited to a fixed-length byte sequence, and the value range of the acceptance result fragment is limited to a single encoded value within the acceptance result enumeration set. The acceptance result enumeration set is maintained by the controller with a fixed configuration and includes acceptance success codes and acceptance failure codes. The controller maps the acceptance result fragment to the acceptance target value. When the acceptance result fragment matches the acceptance success code, the acceptance target value is the success value; when the acceptance result fragment matches the acceptance failure code, the acceptance target value is the failure value.

[0081] S402: Target correspondence verification and target consistency flag generation.

[0082] The target retrieval fragment needs to uniquely correspond to the target identification fragment. The controller is not allowed to use the processing receipt for session handling before the verification is passed. The controller reads the target identification fragment saved in step one and generates a target retrieval verification value. The target retrieval verification value is generated using the third cryptographic hash algorithm. The operation order is as follows: the target identification fragment is used as the input message, message padding, grouping processing, and iterative compression are performed, and a fixed-length hash value is output as the target retrieval verification value. The controller uses a constant-time comparison algorithm to verify the consistency between the target retrieval fragment and the target retrieval verification value. The constant-time comparison algorithm XORs each byte of the byte sequence length and accumulates the XOR results. If the accumulated XOR result is zero, it is considered consistent. If the accumulated XOR result is non-zero, it is considered inconsistent. If consistent, the target consistency flag takes the consistent value. If inconsistent, the target consistency flag takes the inconsistent value. The range of the target consistency flag value is limited to a set of binary tags.

[0083] For example, after receiving the processing receipt, the controller finds that the target retrieval fragment is inconsistent with the target retrieval check value. The target consistency flag takes the inconsistent value, the controller directly enters the session clearing branch and generates an updated control session request to avoid cross-target receipt-driven session retention.

[0084] S403: Determine the corresponding verification and receipt likelihood value calculation.

[0085] The acceptance result fragment needs to correspond to the initial license determination result. The receipt likelihood value needs to express the degree of matching between the acceptance target value and the initial license coefficient. The controller reads the initial license determination result saved in step three and generates a determination target value. When the initial license determination result is release, the determination target value is the success value; when the initial license determination result is cancellation, the determination target value is the failure value. The controller uses a constant-time comparison algorithm to verify the consistency between the determination target value and the acceptance target value. If they are consistent, the consistency flag is the consistent value; if they are inconsistent, the consistency flag is the inconsistent value. The range of the consistency flag value is limited to a set of binary labels. The controller reads... The initial license coefficient saved in step three is retrieved and boundary normalization is performed. The boundary normalization strategy is maintained by the controller's fixed configuration. Boundary normalization uses boundary parameters to restrict the initial license coefficient between the lower and upper bounds. The boundary parameters are positive numbers between zero and one, and the lower bound is less than the upper bound. Boundary normalization yields the normalized initial license coefficient. The controller calculates the receipt likelihood value. The operation order is expressed by conditional assignment. When the acceptance target value is successful, the receipt likelihood value is equal to the normalized initial license coefficient. When the acceptance target value is unsuccessful, the receipt likelihood value is equal to one minus the normalized initial license coefficient. The range of the receipt likelihood value is limited to a dimensionless real number between zero and one.

[0086] S404: Receipt verification coefficient generation and session ready flag handling.

[0087] The receipt verification coefficient needs to simultaneously satisfy target consistency and observation matching. The target consistency flag serves as a hard gate to prevent cross-target receipt contamination in the judgment. The receipt likelihood value serves as a soft quantization to distinguish the degree of matching between the acceptance result fragment and the initial approval coefficient. The controller generates the receipt verification coefficient, and the operation order is expressed using gating assignment. When the target consistency flag takes a consistent value, the receipt verification coefficient equals the receipt likelihood value; when the target consistency flag takes an inconsistent value, the receipt verification coefficient is zero. The value range of the receipt verification coefficient is limited to a dimensionless real number between zero and one. The controller processes the data based on the receipt verification coefficient and the judgment consistency flag. When the acknowledgment verification coefficient meets the threshold condition and the judgment consistency flag takes a consistent value, the session ready flag is maintained as the basis for sending subsequent control messages. When the acknowledgment verification coefficient does not meet the threshold condition or the judgment consistency flag takes an inconsistent value, the session ready flag is cleared and an updated control session request is generated. The updated control session request carries the service visibility flag, target identification fragment, and return instruction plate, and maintains a session index key association with the temporary item of the first control message. At the same time, the target consistency flag, judgment consistency flag, and acknowledgment verification coefficient are written into the judgment context for subsequent acknowledgment verification statistics calls.

[0088] Step S4 extracts the target feedback fragment and the acceptance result fragment, generates the target consistency flag and the judgment consistency flag, calculates the feedback likelihood value and feedback review coefficient, and processes the session ready flag and control session request accordingly. Step S4 enables the controller to correct the session availability judgment with the feedback review result, reduces the failure of subsequent control messages caused by incorrect session retention, and reduces unnecessary reconstruction and control interruption caused by incorrect session clearing.

[0089] Specifically, the above are merely preferred embodiments of this application and are not intended to limit this application.

[0090] The aforementioned preset thresholds or other preset parameters can be pre-calibrated through offline simulation testing or set to fixed values ​​according to on-site operating procedures.

[0091] In the description of this specification, references to terms such as "an embodiment," "example," and "specific example" indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0092] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to any specific implementation. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention.

Claims

1. A method for cooperative communication of controllers based on a distributed bus of the Hong Meng, characterized in that, Including the following steps: S1: Generate a service visibility identifier based on the target service discovery result returned by the distributed soft bus, extract the target identification fragment from the target service discovery result, form a control session request, temporarily store the first control message and generate the first control message binding information, and associate the first control message with the service visibility identifier and the target identification fragment; S2: Send a control session request, receive a session confirmation message, extract the confirmation feedback fragment and ready event fragment from the session confirmation message, generate a session ready identifier based on the ready event fragment, record the state transition records from the generation of the service visibility identifier to the generation of the session ready identifier, and maintain the temporary state of the first control message before the generation of the session ready identifier. S3: Before sending the first control message, the controller first performs cryptographic hash algorithm No. 3 on the target identification fragment to obtain the recalculated service visibility identifier. Then, it converts the recalculated service visibility identifier and the service visibility identifier into a bit sequence and calculates the Hamming distance. The Hamming distance is divided by the bit length of the service visibility identifier to obtain the identifier difference rate. Then, it subtracts the identifier difference rate to obtain the identifier similarity. The controller converts the confirmed return pointer fragment and the return instruction plate in the binding information of the first control message into a bit sequence and calculates the Hamming distance. The Hamming distance is divided by the bit length of the return instruction plate to obtain the return pointer difference rate. Then, it subtracts the return pointer difference rate to obtain the return pointer similarity. The controller takes the smaller value between the identifier similarity and the return pointer similarity as the chain pointer continuity degree. It calculates the state transition bounce rate based on the state transition record. The chain pointer continuity degree is used as consistency evidence and the state transition bounce rate is used as stability evidence for fusion processing to obtain the initial permission coefficient. Based on the initial permission coefficient, it determines whether to release or cancel the sending of the first control message. S4: Receive the first control message processing receipt returned by the target side, extract the target feedback fragment and acceptance result fragment from the processing receipt, generate the receipt review coefficient, process the session ready flag based on the receipt review coefficient, and generate an updated control session request.

2. The method of claim 1, wherein the method further comprises: Step S1 includes: The controller receives the target service discovery result, performs type length value decoding, completes length consistency determination, character decodeability determination, and format matching determination, extracts the target service identifier content and the provider node identifier content, generates the target identification fragment according to the deterministic binary object representation encoding rules, and uses the third cryptographic hash algorithm to generate a service visibility identifier for the target identification fragment.

3. The method of claim 2, wherein the method further comprises: Step S1 also includes: The controller establishes a temporary entry for the first control message. This entry stores the content of the first control message, the service visibility identifier, and the target identification fragment. It generates a fingerprint for the first control message according to the deterministic serialization rules and the third cryptographic hash algorithm. Based on the service visibility identifier and the fingerprint of the first control message, it generates a return instruction token. The binding information of the first control message consists of the service visibility identifier, the fingerprint of the first control message, and the return instruction token. The control session request carries the service visibility identifier, the target identification fragment, and the return instruction token. The session index key associates the control session request with the temporary entry for the first control message.

4. The method of claim 3, wherein the method further comprises: Step S2 includes: The controller receives the session confirmation message, performs type length value decoding, outputs the confirmation retrieval fragment and the ready event fragment, and completes the length consistency determination, length correspondence determination, and value set determination. The confirmation retrieval fragment length is consistent with the retrieval command plate length, and the ready event fragment value belongs to the ready event fragment encoding set.

5. The method of claim 4, wherein, Step S2 also includes: The controller uses a constant-time comparison algorithm to verify that the returned instruction fragment is consistent with the returned instruction plate, generates a session index key to locate the first control message temporary item, and keeps the first control message temporary item in a temporary state. When the ready event fragment is matched and enters the sendable stage encoding, a session ready identifier is generated, and a deterministic finite state automaton is used to generate and seal the state transition record.

6. The method of claim 5, wherein the method further comprises: Step S3 includes: The controller assembly determination context includes target identification fragment, service visibility identifier, first control message binding information, confirmation return fragment, and state transition record. A constant time comparison algorithm is used to verify the consistency between the confirmation return fragment and the return command plate. If they are inconsistent, the first control message is temporarily stored and the initial permission determination is terminated.

7. The controller collaborative communication method based on HarmonyOS distributed bus according to claim 6, characterized in that, Step S3 also includes: The controller constructs adjacent state pairs and marks the migration direction for the state transition record, counts the number of backtracking migrations and round-trip migrations to obtain the state transition bounce rate, performs boundary regularization and log-likelihood fusion on the chain continuation degree and the state transition bounce rate to obtain the initial permission coefficient, and determines whether to release or cancel the sending of the first control message based on the initial permission coefficient.

8. The controller collaborative communication method based on HarmonyOS distributed bus according to claim 7, characterized in that, Step S4 includes: The controller receives the processing receipt and performs type length value decoding, outputs the target retrieval fragment and the acceptance result fragment, and maps the acceptance result fragment to the acceptance target value; it performs the third cryptographic hash algorithm on the target identification fragment to generate the target retrieval verification value, and uses the constant time comparison algorithm to verify the consistency between the target retrieval fragment and the target retrieval verification value and generate a target consistency flag.

9. The controller collaborative communication method based on HarmonyOS distributed bus according to claim 8, characterized in that, Step S4 also includes: The controller generates a judgment target value based on the initial permission judgment result. The controller uses a constant time comparison algorithm to verify the consistency between the judgment target value and the acceptance target value and generates a judgment consistency flag. The controller performs boundary normalization on the initial permission coefficient and obtains the normalized initial permission coefficient. The controller generates a receipt likelihood value and a receipt review coefficient based on the acceptance target value. The controller processes the session ready flag and generates an updated control session request based on the receipt review coefficient and the judgment consistency flag.

Images