A method, system, device and medium for constructing a standard system of the horizen internet of things

Abstract

The application discloses a method, system, device and medium for constructing a harmonious Internet of Things standard system, the method comprising the steps of: constructing a unified Internet of Things model including a device model and a data model, the device model defining a unified description method for various devices in the Internet of Things, including the identity identifier, attributes, services and events of the device; the data model establishing a unified data format and coding rule for encapsulating and transmitting device data; formulating a data security standard based on data encryption, identity authentication and access control; dynamically generating a protocol matching strategy by analyzing a protocol list supported by the device, attribute and service demand, and dynamically generating a protocol mapping table to optimize the communication process. The application realizes seamless communication and data sharing between different devices by establishing a unified data standard system, and improves the compatibility, scalability and data security of the Internet of Things system.

Description

A method, system, equipment, and medium for constructing the HarmonyOS IoT standard system Technical Field

[0001] This application relates to the field of Internet of Things (IoT) communication technology, and in particular, to a method, system, device, and medium for constructing the HarmonyOS IoT standard system. Background Technology

[0002] As the number of user-side devices gradually increases, the need for interconnectivity between heterogeneous user-side devices is becoming increasingly urgent. An object model is an information model that defines the parameters, states, and functions of a specific IoT entity, used to support upper-layer applications in recognizing, managing, and accessing objects. A unified object model for a system means unified subsequent development, reduced maintenance costs, and guaranteed scalability.

[0003] However, current object models have many problems. There are subtle differences between different object models, and there is a lack of a unified object model specifically designed for user-side devices. While existing unified modeling specifications for IoT information have broad coverage, they lack specificity.

[0004] Chinese patent CN115114271A discloses a method, apparatus, storage medium, and electronic device for constructing a data standard system, applicable to the financial field or other fields. The method includes: identifying multiple established business systems and collecting metadata from each system to obtain a set of data items; determining first standard element information corresponding to each data item in the data item set; performing ambiguity elimination processing on the first standard element information corresponding to each data item to obtain second standard element information corresponding to each data item; performing deduplication processing on the data item set based on the second standard element information to obtain a processed data item set; and determining multiple data standards based on the second standard element information corresponding to each data item in the processed data item set to construct a data standard system. This invention only statically collects metadata from business systems and does not incorporate dynamic IoT elements such as real-time device status (e.g., service calls, event triggers) and environmental variables (network fluctuations, security threats), resulting in a standard system that cannot adapt to the real-time needs of device collaboration scenarios. Summary of the Invention

[0005] To address the problems existing in the prior art, this invention provides a method for constructing the HarmonyOS IoT standard system. By establishing a unified data standard system, seamless communication and data sharing between different devices can be achieved, thereby improving the compatibility, scalability, and data security of the IoT system.

[0006] This application is achieved through the following solution:

[0007] A method for constructing the HarmonyOS IoT standard system includes the following steps:

[0008] The construction of a unified IoT model includes a device model and a data model. The device model defines a unified description method for various devices in the Internet of Things, including device identifiers, attributes, services, and events. The data model establishes a unified data format and encoding rules for encapsulating and transmitting device data.

[0009] Develop data security standards based on data encryption, identity authentication, and access control;

[0010] By analyzing the list of protocols supported by the device, its attributes, and service requirements, a protocol matching strategy is dynamically generated, and a protocol mapping table is dynamically generated to optimize the communication process.

[0011] Furthermore, the identification identifier is used to uniquely identify or locate the device, and is defined based on the device root identifier and the area binding code; the device root identifier consists of the device manufacturer OUI and the device type code, and the area binding code is mapped from the area code of the base station currently connected to the device;

[0012] The attributes are used to describe the basic characteristics and status information of the device, including static attributes and dynamic attributes; the static attributes are the device's own static information, and the dynamic attribute update process is as follows:

[0013] Based on historical data of device dynamic attributes, predict attribute values ​​for a future period of time:

[0014] ;

[0015] ;

[0016] ;

[0017] in, Indicates the time after the current moment Predicted values ​​of device dynamic attributes at any given time. ∈[10,30], This represents the predicted horizontal value at time t. This represents the trend prediction value at time t. The horizontal smoothing coefficient. The actual value of the device's dynamic attributes at time t. This is the trend smoothing coefficient;

[0018] Based on the predicted values ​​of equipment dynamic attributes and the historical maximum deviation rate of historical data of equipment dynamic attributes, a prediction data interval is constructed.

[0019] Collect the actual values ​​of the device's dynamic attributes. If the actual values ​​of the device's dynamic attributes fall within the predicted data range, the device will not upload its dynamic attributes and will only update its local data. If the actual values ​​of the device's dynamic attributes exceed the predicted data range, they will be marked as outliers and the outliers and prediction deviations will be uploaded.

[0020] The service is built on a device rule base and is used to define the operations or functions provided by the device. The service is invoked to control the operating status of the device.

[0021] The event is used to describe a specific situation or state change that occurs during the operation of the device. Based on the event, the device autonomously sends an event notification to the IoT platform for corresponding processing.

[0022] Furthermore, the data encryption in the data security standard uses the Dynamic Round Key AES algorithm to encrypt device data. The specific implementation process of the Dynamic Round Key AES algorithm is as follows:

[0023] A 128-bit master key is generated based on a secure key negotiation protocol and an IoT platform. The initial chaotic value is calculated by collecting the last byte of the device's unique identifier and the last byte of the device event. and initialize the wheel counter. ;

[0024] Based on the chaotic mapping formula and initial chaotic value Calculate the new chaotic value :

[0025] ;

[0026] In the formula, These are the chaotic control parameters, which are calculated using the equipment's operating condition data.

[0027] Then convert the new chaotic value to integer form and update the chaotic state. ;

