A traffic order processing method and device of an internet of things equipment and an electronic equipment

Abstract

The application embodiment provides a traffic order processing method and device of an Internet of Things equipment and an electronic device, the method comprises the following steps: sending a traffic order request sent by the Internet of Things equipment to a BSS platform, converting state parameter information carried in a Web order response request returned by the BSS platform into an AT instruction, and transmitting the AT instruction to the Internet of Things equipment; checking an AT instruction response code returned by the Internet of Things equipment; after the checking is passed, sending a traffic consumption value to the BSS platform, and receiving a traffic residual value and an order state issued by the BSS platform; and checking an order state of the traffic order according to the traffic consumption value, the traffic residual value and the order state. According to the application embodiment, the state synchronization is performed between the BSS platform and the Internet of Things equipment, the serial communication of the AT instruction set is combined to control the Internet of Things equipment, the Internet of Things equipment and the business system are linked, the order state confirmation efficiency can be effectively improved, and the operation and maintenance throughput capacity of a large-scale equipment cluster can be significantly improved.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and more specifically, to a method, apparatus, and electronic device for processing traffic orders for Internet of Things (IoT) devices. Background Technology

[0002] In internet business operations, bulk transactions are often achieved by submitting multiple orders at once. The traditional method is to implement bulk order placement based on an automation framework. Current IPC (IP CAMERA, network camera) devices, based on web automation solutions, can perform traffic order placement and receiving operations on the BSS (Business Support Systems) platform side, but they cannot interact with the physical layer of the device. Although they can communicate via serial port through the AT command set, they cannot be linked with the business system.

[0003] When dealing with a large customer base, this automation framework can only complete the order placement process. Order status relies solely on feedback from the BSS platform, and the IPC devices lack verification of the actual order status, making it impossible to obtain order status in real time. For example, the BSS platform may show that the order was successfully placed, but the IPC devices may not have actually received the instruction, thus hindering automated operation and maintenance. Traditional methods require manual verification of order status, confirming its validity by comparing it with each device, which is labor-intensive and inefficient. Summary of the Invention

[0004] The traffic order processing method, apparatus, and electronic device for IoT devices provided in this application solve the technical problems of high labor costs and low order status confirmation efficiency in the prior art by synchronizing the status between the BSS platform and the IoT device, thereby effectively improving the order status confirmation efficiency.

[0005] In a first aspect, embodiments of this application provide a method for processing traffic orders for an Internet of Things (IoT) device, the method comprising:

[0006] Send the traffic order requests sent by IoT devices to the BSS platform;

[0007] Receive the Web order response request returned by the BSS platform, convert the status parameter information carried in the Web order response request into AT commands, and transmit the AT commands to the IoT device;

[0008] Verify the AT command response code returned by the IoT device. After successful verification, send the traffic consumption value to the BSS platform and receive the remaining traffic value and order status from the BSS platform.

[0009] The order status of the traffic order is verified based on the traffic consumption value, the remaining traffic value, and the order status.

[0010] Secondly, embodiments of this application provide a traffic order processing device for Internet of Things (IoT) devices, the device comprising: a processing module, a conversion module, a protocol conversion gateway, a first verification module, and a second verification module;

[0011] The processing module is used to send the traffic order request sent by the IoT device to the BSS platform and receive the Web order response request returned by the BSS platform.

[0012] The protocol conversion gateway is used to convert the status parameter information carried in the Web order response request into AT commands;

[0013] The processing module is also used to transmit the AT command to the Internet of Things device;

[0014] The first verification module is used to verify the AT command response code returned by the IoT device. After the verification is successful, it sends the traffic consumption value to the BSS platform and receives the remaining traffic value and order status issued by the BSS platform.

[0015] The second verification module is used to verify the order status of the traffic order based on the traffic consumption value, the remaining traffic value, and the order status.

[0016] Thirdly, embodiments of this application provide an electronic device, the electronic device comprising:

[0017] A processor, a memory, and a computer program stored in the memory and executable on the processor; the processor, when executing the computer program, implements the method provided in the first aspect described above.

[0018] Fourthly, embodiments of this application provide a machine-readable storage medium having executable instructions stored thereon, which, when executed by a machine, cause the method provided in the first aspect to be implemented.

[0019] Fifthly, embodiments of this application also provide a computer program product containing instructions that, when run on a computer, cause the computer to execute the method provided in the first aspect of embodiments of this application.

[0020] The traffic order processing method for IoT devices provided in this invention involves sending a traffic order request from an IoT device to a BSS platform via an automated server. The automated server first converts the status parameter information carried in the order into AT commands, then transmits these AT commands to the IoT device. The server verifies the AT command response code returned by the IoT device. If the verification is successful, it sends a traffic consumption value to the BSS platform. The order status is then verified based on this traffic consumption value and the remaining traffic value issued by the BSS platform. This invention achieves status synchronization between the BSS platform and the IoT device, and controls the IoT device via serial communication using the AT command set. This enables the IoT device to link with the business system, constructing a fully automated link from order placement to device activation. This allows for timely confirmation of order status, effectively improving order status confirmation efficiency and significantly enhancing the operational throughput of large-scale device clusters. Attached Figure Description

