Data transmission exception processing method and device, equipment and storage medium

Abstract

The embodiment of the invention discloses a data transmission exception processing method and device, equipment and a storage medium, and belongs to the technical field of communication. According to the embodiment of the invention, on one hand, the SSID with the byte length exceeding the preset length in the sequence data is filtered before the Hal layer sends the sequence data to the Carservice layer, so that the situation that the application program crashes when receiving the SSID data not conforming to the preset length is improved, and the probability that the application program crashes when running is reduced; and on the other hand, after the Carservice layer receives the sequence data sent by the Hal layer, secondary verification is carried out on the sequence data, the situation that error data are sent to the upper application, and consequently the upper application crashes is further avoided, the running stability of the application program is improved, and the running robustness of the application program is improved.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of communication technology, and in particular to a method, apparatus, device, and storage medium for processing abnormal data transmission. Background Art

[0002] At present, automobiles are developing towards networking, automation, sharing and electrification, and the "new four modernizations" all point to intelligence.

[0003] Data and signal transmission are essential for intelligent vehicles. This requires a remote / onboard communication module (Telematics Box, T-Box) to interact with the vehicle's computer system to enable functions such as internet access and positioning. This module also provides comprehensive, intelligent, and accurate online monitoring of the vehicle, providing users with rich business information and precise vehicle scheduling management. The signal interaction between the T-Box and the vehicle's computer system involves the transmission of network data, such as Wireless Fidelity (WiFi) data and positioning information.

[0004] However, during the signal interaction between the T-Box and the vehicle system, the vehicle system will set requirements for the data volume of the T-Box transmission signal. When the data volume does not meet the transmission requirements, the vehicle system will activate the protection mechanism to restrict the application operation, causing the application to crash. Summary of the Invention

[0005] Embodiments of the present invention provide a method, apparatus, device, and storage medium for processing data transmission anomalies, thereby filtering SSIDs whose byte length exceeds a preset length at least at the Hal layer and completing sequence data verification at the Carservice layer, thereby improving the stability of application operation, reducing the probability of application operation crashes, and enhancing the robustness of application operation.

[0006] In a first aspect, an embodiment of the present invention provides a method for handling data transmission anomalies, comprising at least the following steps:

[0007] Use T-Box to upload Wifi list data to upper layer applications through SomeIp layer;

[0008] At least after the upper layer application receives the Wifi list data, it sends the Wifi list data to the Linux layer through the SomeIp layer using a data interface;

[0009] Use the Linux layer to read the Wifi list data, and compose the Wifi list data into a Json string and send it to the Hal layer;

[0010] Perform at least a serialization operation on the Json string using the Hal layer to generate sequence data, and filter out SSIDs whose byte length exceeds a preset length in the sequence data;

[0011] At least after the sequence data is filtered, the filtered sequence data is sent to the Carservice layer using the Hal layer, so that the Carservice layer verifies the filtered sequence data;

[0012] At least after the filtered sequence data passes verification, the Carservice layer is used to upload the verified filtered sequence data to an upper layer application, so that the upper layer application is normally started.

[0013] Optionally, the using the Linux layer to read the Wifi list data and composing the Wifi list data into a Json string and sending it to the Hal layer specifically includes:

[0014] Using the Linux layer to read the Wifi list data, and performing format conversion on the data format of the Wifi list data;

[0015] Comparing the character logic consistency of the Wifi list data before format conversion and the Wifi list data after format conversion respectively;

[0016] If the character logic of the Wifi list data before format conversion is inconsistent with that of the Wifi list data after format conversion, the corresponding data is removed from the Wifi list data;

[0017] At least when the character logic of all the Wifi list data before and after the format conversion is consistent after data removal, all the Wifi list data are combined into a Json string and sent to the Hal layer.

[0018] Optionally, the using the Hal layer to perform at least a serialization operation on the Json string to generate sequence data, and filtering SSIDs whose byte length exceeds a preset length in the sequence data, specifically includes:

[0019] Utilizing the Hal layer to perform at least a serialization operation on the Json string to generate sequence data;

[0020] Obtaining all the SSID lengths in the sequence data;

[0021] Determining in turn whether the length of each SSID is greater than a preset length;

[0022] If the length of any of the SSIDs is greater than a preset length, the corresponding SSID is filtered.

[0023] Optionally, at least after the sequence data is verified, the Carservice layer uploads the sequence data to the upper layer application so that the upper layer application starts normally, specifically including:

[0024] At least after the serial data is verified, a deserialization channel is established using the Carservice layer;

[0025] At least performing a deserialization operation on the sequence data using the deserialization channel to generate a corresponding String string;

[0026] Verify each of the String characters at least by a string length threshold;

[0027] The Carservice layer is used to upload each of the verified String characters to the upper layer application so that the upper layer application can be started normally.

[0028] In a second aspect, an embodiment of the present invention further provides a device for processing abnormal data transmission, comprising at least:

[0029] Data upload module, used to upload Wifi list data to upper layer applications through SomeIp layer using T-Box;

[0030] a data sending module, configured to send the Wifi list data to the Linux layer at least through the SomeIp layer using a data interface when the upper layer application receives the Wifi list data;

[0031] A Json composition module is used to read the Wifi list data using the Linux layer, and to compose the Wifi list data into a Json string and send it to the Hal layer;