[0028] based on Calculate the key shift bits and perform a cyclic left shift operation on the master key to obtain the temporary key. Determine the byte insertion position based on the round counter, and insert the chaotic byte into the temporary key at the byte insertion position to obtain the dynamic round key.

[0029] like If the value is 0, perform the initial round key addition operation: XOR the original data block to be encrypted with the dynamic round key; if... The standard AES round operations include: byte substitution, row shifting, column obfuscation, and round key addition; if The final round operations include: byte substitution, row shifting, and round key addition;

[0030] calculate ,like Return to step S2; otherwise, output the ciphertext.

[0031] Obtain the next data block, reset the round counter while maintaining the current chaotic state, and return to step S2 until all data blocks have been processed.

[0032] Furthermore, data security standards introduce dynamic timeliness verification strategies for identity authentication, specifically:

[0033] Based on the authentication device's identity identifier, an event-sensitive verification factor is superimposed: each time the device initiates an authentication request, it first obtains the current timestamp and generates a dynamic verification code using the HMAC_SHA256 algorithm.

[0034] ;

[0035] In the formula, It is a dynamic verification code; The algorithm is HMAC_SHA256. For the device's identity identifier; This is the current timestamp; Preset key;

[0036] The device sends its identity identifier, current timestamp, and dynamic verification code to the authentication server. After receiving the identity authentication request, the authentication server performs the following verifications: Time window verification: Calculate the difference between the current time and the current timestamp, and determine whether it is within the preset tolerance time window. If it is, perform key matching verification: Retrieve the preset key bound to the device in the database, regenerate the dynamic verification code using the HMAC_SHA256 algorithm, and compare the dynamic verification code sent by the device with the dynamic verification code calculated by the authentication server. If they match, the identity authentication is successful; otherwise, access to the IoT system is rejected.

[0037] Real-time extraction of device behavior features, including communication duration, transmission rate, and protocol switching count during the device's last three access attempts, constructs a behavior feature vector [T, R, S], and calculates the distance between the behavior feature vector and the preset base vector [T0, R0, S0].

[0038] ;

[0039] Where D is the behavior distance, w T w R and w SThese are the communication duration feature weight, transmission rate feature weight, and protocol switching number feature weight, respectively. T, R, and S are the communication duration, transmission rate, and protocol switching number, respectively. T0, R0, and S0 are the preset base values ​​for communication duration, transmission rate, and protocol switching number, respectively.

[0040] When the behavior distance D is greater than the preset threshold, the identity authentication step is performed again.

[0041] Furthermore, the communication duration feature weight w T w R and w S Dynamically adjust based on historical data of device type and behavioral characteristics, specifically:

[0042] Define different device types w T w R and w S The basic weight is determined to prioritize either transmission rate or stability.

[0043] In w T w R and w S Based on the basic weights, dynamic adjustments are made according to the historical data of behavioral characteristics. For any behavioral characteristic, the fluctuation coefficient of the corresponding behavioral characteristic in the historical period is first calculated based on the standard deviation and mean of the corresponding behavioral characteristic in the historical period of the equipment.

[0044] Set a fluctuation coefficient threshold for the corresponding behavioral feature. If the fluctuation coefficient of the corresponding behavioral feature is less than the fluctuation coefficient threshold, increase the corresponding basic weight by a certain percentage; if the fluctuation coefficient of the corresponding behavioral feature is greater than or equal to the fluctuation coefficient threshold, decrease the corresponding basic weight by a certain percentage.

[0045] For w T w R and w S After adjusting the basic weights, normalization is performed to ensure that w T +w R +w S =1.

[0046] Furthermore, data security standards introduce a dynamic permission decay pre-detection mechanism into access control, specifically:

[0047] In IoT systems, different initial data access permissions and initial permission points are pre-assigned based on the role and needs of the devices.

[0048] The specific steps for establishing a three-dimensional collaborative integral calculation mechanism to update permission points are as follows:

[0049] ;

[0050] In the formula, for Permission points are updated in real time; for Permission points at any given moment; The natural decay rate of the privilege points per unit time; This refers to the time difference between two permission point updates. for The number of equipment operations that occurred within the time limit. ; The basic attenuation of equipment operation per unit time; For the first Risk factor of secondary equipment operation; For the first The time required for each equipment operation; This is the amplification factor of the attenuation amount due to the current network state;

[0051] The system matches the operation permission level corresponding to the initial permission score, updates the permission score based on the three-dimensional collaborative score calculation mechanism, and freezes device operation and forces identity verification when the permission score is lower than the preset minimum permission score.

[0052] Furthermore, by analyzing the list of protocols supported by the device, their attributes, and service requirements, a protocol matching strategy is dynamically generated, and a protocol mapping table is dynamically generated to optimize the communication process. Specifically:

[0053] The protocol selection is based on a list of protocols supported by both communicating devices as a basic candidate set, and the protocol priority is evaluated according to device attributes and service requirements. The preset matching rules are then applied to select the protocol.

[0054] Based on the adaptive configuration of the selected protocol pair or single protocol, a protocol mapping table is dynamically generated. The protocol mapping table defines the core conversion rules, including parsing the differences in message structure between the source protocol and the target protocol and reconstructing and mapping fields, performing semantic equivalent conversion of operation instructions, adapting data formats according to data transmission rate and bandwidth requirements, matching service quality levels, and transmitting necessary security context information.

[0055] This application also provides a system for constructing the HarmonyOS IoT standard system, including:

[0056] The device model construction module is used to build a unified IoT model, including a device model and a data model. The device model defines a unified description method for various devices in the Internet of Things, including device identifiers, attributes, services, and events. The data model establishes a unified data format and encoding rules for encapsulating and transmitting device data.

[0057] The HarmonyOS IoT Standards Development Module is used to develop data security standards based on data encryption, identity authentication, and access control.

[0058] The protocol matching module is used to dynamically generate protocol matching strategies by analyzing the list of protocols supported by the device, their attributes, and service requirements, and to dynamically generate a protocol mapping table to optimize the communication process.