[0021] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the description of the embodiments or prior art will be briefly introduced below. However, those skilled in the art should understand that the drawings described below are merely some examples of this application and do not limit its scope.

[0022] Figure 1 This is a schematic diagram of a traffic order processing method for an Internet of Things (IoT) device according to one embodiment.

[0023] Figure 2 This is a schematic diagram of three stages of automated operation and maintenance provided according to one embodiment;

[0024] Figure 3 This is another flowchart illustrating a traffic order processing method for an IoT device provided according to one embodiment.

[0025] Figure 4 This is a schematic diagram of the structure of a traffic order processing device for an Internet of Things (IoT) device according to one embodiment;

[0026] Figure 5 This is a schematic block diagram of the structure of an automation server provided according to one embodiment;

[0027] Figure 6 This is a schematic block diagram of the structure of an electronic device provided according to one embodiment. Detailed Implementation

[0028] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Those skilled in the art should understand that the described embodiments are only some, not all, of the embodiments of this invention. Based on the embodiments in this application, those skilled in the art can make any appropriate modifications or variations to obtain all other embodiments.

[0029] Current mainstream solutions for batch order placement based on web automation frameworks offer automated order placement capabilities, but they lack real-time order status feedback and automated order status verification. This necessitates manual verification mechanisms, comparing orders device by device to confirm validity, significantly increasing labor costs and reducing processing efficiency. This invention provides an automation server that interacts with the BSS platform's web automation framework via a serial communication module, achieving a fully automated process. This completes the end-to-end unmanned processing loop from order placement to device activation, significantly improving the operational throughput of large-scale device clusters.

[0030] The above technical solution will be described in detail below with reference to specific embodiments.

[0031] In a first aspect, embodiments of the present invention provide a method for confirming the status of traffic orders for Internet of Things (IoT) devices, such as... Figure 1 As shown, the method includes:

[0032] Step 101: Send the traffic order request sent by the IoT device to the BSS platform;

[0033] Step 102: Receive the Web order response request returned by the BSS platform, convert the status parameter information carried in the Web order response request into AT commands, and transmit the AT commands to the IoT device;

[0034] Step 103: Verify the AT command response code returned by the IoT device. After successful verification, send the traffic consumption value to the BSS platform and receive the remaining traffic value sent by the BSS platform.

[0035] Step 104: Verify the order status of the traffic order based on the traffic consumption value and the remaining traffic value.

[0036] Specifically, the IoT devices in the embodiments of the present invention include, but are not limited to, network camera IPC devices, and / or, IoT devices deployed in a 4G / 5G dual-mode IPC device cluster.

[0037] This invention implements order placement and receiving operations through a BSS platform, and controls the interaction between IoT devices and the BSS platform via serial communication using AT command sets. This invention enables interaction between the BSS platform and IoT devices, constructing a fully automated workflow. When dealing with large-scale customer groups, it can significantly improve the operational throughput of large-scale device clusters.

[0038] The embodiments of the present invention adopt a hierarchical networking architecture, with the automation server as the core node, to build a three-level system of IoT devices, automation servers, and BSS platforms.

[0039] The automated server is equipped with a protocol conversion gateway and a serial communication module. The serial communication module enables rapid connection to IoT devices and supports the parallel access of a large number of IoT devices. The IoT devices include, but are not limited to, network camera IPC devices. A large number of IoT devices form an IPC device cluster, which can adopt a 4G / 5G dual-mode IPC device cluster. It is pre-installed with a standard AT command set and establishes a high-speed communication link with the automated server, supporting an adaptive baud rate of up to 115200bps.

[0040] This embodiment of the invention uses an Internet of Things (IoT) device as an example of an IPC device. The IPC device is equipped with a network communication module that provides network support capabilities. The network communication module first requests an order from the BSS platform. After receiving the order, the network communication module confirms the order data again, thereby realizing a three-level verification process: physical layer response of the IPC device, status verification of the BSS platform, and configuration of the IPC device.

[0041] like Figure 2 As shown in the figure, the method for confirming the status of IoT device traffic orders in batch orders provided by this embodiment of the invention, as an automated operation and maintenance method, is divided into three stages. The implementation process of this embodiment of the invention is provided below in conjunction with the three stages:

[0042] Phase 1: Equipment Discovery Phase

[0043] The automated server deploys the dynamic binding relationship between device identifiers and communication ports for IoT devices. In practical applications, this can be achieved using a serial number (SN) mapping table. This table establishes a dynamic binding relationship between device SN codes and communication ports, enabling automatic binding between IPC devices and port identifiers. During IPC device registration, the corresponding communication port is looked up in the SN mapping table based on the IPC device identifier, completing the communication channel initialization.

[0044] The automation control server in this embodiment of the invention includes, but is not limited to, a PC. Each communication port on the PC has a unique communication port number, so different IoT devices plugged into the same USB port will also have the same communication port number. Establishing the correspondence between device identifiers and communication ports in this embodiment includes: establishing the correspondence between IoT device identifiers and communication ports through an SN code mapping table. When an IoT device connects to different communication interfaces, the correspondence between device identifiers and communication ports changes dynamically.

