Pet device control board security access and remote control method based on internet of things

Abstract

This invention relates to the field of IoT access authentication technology, specifically to a secure access and remote control method for a pet device control board based on IoT. The method includes the following steps: after power-on, collecting startup, clock, credentials, and attachment time; converting the corresponding time consumption; generating timing features such as association number, credential summary, and access sequence number; determining the baseline range, verification number, credential, sequence number, and time consumption based on multiple power-on times for initial binding; forwarding based on time, type, and port status upon approval; and returning a collection or outputting a delayed retry flag upon rejection. In this invention, static credential verification is integrated with power-on physical timing constraints, ensuring that access is both based on identity authenticity and startup consistency. Historical time consumption boundaries are used to identify credential duplication, spoofing, and abnormal replays, reducing erroneous access due to credential comparison. After approval, the forwarding object is limited by command timing and port status, improving remote control security and execution accuracy, and reducing the risk of miscontrol and invalid retries.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) access authentication technology, and in particular to a method for secure access and remote control of pet device control boards based on the Internet of Things. Background Technology

[0002] The field of IoT access authentication technology involves computer security processing methods for establishing trusted connections between IoT terminals, device control boards, servers, and user terminals based on device identifiers, authentication credentials, and access permissions. Specifically, secure access and remote control of pet device control boards refers to the process where, after power-on, the pet device control board reads the device number, key, or certificate data from its local storage, sends an access request to the server via a communication interface, and after verifying the device identifier and binding relationship, the server establishes a control session and forwards control commands issued by the user terminal to the pet device control board for execution.

[0003] Current pet device control board access relies on static number and credential comparison. Physical timing differences such as voltage rise, chip clock, credential reading, and network attachment during device power-on are not included in the access judgment. In scenarios with multiple devices accessing in batches, historical startup fluctuations lack comparable boundaries. The server can only make discrete judgments based on the authenticity of the credential. Once an attacker obtains a copy of the number or credential, it is easy to complete the access by impersonating the control board. The remote control terminal has difficulty distinguishing between real devices and abnormal replays in a timely manner, which increases the risk of session establishment and the probability of mis-controlling pet devices or repeatedly refusing normal access. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies by proposing a secure access and remote control method for pet device control boards based on the Internet of Things.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a secure access and remote control method for a pet device control board based on the Internet of Things, comprising the following steps: S1. After the pet device control board is powered on, the time when the power supply voltage reaches the start threshold, the time when the main control chip clock stabilizes, the time when the memory outputs the authentication credential, and the time when the communication interface attaches to the network are collected. The clock stabilization time, credential reading time, and communication attachment time are recorded from adjacent times. S2. Read the device number, authentication credential summary and current access sequence number, and associate them with the clock stabilization time, the credential reading time and the communication attachment time to obtain power-on timing characteristic information. In the initial binding stage, determine the startup timing reference range based on the maximum and minimum values ​​of various times obtained from multiple power-ons of the same device number. S3. After receiving the power-on timing feature information, verify the device number, the authentication credential summary, the current access sequence number, and the time consumption of each item to determine the access admission result; S4. When the access admission result is passed, a control session is established, and the control command is determined and forwarded to the pet device control board based on the control command reception time, access pass time, control command type and execution port status; when the access admission result is rejected, return to S1 or output a delay retry flag.

[0006] Specifically, in S1, the threshold comparison state of the power supply detection terminal is detected, and the start threshold time is determined when the threshold comparison state switches from low voltage state to qualified state. Read the clock lock status output by the main control chip, the credential read status output by the memory interface, and the network attach status output by the communication interface. When the corresponding status meets the recording conditions, record the clock stabilization time, credential output time, and attach completion time respectively. Establish a power-on time record table according to the order of occurrence of the startup threshold time, the clock stabilization time, the credential output time, and the attachment completion time; The recording conditions include: when the clock lock state is valid for no less than three consecutive sampling periods, the sampling time of the first occurrence of the valid state is recorded as the clock stabilization time. When the credential reading status shows that the number of bytes read has reached the number of bytes for the authentication credential digest, and the memory interface does not return a read error flag, the reading end time is recorded as the credential output time. When the network attachment status shows that the communication interface has obtained a network address and received attachment confirmation information, the time of receiving the attachment confirmation information is recorded as the attachment completion time.

[0007] Specifically, the steps to obtain the clock stabilization time, credential reading time, and communication attach time include: Read adjacent time records from the power-on time record table, and determine the interval between the clock stabilization time and the power supply compliance time as the clock stabilization time. The interval between the credential output time and the clock stabilization time is determined as the credential reading time. The interval between the attachment completion time and the credential output time is determined as the communication attachment time.

[0008] Specifically, the process of generating power-on timing characteristic information includes: Read the device number, authentication credential summary, and access sequence number, and write the device number, authentication credential summary, and access sequence number into the same power-on record identifier; The clock stabilization time, credential reading time, and communication attachment time are associated with the device number, authentication credential summary, and current access sequence number, respectively, according to the same power-on record identifier. The associated record content is then encapsulated in a fixed field order of device, credential, access sequence number, and time to generate the power-on timing feature information.

[0009] Specifically, the process of generating the same power-on record identifier includes: After the power supply voltage reaches the start threshold time, the local start count value of the pet device control board is read, and the local start count value is compared with the current access sequence number for consistency. When the local startup count value and the current access sequence number meet the condition of incrementing, the device number and the local startup count value are concatenated and encoded to generate the same power-on record identifier; When the local startup count value and the current access sequence number do not meet the incrementing consistency condition, the encapsulation of the associated record content is stopped, and a sequence number exception flag is generated.

[0010] Specifically, S2 also includes reading the device number and the authentication credential digest from the memory of the pet device control board, and reading the access sequence number from the local access record of the pet device control board; When the device number, the authentication credential digest, and the current access sequence number are all read within the same power-on reading cycle, and the reading length of the device number is consistent with the set device number length, the reading length of the authentication credential digest is consistent with the set digest length, and the reading length of the current access sequence number is consistent with the set sequence number length, then the reading length condition is determined to be met. When the device number, the authentication credential digest, and the current access sequence number are all not empty or all default values, and the current access sequence number is not less than the previously recorded access sequence number, it is determined that the conditions for reading content are met. When both the read length condition and the read content condition are met, the device number, the authentication credential digest, and the current access sequence number are used as valid data to be associated; otherwise, a read error is output.

[0011] Specifically, the process for determining the access admission result includes: The system receives the power-on timing characteristic information and parses it according to the device, credential, access sequence number and time consumption order to obtain the device number, the authentication credential digest, the current access sequence number, the clock stabilization time, the credential reading time and the communication attachment time. The device number, the authentication credential digest, and the access sequence number are compared with the binding record, and the clock stabilization time, the credential reading time, and the communication attachment time are compared with the startup timing reference range. If the identity verification, credential verification, serial number verification, and time consumption verification all meet the access conditions, the access access result is recorded as passed; otherwise, the access access result is recorded as rejected.