[0059] This application also provides an electronic device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the method for constructing the HarmonyOS IoT standard system.

[0060] This application also provides a computer-readable storage medium storing a computer program thereon, characterized in that the computer program, when executed by a processor, implements the method for constructing the HarmonyOS IoT standard system.

[0061] Compared with the prior art, this application has the following advantages:

[0062] 1. This application establishes a unified data standard system, enabling seamless communication and data sharing between devices from different manufacturers and models within the HarmonyOS IoT standard system, greatly improving the compatibility of IoT systems;

[0063] 2. This application facilitates the expansion of IoT systems by establishing a unified HarmonyOS IoT standard system. New devices can be easily connected to the system without large-scale modifications to the existing system, thus enhancing the scalability of the existing system;

[0064] 3. This application improves data security standards by refining data encryption algorithms, effectively ensuring the security of data from IoT devices, preventing data leakage and unauthorized access, and protecting the legitimate rights and interests of users and enterprises;

[0065] 4. This application improves the efficiency and accuracy of communication protocol conversion and optimizes the overall performance of the Internet of Things system by using dynamic protocol mapping and introducing an adaptive rule base.

[0066] In addition to the purposes, features, and advantages described above, this application has other purposes, features, and advantages. A further detailed description of this application will be provided below with reference to the figures. Attached Figure Description

[0067] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0068] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort, wherein:

[0069] Figure 1 is a flowchart illustrating the method for constructing the HarmonyOS IoT standard system according to a preferred embodiment of this application;

[0070] Figure 2 is a schematic diagram of the modules of the system for constructing the HarmonyOS IoT standard system according to a preferred embodiment of this application;

[0071] Figure 3 is a schematic block diagram of an electronic device according to a preferred embodiment of this application;

[0072] Figure 4 is an internal structural diagram of a computer device according to a preferred embodiment of this application. Detailed Implementation

[0073] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0074] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0075] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or a device capable of building the HarmonyOS IoT standard system. The following description uses a device building the HarmonyOS IoT standard system as an example to illustrate this embodiment and the subsequent embodiments.

[0076] As shown in Figure 1, a preferred embodiment of this application provides a method for constructing the HarmonyOS IoT standard system, including the following steps:

[0077] S1. Constructing a unified IoT model includes a device model and a data model. The device model defines a unified description method for various devices in the Internet of Things, including device identifiers, attributes, services, and events. The data model establishes a unified data format and encoding rules for encapsulating and transmitting device data.

[0078] S2. Develop data security standards based on data encryption, identity authentication, and access control;

[0079] S3. By analyzing the list of protocols supported by the device, attributes and service requirements, a protocol matching strategy is dynamically generated, and a protocol mapping table is dynamically generated to optimize the communication process.

[0080] Compared with the prior art, this embodiment has the following beneficial effects:

[0081] 1. This embodiment establishes a unified data standard system, enabling seamless communication and data sharing between devices from different manufacturers and models within the HarmonyOS IoT standard system, greatly improving the compatibility of IoT systems;

[0082] 2. This embodiment facilitates the expansion of IoT systems by establishing a unified HarmonyOS IoT standard system. New devices can be easily connected to the system without requiring large-scale modifications to the existing system, thus enhancing the scalability of the existing system;

[0083] 3. This embodiment improves data security standards by refining data encryption algorithms, effectively ensuring the security of IoT device data, preventing data leakage and unauthorized access, and protecting the legitimate rights and interests of users and enterprises;

[0084] 4. This embodiment improves the efficiency and accuracy of communication protocol conversion and optimizes the overall performance of the Internet of Things system by using dynamic protocol mapping and introducing an adaptive rule base.

[0085] In a preferred embodiment of this application, the identity identifier is used to uniquely identify or locate the device, and is defined based on the device root identifier and the area binding code. The device root identifier consists of the device manufacturer OUI and the device type code (defined by the HarmonyOS IoT standard). The area binding code is mapped from the location area code of the base station currently connected to the device (taken from the last N letters of the location area code (LAC) in the base station broadcast message). Furthermore, the identity identifier code can be optimized by adding dynamic factors such as timestamp + chained HMAC field calculated based on timestamp and signal strength.

[0086] The attributes are used to describe the basic characteristics and status information of the device, including static attributes and dynamic attributes. The static attributes are the device's own static information, while the dynamic attributes are generally used to describe the continuous status information that the device can maintain during operation, such as operating voltage and current. The update process is as follows:

[0087] Based on historical data of device dynamic attributes, predict attribute values ​​for a future period of time:

[0088] ;

[0089] ;

[0090] ;

[0091] in, Indicates the time after the current moment The predicted dynamic attribute value of a device at a given moment is the prediction of the dynamic attribute value of a device at a future point in time based on the data at the current moment (such as the power of smart home appliances, the temperature of industrial sensors, etc.). ∈[10,30], (if the prediction is 10 seconds, then k=10, and if it is 20 seconds, then k=20). This represents the predicted horizontal value at time t. This represents the trend prediction value at time t. This is a horizontal smoothing coefficient used to balance the impact of current actual and historical forecast data on future forecast results, with a value range of 0.3-0.7. This represents the actual value of the device's dynamic attributes at time t, i.e., the raw data of the dynamic attributes reported or detected by the device at the current time point. This is the trend smoothing coefficient, with a value ranging from 0.2 to 0.4.

[0092] Based on the predicted values ​​of equipment dynamic attributes and the historical maximum deviation rate of historical data of equipment dynamic attributes, a prediction data interval is constructed, specifically as follows:

[0093] First, collect historical data sequences of device dynamic attributes over the past 10 minutes (such as continuous changes in power of smart home appliances, temperature / current of industrial sensors, etc.), and simultaneously record the deviation data between predicted and actual values ​​within the corresponding time period. Then, calculate the historical maximum deviation rate using the deviation data.