[0045] In addition to establishing the correspondence between the SN code of the IPC device and the communication port, the SN code mapping table in this embodiment of the invention also establishes the relationship between the SN code of the IPC device and the access time of the IPC device. In practice, based on this SN code mapping table, the access time of the IPC device is shortened from 3 minutes to 1 minute, and the efficiency is improved by 67%, which greatly reduces the time spent on port selection during the device initialization stage and improves the port operation and maintenance efficiency.

[0046] Phase Two: Instruction Execution Phase

[0047] Traffic order requests sent by IoT devices are sent to the BSS platform via an automated server. The BSS platform's web automation framework integrates a device feature recognition algorithm to automatically identify whether the connection port is an IPC device without manual intervention. After receiving the traffic order request from the automated server, the platform implements an order response request through web operation instructions and returns the order response request to the automated server. The order response request carries the order's status parameter information.

[0048] The automated server converts the status parameter information carried in the Web order response request into AT commands, which are then transmitted to the IPC device via a protocol conversion gateway. Failed commands are automatically placed into a retry queue. In this way, this embodiment of the invention enables cross-system operation between Web operation commands of the BSS platform and AT commands of the IPC device.

[0049] In this embodiment of the invention, the instruction conversion layer serves as the starting point. It first generates initial instructions using the device configuration template and performs syntax verification. Only when the instructions are compliant and match the device protocol version will they enter the transparent transmission guarantee layer. The transparent transmission guarantee layer prioritizes transmitting instructions through the main channel and monitors them in real time. If no acknowledgment is received within 5 seconds, the failed instructions are pushed to the retry management layer. The retry management layer performs graded retries according to the fault type. Only when all retries have been exhausted and there is still no success, the failure record is transferred to the exception error code.

[0050] Phase 3: Status Verification Phase

[0051] The automated server provides a three-level verification mechanism: first, it verifies the order response of the device's physical layer; second, it compares the order status with the BSS platform; and finally, it verifies the validity of the device-side parameter configuration.

[0052] In this embodiment of the invention, an exception handling engine is embedded throughout the three stages of automated operation and maintenance. This includes monitoring communication failures / command execution anomalies, automatically triggering three retries (which can be set to every 1 second), triggering a timeout when a retry fails, sending a manual access warning, and finally generating a structured processing report containing the cause of the anomaly and processing records.

[0053] This invention implements closed-loop verification through three-level verification of an automated server, which can detect anomalies in the batch ordering process and handle them accordingly. In practical applications, when a communication failure is detected, a retry operation is triggered. If the communication failure still occurs after 3 retries or when the retry times out, the process is terminated, and a manual intervention warning is triggered, ultimately generating a structured processing report.

[0054] This invention also provides the network environment required for actual operation. Specifically, at the communication parameter layer, an adaptive baud rate (maximum 115200bps) and a 3-second timeout threshold are set; at the device registration layer, the communication channel is initialized by querying the port mapping table through the SN code; and at the security protection layer, bidirectional ACL control is implemented (allowing TCP / 8080 and SERIAL / COM3-64 channels) and SSL encryption is enabled for high-risk operations.

[0055] A typical configuration process is as follows: extract the BSS platform SN code list → negotiate the optimal communication rate → initialize the serial port / TCP channel → write the device configuration template → enable the three-level verification mechanism, and finally form a reusable configuration work order library.

[0056] The following is combined with Figure 3 This proposal details the method for confirming the status of IoT device traffic orders, which includes:

[0057] Step 201: The automated server loads the SN code mapping table and constructs a dynamic relationship between the device identifier of the IPC device and the communication port;

[0058] In this embodiment of the invention, device identification includes, but is not limited to, serial number (SN) codes. The SN code is a unique identifier for a device. The SN code mapping table establishes not only a dynamic relationship between the IPC device's SN code and the communication port, but also a relationship between the IPC device's SN code and its access time. Based on the device access time in this SN code mapping table, the port selection time during the device initialization phase can be obtained. In practice, based on this SN code mapping table, the IPC device access time is reduced from 3 minutes to 1 minute, improving efficiency by 67%, significantly reducing the port selection time during device initialization, and improving port maintenance efficiency.

[0059] In practical applications, when an IPC device is connected to different communication interfaces, the correspondence between the device identifier and the communication port changes dynamically. This is because each device has a unique identifier on the PC. For example, when device 1 is plugged into the computer, it is identified as communication port 1, and when device 2 is plugged into the computer, it is identified as communication port 2. The "dynamic" here refers to the change of the IPC device's port on different PCs. Each communication port will have a communication port number on the PC. The communication port is a unique identifier for the device on the PC. Different devices plugged into the same USB will have the same port number.

[0060] The automated server in this embodiment of the invention also integrates an online status prediction algorithm. By analyzing historical behavior data of IPC devices, network connection quality and other multi-dimensional information, it predicts the online status of the devices and possible failure risks, thereby taking measures in advance to avoid service interruption.

[0061] The online state prediction algorithm specifically includes:

[0062] The communication port is obtained by querying the SN code in the SN code mapping table, registration is completed, and the registration result and response time are recorded in the status log. The registration result includes: online status, high-risk status, and offline status. When success + response time ≤ a threshold, it indicates an online status; continuous failures or abnormal parameters indicate a high-risk status; if a high-risk status persists for a certain timeout, such as 10 minutes without recovery, it indicates an offline status. The prediction results are written to the log to drive subsequent maintenance actions, such as prioritizing the investigation of high-risk devices, thus achieving status updates.

[0063] The automated server performs anomaly handling and optimization based on online status prediction results, providing retry mechanisms, rule tuning, and log auditing. Specifically, it automatically retryes registration failures up to 3 times, and marks them as high-risk after a timeout. It regularly analyzes false alarm cases and optimizes thresholds or rule logic, such as adjusting the failure count threshold. It records the prediction process and rule trigger details, supporting problem backtracking.

[0064] This proposal dynamically binds device identifiers and communication ports through an SN code mapping table, initializes the communication channel, and links the prediction results with the automation server through a three-level verification mechanism: parameter verification at the device layer → BSS platform → automation server.

[0065] Step 202: The automation server receives the traffic order request sent by the IPC device, and automatically resolves the communication port corresponding to the IPC device according to the dynamic relationship between the device identifier and the communication port of the constructed IPC device, so as to realize the automated access of the IPC device.

[0066] Step 203: The automation server sends the traffic order request to the BSS platform, receives the Web order response request sent by the BSS platform through Web operation instructions, the Web order response request carries the status parameter information of the order, converts the status parameter information carried by the Web order response request into AT commands, and transmits the AT commands to the IPC device through the protocol conversion gateway;

[0067] This invention integrates a device feature recognition algorithm into the Web framework of the BSS platform. This algorithm automatically determines whether the device corresponding to the connected communication port is the target IPC device without manual intervention.

[0068] The device feature recognition algorithm includes: extracting the unique identifier of the device associated with the current communication port, querying the preset SN code mapping table, and verifying whether the encoding rule of the SN code conforms to the IPC device specification; sending a protocol version detection command through the port communication link, collecting the communication protocol type and version number fed back by the device, and determining whether it is compatible with the standard AT command set protocol version supported by the IPC device; detecting the serial communication parameters and hardware interface type of the port, and comparing them with the preset hardware feature library of the IPC device;

[0069] Among them, the serial communication parameters can be an adaptive baud rate range and / or timeout threshold, the hardware interface type can be a USB-to-serial adapter model, and the comparison with the preset hardware feature library of the IPC device can show that the IPC device supports a maximum baud rate of 115200bps and is compatible with COM3-64 communication ports.

[0070] In summary, when the three conditions of SN code rule matching, protocol version compatibility, and hardware characteristic consistency are met, the IPC device is determined to be an accessible IPC device, and subsequent order parameter command pass-through is allowed. If any condition is not met, it is determined to be a non-target device, command interaction is rejected, and an exception log is recorded.

[0071] Specifically, the status parameter information can be traffic validity period parameters and / or traffic package specification parameters, and the status parameter information carried in the Web order response request needs to be converted into AT commands.

[0072] In practical applications, when IPC devices communicate with other modules using AT commands, serial communication is usually involved. This requires converting Web operation commands into AT commands and converting the status parameter information carried in Web order response requests into AT commands, including:

[0073] Extract the status parameter information from the Web order response request returned by the BSS platform, and preprocess the parameter format of the status parameter information into standardized fields;

[0074] Based on the standardized fields, query the preset standard AT command set of the IoT device to determine the corresponding AT command template;

[0075] Cross-protocol mapping is performed through a protocol conversion gateway. The status parameter information encapsulated by the Web protocol is reorganized according to the syntax rules of AT commands in the AT command template. The parameter key-value pairs in the Web order response request are parsed and mapped to AT command fields. The protocol header, field separator and checksum required by the AT command are added to ensure that the AT command conforms to the syntax requirements of serial communication.

[0076] In addition, to improve transmission adaptability, this embodiment of the invention also optimizes the transparent transmission of the converted AT commands based on the communication capabilities of IoT devices. For adaptation to 4G / 5G dual-mode communication environments, or for high-risk parameter configurations, AES encryption is enabled to ensure transmission security.

[0077] This invention also provides a compliance verification operation for AT commands, performing syntax verification on the converted AT commands to verify whether the command length, field format, and parameter range match the protocol requirements of the target device. Only after the verification is passed can the commands be transmitted to the IoT device.

[0078] The automated server converts the status parameter information carried in the received Web order response request into AT commands, which are then transmitted to the IPC device via a protocol conversion gateway. Failed commands are automatically placed into a retry queue. In this way, this embodiment of the invention enables cross-system operation between Web operation commands of the BSS platform and AT commands of the IPC device.

[0079] In this step, the correspondence between IoT device identifiers and communication ports is established, and AT commands are transparently transmitted to the IoT device. This includes: obtaining the device identifier of the IoT device; obtaining the corresponding communication port of the IoT device based on the device identifier and the correspondence; and transmitting the AT commands to the IoT device through the corresponding communication port.