[0012] Specifically, the process of comparing with the binding record is as follows: read the most recent access sequence number in the binding record, and record it as meeting the admission conditions when the current access sequence number is greater than the most recent access sequence number and the difference does not exceed the set sequence number jump threshold; otherwise, it is not met. The process of comparing with the startup timing reference range specifically involves: obtaining the startup timing reference range corresponding to the device number, and reading the lower limit boundary of clock stabilization time, the upper limit boundary of clock stabilization time, the lower limit boundary of credential reading time, the upper limit boundary of credential reading time, the lower limit boundary of communication attachment time, and the upper limit boundary of communication attachment time from the startup timing reference range; when the clock stabilization time, the credential reading time, and the communication attachment time fall between the corresponding lower limit boundary and the corresponding upper limit boundary, it is recorded as meeting the admission conditions; otherwise, it is not met.

[0013] Specifically, in S4, when the access admission result is passed, the admission pass time, device number and session validity duration are read, and the admission pass time and session validity duration are associated and written into the session status table. The control command reception time, control command type and execution port status are obtained, and the control command is forwarded to the pet device control board when the forwarding conditions are met. When the access admission result is rejected, the temporary session record corresponding to the device number in the session status table is cleared, and the rejection reason identifier is written into the access failure record. Read the number of consecutive rejections corresponding to the device number. If the number of rejections does not reach the threshold, return to S1. Allow the pet device control board to re-collect the time when the power supply voltage reaches the start threshold, the time when the main control chip clock stabilizes, the time when the memory outputs the authentication credentials, and the time when the communication interface completes network attachment. When the number of consecutive rejections reaches the rejection count threshold, a delayed retry flag is output.

[0014] Specifically, the forwarding conditions are as follows: When the control command is received later than the access pass time but does not exceed the session validity period, the session validity condition is determined to be met. Read the allowed port status corresponding to the control instruction type. When the execution port status matches the allowed port status, it is determined that the port matching condition is met. When both the session expiration condition and the port matching condition are met, the forwarding condition is determined to be satisfied.

[0015] Compared with the prior art, the advantages and positive effects of the present invention are as follows: By collecting data on the power-on phase, such as the time it takes for the power supply voltage to reach the start threshold, the main control chip clock to stabilize, the memory to output authentication credentials, and the communication interface to attach to the network, and converting adjacent records into correlation features such as clock stabilization time, credential reading time, communication attachment time, device number, credential summary, and access sequence number, the access decision is constrained by both credential credibility and start-up timing consistency. In the initial binding phase, the time boundary of multiple power-on cycles of the same device forms a benchmark range. Subsequent access can identify credential duplication, timing anomalies, and replay access. After access is granted, the forwarding target is determined based on the instruction arrival time, access time, instruction type, and port status, reducing the risks of spoofing, miscontrol, and invalid retries. Attached Figure Description

[0016] Figure 1 This is the main flowchart of the secure access and remote control of the pet equipment control board of the present invention; Figure 2 This is a schematic diagram showing the power-on timing data acquisition effect on the pet device control board of the present invention; Figure 3 This is a schematic diagram illustrating the effect of the encapsulation of power-on timing feature information and the startup timing reference range in this invention; Figure 4 This is a schematic diagram illustrating the cloud access admission verification effect of the present invention; Figure 5 This is a schematic diagram illustrating the effect of establishing a control session and forwarding control commands according to the present invention. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Example

[0018] Please see Figures 1 to 5This embodiment provides a secure access and remote control method for pet device control boards based on the Internet of Things (IoT). In practical applications, such as when pet feeders, water dispensers, litter boxes, or pet interactive devices are connected to a home router, cellular network gateway, or IoT access network, the control board first completes local startup status collection after power-on, and then submits the device identity, credential summary, access sequence number, and startup phase timing record to the cloud access service. The cloud access service performs access judgment based on the binding record, sequence number status, and startup timing reference range. After access is granted, control commands such as feeding, watering, cleaning, lighting, fan control, or locking issued by the user terminal undergo session verification and port status verification. After successful verification, the commands are then sent to the pet device control board, including the following steps: S1: After the pet device control board is powered on, the time it takes for the power supply voltage to reach the start-up threshold, the time it takes for the main control chip clock to stabilize, the time it takes for the memory to output authentication credentials, and the time it takes for the communication interface to attach to the network are collected. The clock stabilization time, credential reading time, and communication attachment time are recorded from adjacent times.

[0019] The pet device control board includes a power supply detection terminal, a main control chip, a memory interface, and a communication interface. The power supply detection terminal outputs a threshold comparison status, the main control chip outputs a clock lock status, the memory interface outputs a credential read status, and the communication interface outputs a network attach status. The startup threshold time is a startup baseline record written when the power supply detection terminal switches from a low-voltage state to a qualified state. The clock stabilization time is a startup phase record written after the main control chip's clock lock status is confirmed. The credential output time is a credential phase record written after the memory interface completes the authentication credential digest read. The attach completion time is a network phase record written after the communication interface obtains the network address and receives the attach confirmation information.

[0020] The control board maintains a power-on time record table locally. This table is written with the record type, status source interface, status confirmation result, exception flag, and time record category for each power-on cycle. This record table only accepts data generated in the current power-on cycle and does not accept data left over from the previous access process. Only after all power supply compliance records, clock stability records, credential output records, and attachment completion records are written will the process of generating the next record's time consumption begin. If any record is missing, duplicated, out of order, or has a mismatched source interface, the record table generates a corresponding exception flag, and subsequent encapsulation processes stop reading that exception record.

[0021] S101: Detects the threshold comparison status of the power supply detection terminal. When the threshold comparison status switches from low voltage state to qualified state, it is determined as the start threshold time.

[0022] The threshold comparison status of the power supply detection terminal comes from the comparison output of the power input side of the control board. A low voltage state indicates that the input power supply has not yet entered the startup boundary registered in the startup rule table, while a qualified state indicates that the input power supply has entered the operating boundary allowed by the control board. The startup rule table is stored in the local configuration area of ​​the control board and includes the power supply detection terminal identifier, threshold status field, status transition confirmation field, and record write permission field. The status transition confirmation field only confirms the unidirectional change from low voltage state to qualified state, and does not consider power failure, jitter, or interface unresponsiveness as startup threshold times.

[0023] After the power supply detection terminal outputs a qualified status, the control board reads the previous status record. If the previous status was low voltage and the current status is qualified, the control board writes the time record category corresponding to this status switch into the power supply qualified record position in the power-on time record table. If the collected status repeatedly changes between low voltage and qualified status, the control board writes this record to the power supply pending confirmation buffer and does not output a formal start record to the subsequent clock stabilization stage. After the power supply qualified record position is successfully written, this position serves as the starting source of the clock stabilization time and also as the starting source of the same power-on record identifier generation process.

[0024] S102: Read the clock lock status output by the main control chip, and record the clock stabilization time when the clock lock status meets the recording conditions.

[0025] The clock lock status is output by the clock management terminal of the main control chip, reflecting whether the internal operating clock of the main control chip has entered a locked state. Before reading the clock lock status, the control board first checks whether there is a power supply compliance record in the power-on time record table. If there is no power supply compliance record, the clock lock status is written to the startup exception cache and does not participate in the formation of the formal time consumption field. If there is a power supply compliance record, the clock lock status is confirmed in the clock stability rule table. The clock stability rule table includes a clock source identifier, a lock status validity flag, a continuous validity status confirmation field, a sampling exception exclusion field, and a recording time selection field.