[0094] ;

[0095] in, This represents the highest historical deviation rate. This indicates the operation of retrieving the maximum value. express Predicted values ​​of device dynamic attributes at any given time. express The actual value of the device's dynamic attributes at any given time. Indicates a time step;

[0096] A dynamic baseline is constructed using historical maximum deviation rates and historical data of equipment dynamic attribute values:

[0097] First, calculate the mean and standard deviation of the device's dynamic attribute values:

[0098] ;

[0099] ;

[0100] in, This represents the average of the device's dynamic attribute values. The standard deviation of the device's dynamic attribute values. This represents the total number of historical data points for the device's dynamic attribute values. This refers to the historical data of the dynamic attribute values ​​of the i-th device.

[0101] Construct a dynamic baseline based on the mean and standard deviation:

[0102] ;

[0103] in, For dynamic baseline, The sparsity coefficient (dynamically set according to device type).

[0104] Will , and It is stored locally on the edge device and updated according to a preset period. The dynamic baseline is recalculated based on the newly generated historical data, so that the dynamic baseline can be iterated with the device operating conditions, avoiding the failure of the dynamic baseline due to device aging or environmental changes.

[0105] The system collects the actual values ​​of the device's dynamic attributes. If the actual value falls within the predicted data range, the device will not upload its dynamic attributes and will only update its local data. If the actual value exceeds the predicted data range, it will be marked as an outlier, and the outlier and prediction deviation will be uploaded. Specifically, this includes:

[0106] Collect the actual values ​​of the device's dynamic attributes and calculate the deviation between the actual and predicted values ​​of the device's dynamic attributes:

[0107] ;

[0108] in, This is the deviation value;

[0109] like If the actual value of the device's dynamic attribute is within the predicted coverage area, no data packet will be uploaded. Then, the dynamic baseline is used to determine whether the data belongs to the normal or abnormal category. The specific determination criteria are as follows:

[0110] like If the data is positive, it is considered normal data; otherwise, it is considered abnormal data.

[0111] For normal data, the data index and default identifier of the actual value of the corresponding device dynamic attribute are encoded and packaged for uploading; for abnormal data, the data index, timestamp, and deviation value of the actual value of the corresponding device dynamic attribute are encoded and uploaded as a data packet.

[0112] In traditional solutions, devices need to upload all dynamic attribute data in real time (even if the changes are minor), leading to a surge in transmission volume in high-concurrency scenarios. This embodiment filters data within the prediction coverage by the deviation between actual and predicted values, and filters normal and abnormal data by a dynamically updated baseline. Only data with significant deviations is encoded and uploaded; otherwise, the device only updates its local cache and does not upload data to the platform, significantly reducing redundant data transmission.

[0113] The service is built on a device rule base and is used to define the operations or functions provided by the device, including on / off control, brightness adjustment, color switching, etc. of the user-side device. The service is called to control the operating status of the device.

[0114] The events are used to describe specific situations (such as device startup, shutdown, fault alarm, etc.) or state changes (including power changes, switch status changes, fault alarms, etc.) that occur during device operation. Based on the events that occur, the device autonomously sends event notifications to the IoT platform for corresponding processing.

[0115] In a preferred embodiment of this application, the data encryption in the data security standard uses the Dynamic Round Key AES algorithm to encrypt the device data. The specific implementation process of the Dynamic Round Key AES algorithm is as follows:

[0116] S1: Generate a 128-bit master key based on the secure key negotiation protocol and the IoT platform, and calculate the initial value of chaos by collecting the last byte of the device's unique identifier and the last byte of the device event. and initialize the wheel counter. =0;

[0117] S2: Based on the chaotic mapping formula and initial chaotic values Calculate the new chaotic value :

[0118] ;

[0119] In the formula, These are the chaotic control parameters, calculated using the equipment's operating condition data.

[0120] ;

[0121] in, The strength of network encryption (e.g., 80 points for TLS 1.2, 100 points for TLS 1.3). CPU utilization This represents the number of authentication failures in the past hour. The value range is limited to between 3.5 and 3.8 to ensure the randomness of the chaotic sequence;

[0122] Then convert the new chaotic value to integer form and update the chaotic state. ;

[0123] S3: The key shift bits are calculated based on the remainder after dividing r by a preset integer, and a temporary key is obtained by cyclically shifting the master key to the left. The byte insertion position is determined based on the remainder after dividing the round counter by a preset integer. The chaotic byte is inserted into the temporary key at the byte insertion position to obtain the dynamic round key, while the other positions remain unchanged.

[0124] S4: If If the value is 0, perform the initial round key addition operation: XOR the original data block to be encrypted with the dynamic round key; if... The standard AES round operations include: byte substitution (applying AES S-box permutation byte by byte), row shifting (cyclically shifting each row of the state matrix), column obfuscation (applying MixColumns transformation), and round key addition; if The final round operations include: byte substitution, row shifting, and round key addition;

[0125] S5: Calculation ,like Return to step S2; otherwise, output the ciphertext.

[0126] S6: Obtain the next data block, reset the round counter and maintain the current chaotic state, and return to step S2 until all data blocks have been processed.

[0127] In a preferred embodiment of this application, the data security standard introduces a dynamic timeliness verification strategy for identity authentication, specifically as follows:

[0128] Based on the authentication device's identity identifier, an event-sensitive verification factor is superimposed: each time the device initiates an authentication request, it first obtains the current timestamp and generates a dynamic verification code using the HMAC_SHA256 algorithm.

[0129] ;

[0130] In the formula, It is a dynamic verification code; The algorithm is HMAC_SHA256. For the device's identity identifier; This is the current timestamp; Preset key;