[0080] In this embodiment of the invention, the protocol conversion gateway is located between two or more networks or devices using different protocols. After parsing the protocol data packets sent by one party, it re-encapsulates them into a protocol format that the other party can recognize, thereby realizing cross-protocol communication. For example, in this embodiment of the invention, HTTP requests, such as web applications, are converted into serial port commands, such as RS485, to control the underlying hardware devices.

[0081] Its core function is to perform protocol parsing and encapsulation, parsing the received source protocol data packets and extracting valid instruction type information. Then, according to the target protocol rules, it reorganizes data field mappings, checksums, and other formats (such as adding protocol headers). Furthermore, it features data pass-through and optimization, preserving the semantics and content of the original data during protocol conversion without modifying business logic.

[0082] Furthermore, it can compress (e.g., LZ4), encrypt (e.g., AES), or fragment and reassemble transmitted data to adapt to different network environments.

[0083] Step 204: The IPC device receives the AT commands transmitted by the automation server through the protocol conversion gateway, generates an AT command response code, and returns it to the automation server;

[0084] In this step, the automation server sends an AT command, such as AT+NETREG?, to the IPC device and receives an AT command response code, such as +NETREG: 0, indicating that the IPC device has successfully registered with the operator's network. This step then returns the AT command response code to the automation server, which verifies it.

[0085] Step 205: The automated server verifies the AT command response code. If the verification passes, proceed to step 206; otherwise, proceed to step 208.

[0086] This invention provides a three-level verification mechanism in the automated server, including: verifying the AT command response code sent by the IPC device via the serial port; comparing the order status with the BSS platform; and finally verifying the validity of the device-side parameter configuration. This three-level verification achieves closed-loop verification of order status, significantly reducing the order error rate and enabling automated operation and maintenance.

[0087] Specifically, in this embodiment of the invention, the operation of verifying the AT command response code includes: verifying whether the AT command response code passes the internal format verification, semantic verification, and timing verification. If all verifications pass, it means that the AT command response code has passed the initial verification.

[0088] When the automation server receives the response code +NETREG: 0, it indicates that the IPC device has been successfully registered to the operator's network. If the response code is verified, it means that the AT command response code meets the preset conditions.

[0089] Specifically, the following example illustrates how to verify the AT command response code +NETREG: 0:

[0090] +NETREG: 0's internal format conforms to +NETREG:<status_code> The regular expression indicates that the internal format validation passed; the 0 in +NETREG: 0 maps to the "registered" status, indicating that the semantic validation passed; the response time of +NETREG: 0 is ≤200ms, indicating that the timing validation passed. Therefore, the internal format validation, semantic validation, and timing validation of the AT command response code +NETREG: 0 all passed, indicating that the AT command response code validation passed.

[0091] Step 206: After the initial verification is successful, the IPC device and the BSS platform continue to interact through the automated server. The automated server verifies the order status of the traffic order. If the order status verification is successful, proceed to step 207. If the order status verification fails, proceed to step 208.

[0092] This step serves as the second verification step in the automated server's three-level verification mechanism, namely, comparing the order status with the BSS platform; verifying the order status based on the traffic consumption value reported by the IPC device, and the remaining traffic package and order status returned by the BSS platform.

[0093] In a preferred embodiment, the AT command response code sent by the IPC device carries the data plan value and data consumption value. The BSS platform issues the remaining data value and order status, and verifies the order status of the data order based on the data consumption value, remaining data value, and order status, including:

[0094] When the sum of the data consumption value and the remaining data value equals the data plan value, the order status is normal. The order status is determined based on the data consumption value. The order status is verified to be consistent with the received order status to determine whether the order status verification is successful.

[0095] Correspondingly, when the data consumption value and the remaining data value are not equal to the data plan value, the order status is abnormal.

[0096] Verify whether the determined order status is consistent with the received order status to determine whether the order status verification passes. Specifically, if the determined order status is consistent with the received order status, the order status verification passes; if the determined order status is inconsistent with the received order status, the order status verification fails.

[0097] Specifically, the order status can be either "order placed successfully" or "received confirmed". For example, if the BSS platform issues an order status of "order placed successfully", but the IPC device does not actually receive the instruction, the order status will be determined as "ordering in progress" based on the traffic consumption value reported by the IPC device. This determined order status is inconsistent with the order status issued by the BSS platform, indicating that the order status verification fails.

[0098] Step 207: After the order status verification passes, verify the validity of the IPC device parameter configuration.

[0099] This step serves as the third verification step in the automated server's three-level verification mechanism, verifying the validity of the device-side parameter configuration. Through these three levels of verification, a closed-loop verification of the order status is achieved, enabling automated operation and maintenance.

[0100] The verification of the validity of the IPC device's parameter configuration includes: collecting the device status parameters and timestamps of the IPC device through AT commands; firstly, the timestamp is format-verified, and if the timestamp conforms to the order date format, the verification passes; then, the device status parameters are semantically verified, and if the device status parameters are consistent with the order template, the device status parameters are verified, and the validity of the IPC device's parameter configuration is verified.

[0101] This invention employs a two-step verification mechanism to validate the validity of IPC device parameter configurations, prevent order anomalies, record detailed logs for subsequent traceability of the entire process, and ultimately determine whether acceptance is successful or an anomaly is triggered based on the verification results.