[0026] Once the clock lock state meets the stability rules, the control board writes the time record category corresponding to the first valid state entering the stability confirmation sequence into the clock stability record position of the power-on time record table. If an invalid state, interface return exception, state record inversion, or sampling source conflict occurs during the clock lock state confirmation process, the control board generates a clock lock exception flag and writes the exception flag into the status appendix field of the power-on time record table. After the clock stability record position is successfully written, this record position serves as the end source of clock stability time consumption and the starting source of credential reading time consumption.

[0027] S103: Read the credential reading status output by the memory interface. When the credential reading status meets the recording conditions, record the credential output time.

[0028] The memory interface reads the device number, authentication credential digest, and local access record from the control board's secure storage area. The authentication credential digest is a fixed identity verification field formed after the authentication credential has been digested. This field is used during the access admission phase to compare with the credential digest field in the cloud-bound record and does not directly carry plaintext credentials. Credential reading status includes reading progress, reading completion indicator, and reading error flag. Credential field rules are stored in the control board's secure storage area, including digest field boundaries, reading termination conditions, reading error flag meanings, and field validity check rules.

[0029] Before the control board reads the credential read status, it first checks whether the clock stabilization record position has been written. If the clock stabilization record position does not exist, the data returned by the memory interface is written to the credential pending confirmation buffer, and no credential output time is generated. If the clock stabilization record position exists, the read completion flag and read error flag are entered into the credential read rule table. When the read progress covers the authentication credential summary field and no read error flag appears, the control board writes the time record category corresponding to the read completion to the credential output record position. If the read progress does not cover the authentication credential summary field, an incomplete credential flag is generated. If the memory interface returns a read error flag, a credential read exception flag is generated. After the credential output record position is successfully written, this record position serves as the end source of credential read time and the start source of communication attach time.

[0030] S104: Read the network attachment status output by the communication interface, and record the attachment completion time when the network attachment status meets the recording conditions.

[0031] The communication interface connects to a home IoT network, Bluetooth gateway, Wi-Fi gateway, or cellular gateway, and outputs the network attach status to the control board. The network attach status includes address acquisition status, attach confirmation message reception status, interface error status, and reconnection status. The attach confirmation message is a network attach confirmation message returned by the access network or cloud access service, indicating that the control board has the communication conditions to initiate a secure access request.

[0032] Before reading the network attach status, the control board first checks whether the credential output record position has been written. If the credential output record position does not exist, the network attach status is written to the communication pending confirmation buffer, and no attach completion time is generated. If the credential output record position exists, the communication interface submits the address acquisition status, attach confirmation information reception status, and interface error status to the communication attach rule table. The communication attach rule table includes an interface type field, an address acquisition field, an attach confirmation field, an error flag field, and a retry flow field. When both the address acquisition status and the attach confirmation information reception status meet the rule table conditions and the interface error status does not indicate failure, the control board writes the attachment confirmation information reception time record category to the attach completion record position. When the address is not acquired, the attach confirmation is missing, or the interface returns a failure, the control board generates a corresponding communication exception flag and writes it to the power-on time record table.

[0033] S105: Establish a power-on time record table according to the order of occurrence of the start-up threshold time, clock stabilization time, credential output time, and attachment completion time, and read adjacent time records in the power-on time record table to form clock stabilization time, credential reading time, and communication attachment time.

[0034] The power-on time log is organized according to the sequence of the power supply attainment record, clock stabilization record, credential output record, and attachment completion record. Adjacent time records are valid records formed by adjacent stages within the same power-on cycle. The clock stabilization time field is formed by the power supply attainment record and the clock stabilization record, indicating the time taken for the main control chip to enter a clock stabilization state after the control board power supply reaches the startup boundary. The credential reading time field is formed by the clock stabilization record and the credential output record, indicating the time taken for the memory interface to complete the authentication credential digest reading after the main control chip clock stabilizes. The communication attachment time field is formed by the credential output record and the attachment completion record, indicating the time taken for the communication interface to complete network attachment after credential output.

[0035] Before generating the time consumption field, the control board performs integrity, source, and sequence checks on adjacent records. A missing record is marked with a stage missing flag. A duplicate record is marked with a stage duplicate flag. A record order that does not conform to the power-on link is marked with an order exception flag. A record source interface that is inconsistent with the stage type is marked with a source conflict flag. If any exception flag exists, the control board does not generate complete power-on timing characteristic information; it only retains the abnormal power-on record for subsequent re-acquisition or delayed retry judgment. After passing the checks, the three time consumption fields are written to the time consumption record area and used as input for the identity field association encapsulation in S2.

[0036] S2: Read the device number, authentication credential summary and access sequence number, associate them with clock stabilization time, credential reading time and communication attachment time to obtain power-on timing characteristic information, and determine the startup timing reference range based on the time boundaries of various items obtained from multiple power-ons of the same device number during the initial binding phase.

[0037] The device number is a device identity field written at the factory or during binding initialization of the control board. The cloud access service uses this field to retrieve binding records. The authentication credential digest is a credential digest field output from the memory. The cloud access service uses this field to verify the consistency of credentials between the control board and the binding record. The access sequence number is the access order field in the control board's local access record, used to identify sequence number rollback, reuse, and abnormal jumps. The power-on timing characteristic information is an access characteristic data object submitted by the control board to the cloud access service, including the device number, authentication credential digest, access sequence number, clock stabilization time, credential reading time, communication attach time, and the same power-on record identifier.

[0038] The startup timing baseline range is established by the cloud access service for the same device number during the initial binding phase. This range stores the lower and upper boundary fields corresponding to each time consumption field. The boundaries are derived from power-on records of the same device number that have passed identity and credential checks during the initial binding phase. Power-on records that fail identity checks, credential checks, serial number checks, or record integrity checks are only entered into the abnormal record area and are not included in the startup timing baseline range.

[0039] S201: Read the device number and authentication credential summary from the memory of the pet device control board, and read the access sequence number from the local access record of the pet device control board.

[0040] After completing the credential output recording, the control board reads the device number field and authentication credential digest field from the secure storage area, and then reads the current access sequence number field from the local access record area. The local access record area stores the most recently recorded access sequence number, the current startup count value, the anomaly flag, and the pending reporting status. The read device number, authentication credential digest, and current access sequence number are checked in the same power-on reading cycle. The reading cycle identifier comes from the local startup record generated after power supply meets the requirements, and is used to confirm that the three fields belong to the same power-on process.

[0041] If any field fails to be read, the control panel generates a read error flag and writes it to the local access record area. If a field is read successfully but the source period is inconsistent, the control panel generates a read period inconsistency flag. If a field is read successfully and the source period is consistent, all three fields undergo read length and read content condition checks. During this stage, fields are not directly sent to the cloud access service; only fields that pass both length and content checks are written to the set of valid data to be associated.

[0042] S202: When the device number, authentication credential digest, and access sequence number are all read within the same power-on reading cycle, and the reading length of the device number is consistent with the set device number length, the reading length of the authentication credential digest is consistent with the set digest length, and the reading length of the access sequence number is consistent with the set sequence number length, then the reading length condition is determined to be met.