[0032] a data filtering module, configured to perform at least a serialization operation on the Json string using the Hal layer to generate sequence data, and filter out SSIDs in the sequence data whose byte length exceeds a preset length;

[0033] A filtering and verification module, configured to, after filtering of the sequence data is completed, send the filtered sequence data to the Carservice layer using the Hal layer, so that the Carservice layer verifies the filtered sequence data;

[0034] The upper layer transfer module is used to upload the filtered sequence data that has passed the verification to the upper layer application by using the Carservice layer after the filtered sequence data passes the verification, so that the upper layer application can be normally started.

[0035] Optionally, the Json component module is specifically used to:

[0036] The Linux layer is used to read the Wifi list data and perform format conversion on the data format of the Wifi list data; and, respectively, comparing the logical consistency of characters of the Wifi list data before the format conversion and after the format conversion; and, if the logical consistency of characters of the Wifi list data before the format conversion and after the format conversion is inconsistent, removing the corresponding data from the Wifi list data; and, if, at least after the data is removed, the logical consistency of characters of all the Wifi list data before and after the format conversion is consistent, forming all the Wifi list data into a JSON string and sending it to the Hal layer.

[0037] Optionally, the data filtering module is specifically configured to:

[0038] Utilize the Hal layer to perform at least a serialization operation on the Json string to generate sequence data; and obtain all the SSID lengths in the sequence data; and determine in turn whether the length of each SSID is greater than a preset length; and when the length of any SSID is greater than the preset length, filter the corresponding SSID.

[0039] Optionally, the upper layer transmission module is specifically configured to:

[0040] At least after the sequence data is verified, a deserialization channel is established using the Carservice layer; and at least a deserialization operation is performed on the sequence data using the deserialization channel to generate a corresponding String string; and each of the String strings is verified at least by a string length threshold; and, using the Carservice layer, each of the verified String strings is uploaded to the upper-layer application to enable the upper-layer application to start normally.

[0041] In a third aspect, an embodiment of the present invention further provides an electronic device comprising a processor and a memory, wherein the memory stores computer-readable instructions. When the computer-readable instructions are executed by the processor, the steps in the method for processing data transmission anomalies as described in the first aspect are executed.

[0042] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in the method for processing data transmission anomalies described in the first aspect.

[0043] The technical solution provided by the embodiment of the present invention first uses the T-Box to upload Wifi list data to the upper-layer application through the SomeIp layer; further, at least after the upper-layer application receives the Wifi list data, the Wifi list data is sent to the Linux layer through the SomeIp layer using a data interface; further, the Linux layer is used to read the Wifi list data, and the Wifi list data is composed into a Json string and sent to the Hal layer; further, the Hal layer is used to perform at least a serialization operation on the Json string to generate sequence data, and filter out SSIDs in the sequence data whose byte length exceeds a preset length; further, at least after the sequence data is filtered, the Hal layer is used to send the filtered sequence data to the Carservice layer, so that the Carservice layer verifies the filtered sequence data; finally, at least after the filtered sequence data passes the verification, the Carservice layer is used to upload the verified filtered sequence data to the upper-layer application, so that the upper-layer application can be normally started.

[0044] It can be seen that, on the one hand, the embodiment of the present invention performs a filtering operation on the SSID whose byte length in the sequence data exceeds the preset length before the Hal layer sends the sequence data to the Carservice layer, which helps to improve the situation where the application crashes when receiving SSID data that does not meet the preset length, and reduces the probability of the application crashing; on the other hand, after receiving the sequence data sent by the Hal layer, the Carservice layer of the embodiment of the present invention performs a secondary check on the sequence data, further avoiding the situation where erroneous data is sent to the upper-layer application and causes the upper-layer application to crash, which helps to improve the stability of the application operation and enhance the robustness of the application operation. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the specific embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0046] Figure 1 This is a software component architecture diagram provided by an embodiment of the present invention;

[0047] Figure 2 This is a timing diagram of data transmission provided by an embodiment of the present invention;

[0048] Figure 3 This is a flow chart of a method for processing data transmission anomalies provided by an embodiment of the present invention;

[0049] Figure 4 is a flowchart of another method for processing data transmission anomalies provided by an embodiment of the present invention;

[0050] Figure 5 This is a structural diagram of a device for processing abnormal data transmission provided by an embodiment of the present invention;

[0051] Figure 6 It is a structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0052] To make the objectives, technical solutions, and advantages of this application more clear, this application will be further described in detail below with reference to the accompanying drawings. Obviously, the embodiments described are only some of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making any creative efforts are within the scope of protection of this application.

[0053] The terms used in the examples of this application are for the purpose of describing specific embodiments only and are not intended to limit this application. The singular forms "a," "the," and "the" used in the examples of this application and the appended claims are also intended to include plural forms, and unless the context clearly indicates otherwise, "a plurality" generally includes at least two.

[0054] It should be understood that the term "and / or" as used herein simply describes a relationship between associated objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, or B exists alone. Furthermore, the character " / " in this document generally indicates that the associated objects are in an "or" relationship.

[0055] It should be understood that although the terms first, second, third, etc. may be used to describe in the embodiments of the present application, these descriptions should not be limited to these terms. These terms are only used to distinguish the descriptions. For example, without departing from the scope of the embodiments of the present application, the first may also be referred to as the second, and similarly, the second may also be referred to as the first.