[0102] The present invention addresses the issue that the parameter configuration for the current order requires manual acquisition from the BSS platform and then manual writing to the device firmware, which is inefficient and prone to configuration errors due to special time-sensitive rules such as holidays. It is difficult to adapt to complex business needs and optimize the utilization of system resources. The present invention introduces a set of configurable time strategy parameters, enabling the automated server to accurately control and intelligently schedule the configuration time of the order.

[0103] The specific workflow is as follows:

[0104] 1. Trigger the loading of the order placement and parameter interface:

[0105] Users or external systems trigger order placement through a user interface or API. The BSS platform front-end loads the order parameter configuration interface, which includes an input control for setting the desired execution time.

[0106] 2. Calculation and setting of expected execution time:

[0107] Specifically, a time calculation method is provided, which receives a base time and a time increment, calculates a future time point string accurate to the second, and then fills the future time into the input box of the front-end interface.

[0108] In practical applications, the order parameter configuration interface serves as the user interface, and its function is to assign values ​​to parameters in the backend order data model; it can also modify the default time according to user needs.

[0109] 3. Order Submission and Data Transmission:

[0110] Once the user confirms the submission, the front end will package the order data, which includes this future time parameter, and send it to the automation server via an HTTP request.

[0111] 4. Automated server reception and scheduling:

[0112] After receiving the order, the automated server recognizes that it is a scheduled task, parses the order time parameters, and updates the order status.

[0113] 5. Scheduled execution:

[0114] When the system time reaches the time specified for the order, the order is retrieved from the queue and sent to the configuration execution engine for processing, thus realizing the timed automatic configuration function of the order.

[0115] Step 208: Stop the automated operation and maintenance process.

[0116] The automated server provides a three-level verification mechanism. If the current verification fails, the next level of verification parameters will not be executed, thus stopping the automated operation and maintenance process.

[0117] This invention, through capturing actual response data from the device and verifying order status based on this data and data issued by the BSS platform, achieves an end-to-end unmanned closed-loop processing from order placement to device activation. This fully automated process supports parallel processing of a large number of devices, improving operational efficiency by 80%. When dealing with large customer groups, it significantly enhances the throughput of large-scale device cluster operations. By loading an SN code mapping table on the automation server and establishing AT command interaction between the BSS platform's Web automation framework and IPC device serial communication, it can automatically identify whether the connection port is an IPC device. IPC device access time is reduced from 3 minutes to 1 minute, improving efficiency by 67%, greatly reducing port selection time during device initialization and improving port maintenance efficiency. Three-level verification achieves closed-loop verification, significantly reducing order error rates and enabling automated operation and maintenance with single-person monitoring.

[0118] This invention is compatible with IPC devices and mainstream manufacturers' AT command sets, and has good scalability. In actual operation and maintenance scenarios, it increases the accuracy of device activation verification and reduces errors in traffic validity period configuration.

[0119] Secondly, based on the same inventive concept, embodiments of the present invention provide a traffic order processing device for Internet of Things (IoT) devices, such as... Figure 4 As shown, the device includes: a processing module 301, a protocol conversion gateway 302, a first verification module 303, and a second verification module 304;

[0120] The processing module 301 is used to send the traffic order request sent by the IoT device to the BSS platform and receive the Web order response request returned by the BSS platform.

[0121] Protocol conversion gateway 302 is used to convert the status parameter information carried in the Web order response request into AT commands;

[0122] Processing module 301 is also used to transmit AT commands to IoT devices;

[0123] The first verification module 303 is used to verify the AT command response code returned by the IoT device. After the verification is successful, it sends the traffic consumption value to the BSS platform and receives the remaining traffic value and order status issued by the BSS platform.

[0124] The second verification module 304 is used to verify the order status of traffic orders based on the traffic consumption value, the remaining traffic value, and the order status.

[0125] The apparatus provided in this embodiment of the invention further includes a third verification module, used to collect the device status parameters and timestamp of the IoT device through AT commands; to perform format verification on the timestamp; after the timestamp verification is passed, to perform semantic verification on the device status parameters; if the device status parameter verification is passed, it indicates that the parameter configuration validity verification of the IoT device is passed.

[0126] The device provided in this embodiment of the invention captures actual response data from the device and verifies the order status based on the actual response data and the data issued by the BSS platform, thereby realizing an end-to-end unmanned processing closed loop from order issuance to device activation. The device can support parallel processing of a large number of devices, improving operational efficiency by 80%, and significantly improving the operation and maintenance throughput of large-scale device clusters when facing a large customer group.

[0127] The system operating environment provided in this embodiment of the invention is as follows: the server operating system is recommended to be Windows Server 2019 or later; .NET Core runtime and IIS web server need to be installed, the CPU is recommended to be a multi-core processor, and the memory is 16G or more; the database is installed with MySQL 5.7 or later.