[0043] The read length condition is used to verify the integrity of the identity field structure. The device number length, digest length, and sequence number length are set from the field rule record in the control board's secure storage area. The field rule record is written by factory configuration or initial binding configuration and includes field boundaries, field types, default padding flags, and valid field read rules. The read length condition is based on the field boundaries actually returned by the memory interface, and does not rely on self-declared field lengths in the communication message.

[0044] The control board performs length checks in the order of device number, authentication credential digest, and current access sequence number. If the device number length is inconsistent, a device number length exception flag is written. If the authentication credential digest length is inconsistent, a credential digest length exception flag is written. If the current access sequence number is inconsistent, a sequence number length exception flag is written. If any length exception exists, the field is not included in the valid data set, and the exception flag is written to the local access record area. When the read length of all three fields matches the field rule record, the read length condition is met, and the field enters the read content condition check.

[0045] S203: When the device number, authentication credential digest, and current access sequence number are not empty or all default values, and the current access sequence number is not less than the previously recorded access sequence number, the read content condition is determined to be met; when both the read length condition and the read content condition are met, the device number, authentication credential digest, and current access sequence number are used as valid data to be associated; otherwise, a read error is output.

[0046] The read content conditions are used to exclude empty fields, default-filled fields, and sequence number rollback fields. An empty value indicates that the storage interface did not return valid field content. Full default values ​​indicate that the field content matches the default fill identifier in the field rule record. The previously recorded access sequence number comes from the most recent valid access record in the local access record area. The control board first checks whether the device number and authentication credential summary are empty or full default values, and then checks the order relationship between the current access sequence number and the previously recorded access sequence number. If the order relationship does not meet the local sequence number rules, the control board marks the field as sequence number rollback or sequence number reuse.

[0047] If the read content conditions are not met, the control board outputs a read exception. Read exceptions include flags indicating an empty device number, a default device number flag, an empty credential digest flag, a default credential digest flag, an empty sequence number flag, a default sequence number flag, and a sequence number rollback flag. The read exception is written to the local access record area and enters the retry processing path after S4 rejection. If both the read length and read content conditions are met, the device number, authentication credential digest, and current access sequence number are written to the valid data set to be associated. The valid data set stores the field content, field source, read cycle identifier, and field verification status, and is output to the same power-on record identifier generation process.

[0048] S204: After the power supply voltage reaches the start-up threshold time, read the local start-up count value of the pet device control board and compare the local start-up count value with the current access sequence number; when the local start-up count value and the current access sequence number meet the incrementing consistency condition, concatenate the device number with the local start-up count value to generate the same power-on record identifier; when the local start-up count value and the current access sequence number do not meet the incrementing consistency condition, stop encapsulating the associated record content and generate a sequence number abnormality mark.

[0049] The local startup count value is written to the startup sequence field in the local access record area by the control board after the power supply meets the requirements. The access sequence number is the access sequence field used when the access request was submitted. The increment consistency condition comes from the local sequence number rule table, which includes a startup sequence field, an access sequence field, a previously valid sequence number field, and an abnormal transition flag field. This rule table is used to determine whether the local startup sequence and the access request sequence maintain the same progression direction.

[0050] When the incremental consistency condition is met, the control board concatenates and encodes the device number and local startup count value to generate a single power-on record identifier. This identifier is used to group the device number, authentication credential summary, access sequence number, and three time-consuming fields within the same power-on cycle into the same encapsulated record. When the incremental consistency condition is not met, the control board stops encapsulating the associated record content, generates a sequence number anomaly flag, and writes it to the local access record area. Records with sequence number anomaly flags are not sent as formal power-on timing characteristic information; they only enter the abnormal access status feedback path.

[0051] S205: Read the device number, authentication credential summary, and current access sequence number, and write the device number, authentication credential summary, and current access sequence number into the same power-on record identifier; associate the clock stabilization time, credential reading time, and communication attach time with the device number, authentication credential summary, and current access sequence number respectively according to the same power-on record identifier, and encapsulate the associated record content according to the fixed field order of device, credential, access sequence number, and time consumption to generate power-on timing feature information.

[0052] After the same power-on record identifier is written into the valid data set, the device number, authentication credential summary, and access sequence number belong to the same power-on cycle. The control board then reads the clock stabilization time, credential reading time, and communication attach time from the time consumption record area, and checks whether the record identifiers of these time consumption fields are consistent with the record identifiers in the valid data set. If the record identifiers are consistent, the control board writes the identity field and the time consumption field into the same encapsulated record. If the record identifiers are inconsistent, the control board generates a record ownership anomaly flag and stops generating power-on timing characteristic information.

[0053] The encapsulated record uses a fixed field order. The device field carries the device number, the credential field carries the authentication credential summary, the access sequence number field carries the access sequence number for this access, and the time consumption field carries the clock stabilization time, credential reading time, and communication attach time. The fixed field order is stored in the protocol configuration table, and the control board communication interface and the cloud access service parse the fields according to the same protocol configuration table. After the power-on timing characteristic information is generated, it is sent to the access verification entry of the cloud access service by the communication interface. The local access record area synchronously saves the sending status, field verification status, and anomaly marking status, which can be used to trace the source of this access data later by using the device number and the same power-on record identifier.

[0054] S206: During the initial binding phase, the startup timing reference range is determined based on the maximum and minimum time values ​​of each item obtained from multiple power-ups of the same device number.

[0055] The initial binding phase is the initial access phase where the control board establishes a binding relationship with the user account and cloud access service. During this phase, the cloud access service receives power-on timing characteristic information reported by the same device ID and writes records that have passed device ID verification and authentication credential digest verification into the timing baseline candidate area. The timing baseline candidate area stores the device ID, credential digest status, access sequence number status, clock stability time boundary candidates, credential read time boundary candidates, and communication attach time boundary candidates. Power-on records with abnormal fields, abnormal sequence numbers, or abnormal record attribution are written to the abnormal record area and do not enter the timing baseline candidate area.

[0056] The cloud access service reads the candidate time consumption boundaries corresponding to the same device number from the timing benchmark candidate area and writes them into the startup timing benchmark range. The startup timing benchmark range includes the lower boundary of clock stability time consumption, the upper boundary of clock stability time consumption, the lower boundary of credential read time consumption, the upper boundary of credential read time consumption, the lower boundary of communication attach time consumption, and the upper boundary of communication attach time consumption. The engineering source of each boundary field is the valid power-on record of the same device number during the initial binding phase, the device rule table, and the communication interface status rule table. After the startup timing benchmark range is written to the binding record, subsequent access verification locates this range by device number and calls it item by item according to the time consumption field.

[0057] S3: After receiving the power-on timing feature information, verify the device number, authentication credential summary, access sequence number, and time consumption of each item to determine the access admission result.

[0058] After receiving the power-on timing characteristic information, the access verification entry point of the cloud access service first parses the fields according to the protocol configuration table, and then retrieves the binding record by device number. The binding record stores the device number, authentication credential summary, most recent access sequence number, startup timing reference range, session state index, and access failure record index. The access admission result is a status record output by the cloud access service, with statuses including pass and reject. A pass status enters the S4 control session establishment process, while a reject status enters the access failure record and retry control process.