[0056] As used herein, the words "if" and "if" may be interpreted as "at the time of" or "when" or "in response to determining" or "in response to detecting," depending on the context. Similarly, the phrases "if it is determined" or "if (stated condition or event) is detected" may be interpreted as "when it is determined" or "in response to the determination" or "when detecting (stated condition or event)" or "in response to detecting (stated condition or event)," depending on the context.

[0057] It should also be noted that the terms "include," "comprises," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a product or device comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such product or device. In the absence of further limitations, an element defined by the phrase "comprises a..." does not exclude the presence of other identical elements in the product or device comprising the element.

[0058] It should be noted in particular that any symbols and / or numbers in the specification that are not marked in the accompanying drawings are not drawing marks.

[0059] In a practical automotive application, the T-Box is equipped with a mobile communication module, enabling it to connect to the mobile network and provide voice calls and packet data internet access. However, the T-Box itself lacks display and operation capabilities; the vehicle's computer system is required to do so. The T-Box also shares the mobile communication network, allowing other units in the vehicle to access the internet. Mobile network functions between the vehicle and the T-Box primarily involve network information display, voice call control, and packet data forwarding.

[0060] When the T-Box device is properly connected to the vehicle system and the vehicle system successfully connects to the network through the T-Box Internet access mode, the vehicle system obtains relevant T-Box status information through the Ethernet channel and displays the T-Box status in real time in the status bar. The T-Box status includes: operator information, signal strength, and network standard. The notification period for all network information is 5 seconds. After the system starts normally, the T-Box device periodically sends status information to the system via Ethernet based on the system status.

[0061] The vehicle system sets the hotspot information or Wifi mode through remote commands based on the user's operation. The hotspot information can be set in any mode. When Wifi is in hotspot mode, T-Box provides hotspot function, and the in-vehicle infotainmen (IVI) can set the hotspot name and password (the encryption method defaults to: WPA2) of T-Box through remote commands. If a terminal successfully connects to or disconnects from the T-Box's hotspot, T-Box will actively push the connection information once, including the number of hotspots connected, the SSID, Media Access Control (MAC) address, and Internet Protocol (IP) address of each hotspot. When T-Box detects a change in connection information, it will actively send the connected client list to IVI through remote notification. To ensure the synchronization of connection information, if the connection status has not changed, T-Box will actively push the connection information once more than 5 seconds after the last push. The Wifi list format is UTF-8, and the specific requirements are as follows:

[0062] 1. In hotspot mode, the maximum number of connected devices is 8.

[0063] 2. In hotspot mode, you can add devices to the blacklist and remove them from the blacklist. Up to 8 devices can be blacklisted.

[0064] 3. In hotspot mode, the 2.4GHz / 5GHz frequency band switching setting is added, and the default frequency band is 2.4GHz.

[0065] The Personal Hotspot switch is a setup switch. The Personal Hotspot disconnect switch is a click switch. The system sends Personal Hotspot related instructions to the T-Box via the vehicle body network.

[0066] Based on the above basic requirements, the inventor will build a related component architecture to implement specific functions during actual development. Figure 1 This is a software component architecture diagram provided by an embodiment of the present invention, such as Figure 1 As shown:

[0067] System UI: Mainly used to implement interface interaction related to T-Box hotspots in the shortcut panel and status bar.

[0068] Settings APP: Mainly used to implement the setting interface interaction of T-Box hotspot in the system settings.

[0069] Framework module: Android API class, mainly used to manage the OEM-defined T-Box Wifi-related vehicleproperties interface and communicate with the Hal layer through the vehicle properties interface.

[0070] The Hal module is the middle layer for communication between Android and Linux (an operating system). It is primarily responsible for communicating with the Linux layer by sending Bagad messages (set property ID) using the vehicle properties interface and receiving Bagad messages (get property ID) using the OEM-defined vehicle properties interface.

[0071] Native module: Mainly responsible for controlling the built-in chip hotspot and detecting whether the Wi-Fi driver has been loaded successfully. If so, it generates a random SSID, password, and MAC address, and sends the SSID, password, and hotspot activation status to the microcontroller unit (MCU) via Bagad. The hotspot activation status is also sent to the terminal device via the Controller Area Network (CAN) bus. The CAN bus also periodically sends the SSID and password to the device. The terminal device's own Wi-Fi module connects to the vehicle's built-in chip Wi-Fi hotspot in STA mode. If unsuccessful, the Wi-Fi driver is reloaded up to six times. If all six attempts fail, the Wi-Fi hotspot shutdown status is sent to the terminal device. The Wi-Fi driver loading results are sent to DiagApp via Bagad, which then sends them to the MCU-DiagApp via Bagad.

[0072] Linux layer: On the one hand, the Linux layer is responsible for interactive management with the T-Box status module, obtaining / notifying T-Box status-related information through the Scalable Service-Oriented Middleware over IP (SomeIp) protocol. When the T-Box status information is sent to the Android layer via Bagad (tboxsystemstatusready), the Android app can continue to query the status of various T-Box functions. On the other hand, the Linux layer is responsible for communicating and interacting with the T-Box's cellular mobile data network module, setting / obtaining / notifying T-Box's cellular mobile data network-related information through the SomeIp protocol, and sending the relevant information to the Android layer via Bagad, completing the interactive operations of the relevant user interfaces.

[0073] T-Box: interacts as a server and communicates with IVI through the SomeIp protocol interface.