[0128] The web server in this embodiment of the invention includes, but is not limited to, .NET Core MVC (Model-View-Controller), and the storage module includes, but is not limited to, a MySQL database. The automated operation and maintenance device for batch ordering in this embodiment of the invention combines the .NET Core MVC (Model-View-Controller) pattern, Web API, and MySQL database to build feature-rich web applications. .NET Core MVC is responsible for receiving user requests, processing the user interface and interaction logic, and sending alarm trigger information to the monitoring and display module; the Web API provides interfaces for data services and business logic, while the MySQL database is used to store and manage application data.

[0129] After installing the database, deploying the Web API interface, and deploying the Web system on the server, the engineer exports the necessary PLC program source files (AWL), symbol names, and comment files from the automation system and places them in the designated folder.

[0130] Thirdly, based on the same inventive concept, embodiments of the present invention provide an automated server, such as... Figure 5 The automation server 400 includes: a protocol conversion gateway 401, a serial communication module 402, and a processing chip 403;

[0131] The processing chip 403 is used to receive traffic order requests sent by IoT devices and send them to the protocol conversion gateway. It also transmits the AT commands sent by the protocol conversion gateway to the IoT devices, verifies the AT command response codes returned by the IoT devices, and sends the traffic consumption value to the BSS platform after successful verification. It also receives the remaining traffic value issued by the BSS platform and verifies the status of the order based on the traffic consumption value and the remaining traffic value.

[0132] The serial communication module 402 sends the order request to the BSS platform and receives the order response request returned by the BSS platform;

[0133] Protocol conversion gateway 401 is used to convert traffic order requests into AT commands.

[0134] The reliability assurance mechanism provided in this invention includes at least: dual-channel redundancy design, heartbeat detection mechanism, and end-to-end control. The dual-channel redundancy design includes a primary serial port channel / backup TCP channel; the heartbeat detection mechanism is used to monitor link connectivity in real time; and the end-to-end control is used for closed-loop control from the business system to the device terminal.

[0135] The automated control server provided in this embodiment of the invention includes, but is not limited to, a PC computer, used to control automated code to operate the network communication module in IoT devices, and then realize the interaction between the BSS platform and the network communication module in the IoT devices. It can quickly connect to IPC devices through a serial communication module, eliminating the need for manual judgment of whether the port corresponds to the IPC device, improving device identification efficiency, and is suitable for cross-platform compatibility.

[0136] Figure 6 This is a schematic block diagram of an electronic device provided according to one embodiment, which may be a program generation device or an AI system.

[0137] The electronic device 500 includes a processor 501, a memory 502, and a computer program stored in the memory and capable of running on the processor. When the processor 501 executes the computer program, it implements the automated operation and maintenance method for batch ordering in the above embodiments.

[0138] For example, processor 501 may be a central processing unit (CPU), etc. Memory 502 may include random access memory, flash memory, read-only memory, programmable read-only memory, non-volatile memory, or registers, etc. Memory 502 may store executable instructions. Processor 501 may execute the executable instructions stored in memory 502 to implement the various processes described herein.

[0139] Furthermore, embodiments of this application also provide a machine-readable storage medium. This machine-readable storage medium can store executable instructions, which, when executed by a machine, cause the machine to implement the specific processes described in the above-described method embodiments.

[0140] For example, machine-readable storage media may include, but are not limited to, random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), static random access memory (SRAM), hard disks, flash memory, etc.

[0141] Furthermore, this application also provides a computer program product containing instructions, which, when run on a computer, causes the computer to execute the steps in the above-described automated operation and maintenance method for batch ordering.

[0142] These computer-executable 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, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0143] These computer-executable instructions can also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0144] Those skilled in the art will understand that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can implement the described functions in different ways for each specific application, but such implementation should not be considered beyond the scope of this application.

[0145] In the embodiments of this application, the disclosed automated operation and maintenance method for batch ordering can be implemented in other ways. For example, the division of units is only a logical functional division, and there can be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system. In addition, the coupling between the various units can be direct coupling or indirect coupling. Furthermore, the functional units in the embodiments of this application can be integrated into a processing unit, or they can exist as separate physical entities, etc.

[0146] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a machine-readable storage medium. Therefore, the technical solution of this application can be embodied in the form of a software product, which can be stored in a machine-readable storage medium. This software product may include several instructions to cause an electronic device to execute all or part of the processes of the technical solution described in the embodiments of this application. The aforementioned storage medium may include various media capable of storing program code, such as ROM, RAM, removable disk, hard disk, magnetic disk, or optical disk.

[0147] The above description is merely a specific embodiment of this application, and the scope of protection of this application is not limited thereto. Those skilled in the art can make changes or substitutions within the technical scope disclosed in this application, and all such changes or substitutions should be within the scope of protection of this application.

Claims

1. A method for processing traffic orders of an Internet of Things device, characterized in that, The method comprises: The traffic order request sent by the Internet of Things device is sent to the BSS platform; The state parameter information carried by the Web order response request returned by the BSS platform is converted into an AT instruction, and the AT instruction is transparently transmitted to the Internet of Things device; The AT instruction response code returned by the Internet of Things device is checked, and after the check is passed, a traffic consumption value is sent to the BSS platform, and a traffic remaining value and an order state issued by the BSS platform are received; According to the traffic consumption value, the traffic remaining value and the order state, the order state of the traffic order is checked.