[0059] S301: Receive power-on timing characteristic information, and parse it according to the device, credential, access sequence number and time consumption order to obtain the device number, authentication credential summary, current access sequence number, clock stabilization time, credential reading time and communication attachment time.

[0060] The access verification entry reads the device field, credential field, access sequence number field, and time consumption field from the protocol configuration table, and parses the power-on timing characteristic information in a fixed order. The parsing result object stores the device number, authentication credential summary, current access sequence number, clock stabilization time, credential reading time, communication attach time, same power-on record identifier, and parsing status identifier. The parsing status identifier includes whether the field is complete, missing, misaligned, or unrecognizable.

[0061] When a field is missing, misaligned, or unrecognizable, a parsing error flag is written to the access verification entry point, and the access admission result is recorded as rejected. When the field is complete, the parsing result object is retrieved from the binding record. If the device number matches a binding record, the cloud access service reads the credential summary field, the most recent access sequence number field, and the startup timing baseline range from the binding record. If the device number does not match a binding record, the access admission result is recorded as rejected, and the rejection reason flag is written to the access failure record.

[0062] S302: Compare the device number, authentication credential summary, and access sequence number with the binding record, and compare the clock stabilization time, credential reading time, and communication attachment time with the startup timing reference range.

[0063] Device ID comparison confirms that the parsed device ID matches the binding record. Authentication credential digest comparison confirms that the credential digest submitted by the control panel matches the credential digest field in the binding record. Access sequence number comparison confirms that the access order is later than the most recent access sequence number in the binding record, and that the sequence number jump status does not exceed the allowed boundaries registered in the sequence number rule table. The sequence number rule table is maintained by the cloud access service in the binding record and includes the most recent access sequence number field, the allowed jump boundary field, the fallback identification field, and the reuse identification field.

[0064] The time consumption comparison reads the startup timing reference range through the device number. The cloud access service reads the lower boundary of clock stability time consumption, the upper boundary of clock stability time consumption, the lower boundary of credential read time consumption, the upper boundary of credential read time consumption, the lower boundary of communication attachment time consumption, and the upper boundary of communication attachment time consumption, respectively. Before comparing clock stability time consumption, credential read time consumption, and communication attachment time consumption, it checks whether these fields have the same power-on record identifier and whether the fields have anomaly markers reported by the control board. When the record identifiers are consistent and there are no anomaly markers, each time consumption field is compared with its corresponding boundary field. When a time consumption field falls within the admission range covered by the corresponding boundary rule, it is recorded as meeting the time consumption admission condition. When any time consumption field does not meet the boundary rule, it is recorded as a timing anomaly.

[0065] S303: If the identity verification, credential verification, serial number verification, and time consumption verification all meet the access conditions, record the access access result as passed; otherwise, record the access access result as rejected.

[0066] The cloud access service writes the verification status in the following order: identity comparison, credential comparison, sequence number comparison, and time consumption comparison. If the identity comparison fails, the access rejection result is set to "Reject," and a device not bound or device inconsistent flag is written. If the credential comparison fails, the access rejection result is set to "Reject," and a credential mismatch flag is written. If the sequence number comparison fails, the access rejection result is set to "Reject," and a sequence number anomaly flag is written. If the time consumption comparison fails, the access rejection result is set to "Reject," and a timing anomaly flag is written. If a rejection result has already been generated in a previous step, the subsequent step will not change the rejection status but will only supplement the already parsed anomaly source.

[0067] When all verification states meet the admission criteria, the access admission result is written to the "Pass" status. The "Pass" status updates the most recent access sequence number field in the binding record and writes the "Access Pass Time" field. The most recent access sequence number field serves as the benchmark for the next access sequence number comparison, and the "Access Pass Time" field serves as the starting field for the S4 control session. The "Reject" status is written to the access failure record. The access failure record saves the device number, same power-on record identifier, parsing status identifier, rejection reason identifier, cumulative consecutive rejection status, and retry control status. The access failure record is stored in the audit storage area of ​​the cloud access service and can be traced later by device number, access sequence number, or rejection reason.

[0068] S4: When the access admission result is passed, establish a control session and determine the control command based on the control command reception time, access pass time, control command type and execution port status, and forward it to the pet device control board; when the access admission result is rejected, return to S1 or output a delayed retry flag.

[0069] The control session is a temporary control status record created by the cloud access service for the device ID after access is granted. The session status table stores the device ID, access grant time, session duration, current session status, most recent control command type, most recently executed port status, and forwarding result identifier. The control command reception time comes from the record category written by the cloud access service when it receives the user terminal's control message. The control command type comes from the action field in the control message. The execution port status comes from the port status field fed back by the pet device control board within the session. The delayed retry flag is the retry control status output after the cumulative rejection status hits the rejection control rule.

[0070] S401: When the access admission result is passed, read the admission pass time, device number and session validity duration, and write the admission pass time and session validity duration into the session status table. Obtain the control command reception time, control command type and execution port status. When the forwarding conditions are met, forward the control command to the pet device control board.

[0071] The cloud access service reads the access approval time from the binding record, the device number from the parsed result object, and the session validity duration field from the session rule table. The session rule table, maintained by the cloud access service, includes device type, session status, validity duration fields, command reception rules, and session closure rules. Before writing to the session status table, the cloud access service first checks if there is an unclosed temporary session record for the same device number. If an unclosed record exists, the old record is written to the replaced status, and the new record is written to the control command reception status. If no unclosed record exists, a new session record is created directly.

[0072] After the session state table is successfully written, the cloud access service begins receiving control messages from user terminals. Upon receiving a control message, the cloud access service reads the control command reception time, control command type, and execution port status. The execution port status is reported by the control board, and includes port availability, port occupation, port lock, port failure, and port unacknowledged. The port status rule table stores the correspondence between control command types and allowed port statuses, including control command type, allowed port status, prohibited port status, port unacknowledged processing flag, and forwarding status output flag. If the session state table write fails, the control command entry remains closed, and an exception flag is written to the session table.

[0073] S402: The forwarding conditions are as follows: when the control command reception time is later than the admission time but does not exceed the session validity period, the session validity period condition is determined to be met; the allowed port status corresponding to the control command type is read, and when the execution port status matches the allowed port status, the port matching condition is determined to be met; when both the session validity period condition and the port matching condition are met, the forwarding condition is determined to be met.

[0074] The session validity period is determined by the control command reception time, access approval time, and session validity duration fields. When the control command reception time falls within the valid boundaries registered in the session status table, the cloud access service writes a session validity period approval status. When the control command reception time is outside the valid boundaries, a session failure flag is written, and control commands are refused to be issued. The session failure flag is simultaneously written to both the session status table and the control command log.

[0075] Port matching conditions are determined by both the control command type and the execution port status. The cloud access service reads the allowed port status from the port status rule table based on the control command type. When the execution port status matches an allowed port status, a port matching pass status is written. When the execution port status matches a prohibited port status, a port mismatch flag is written. When the execution port status is unacknowledged, the system enters a waiting for acknowledgment or rejection forwarding path according to the unacknowledged port status. When both the session validity period and port matching conditions are met, the cloud access service writes the control command into the forwarding queue and sends it to the pet device control board through the communication interface. After receiving the command, the control board returns a reception acknowledgment, and the cloud access service writes the forwarding result flag into the session status table. If no reception acknowledgment is received, the forwarding result flag is written into the command unacknowledged status, and the control message flag is retained for later tracing.