[0074] MCU: Communicates with the vehicle's electronic control units (ECUs) by sending and receiving Bagad messages.

[0075] Based on the above software component architecture, Figure 2 This is a timing diagram of data transmission provided by an embodiment of the present invention. The data transmission timing diagram of the system initially built by the inventor is as follows: Figure 2 As shown:

[0076] 1. T-Box will first send the hotspot / Wifi list data to the SomeIp layer.

[0077] 2. The SomeIp layer passes the obtained list data to the Linux layer.

[0078] 3. The Linux layer converts the data sent by SomeIp into Json format, and then transmits it to the Hal layer after format conversion.

[0079] 4. The Hal layer performs string serialization on the acquired data and sends it to CarSevive through HIDL communication.

[0080] 5. CarSevive passes the serialized string to the upper-level application through the interface for display in the user interface.

[0081] However, in the process of verifying the feasibility of the above-mentioned software component architecture, the inventors discovered that the vehicle system had application crashes (i.e., some switches of the vehicle setting items rebounded, the air conditioning display interface and the right side control buttons failed to work, and the system recovered after simply restarting Android without powering off, etc.). By capturing the vehicle system logs, the inventors found that the reason for the application crash was that the vehicle system received a service set identifier (SSID) with missing characters in the data sent by the T-Box. Therefore, the vehicle system determined that the data was damaged and activated the native Android protection mechanism to stop the current application service, further causing the application to crash. This phenomenon also confirms what was mentioned in the background technology. During the signal interaction between the T-Box and the vehicle system, the vehicle system will set requirements for the data volume of the T-Box transmission signal. When the data volume does not meet the transmission requirements, the vehicle system will activate the protection mechanism to limit the application operation, thereby causing the application to crash.

[0082] After careful research, the inventors discovered that normal hotspot signals use the UTF-8 protocol (a variable-length character encoding for Unicode) to transmit characters. During character transmission, numbers, English characters, and symbols each occupy one character, and Chinese characters occupy three characters, with the total character length not exceeding 32 characters. However, currently, common terminals such as mobile phones and in-vehicle computers do not support SSID names exceeding 32 characters. Therefore, the reason for the in-vehicle application crash is that the external device's SSID itself exceeds 32 characters (i.e., exceeds the protocol limit). Therefore, when transmitting the SSID, the T-Box directly truncates the portion of the string that exceeds 32 characters, compromising the string's data integrity. As a result, the last byte of the data sent by the T-Box to the IVI is incomplete, containing only an identification byte (Chinese characters typically occupy 3 bytes in UTF-8 encoding; the first byte indicates the character length and encoding information, and the subsequent bytes contain code point information). This causes the application to crash.

[0083] In addition, since part of the data in the SSID is cut off, the name of the SSID for data transmission is different from the name of the real SSID, and the WiFi corresponding to the SSID naturally cannot be connected.

[0084] In view of this, the present invention intends to gradually resolve the problem of application crashes as data flows through various system layers, and proposes the following solutions based on the aforementioned software component architecture:

[0085] Figure 3This is a flowchart of a method for processing data transmission anomalies provided by an embodiment of the present invention. This embodiment is at least applicable to scenarios where vehicle data transmission anomalies are processed. The method for processing data transmission anomalies can be, but is not limited to, executed by the data transmission anomaly processing device in the embodiment of the present invention as the execution subject, and the execution subject can be implemented in software and / or hardware. Figure 3 As shown, the method for handling data transmission anomalies includes at least the following steps:

[0086] S1. Use T-Box to upload Wifi list data to the upper layer application through the SomeIp layer.

[0087] The Wifi list data may be a data set including SSID data information of multiple Wifis. The upper layer application may refer to an application located in a cockpit space center (CSC).

[0088] S2. After receiving the Wifi list data, at least the upper layer application sends the Wifi list data to the Linux layer through the SomeIp layer using the data interface.

[0089] The interaction logic between the Android Application and the T-Box can be specifically as follows: when the user clicks the setting operation in the upper-level application, the upper-level Android Application uses vehicle properties (a data structure used to describe vehicle properties) to send an interface (set property ID) and a Bagad message to realize the communication between the upper-level application and the Linux layer. The tboxWifiService of the Linux layer reads the Bagad message and uses the someip_client related protocol to complete the communication with the T-Box.

[0090] The T-Box uses the someip_server protocol to send a corresponding message callback to the Linux layer's tboxWifiService. The tboxWifiService then sends the callback message to the Android application via Bagad. The Hal layer reads the Bagad message and uses the vehicle properties callback interface (get property ID) to return the Bagad message. The Android application uses the getProperty callback interface to receive the Bagad message, thus enabling communication with the Linux layer. The aforementioned vehicle properties delivery interface can be understood as a data interface. The functions corresponding to each protocol or interface are shown in Table 1.

[0091] Table 1

[0092] name Function / Meaning Application System UI, Settings App setProperty Set the attribute value of the vehicle property corresponding to the Bagad ID getProperty Returns the attribute value of the callback vehicle property according to the Bagad ID Bagad ID Bagad message ID bagadCreate Send Bagad message bagadRead Read Bagad messages someip_client Call the Someip protocol client interface someip_server Call the Someip protocol server interface

[0093] S3. Use the Linux layer to read the Wifi list data, and compose the Wifi list data into a Json string and send it to the Hal layer.