[0131] The device sends its identity identifier, current timestamp, and dynamic verification code to the authentication server. Upon receiving the authentication request, the authentication server performs verification including: Time window verification: Calculating the difference between the current time and the current timestamp, and determining if it falls within a preset tolerance time window. If so, key matching verification is performed: Retrieving the preset key bound to the device from the database, and using the HMAC_SHA256 algorithm to regenerate the dynamic verification code based on the received device identity identifier, the received current timestamp, and the preset key bound to the device in the database. Comparing the dynamic verification code sent by the device with the dynamic verification code calculated by the authentication server, if they match, authentication is successful; otherwise, access to the IoT system is rejected. If the difference between the current time and the current timestamp is not within the preset tolerance time window, a sliding window compensation mechanism is used to automatically generate P candidate timestamps (preferably the device's current timestamp and timestamps at a uniform distance before and after the device's current timestamp). Candidate verification codes are calculated for each candidate timestamp. Successful authentication is considered achieved if any one of these candidate timestamps matches the dynamic verification code sent by the device, thus mitigating network latency or device clock drift issues.

[0132] Real-time extraction of device behavior features, including communication duration, transmission rate, and protocol switching count during the device's last three access attempts, to construct a behavior feature vector. , , ], calculate the behavioral feature vector and the preset base value vector[ , , Distance:

[0133] ;

[0134] Where D is the behavior distance, w T w R and w S These are the communication duration feature weight, transmission rate feature weight, and protocol switching number feature weight, respectively. T, R, and S are the communication duration, transmission rate, and protocol switching number, respectively. T0, R0, and S0 are the preset base values ​​for communication duration, transmission rate, and protocol switching number, respectively.

[0135] Specifically, the communication duration feature weight w T w R and w S Dynamically adjust based on historical data of device type and behavioral characteristics, specifically:

[0136] First, define w for different device types T w R and w SThe basic weights are determined to prioritize either transmission rate or stability; for example, for industrial sensors, w T w R and w S The base weights are set to 0.2, 0.6, and 0.2 respectively to prioritize transmission speed; for home devices, the base weights are set to 0.5, 0.3, and 0.2 respectively to prioritize stability.

[0137] Next, in w T w R and w S Based on the basic weights, dynamic adjustments are made according to historical data of behavioral characteristics. For any behavioral characteristic, the fluctuation coefficient of the corresponding behavioral characteristic within the historical period is first calculated based on the standard deviation and mean of the corresponding behavioral characteristic within the historical period of the device. For example, for transmission rate, the standard deviation and mean of its last 30 accesses are obtained, and the fluctuation coefficient is calculated.

[0138] ;

[0139] in, The fluctuation coefficient representing the transmission rate. This represents the standard deviation of the transmission rate over the device's last 30 connections. This represents the average transmission rate of the device during its last 30 access attempts.

[0140] Then, a fluctuation coefficient threshold is set for the corresponding behavioral characteristic. If the fluctuation coefficient of the corresponding behavioral characteristic is less than the fluctuation coefficient threshold, it indicates that the corresponding behavioral characteristic of the device is stable in the long term and has high sensitivity, so the corresponding basic weight is increased by a certain percentage. If the fluctuation coefficient of the corresponding behavioral characteristic is greater than or equal to the fluctuation coefficient threshold, it indicates that the transmission rate of the device fluctuates in the long term and has low sensitivity, so the corresponding basic weight is decreased by a certain percentage. For example, if... A value less than the fluctuation coefficient threshold indicates that the device's transmission rate is stable over a long period, and it has high sensitivity. Increase by a certain percentage (e.g., 10%); if A value greater than or equal to the fluctuation coefficient threshold indicates that the device's transmission rate fluctuates over a long period, indicating low sensitivity. Reduce by a certain percentage (e.g., 10%).

[0141] Finally, regarding w T w R and w S After adjusting the basic weights, normalization is performed to ensure that w T +w R +w S =1;

[0142] When the behavior distance D is greater than the preset threshold, the identity authentication step is performed again.

[0143] Traditional behavioral authentication often relies on a single feature (such as verifying only the transmission rate), which is prone to misjudgment due to network fluctuations (such as temporary signal weakness causing a rate drop, which is mistakenly judged as abnormal). The technical solution in this embodiment solves this problem by using three-dimensional feature vectors and Euclidean distance calculation. The three dimensions of features are communication duration T (reflecting the connection stability between the device and the platform), transmission rate R (reflecting the device's hardware capabilities and network bandwidth), and protocol switching count S (reflecting the device's functional requirements). These three together constitute the device's behavioral fingerprint, and fluctuations in a single feature do not affect the overall judgment.

[0144] To dynamically adapt to the evolution of device behavior and avoid excessive security restrictions that may lead to slow changes in device behavior due to hardware aging and network environment changes during long-term use, traditional static thresholds are prone to misinterpreting such normal changes as abnormal. The technical solution of this application adapts to this change through the following mechanism:

[0145] The base value vector is dynamically updated. If the device passes the identity authentication three times in a row and the behavior distance D is close to the threshold but not exceeded (e.g., D=5.2, threshold=5.5), the platform automatically updates the current behavior feature vector [T, R, S] to the new base value vector [T0, R0, S0] to avoid triggering re-authentication due to the same change in the future. Through dynamic updating of the base value, security can be guaranteed while avoiding affecting the user experience.

[0146] In a preferred embodiment of this application, the data security standard introduces a dynamic permission decay pre-detection mechanism for access control, specifically as follows:

[0147] In IoT systems, different initial data access permissions and initial permission scores are pre-assigned according to the role and needs of the devices. While retaining the initial data access permission allocation, a two-factor adjustment strategy of operation entropy weight and environmental trust coefficient is introduced. Specifically, a three-dimensional collaborative integral calculation mechanism is established, including linear decay of permission values ​​in the time dimension, operation entropy weight calculated according to the risk level of the device's execution instructions for permission integration in the operation dimension, and attenuation multiplier coefficient generated by real-time evaluation of the network status of the device in the environmental dimension.