[0076] S403: When the access admission result is rejected, clear the temporary session record corresponding to the device number in the session status table and write the rejection reason identifier into the access failure record.

[0077] When the access access service results in a rejection, it searches the session status table based on the device ID. If a temporary session record is found, it is written to the closed state, and the control command forwarding entry stops receiving control commands corresponding to that device ID. If no temporary session record is found, the session clearing completion state is written. Rejection reason identifiers come from parsing errors, device inconsistencies, credential mismatches, sequence number errors, timing errors, read errors, and record attribution errors. The rejection reason identifier, along with the device ID, the same power-on record identifier, and the parsing status identifier, is written to the access failure record.

[0078] S404: Read the number of consecutive rejections corresponding to the device number. If the number of rejections does not reach the threshold, return to S1. Allow the pet device control board to re-collect the time when the power supply voltage reaches the start threshold, the time when the main control chip clock stabilizes, the time when the memory outputs the authentication credentials, and the time when the communication interface completes network attachment. When the number of consecutive rejections reaches the threshold, output a delay retry flag.

[0079] The consecutive rejection count is the cumulative data of consecutive rejections maintained for the same device number in the access failure records. The rejection count threshold is obtained and maintained by the cloud access service, including the allowed re-collection status, delayed retry status, rejection reason retention policy, and local prompt status. When the consecutive rejection count does not reach the rejection count threshold, the cloud access service returns a re-collection status to the control board and returns S1 to re-collect relevant time records for power supply compliance, clock stability, credential output, and network attachment.

[0080] When the number of consecutive rejections reaches the rejection threshold, the cloud access service outputs a delayed retry flag. The delayed retry flag is written to the access failure record and returned to the control board communication interface.

[0081] The following is a complete process from powering on the pet device control board to cloud access access, control session establishment, and control command forwarding.

[0082] For example, the pet device is a WiFi pet feeder. The pet device control board uses a 5V DC input power supply, and the onboard power management circuit provides 3.3V operating power to the main control chip, memory, and WiFi communication interface respectively. The power supply detection threshold is set to 4.55V. When the input voltage is lower than 4.55V, it is recorded as a low voltage state; when the input voltage reaches or exceeds 4.55V and the continuous sampling status remains consistent, it is recorded as a qualified state. The main control chip is a low-power IoT control chip, and the memory is a secure storage chip. The secure storage area stores the device number, authentication credential digest, and local access record. The device number field is 16 bytes long, the authentication credential digest field is 32 bytes long, and the access sequence number field is 4 bytes long.

[0083] The device number is stored as a 16-byte binary field, for example, 50 45 54 2D 44 45 56 2D 30 30 30 30 30 31 41 31. The authentication credential digest is a 32-byte digest field, output by the secure storage chip. The access sequence number is a 4-byte incrementing field, which is synchronously maintained by the cloud access service and the control board's local access records after the initial successful binding. The control board establishes a power-on time record table after power-on. Each record includes a device number field, a record stage field, an interface source field, a status flag field, and a timestamp field. Each timestamp is recorded by a millisecond-level system timer that starts after power supply meets the requirements. Power supply compliance records, clock stability records, credential output records, and attachment completion records use the same timing source.

[0084] In step S1, after the control board powers on, the power supply detection terminal detects that the input voltage has switched from a low voltage state to a qualified state. Once the input voltage reaches 4.55V and remains stable, this moment is recorded as the start-up threshold time. The pet feeder may experience short-term voltage fluctuations when the motor starts, the electromagnetic lock releases, or the power adapter output fluctuates. The control board does not use a single comparison result as the start-up threshold time; instead, it uses the first qualified sampling point after continuous stabilization as the start-up threshold time. Power supply status fluctuations are written into the power supply anomaly cache and no longer participate in the formation of the clock stabilization time.

[0085] Subsequently, the main control chip switches from an internal RC clock to an external crystal oscillator or phase-locked loop (PLL) stabilized clock and outputs a clock lock status. Statistics from the startup records of multiple pet feeder control boards show that the clock stabilization time after power supply compliance mainly ranges from 80ms to 420ms. Records below 80ms typically indicate a false triggering of the clock lock status or premature writing of the startup record; records above 420ms typically indicate abnormal crystal oscillation, low-temperature startup delay, or main control chip reset and re-entry. In this example, the clock stabilization time recorded by the control board is 186ms.

[0086] After the main control chip clock stabilizes, the memory interface reads the device number, authentication credential digest, and access sequence number. The device number is a 16-byte field, the authentication credential digest is a 32-byte field, and the access sequence number is a 4-byte field. The credential reading phase takes between 15ms and 120ms. If the credential reading time is less than 15ms, the control board checks whether the reading progress only overwrites the cached copy; if the credential reading time is greater than 120ms, the control board checks the memory busy state, interface retry state, or security storage chip wake-up state. In this example, the control board recorded a credential reading time of 42ms.

[0087] After the credentials are read, the WiFi communication interface performs wireless scanning, association authentication, address acquisition, and cloud attachment confirmation. When the router signal is normal and the device has saved historical access information, the communication attachment time is generally 1200ms to 8500ms; when the router restarts, the signal is weak, or the communication link switches, the communication attachment time can be extended to 12000ms. In this example, the control board connects to the home router and receives cloud attachment confirmation, and the communication attachment time is 3560ms.

[0088] In step S1, the time consumed by adjacent stages is obtained according to equation (1): ;-----Equation (1) In the formula, Clock stabilization time indicates the time it takes for the main control chip's clock to stabilize after the power supply meets the standard; The credential read time represents the time it takes for the memory to complete the reading of the authentication credential digest after the clock stabilizes; Communication attach time represents the time taken for the communication interface to complete network attach after the credentials are read; The threshold time for activation; This is the clock settling time; For the time when the credentials were output; This refers to the attachment completion time. Here, It takes 186ms. It takes 42ms. It takes 3560ms.

[0089] In step S2, the control board reads the device number, authentication credential digest, and access sequence number, and associates these fields with clock stabilization time, credential reading time, and communication attachment time. An actual encapsulated record of the power-on timing characteristic information includes a 16-byte device number, a 32-byte authentication credential digest, a 4-byte access sequence number, a 4-byte clock stabilization time field, a 4-byte credential reading time field, a 4-byte communication attachment time field, and a record identifier field. These fields are arranged in a fixed order according to the protocol configuration table. The cloud access service does not rely on field name strings during parsing; instead, it reads the data according to the fixed field positions.

[0090] During the initial binding phase, at least six valid power-on records must be collected for the same device ID. The cloud access service saves the clock stabilization time, credential reading time, and communication attachment time for each power-on. Taking the WiFi pet feeder prototype in this example, in the valid records during the initial binding phase, the clock stabilization time falls between 80ms and 420ms, the credential reading time falls between 15ms and 120ms, and the communication attachment time falls between 1200ms and 8500ms. If there is a router restart, memory read error, or power supply jitter flag during the binding phase, the power-on record is written to the abnormal record area and is not included in the generation of the startup timing reference range.