[0094] Among them, Json string is a lightweight data exchange format.

[0095] S4. Use the Hal layer to perform at least a serialization operation on the Json string to generate sequence data, and filter out SSIDs whose byte length exceeds a preset length in the sequence data.

[0096] The default length can be 32 bytes. It's understandable that when Android Hal (C++) passes data to CarService (Java), it needs to serialize the data using the data exchange container (Android native plugin Parcel). Serialization refers to the process of converting the state information of the object to be forwarded into a form that can be stored or transmitted (i.e., serialized data).

[0097] S5. At least after the sequence data filtering is completed, the filtered sequence data is sent to the Carservice layer using the Hal layer, so that the Carservice layer verifies the filtered sequence data.

[0098] Among them, the Hal layer and the Carservice layer communicate through HIDL. HIDL (full name: HAL Interface Definition Language) is an interface description language used to specify the interface between HAL and the user. Its specific definition rules are the interface between Android Framework and Android HAL.

[0099] S6. After at least the filtered sequence data passes verification, the Carservice layer is used to upload the verified filtered sequence data to the upper layer application, so that the upper layer application can be started normally.

[0100] The technical solution provided by this embodiment is as follows: first, using the T-Box to upload Wifi list data to the upper-layer application through the SomeIp layer; further, at least after the upper-layer application receives the Wifi list data, the Wifi list data is sent to the Linux layer through the SomeIp layer using a data interface; further, using the Linux layer to read the Wifi list data, and composing the Wifi list data into a JSON string and sending it to the Hal layer; further, using the Hal layer to at least perform a serialization operation on the JSON string to generate sequence data, and filter out SSIDs in the sequence data whose byte length exceeds a preset length; further, at least after the sequence data is filtered, using the Hal layer to send the filtered sequence data to the Carservice layer, so that the Carservice layer verifies the filtered sequence data; finally, at least after the filtered sequence data passes verification, using the Carservice layer to upload the verified filtered sequence data to the upper-layer application, so that the upper-layer application can start normally.

[0101] It can be seen that, on the one hand, this embodiment performs a filtering operation on the SSID whose byte length in the sequence data exceeds the preset length before the Hal layer sends the sequence data to the Carservice layer, which helps to improve the situation where the application crashes when receiving SSID data that does not meet the preset length, and reduces the probability of the application crashing; on the other hand, after receiving the sequence data sent by the Hal layer, the Carservice layer of this embodiment performs a secondary check on the sequence data, further avoiding the situation where erroneous data is sent to the upper-layer application and causes the upper-layer application to crash, which helps to improve the stability of the application operation and enhance the robustness of the application operation.

[0102] Based on the above embodiments or implementation methods, Figure 4 This is a flowchart of another method for processing abnormal data transmission provided by an embodiment of the present invention. This embodiment is supplemented based on the above embodiment. Figure 4 As shown, the method for handling data transmission anomalies includes at least the following steps:

[0103] S1. Use T-Box to upload Wifi list data to the upper layer application through the SomeIp layer.

[0104] S2. After receiving the Wifi list data, at least the upper layer application sends the Wifi list data to the Linux layer through the SomeIp layer using the data interface.

[0105] S31 . Read Wifi list data using the Linux layer, and perform format conversion on the data format of the Wifi list data.

[0106] Among them, performing format conversion on the data format of the Wifi list data can refer to converting the data format of the SSID in the Wifi list data. Normal hotspot signals are transmitted using the UTF-8 protocol. Before the hotspot signal is transmitted, the data encoding format of the SSID needs to be converted to the UTF-8 encoding format. For example, if the SSID is in the String encoding format, then the SSID in the String encoding format needs to be converted to the UTF-8 encoding format.

[0107] S32 : Compare the character logic consistency of the Wifi list data before format conversion and the Wifi list data after format conversion.

[0108] For this example, the conversion of the SSID from String to UTF-8 encoding format is used. The String encoding format corresponds to the Wi-Fi list data before the conversion, while the UTF-8 encoding format corresponds to the Wi-Fi list data after the conversion. It is understood that the conversion process may cause encoding anomalies or errors, so the data after the conversion needs to be verified. For example, if the data length of a piece of data in String encoding format is 1 Byte, but in UTF-8 encoding format, the data length should be 3 Bytes. It is necessary to determine whether the data length after the UTF-8 conversion is 3 Bytes.

[0109] It is understandable that when determining whether the data length after format conversion is correct, it is necessary to first obtain the actual data length in the data packet. It is known that when determining the actual data length, it is necessary to first determine the first byte of the data, and then determine the actual data length based on the first byte. For example, the first byte can be confirmed by the first byte identifier and the consecutive following byte identifiers. In the UTF-8 encoding, the first byte of each encoded character has a specific bit pattern, such as a single-byte character (starting byte is 0), a double-byte character (starting byte is 110), a three-byte character (starting byte is 1110) and a four-byte character (starting byte is 11110), and the following bytes after the first byte must start with 10. After obtaining each first byte identifier of each segment of data, the actual data length in the data can be obtained.

[0110] S33: If the character logic of the Wifi list data before format conversion is inconsistent with that of the Wifi list data after format conversion, the corresponding data is removed from the Wifi list data.

[0111] S34. When at least the character logic of all Wifi list data before and after format conversion is consistent after data removal, all Wifi list data are combined into a Json string and sent to the Hal layer.