2. The method of claim 1, wherein, The AT instruction response code returned by the Internet of Things device for the first time carries a traffic package value, and correspondingly, according to the traffic consumption value, the traffic remaining value and the order state, the order state of checking the traffic order comprises: Determine whether the sum of the traffic consumption value and the traffic remaining value is equal to the traffic package value; When the sum of the traffic consumption value and the traffic remaining value is equal to the traffic package value, it indicates that the order state is normal; According to the traffic consumption value, the order state is determined, and whether the determined order state is consistent with the received order state is checked to determine whether the order state is checked.

3. The method of claim 2, wherein, After the order state is checked, the method further comprises: The device state parameter and the timestamp of the Internet of Things device are collected through the AT instruction; The timestamp is format-checked, and after the timestamp is checked, the device state parameter is semantically checked, and the device state parameter is checked, indicating that the parameter configuration validity of the Internet of Things device is checked.

4. The method according to any one of claims 1 to 3, characterized in that, The state parameter information carried by the Web order response request is converted into an AT instruction, which comprises: The state parameter information is extracted from the Web order response request returned by the BSS platform, and the parameter format of the state parameter information is preprocessed into a standardized field; Based on the standardized field, the standard AT instruction set preset by the Internet of Things device is queried to determine the corresponding AT instruction template; Through the protocol conversion gateway, cross-protocol mapping is performed, the state parameter information encapsulated by the Web protocol is reorganized according to the syntax rules of the AT instruction in the AT instruction template, the parameter key-value pairs in the Web order response request are parsed, the parameter key-value pairs are mapped into AT instruction fields, and the protocol header, field separator and check code required by the AT instruction are added to ensure that the AT instruction meets the syntax requirements of serial communication.

5. The method of claim 4, wherein, The method further comprises: establishing a correspondence between the Internet of Things device identifier and the communication port, and correspondingly, the AT instruction is transparently transmitted to the Internet of Things device, which comprises: The device identifier of the Internet of Things device is obtained, and the corresponding communication port of the Internet of Things device is obtained according to the device identifier and the correspondence; The AT instruction is transparently transmitted to the Internet of Things device through the corresponding communication port.

6. The method of claim 5, wherein, The correspondence between the device identifier and the communication port comprises: The correspondence between the device identifier of the Internet of Things device and the communication port is established through an SN code mapping table; The correspondence between the device identifier and the communication port dynamically changes when the Internet of Things device accesses different communication interfaces.

7. The method of claim 5, wherein, The Internet of Things device includes, but is not limited to, an Internet Protocol Camera (IPC) device, and / or the Internet of Things device is deployed in a 4G / 5G dual-mode IPC device cluster.

8. A traffic order processing apparatus of an Internet of Things device, characterized by, The device includes a processing module, a conversion module, a protocol conversion gateway, a first verification module, and a second verification module. The processing module is configured to send a traffic order request sent by an Internet of Things device to a BSS platform and receive a Web order response request returned by the BSS platform. The protocol conversion gateway is configured to convert state parameter information carried in the Web order response request into an AT instruction. The processing module is further configured to transparently transmit the AT instruction to the Internet of Things device. The first verification module is configured to verify an AT instruction response code returned by the Internet of Things device, send a traffic consumption value to the BSS platform after verification, and receive a traffic remaining value and an order state issued by the BSS platform. The second verification module is configured to verify an order state of the traffic order according to the traffic consumption value, the traffic remaining value, and the order state.

9. The apparatus of claim 8, wherein, The device further includes a third verification module configured to collect device state parameters and a timestamp of the Internet of Things device through an AT instruction. After format verification of the timestamp, semantic verification of the device state parameters is performed after the timestamp verification is passed, and the device state parameters are verified to pass the parameter configuration validity verification of the Internet of Things device.

10. An automation server, characterized by The automatic server includes a serial communication module, a protocol conversion gateway, and a processing chip. The processing chip is configured to receive a traffic order request sent by an Internet of Things device and send it to the protocol conversion gateway, transparently transmit an AT instruction sent by the protocol conversion gateway to the Internet of Things device, verify an AT instruction response code returned by the Internet of Things device, send a traffic consumption value after verification to a BSS platform, receive a traffic remaining value issued by the BSS platform, and verify the state of the order according to the traffic consumption value and the traffic remaining value. The serial communication module sends the order request to the BSS platform and receives an order response request returned by the BSS platform. The protocol conversion gateway is configured to convert the traffic order request into an AT instruction.

11. An electronic device, comprising: a processor, a memory, and a computer program stored on the memory and executable on the processor; wherein the processor implements the traffic order processing method of the Internet of Things device according to any one of claims 1-7 when executing the computer program.

12. A machine-readable storage medium, characterized in that, The computer program product has executable instructions stored thereon, which, when executed by a machine, cause implementation of the traffic order processing method of the Internet of Things device according to any one of claims 1 to 7.

13. A computer program product comprising instructions, characterized in that, When executed on a computer, the computer program product causes the computer to perform the steps of the traffic order processing method of the Internet of Things device according to any one of claims 7.

Images