[0148] The specific steps for establishing a three-dimensional collaborative integral calculation mechanism to update permission points are as follows:

[0149] ;

[0150] In the formula, for Permission points are updated in real time; for Permission points at any given moment; The natural decay rate of the privilege points per unit time; This refers to the time difference between two permission point updates. for The number of equipment operations that occurred within the time limit. ; The basic attenuation of equipment operation per unit time; For the first The risk factor of this equipment operation, among which... , As a quantification factor for risk level; For the first The time required for each equipment operation; This is the amplification factor of the attenuation due to the current network state, which can be calculated based on the network encryption strength and connection stability.

[0151] The system matches the operation permission level corresponding to the initial permission score, updates the permission score based on the three-dimensional collaborative score calculation mechanism, and freezes device operation and forces identity verification when the permission score is lower than the preset minimum permission score.

[0152] In a preferred embodiment of this application, a protocol matching strategy is dynamically generated by analyzing the list of protocols supported by the device, their attributes, and service requirements, and a protocol mapping table is dynamically generated to optimize the communication process. Specifically:

[0153] First, a list of protocols commonly supported by both communicating devices (the protocol intersection) is used as the basic candidate set. Then, the protocol priority is evaluated based on device attributes (such as device type, processing power, and power consumption limitations) and service requirements (such as real-time requirements, data volume, transmission frequency, reliability level, and security strength). Pre-defined matching rules are applied to select the protocol. For example, lightweight protocols (such as CoAP and MQTT-SN) are preferred for resource-constrained devices and low-bandwidth scenarios; low-latency protocols (such as DDS or a specially configured MQTT) are preferred for high-real-time control commands; streaming or chunked protocols (such as HTTP) are preferred for large data transmissions; and encrypted protocol versions (such as MQTT over TLS) are mandatory for security-sensitive scenarios.

[0154] Based on the adaptive configuration of selected protocol pairs or single protocols, a protocol mapping table is dynamically generated. This table defines core conversion rules, including parsing the differences in message structure between the source and target protocols and reconstructing and mapping fields; semantically converting operation commands (such as publish / subscribe, read / write) to equivalent forms; adapting data formats according to data transmission rate and bandwidth requirements (such as compressing and simplifying non-critical data or performing efficient encoding / decoding); matching Quality of Service (QoS) levels (such as acknowledgment mechanism mapping) to handle differences in message delivery reliability guarantees between different communication protocols; and transmitting necessary security context information (such as credential conversion). This ensures that the generated protocol mapping table can accurately and efficiently bridge devices using different protocols, achieving dynamic, optimized, and seamless communication, and can be continuously optimized based on network conditions and device status.

[0155] As shown in Figure 2, another preferred embodiment of this application also provides a system for constructing the HarmonyOS IoT standard system, including:

[0156] The device model construction module is used to build a unified IoT model, including a device model and a data model. The device model defines a unified description method for various devices in the Internet of Things, including device identifiers, attributes, services, and events. The data model establishes a unified data format and encoding rules for encapsulating and transmitting device data.

[0157] The HarmonyOS IoT Standards Development Module is used to develop data security standards based on data encryption, identity authentication, and access control.

[0158] The protocol matching module is used to dynamically generate protocol matching strategies by analyzing the list of protocols supported by the device, their attributes, and service requirements, and to dynamically generate a protocol mapping table to optimize the communication process.

[0159] The system for constructing the HarmonyOS IoT standard system provided in this embodiment adopts the method for constructing the HarmonyOS IoT standard system in the above embodiments. Compared with the prior art, the beneficial effects of the system for constructing the HarmonyOS IoT standard system provided in this embodiment are the same as the beneficial effects of the method for constructing the HarmonyOS IoT standard system provided in the above embodiments. Moreover, the other technical features of the system for constructing the HarmonyOS IoT standard system are the same as the features disclosed in the method of the above embodiments, and will not be repeated here.

[0160] As shown in Figure 3, a preferred embodiment of this embodiment also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the method for constructing the HarmonyOS IoT standard system in the above embodiment.

[0161] This embodiment provides an electronic device that uses the method for constructing the HarmonyOS IoT standard system described in the above embodiments. Compared with the prior art, the beneficial effects of the electronic device provided in this embodiment are the same as those of the method for constructing the HarmonyOS IoT standard system described in the above embodiments. Furthermore, the other technical features of the electronic device are the same as those disclosed in the method of the above embodiments, and will not be elaborated here.

[0162] As shown in Figure 4, a preferred embodiment of this invention also provides a computer device, which can be a terminal or a liveness detection server, and its internal structure is shown in Figure 4. The computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface is used to communicate with other external computer devices via a network connection. When the computer program is executed by the processor, it implements the steps of the method for constructing the HarmonyOS IoT standard system described above.

[0163] Those skilled in the art will understand that the structure shown in Figure 4 is merely a block diagram of a portion of the structure related to the solution of this embodiment, and does not constitute a limitation on the computer device to which the solution of this embodiment is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0164] The computer device provided in this application adopts the method for constructing the HarmonyOS IoT standard system in the above embodiments. Compared with the prior art, the beneficial effects of the computer device provided in this embodiment are the same as the beneficial effects of the method for constructing the HarmonyOS IoT standard system provided in the above embodiments. Moreover, the other technical features in the electronic device are the same as the features disclosed in the method of the above embodiments, and will not be repeated here.

[0165] A preferred embodiment of this example also provides a storage medium, which includes a stored program. When the program is executed, it controls the device where the storage medium is located to perform the steps of the method for constructing the HarmonyOS IoT standard system described in the above embodiment.