[0112] S41. Use the Hal layer to perform at least a serialization operation on the Json string to generate sequence data.

[0113] S42. Obtain the length of all SSIDs in the sequence data.

[0114] S43: Determine in turn whether the length of each SSID is greater than a preset length.

[0115] S44. If the length of any SSID is greater than a preset length, filter the corresponding SSID.

[0116] S5. At least after the sequence data filtering is completed, the filtered sequence data is sent to the Carservice layer using the Hal layer, so that the Carservice layer verifies the filtered sequence data.

[0117] S61. After at least the sequence data is verified, a deserialization channel is established using the Carservice layer.

[0118] The purpose of establishing a deserialization channel is to convert UTF-8 encoded data into String characters to perform secondary verification on the sequence data.

[0119] S62: Perform a deserialization operation on the sequence data using at least a deserialization channel to generate a corresponding String character string.

[0120] S63. Verify each String character string at least by using a character string length threshold.

[0121] When deserializing a UTF-8 encoded format, the required data length (i.e., the string length threshold) is calculated based on the character length byte. If the required data length does not match the actual length, the system will crash. Therefore, a validation operation must be performed on the string to filter out data that does not match the required length.

[0122] S64. Use the Carservice layer to upload each verified String string to the upper-layer application so that the upper-layer application can be started normally.

[0123] The technical solution provided in this embodiment first uses a T-Box to upload Wifi list data to an upper-layer application via the SomeIp layer. Furthermore, at least after receiving the Wifi list data, the upper-layer application sends the Wifi list data to the Linux layer via the SomeIp layer using a data interface. Furthermore, the Linux layer reads the Wifi list data and performs format conversion on the Wifi list data. Furthermore, the character logical consistency of the Wifi list data before and after the format conversion is compared. Furthermore, if the character logical consistency of the Wifi list data before and after the format conversion is inconsistent, the corresponding data is removed from the Wifi list data. Furthermore, at least when the character logical consistency of all Wifi list data before and after the format conversion is consistent after the data is removed, the entire Wifi list data is combined into a JSON string and sent to the Hal layer. Furthermore, the Hal layer performs at least a serialization operation on the JSON string to generate sequence data. Furthermore, the length of all SSIDs within the sequence data is obtained. Furthermore, it is determined in turn whether the length of each SSID is greater than the preset length. Furthermore, if the length of any SSID is greater than the preset length, the corresponding SSID is filtered. Furthermore, at least after the filtering of the sequence data is completed, the Hal layer is used to send the filtered sequence data to the Carservice layer so that the Carservice layer verifies the filtered sequence data. Further, at least after the sequence data verification is passed, a deserialization channel is established using the Carservice layer. Further, at least the deserialization channel is used to perform a deserialization operation on the sequence data to generate a corresponding String string. Further, each String string is verified at least by a string length threshold. Further, each verified String string is uploaded to the upper-layer application using the Carservice layer so that the upper-layer application can be started normally.

[0124] As can be seen, this embodiment, on the one hand, filters SSIDs whose byte length exceeds a preset length in the sequence data before the Hal layer sends it to the Carservice layer. This helps to improve the application's crash when receiving SSID data that does not meet the preset length, reducing the probability of application crashes and improving application stability. On the other hand, after receiving the sequence data sent by the Hal layer, the Carservice layer of this embodiment establishes a deserialization channel to perform a deserialization operation on the sequence data to generate a corresponding String string, and verifies the String string according to the string length threshold to further prevent erroneous data from being sent to the upper-layer application and causing the upper-layer application to crash, thereby improving the robustness of application operation. On the other hand, this embodiment implements progressive cleansing as data flows through each layer of the system. While meeting the Android framework's input data requirements, it also effectively reduces the risk of service crashes triggered by processing abnormal data and the probability of false activation of system-level protection mechanisms, thus ensuring the continuous and reliable operation of core in-vehicle services.

[0125] Figure 5 This is a schematic diagram of the structure of a data transmission anomaly processing device provided by an embodiment of the present invention. This embodiment is at least applicable to the scenario of processing vehicle data transmission anomalies. The data transmission anomaly processing device can be implemented in software and / or hardware. Figure 5 As shown, the data transmission abnormality processing device 100 at least includes:

[0126] The data upload module 110 is used to upload the Wifi list data to the upper layer application through the SomeIp layer using the T-Box;

[0127] The data sending module 120 is used to send the Wifi list data to the Linux layer at least through the SomeIp layer using the data interface when the upper layer application receives the Wifi list data;

[0128] The Json composition module 130 is used to read the Wifi list data using the Linux layer, and compose the Wifi list data into a Json string and send it to the Hal layer;

[0129] The data filtering module 140 is configured to perform at least a serialization operation on the Json string using the Hal layer to generate sequence data, and filter out SSIDs in the sequence data whose byte length exceeds a preset length;

[0130] The filtering and verification module 150 is used to send the filtered sequence data to the Carservice layer using the Hal layer after the sequence data is filtered, so that the Carservice layer can verify the filtered sequence data;

[0131] The upper layer transmission module 160 is used to upload the filtered sequence data that passes the verification to the upper layer application by using the Carservice layer after the filtered sequence data passes the verification, so that the upper layer application can be started normally.

[0132] Optionally, the Json component module 130 is specifically used to:

[0133] Using the Linux layer to read Wifi list data and perform format conversion on the data format of the Wifi list data; and comparing the logical consistency of characters in the Wifi list data before and after the format conversion; and if the logical consistency of characters in the Wifi list data before and after the format conversion is inconsistent, removing the corresponding data from the Wifi list data; and, if at least the logical consistency of characters in all the Wifi list data before and after the format conversion is consistent after the data is removed, constructing all the Wifi list data into a JSON string and sending it to the Hal layer.

[0134] Optionally, the data filtering module 140 is specifically configured to:

[0135] Perform at least a serialization operation on the Json string using the Hal layer to generate sequence data; obtain all SSID lengths in the sequence data; determine in turn whether the length of each SSID is greater than a preset length; and, when the length of any SSID is greater than the preset length, filter the corresponding SSID.

[0136] Optionally, the upper layer transmission module 160 is specifically configured to:

[0137] At least after the sequence data is verified, a deserialization channel is established using the Carservice layer; and, at least, a deserialization operation is performed on the sequence data using the deserialization channel to generate a corresponding String string; and, at least, each String string is verified using a string length threshold; and, using the Carservice layer, each verified String string is uploaded to the upper-layer application to enable the upper-layer application to start normally.

[0138] The technical solution provided by this embodiment is as follows: first, the data upload module uses the T-Box to upload the Wifi list data to the upper-layer application through the SomeIp layer; further, when the upper-layer application receives the Wifi list data, the data delivery module uses the data interface based on the SomeIp layer to deliver the Wifi list data to the Linux layer; further, the Json composition module uses the Linux layer to read the Wifi list data, and composes the Wifi list data into a Json string and sends it to the Hal layer; further, the data filtering module uses the Hal layer to perform a serialization operation on the Json string to generate sequence data, and filters out SSIDs in the sequence data whose byte length exceeds a preset length; further, after the sequence data is filtered, the filter verification module uses the Hal layer to send the filtered sequence data to the Carservice layer, so that the Carservice layer verifies the filtered sequence data; finally, after the filtered sequence data passes the verification, the upper-layer transmission module uses the Carservice layer to upload the verified filtered sequence data to the upper-layer application, so that the upper-layer application can start normally.

[0139] It can be seen that, on the one hand, this embodiment performs a filtering operation on the SSID whose byte length in the sequence data exceeds the preset length before the Hal layer sends the sequence data to the Carservice layer, which helps to improve the situation where the application crashes when receiving SSID data that does not meet the preset length, and reduces the probability of the application crashing; on the other hand, after receiving the sequence data sent by the Hal layer, the Carservice layer of this embodiment performs a secondary check on the sequence data, further avoiding the situation where erroneous data is sent to the upper-layer application and causes the upper-layer application to crash, which helps to improve the stability of the application operation and enhance the robustness of the application operation.

[0140] An embodiment of the present invention further provides an electronic device, Figure 6 This is a schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. Figure 6The electronic device 1000 includes a processor 1001 and a memory 1002. The memory 1002 stores computer-readable instructions. When the computer-readable instructions are executed by the processor 1001, the steps in any of the above methods for handling data transmission anomalies are executed. Through the above technical solution, the processor 1001 and the memory 1002 are interconnected and communicate with each other through a communication bus and / or other forms of connection mechanisms (not marked). The memory 1002 stores a computer program executable by the processor. When the electronic device 1000 is running, the processor 1001 executes the computer program to execute the method for handling data transmission anomalies in any optional implementation of the above embodiment to at least achieve the following functions: using T-Box to upload Wifi list data to the upper-layer application through the SomeIp layer; at least after the upper-layer application receives the Wifi list data, it uses the data interface through the SomeIp layer to send the Wifi list data to the Linux layer; using the Linux layer to read the Wifi list data, and composing the Wifi list data into a Json string and sending it to the Hal layer; using the Hal layer to at least perform a serialization operation on the Json string to generate sequence data, and filter out SSIDs whose byte length in the sequence data exceeds a preset length; at least after the sequence data filtering is completed, using the Hal layer to send the filtered sequence data to the Carservice layer, so that the Carservice layer verifies the filtered sequence data; at least after the filtered sequence data passes the verification, using the Carservice layer to upload the verified filtered sequence data to the upper-layer application, so that the upper-layer application can be started normally.

[0141] An embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a method for handling data transmission anomalies as provided in all embodiments of the invention of the present application: using a T-Box to upload Wifi list data to an upper-layer application through the SomeIp layer; at least after the upper-layer application receives the Wifi list data, sending the Wifi list data to the Linux layer through the SomeIp layer using a data interface; using the Linux layer to read the Wifi list data, and forming the Wifi list data into a JSON string and sending it to the Hal layer; using the Hal layer to perform at least a serialization operation on the JSON string to generate sequence data, and filtering out SSIDs in the sequence data whose byte length exceeds a preset length; at least after the sequence data filtering is completed, using the Hal layer to send the filtered sequence data to the Carservice layer, so that the Carservice layer verifies the filtered sequence data; at least after the filtered sequence data passes the verification, using the Carservice layer to upload the verified filtered sequence data to the upper-layer application, so that the upper-layer application can start normally.