[0091] The startup timing reference range is obtained from equation (2): ;-----Equation (2) In the formula, For the first The startup timing reference range of the time-consuming field corresponds to the clock stabilization time, credential reading time, and communication attachment time, respectively. This is a record of the effective time spent for the same device number during the initial binding phase; The minimum value among the valid time records; the maximum value among the valid time records; This is an engineering margin field used to cover normal deviations caused by changes in temperature, power ripple, and network access status of the same model of control board.

[0092] The engineering margin field for clock stabilization time is set to 20ms, the engineering margin field for credential read time is set to 10ms, and the engineering margin field for communication attach time is set to 800ms. The valid range for clock stabilization time is 80ms to 420ms, and the clock stabilization admission range after adding the engineering margin is 60ms to 440ms; the valid range for credential read time is 15ms to 120ms, and the credential read admission range after adding the engineering margin is 5ms to 130ms; the valid range for communication attach time is 1200ms to 8500ms, and the communication attach admission range after adding the engineering margin is 400ms to 9300ms. The above startup timing reference ranges are written into the binding record corresponding to the device number.

[0093] In step S3, after receiving the power-on timing feature information, the cloud access service parses it according to a fixed field order. The device number field is read in a fixed 16-byte order, the authentication credential digest field in a fixed 32-byte order, the access sequence number field in a fixed 4-byte order, and each time-consuming field in a fixed 4-byte order. If the length of the received message is less than the sum of the fixed field lengths, the parsing status identifier write field is missing; if the field order is inconsistent with the protocol configuration table, the parsing status identifier write field is misaligned; if the time-consuming field cannot be converted to a non-negative integer millisecond value, the parsing status identifier write field is unrecognizable.

[0094] The cloud access service retrieves binding records by device ID. Multiple pet devices can be bound to a single pet device account, but only one valid binding record corresponds to the same device ID. The most recent access sequence number in the binding record is the sequence number field written by the cloud access service after the last successful access. The current access sequence number must be greater than the most recent access sequence number, and the jump difference must not exceed 32. If the current access sequence number is less than or equal to the most recent access sequence number, the cloud access service writes a sequence number rollback or sequence number reuse flag; if the current access sequence number is greater than the most recent access sequence number but the jump difference exceeds 32, the cloud access service writes a sequence number jump anomaly flag.

[0095] The pet feeder reported a clock stabilization time of 186ms, a credential read time of 42ms, and a communication attach time of 3560ms. The startup timing baseline range in the device binding record is 60ms to 440ms for clock stabilization, 5ms to 130ms for credential read, and 400ms to 9300ms for communication attach. After comparison by the cloud access service, all three time fields fall within the corresponding admission range. If the device number, authentication credential summary, and access sequence number simultaneously meet the binding record requirements, the access admission result is successfully written.

[0096] If the same device subsequently reports a communication attach time of 80ms, which is lower than the communication attach lower limit boundary of 400ms, the cloud access service writes a timing anomaly flag and rejects the access attempt. This status is used to identify situations where the control board bypasses the actual network attach process, repeatedly submits historical startup data, or returns abnormal communication link responses.

[0097] In step S4, after the access permission result is approved, the cloud access service establishes a control session. In this example, the session validity duration field is set to 300 seconds. The motor execution port of the feeder, the water pump execution port of the water dispenser, the cleaning motor port of the litter box, and the lighting port all return their current status through the port status field. Port status includes idle, running, locked, faulty, and unacknowledged. Control command types include feed immediately, dispense a fixed amount of water, start cleaning, turn on lighting, and stop execution. The cloud access service does not directly forward control commands according to the user terminal request, but first checks whether the control session is valid, and then checks whether the control command type matches the execution port status.

[0098] In the port status rules table, the allowed port status for the "Immediate Feeding" command is "Idle". If the motor port is in an executing or faulty state, forwarding is refused. The allowed port status for the "Quantitative Water Discharge" command is "Idle". If the water pump port is locked, forwarding is refused. The "Stop Execution" command can be forwarded in an executing state to interrupt the current execution action. The above port statuses are returned by the control board through in-session status reporting messages. The cloud access service saves the most recent port status; if the status is not updated for more than 30 seconds, an unacknowledged flag is written to the port.

[0099] The validity of the conversation is determined according to formula (3): ;-----Equation (3) In the formula, The cloud access service writes a binding record to S3 to determine the access time. To control the instruction reception time, the cloud access service writes the command when it receives the user terminal control message. The effective duration of the session is set to 300s here. When the control command reception time meets the conditions of equation (3), the cloud access service determines that the session validity condition is met; when the control command reception time does not meet the conditions of equation (3), the cloud access service writes a session expiration flag and refuses to forward it.

[0100] For example, if a pet feeder completes access approval at 12:00:00, with a session validity period of 300 seconds, and the user terminal sends an immediate feeding command at 12:02:10, the control command reception time falls within the session validity period. If the motor execution port is idle at this time, the cloud access service will write the immediate feeding command into the forwarding queue. However, if the user terminal sends the same command at 12:06:20, the control command reception time has exceeded the session validity period, the cloud access service will refuse to forward the command and require the control board to reconnect.

[0101] When the access rejection result is denied, the cloud access service writes the rejection reason to the access failure record. The access failure record stores the rejection reason code: parsing error corresponds to code E01, device inconsistency to code E02, credential mismatch to code E03, sequence number error to code E04, timing error to code E05, and read error to code E06. The audit storage area is indexed by device number and access sequence number. The pet device after-sales maintenance terminal can distinguish whether the rejection reason code indicates a device power-off startup problem, credential read problem, network attachment error, or suspected replay access problem.

[0102] In this example, the rejection threshold is set to 3 times, and the retry delay time is set to 180 seconds. If the same device ID experiences 3 consecutive access rejections, the cloud access service returns a retry delay flag to the control board. During the retry delay time, the control board will not submit new access requests, but will only retain the local anomaly flag and maintain a low-power waiting state. If the consecutive rejections are all due to abnormal communication attach time, the control board will prioritize re-executing the network attach process; if the consecutive rejections are all due to credential mismatch, the control board will stop the control command entry and wait for rebinding processing.

[0103] The above process demonstrates that the control board records power supply compliance, clock stability, credential output, and network attachment time using the same timing source. The cloud access service then jointly verifies the device identity, credential digest, access sequence number, and startup timing reference range, enabling it to identify normal control board startup links, historical data replays, abnormal sequence number jumps, and abnormal network attachment. After access is granted, control commands still need to undergo session validity and port status matching checks before being forwarded to the pet device control board, thus ensuring that access security verification and remote control execution are within the same closed-loop recording link.