[0166] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0167] If the functions described in this embodiment are implemented as software functional units and sold or used as independent products, they can be stored in one or more computing device-readable storage media. Based on this understanding, the parts of this embodiment that contribute to the prior art or the technical solution can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a computing device (which may be a personal computer, server, mobile computing device, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this embodiment. The aforementioned storage media include: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.

[0168] Those skilled in the art will understand that the embodiments of this example can be provided as methods, systems, or computer program products. Therefore, this example can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this example can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The solutions in this example can be implemented using various computer languages, such as the object-oriented programming language C++ and the embedded programming language C.

[0169] This embodiment is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this embodiment. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0170] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0171] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0172] This embodiment also provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the method for constructing the HarmonyOS IoT standard system as described above.

[0173] The computer program product provided in this embodiment solves the technical problems of high testing and experimentation costs, delays, limited applicability, and slowdowns in scientific research progress in existing technologies. Compared with the prior art, the beneficial effects of the computer program product provided in this embodiment are the same as those of the method for constructing the HarmonyOS IoT standard system provided in the above embodiments, and will not be repeated here.

[0174] Although preferred embodiments of this embodiment have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this embodiment.

[0175] Obviously, those skilled in the art can make various modifications and variations to this embodiment without departing from the spirit and scope of this embodiment. Therefore, if these modifications and variations of this embodiment fall within the scope of the claims of this embodiment and their equivalents, this embodiment is also intended to include these modifications and variations.

Claims

1. A method for constructing the HarmonyOS IoT standard system, characterized in that, The steps include: constructing a unified IoT model, comprising a device model and a data model. The device model defines a unified description method for various devices in the IoT, including device identifiers, attributes, services, and events. The data model establishes a unified data format and encoding rules for encapsulating and transmitting device data. The identifier is used to uniquely identify or locate the device, defined based on the device root identifier and the area binding code. The device root identifier consists of the device manufacturer's OUI and the device type code, and the area binding code is mapped from the area code of the base station currently connected to the device. The attributes describe the basic characteristics and status information of the device, including static and dynamic attributes. The static attributes are the device's own static information, and the dynamic attribute update process specifically involves predicting attribute values ​​for a future period based on historical data of the device's dynamic attributes. ； ； ;in, Indicates the time after the current moment Predicted values ​​of device dynamic attributes at any given time. ∈[10,30]， This represents the predicted horizontal value at time t. This represents the trend prediction value at time t. The horizontal smoothing coefficient. The actual value of the device's dynamic attributes at time t. The trend smoothing coefficient is used; a prediction data range is constructed based on the predicted values ​​of device dynamic attributes and the historical maximum deviation rate of historical data of device dynamic attributes; the actual values ​​of device dynamic attributes are collected. If the actual value of the device dynamic attribute falls within the prediction data range, the device will not upload the device dynamic attribute temporarily, but will only perform local data updates. If the actual value of the device dynamic attribute exceeds the prediction data range, it is marked as an outlier, and the outlier and prediction deviation are uploaded; the service is built based on the device rule base and is used to define the operations or functions provided by the device, and to control the device's operating status by calling the service; the event is used to describe specific situations or state changes that occur during the operation of the device. Based on the events that occur, the device autonomously sends event notifications to the IoT platform for corresponding processing; data security standards based on data encryption, identity authentication, and access control are formulated; a protocol matching strategy is dynamically generated by analyzing the list of protocols supported by the device, attributes, and service requirements, and a protocol mapping table is dynamically generated to optimize the communication process.

2. The method for constructing the HarmonyOS IoT standard system according to claim 1, characterized in that, The data encryption in the data security standard uses the Dynamic Round Key AES algorithm to encrypt device data. The specific implementation process of the Dynamic Round Key AES algorithm is as follows: a 128-bit master key is generated based on the security key negotiation protocol and the IoT platform; the last byte of the device's unique identifier and the last byte of the device event are collected to calculate the initial chaotic value. and initialize the wheel counter. ； Based on the chaotic mapping formula and initial chaotic value Calculate the new chaotic value ： In the formula, These are the chaotic control parameters, calculated using the equipment's operating data; the new chaotic values ​​are then converted to integer form to update the chaotic state. ； based on Calculate the key shift bits and perform a cyclic left shift operation on the master key to obtain the temporary key. Determine the byte insertion position based on the round counter, and insert the chaotic byte into the temporary key at the byte insertion position to obtain the dynamic round key. like If the value is 0, perform the initial round key addition operation: XOR the original data block to be encrypted with the dynamic round key; like The standard AES round operations include: byte substitution, row shifting, column obfuscation, and round key addition; if The final round operations include: byte substitution, row shifting, and round key addition; calculation ,like If the previous data block is not processed, return to step S2; otherwise, output the ciphertext; obtain the next data block, reset the round counter and maintain the current chaotic state, and return to step S2 until all data blocks have been processed.

3. The method for constructing the HarmonyOS IoT standard system according to claim 1, characterized in that, Data security standards introduce a dynamic timeliness verification strategy for identity authentication. Specifically, an event-sensitive verification factor is superimposed on the identity identifier of the authentication device. Each time the device initiates an identity authentication request, it first obtains the current timestamp and generates a dynamic verification code using the HMAC_SHA256 algorithm. In the formula, It is a dynamic verification code; The algorithm is HMAC_SHA256. For the device's identity identifier; This is the current timestamp; Preset key; The device sends its identity identifier, current timestamp, and dynamic verification code to the authentication server. Upon receiving the authentication request, the authentication server performs verification including: Time window verification: calculating the difference between the current time and the current timestamp, and determining if it falls within a preset tolerance time window. If so, key matching verification is performed: retrieving the preset key bound to the device from the database, regenerating the dynamic verification code using the HMAC_SHA256 algorithm, and comparing the dynamic verification code sent by the device with the dynamic verification code calculated by the authentication server. If they match, authentication is successful; otherwise, access to the IoT system is rejected. Real-time extraction of device behavior characteristics, including communication duration, transmission rate, and protocol switching count during the device's last three access attempts, constructs a behavior feature vector [T, R, S], and calculates the distance between the behavior feature vector and the preset base vector [T0, R0, S0]. Where D is the behavioral distance, w T w R and w S These are the communication duration feature weight, transmission rate feature weight, and protocol switching number feature weight, respectively. T, R, and S are the communication duration, transmission rate, and protocol switching number, respectively. T0, R0, and S0 are the preset base values ​​for communication duration, transmission rate, and protocol switching number, respectively. When the behavior distance D is greater than the preset threshold, the identity authentication step is performed again.