[0142] Any combination of one or more computer-readable media may be employed. A computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more conductors, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0143] A computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal may take a variety of forms, including, but not limited to, electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0144] Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0145] Computer program code for performing the operations of the present invention may be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0146] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for processing data transmission anomalies, characterized in that: At least the following steps are included: Use T-Box to upload Wifi list data to upper layer applications through SomeIp layer; At least after the upper layer application receives the Wifi list data, it sends the Wifi list data to the Linux layer through the SomeIp layer using a data interface; Use the Linux layer to read the Wifi list data, and compose the Wifi list data into a Json string and send it to the Hal layer; Perform at least a serialization operation on the Json string using the Hal layer to generate sequence data, and filter out SSIDs whose byte length exceeds a preset length in the sequence data; At least after the sequence data is filtered, the filtered sequence data is sent to the Carservice layer using the Hal layer, so that the Carservice layer verifies the filtered sequence data; At least after the filtered sequence data passes verification, the Carservice layer is used to upload the verified filtered sequence data to an upper layer application, so that the upper layer application is normally started.

2. The method for processing data transmission anomalies according to claim 1, characterized in that: The method of using the Linux layer to read the Wifi list data and composing the Wifi list data into a Json string and sending it to the Hal layer specifically includes: Using the Linux layer to read the Wifi list data, and performing format conversion on the data format of the Wifi list data; Comparing the character logic consistency of the Wifi list data before format conversion and the Wifi list data after format conversion respectively; If the character logic of the Wifi list data before format conversion is inconsistent with that of the Wifi list data after format conversion, the corresponding data is removed from the Wifi list data; At least when the character logic of all the Wifi list data before and after the format conversion is consistent after data removal, all the Wifi list data are combined into a Json string and sent to the Hal layer.

3. The method for processing data transmission anomalies according to claim 1, wherein: The step of using the Hal layer to perform at least a serialization operation on the Json string to generate sequence data, and filtering out SSIDs in the sequence data whose byte length exceeds a preset length, specifically includes: Utilizing the Hal layer to perform at least a serialization operation on the Json string to generate sequence data; Obtaining all the SSID lengths in the sequence data; Determining in turn whether the length of each SSID is greater than a preset length; If the length of any of the SSIDs is greater than a preset length, the corresponding SSID is filtered.

4. The method for processing data transmission anomalies according to claim 1, wherein: At least after the sequence data is verified, the Carservice layer uploads the sequence data to the upper layer application so that the upper layer application can be started normally, specifically including: At least after the serial data is verified, a deserialization channel is established using the Carservice layer; At least performing a deserialization operation on the sequence data using the deserialization channel to generate a corresponding String string; Verify each of the String characters at least by a string length threshold; The Carservice layer is used to upload each of the verified String characters to the upper layer application so that the upper layer application can be started normally.

5. A device for processing abnormal data transmission, characterized in that: At least: Data upload module, used to upload Wifi list data to upper layer applications through SomeIp layer using T-Box; a data sending module, configured to send the Wifi list data to the Linux layer at least through the SomeIp layer using a data interface when the upper layer application receives the Wifi list data; A Json composition module is used to read the Wifi list data using the Linux layer, and to compose the Wifi list data into a Json string and send it to the Hal layer; a data filtering module, configured to perform at least a serialization operation on the Json string using the Hal layer to generate sequence data, and filter out SSIDs in the sequence data whose byte length exceeds a preset length; A filtering and verification module, configured to, after filtering of the sequence data is completed, send the filtered sequence data to the Carservice layer using the Hal layer, so that the Carservice layer verifies the filtered sequence data; The upper layer transfer module is used to upload the filtered sequence data that has passed the verification to the upper layer application by using the Carservice layer after the filtered sequence data passes the verification, so that the upper layer application can be normally started.

6. The device for processing data transmission anomalies according to claim 5, characterized in that: The Json component module is specifically used for: Using the Linux layer to read the Wifi list data, and performing format conversion on the data format of the Wifi list data; Furthermore, the character logic consistency of the Wifi list data before format conversion and the Wifi list data after format conversion are compared; and when the character logic of the Wifi list data before format conversion and the Wifi list data after format conversion are inconsistent, the corresponding data is removed from the Wifi list data; and when at least the character logic of all the Wifi list data before and after format conversion after the data is removed is consistent, all the Wifi list data is combined into a JSON string and sent to the Hal layer.

7. The device for processing data transmission anomalies according to claim 5, characterized in that: The data filtering module is specifically used to: Utilize the Hal layer to perform at least a serialization operation on the Json string to generate sequence data; and obtain all the SSID lengths in the sequence data; and determine in turn whether the length of each SSID is greater than a preset length; and when the length of any SSID is greater than the preset length, filter the corresponding SSID.

8. The device for processing data transmission anomalies according to claim 5, characterized in that: The upper layer transmission module is specifically used to: At least after the sequence data passes verification, establish a deserialization channel using the Carservice layer; and at least perform a deserialization operation on the sequence data using the deserialization channel to generate a corresponding String string; and verifying each of the String characters at least by a character string length threshold; and uploading each of the verified String characters to the upper layer application by using the Carservice layer, so that the upper layer application can be started normally.

9. An electronic device, characterized in that: The method comprises a processor and a memory, wherein the memory stores computer-readable instructions. When the computer-readable instructions are executed by the processor, the steps of the method for processing data transmission anomalies according to any one of claims 1 to 4 are executed.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method for processing data transmission anomalies according to any one of claims 1 to 4 is implemented.

Images