[0104] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A method for secure access and remote control of a pet device control board based on the Internet of Things, characterized in that, Includes the following steps: S1. After the pet device control board is powered on, the time when the power supply voltage reaches the start threshold, the time when the main control chip clock stabilizes, the time when the memory outputs the authentication credential, and the time when the communication interface attaches to the network are collected. The clock stabilization time, credential reading time, and communication attachment time are recorded from adjacent times. S2. Read the device number, authentication credential summary and current access sequence number, and associate them with the clock stabilization time, the credential reading time and the communication attachment time to obtain power-on timing characteristic information. In the initial binding stage, determine the startup timing reference range based on the maximum and minimum values ​​of various times obtained from multiple power-ons of the same device number. S3. After receiving the power-on timing feature information, verify the device number, the authentication credential summary, the current access sequence number, and the time consumption of each item to determine the access admission result; S4. When the access admission result is passed, a control session is established, and the control command is determined and forwarded to the pet device control board based on the control command reception time, access pass time, control command type and execution port status; when the access admission result is rejected, return to S1 or output a delay retry flag.

2. The method for secure access and remote control of a pet device control board based on the Internet of Things as described in claim 1, characterized in that, In S1, the threshold comparison state of the power supply detection terminal is detected. When the threshold comparison state switches from low voltage state to qualified state, the start threshold time is determined. Read the clock lock status output by the main control chip, the credential read status output by the memory interface, and the network attach status output by the communication interface. When the corresponding status meets the recording conditions, record the clock stabilization time, credential output time, and attach completion time respectively. Establish a power-on time record table according to the order of occurrence of the startup threshold time, the clock stabilization time, the credential output time, and the attachment completion time; The recording conditions include: when the clock lock state is valid for no less than three consecutive sampling periods, the sampling time of the first occurrence of the valid state is recorded as the clock stabilization time. When the credential reading status shows that the number of bytes read has reached the number of bytes for the authentication credential digest, and the memory interface does not return a read error flag, the reading end time is recorded as the credential output time. When the network attachment status shows that the communication interface has obtained a network address and received attachment confirmation information, the time of receiving the attachment confirmation information is recorded as the attachment completion time.

3. The method for secure access and remote control of a pet device control board based on the Internet of Things as described in claim 2, characterized in that, The steps to obtain the clock stabilization time, credential reading time, and communication attach time include: Read adjacent time records from the power-on time record table, and determine the interval between the clock stabilization time and the power supply compliance time as the clock stabilization time. The interval between the credential output time and the clock stabilization time is determined as the credential reading time. The interval between the attachment completion time and the credential output time is determined as the communication attachment time.

4. The method for secure access and remote control of a pet device control board based on the Internet of Things as described in claim 1, characterized in that, The process of generating power-on timing feature information includes: Read the device number, authentication credential summary, and access sequence number, and write the device number, authentication credential summary, and access sequence number into the same power-on record identifier; The clock stabilization time, credential reading time, and communication attachment time are associated with the device number, authentication credential summary, and current access sequence number, respectively, according to the same power-on record identifier. The associated record content is then encapsulated in a fixed field order of device, credential, access sequence number, and time to generate the power-on timing feature information.

5. The method for secure access and remote control of a pet device control board based on the Internet of Things according to claim 4, characterized in that, The process of generating the same power-on record identifier includes: After the power supply voltage reaches the start threshold time, the local start count value of the pet device control board is read, and the local start count value is compared with the current access sequence number for consistency. When the local startup count value and the current access sequence number meet the condition of incrementing, the device number and the local startup count value are concatenated and encoded to generate the same power-on record identifier; When the local startup count value and the current access sequence number do not meet the incrementing consistency condition, the encapsulation of the associated record content is stopped, and a sequence number exception flag is generated.

6. The method for secure access and remote control of a pet device control board based on the Internet of Things according to claim 1, characterized in that, S2 also includes reading the device number and the authentication credential digest from the memory of the pet device control board, and reading the access sequence number from the local access record of the pet device control board; When the device number, the authentication credential digest, and the current access sequence number are all read within the same power-on reading cycle, and the reading length of the device number is consistent with the set device number length, the reading length of the authentication credential digest is consistent with the set digest length, and the reading length of the current access sequence number is consistent with the set sequence number length, then the reading length condition is determined to be met. When the device number, the authentication credential digest, and the current access sequence number are all not empty or all default values, and the current access sequence number is not less than the previously recorded access sequence number, it is determined that the conditions for reading content are met. When both the read length condition and the read content condition are met, the device number, the authentication credential digest, and the current access sequence number are used as valid data to be associated; otherwise, a read error is output.

7. The method for secure access and remote control of a pet device control board based on the Internet of Things according to claim 1, characterized in that, The process for determining the access admission result specifically includes: The system receives the power-on timing characteristic information and parses it according to the device, credential, access sequence number and time consumption order to obtain the device number, the authentication credential digest, the current access sequence number, the clock stabilization time, the credential reading time and the communication attachment time. The device number, the authentication credential digest, and the access sequence number are compared with the binding record, and the clock stabilization time, the credential reading time, and the communication attachment time are compared with the startup timing reference range. If the identity verification, credential verification, serial number verification, and time consumption verification all meet the access conditions, the access access result is recorded as passed; otherwise, the access access result is recorded as rejected.

8. The method for secure access and remote control of a pet device control board based on the Internet of Things according to claim 7, characterized in that, The process of comparing with the binding record is as follows: read the most recent access sequence number in the binding record, and record it as meeting the admission conditions when the current access sequence number is greater than the most recent access sequence number and the difference does not exceed the set sequence number jump threshold; otherwise, it is not met. The process of comparing with the startup timing reference range specifically involves: obtaining the startup timing reference range corresponding to the device number, and reading the lower limit boundary of clock stabilization time, the upper limit boundary of clock stabilization time, the lower limit boundary of credential reading time, the upper limit boundary of credential reading time, the lower limit boundary of communication attachment time, and the upper limit boundary of communication attachment time from the startup timing reference range; when the clock stabilization time, the credential reading time, and the communication attachment time fall between the corresponding lower limit boundary and the corresponding upper limit boundary, it is recorded as meeting the admission conditions; otherwise, it is not met.

9. The method for secure access and remote control of a pet device control board based on the Internet of Things according to claim 1, characterized in that, In S4, when the access admission result is passed, the admission pass time, device number and session validity duration are read, and the admission pass time and session validity duration are associated and written into the session status table. The control command reception time, control command type and execution port status are obtained. When the forwarding conditions are met, the control command is forwarded to the pet device control board. When the access admission result is rejected, the temporary session record corresponding to the device number in the session status table is cleared, and the rejection reason identifier is written into the access failure record. Read the number of consecutive rejections corresponding to the device number. If the number of rejections does not reach the threshold, return to S1. Allow the pet device control board to re-collect the time when the power supply voltage reaches the start threshold, the time when the main control chip clock stabilizes, the time when the memory outputs the authentication credentials, and the time when the communication interface completes network attachment. When the number of consecutive rejections reaches the rejection count threshold, a delayed retry flag is output.

10. The method for secure access and remote control of a pet device control board based on the Internet of Things according to claim 9, characterized in that, The specific forwarding conditions are as follows: When the control command is received later than the access pass time but does not exceed the session validity period, the session validity condition is determined to be met. Read the allowed port status corresponding to the control instruction type. When the execution port status matches the allowed port status, it is determined that the port matching condition is met. When both the session expiration condition and the port matching condition are met, the forwarding condition is determined to be satisfied.

Images