4. The method for constructing the HarmonyOS IoT standard system according to claim 3, characterized in that, Communication duration feature weight w T w R and w S Dynamically adjust based on historical data of device type and behavioral characteristics, specifically: define w for different device types T w R and w S The basic weight is used to ensure either transmission rate priority or stability priority; in w T w R and w S Based on the basic weights, dynamic adjustments are made according to historical data of behavioral characteristics. For any behavioral characteristic, the fluctuation coefficient of the corresponding behavioral characteristic within the historical period is first calculated based on the standard deviation and mean of the corresponding behavioral characteristic within the historical period of the equipment. A fluctuation coefficient threshold is set for the corresponding behavioral characteristic. If the fluctuation coefficient of the corresponding behavioral characteristic is less than the fluctuation coefficient threshold, the corresponding basic weight is increased by a certain percentage; if the fluctuation coefficient of the corresponding behavioral characteristic is greater than or equal to the fluctuation coefficient threshold, the corresponding basic weight is decreased by a certain percentage. T w R and w S After adjusting the basic weights, normalization is performed to ensure that w T +w R +w S =1.

5. The method for constructing the HarmonyOS IoT standard system according to claim 1, characterized in that, Data security standards introduce a dynamic permission decay pre-detection mechanism for access control. Specifically, in IoT systems, different initial data access permissions and initial permission points are pre-assigned based on the device's role and needs. A three-dimensional collaborative integral calculation mechanism is established to update permission points. In the formula, for Permission points are updated in real time; for Permission points at any given moment; The natural decay rate of the privilege points per unit time; This refers to the time difference between two permission point updates; for The number of equipment operations that occurred within the time limit. ； The basic attenuation of equipment operation per unit time; For the first Risk factor of secondary equipment operation; For the first The time required for each equipment operation; This is the amplification factor of the attenuation amount due to the current network state; The system matches the operation permission level corresponding to the initial permission score, updates the permission score based on the three-dimensional collaborative score calculation mechanism, and freezes device operation and forces identity verification when the permission score is lower than the preset minimum permission score.

6. The method for constructing the HarmonyOS IoT standard system according to claim 1, characterized in that, By analyzing the list of protocols supported by the devices, their attributes, and service requirements, a protocol matching strategy is dynamically generated, and a protocol mapping table is dynamically generated to optimize the communication process. Specifically, the following steps are taken: the list of protocols supported by both communicating devices is used as the basic candidate set, and the protocol priority is evaluated based on device attributes and service requirements. Preset matching rules are applied to select the protocol. Based on the adaptive configuration of the selected protocol pair or single protocol, a protocol mapping table is dynamically generated. The protocol mapping table defines core conversion rules, including parsing the differences in message structure between the source and target protocols and reconstructing and mapping fields, semantically converting operation instructions, adapting data formats according to data transmission rate and bandwidth requirements, matching service quality levels, and transmitting necessary security context information.

7. A system for constructing the HarmonyOS IoT standard system, characterized in that, include: The device model construction module is used to build a unified IoT model, including a device model and a data model. The device model defines a unified description method for various devices in the IoT, including device identifiers, attributes, services, and events. The data model establishes a unified data format and encoding rules for encapsulating and transmitting device data. The identifier is used to uniquely identify or locate the device, defined based on the device root identifier and the area binding code. The device root identifier consists of the device manufacturer's OUI and the device type code, and the area binding code is mapped from the area code of the base station currently connected to the device. The attributes describe the basic characteristics and status information of the device, including static and dynamic attributes. The static attributes are the device's own static information, and the dynamic attribute update process specifically involves predicting attribute values ​​for a future period based on historical data of the device's dynamic attributes. ； ； ;in, Indicates the time after the current moment Predicted values ​​of device dynamic attributes at any given time. ∈[10,30]， This represents the predicted horizontal value at time t. This represents the trend prediction value at time t. The horizontal smoothing coefficient. The actual value of the device's dynamic attributes at time t. The trend smoothing coefficient is used; a prediction data range is constructed based on the predicted values ​​of device dynamic attributes and the historical maximum deviation rate of historical data of device dynamic attributes; the actual values ​​of device dynamic attributes are collected. If the actual value of the device dynamic attribute falls within the prediction data range, the device will not upload the device dynamic attribute temporarily, but will only perform local data updates. If the actual value of the device dynamic attribute exceeds the prediction data range, it is marked as an outlier, and the outlier and prediction deviation are uploaded; the service is built based on the device rule base and is used to define the operations or functions provided by the device, and to control the device's operating status by calling the service; the event is used to describe specific situations or state changes that occur during the operation of the device. Based on the events that occur, the device autonomously sends event notifications to the IoT platform for corresponding processing; the HarmonyOS IoT standard setting module is used to set data security standards based on data encryption, identity authentication, and access control; the protocol matching module is used to dynamically generate protocol matching strategies by analyzing the list of protocols supported by the device, attributes, and service requirements, and dynamically generate a protocol mapping table to optimize the communication process.

8. An electronic device, the electronic device comprising: A memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, when the processor executes the computer program, it implements the method for constructing the HarmonyOS IoT standard system as described in any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the method for constructing the HarmonyOS IoT standard system as described in any one of claims 1 to 6.

Images