Vehicle-mounted optical communication system, method, device and vehicle

Abstract

Embodiments of the present application provide a kind of vehicle-mounted optical communication system, method, device and vehicle.The method comprises: for each cabin area ODN, the optical power margin of cabin area uplink, error rate margin and time delay margin are acquired.Then according to optical power margin, error rate margin and time delay margin, the health degree of cabin area uplink is determined.If the health degree of cabin area uplink is lower than preset health degree threshold, then the cabin area service data borne by cabin area uplink is re-routed to adjacent cabin area ODN via backup optical fiber, so that adjacent cabin area ODN uplink cabin area service data to cabin area optical line terminal OLT.The method is used to achieve the effect of improving the reliability and continuity of cabin area service transmission.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to an in-vehicle optical communication system, method, device and vehicle. Background Technology

[0002] The next-generation vehicle electrical / electronic (E / E) architecture is rapidly evolving towards a domain-centralized approach, and generally adopts a deployment architecture with two independent computing platforms: an intelligent driving computing platform and a cockpit computing platform.

[0003] To support the efficient and reliable transmission of the aforementioned dual-domain services, a star-shaped fiber optic Ethernet network is generally constructed in the vehicle's E / E architecture, with a main switch as the center and several regional switches as access points. Each regional switch aggregates the sensor and actuator devices in its local area, and then they are all converged to the main switch for centralized processing.

[0004] However, a pure tree topology reduces the reliability and continuity of cabin domain service transmission when the cabin domain uplink between the cabin domain optical distribution network (ODN) and the cabin domain optical line terminal (OLT) fails. Summary of the Invention

[0005] This application provides vehicle-mounted optical communication systems, methods, apparatus, and vehicles to achieve the technical effect of improving the reliability and continuity of cockpit domain service transmission.

[0006] In a first aspect, embodiments of this application provide a vehicle-mounted optical communication system, including:

[0007] Intelligent driving domain optical line terminal (OLT), cockpit domain OLT, cockpit domain ODN with cockpit domain terminal access, and intelligent driving domain ODN with intelligent driving domain terminal access;

[0008] The cockpit domain ODN is connected to the cockpit domain OLT to form the cockpit domain uplink; the intelligent driving domain ODN is connected to the intelligent driving domain OLT to form the intelligent driving domain uplink.

[0009] Backup optical fibers are laid between adjacent cabin domain ODNs, forming a closed backup loop.

[0010] Secondly, embodiments of this application provide a vehicle-mounted communication method, applied to a vehicle equipped with the vehicle-mounted optical communication system as described in the first aspect above, the method comprising:

[0011] For each cabin domain ODN, obtain the optical power margin, bit error rate margin, and latency margin of the cabin domain uplink;

[0012] The health of the cockpit domain uplink is determined based on the optical power margin, the bit error rate margin, and the delay margin.

[0013] If the health of the cockpit domain uplink is lower than a preset health threshold, the cockpit domain service data carried by the cockpit domain uplink will be rerouted to the adjacent cockpit domain ODN via a backup fiber, so that the adjacent cockpit domain ODN will uplink the cockpit domain service data to the cockpit domain OLT.

[0014] In one possible implementation, obtaining the optical power margin of the cockpit domain uplink includes:

[0015] Obtain the received optical power and receiving sensitivity of the cockpit domain OLT in the cockpit domain uplink;

[0016] The optical power margin is determined based on the received optical power and the received sensitivity.

[0017] In one possible implementation, obtaining the bit error rate margin of the cockpit domain uplink includes:

[0018] Obtain the measured bit error rate of the cockpit domain uplink and the bit error rate threshold corresponding to the cockpit domain service data;

[0019] The bit error rate margin is determined based on the bit error rate threshold and the measured bit error rate.

[0020] In one possible implementation, obtaining the latency margin of the cockpit domain uplink includes:

[0021] Obtain the actual uplink latency of the cockpit domain and the latency budget window corresponding to the cockpit domain service data;

[0022] The latency margin is determined based on the actual latency and the latency budget window.

[0023] In one possible implementation, determining the health of the cockpit domain uplink based on the optical power margin, the bit error rate margin, and the delay margin includes:

[0024] The health score is determined by multiplying the optical power margin, the bit error rate margin, and the delay margin.

[0025] In one possible implementation, the step of rerouting the cockpit domain service data carried by the cockpit domain uplink to an adjacent cockpit domain ODN via a backup fiber optic cable if the health of the cockpit domain uplink is lower than a preset health threshold includes:

[0026] The health of the uplink in the cockpit domain is calculated by a sliding average over a preset time window to obtain the average health value for each preset time window.

[0027] If the average health value of a preset number of preset time windows is lower than the preset health threshold, the cockpit domain service data carried by the cockpit domain uplink will be rerouted to the adjacent cockpit domain ODN via a backup fiber.

[0028] In one possible implementation, before obtaining the optical power margin, bit error rate margin, and delay margin of the cabin domain uplink for each cabin domain ODN, the method further includes:

[0029] Based on the deployment location of each vehicle-mounted terminal in the vehicle, multiple initial ODN deployment schemes are determined. Each initial ODN deployment scheme is used to represent the connection relationship between each ODN and the vehicle-mounted terminal, wherein the vehicle-mounted terminal belongs to the cockpit domain terminal or the intelligent driving domain terminal.

[0030] Based on the total cabling length, bandwidth utilization, and the maximum service bandwidth affected by a single ODN failure, a target ODN deployment scheme is determined from the multiple initial ODN deployment schemes.

[0031] According to the target ODN deployment scheme, a cockpit domain ODN that connects to the cockpit domain terminal and an intelligent driving domain ODN that connects to the intelligent driving domain terminal are deployed to form the vehicle-mounted optical communication system.

[0032] Thirdly, embodiments of this application provide a vehicle-mounted communication device, applied to a vehicle equipped with the vehicle-mounted optical communication system as described in the first aspect, the device comprising:

[0033] The acquisition module is used to acquire the optical power margin, bit error rate margin, and latency margin of the uplink of each cabin domain ODN.

[0034] The determination module is used to determine the health of the cockpit domain uplink based on the optical power margin, the bit error rate margin, and the delay margin.

[0035] The rerouting module is used to reroute the cockpit domain service data carried by the cockpit domain uplink to the adjacent cockpit domain ODN via the backup fiber if the health of the cockpit domain uplink is lower than a preset health threshold, so that the adjacent cockpit domain ODN will uplink the cockpit domain service data to the cockpit domain OLT.

[0036] In one possible implementation, the acquisition module is specifically used for:

[0037] Obtain the received optical power and receiving sensitivity of the cockpit domain OLT in the cockpit domain uplink;

[0038] The optical power margin is determined based on the received optical power and the received sensitivity.

[0039] In one possible implementation, the acquisition module is specifically used for:

[0040] Obtain the measured bit error rate of the cockpit domain uplink and the bit error rate threshold corresponding to the cockpit domain service data;

[0041] The bit error rate margin is determined based on the bit error rate threshold and the measured bit error rate.

[0042] In one possible implementation, the acquisition module is specifically used for:

[0043] Obtain the actual uplink latency of the cockpit domain and the latency budget window corresponding to the cockpit domain service data;

[0044] The latency margin is determined based on the actual latency and the latency budget window.

[0045] In one possible implementation, the determining module is specifically used for:

[0046] The health score is determined by multiplying the optical power margin, the bit error rate margin, and the delay margin.

[0047] In one possible implementation, the rerouting module is specifically used for:

[0048] The health of the uplink in the cockpit domain is calculated by a sliding average over a preset time window to obtain the average health value for each preset time window.

[0049] If the average health value of a preset number of preset time windows is lower than the preset health threshold, the cockpit domain service data carried by the cockpit domain uplink will be rerouted to the adjacent cockpit domain ODN via a backup fiber.

[0050] In one possible implementation, the in-vehicle communication device includes a deployment module that, before acquiring the optical power margin, bit error rate margin, and latency margin of the cockpit domain uplink for each cockpit domain ODN, is configured to:

[0051] Based on the deployment location of each vehicle-mounted terminal in the vehicle, multiple initial ODN deployment schemes are determined. Each initial ODN deployment scheme is used to represent the connection relationship between each ODN and the vehicle-mounted terminal, wherein the vehicle-mounted terminal belongs to the cockpit domain terminal or the intelligent driving domain terminal.

[0052] Based on the total cabling length, bandwidth utilization, and the maximum service bandwidth affected by a single ODN failure, a target ODN deployment scheme is determined from the multiple initial ODN deployment schemes.

[0053] According to the target ODN deployment scheme, a cockpit domain ODN that connects to the cockpit domain terminal and an intelligent driving domain ODN that connects to the intelligent driving domain terminal are deployed to form the vehicle-mounted optical communication system.

[0054] Fourthly, embodiments of this application provide a vehicle, including:

[0055] Memory, processor, and vehicle-mounted optical communication system as described in the first aspect;

[0056] The memory stores computer-executed instructions;

[0057] The processor executes computer execution instructions stored in the memory, causing the processor to perform the second aspect and / or various possible implementations of the second aspect as described above.

[0058] Fifthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the second aspect and / or various possible implementations of the second aspect as described above.

[0059] Sixthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the second aspect and / or various possible implementations of the second aspect as described above.

[0060] The vehicle-mounted optical communication system, method, apparatus, and vehicle provided in this application collect three core parameters—optical power margin, bit error rate margin, and latency margin—of the cockpit domain uplink to comprehensively calculate the health of the cockpit domain uplink. This allows for a comprehensive and accurate assessment of the actual operating status and performance margin of the cockpit domain uplink, avoiding the bias of relying on a single indicator. When the health falls below a preset health threshold, service rerouting is triggered. This allows for early identification of performance degradation before a complete interruption of the cockpit domain uplink, switching cockpit domain service data via backup fiber to an adjacent cockpit domain ODN to complete the uplink. This enables early fault prediction and seamless switching, effectively reducing the impact of link failures on cockpit services and significantly improving the reliability and continuity of cockpit domain service transmission. Attached Figure Description

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

[0062] Figure 1Schematic diagram of the vehicle-mounted optical communication system provided in this application Figure 1 ;

[0063] Figure 2 Schematic diagram of the vehicle-mounted optical communication system provided in this application Figure 2 ;

[0064] Figure 3 Flowchart of the vehicle communication method provided in this application Figure 1 ;

[0065] Figure 4 Flowchart of the vehicle communication method provided in this application Figure 2 ;

[0066] Figure 5 Flowchart of the vehicle communication method provided in this application Figure 3 ;

[0067] Figure 6 A schematic diagram illustrating the rerouting judgment principle in the vehicle communication method provided in this application;

[0068] Figure 7 A schematic diagram of the closed-loop state flow of the cockpit domain uplink in the vehicle communication method provided in this application;

[0069] Figure 8 A schematic diagram of the vehicle-mounted communication device provided in this application;

[0070] Figure 9 A structural schematic diagram of the vehicle provided in this application.

[0071] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0072] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application.

[0073] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0074] First, the application scenarios involved in this application will be explained:

[0075] The next-generation E / E architecture is rapidly evolving towards a domain-centralized approach, generally adopting a deployment architecture with two independent computing platforms: an intelligent driving computing platform and a cockpit computing platform. Under this architecture, the vehicle optical communication backbone needs to simultaneously carry two distinct categories of business data within a vehicle wiring harness space of tens to twenty meters: one is intelligent driving domain perception data, including massive amounts of real-time data generated by sensors such as front-view cameras, surround-view cameras, millimeter-wave radar, and lidar; the other is cockpit domain display data, including high-definition video and multimedia data from multi-screen interactive devices such as the central control screen, instrument panel, passenger screen, and ceiling-mounted screen.

[0076] To support the efficient and reliable transmission of the aforementioned dual-domain services, the industry typically builds an in-vehicle communication architecture based on passive optical networks. The in-vehicle communication backbone is composed of an OLT and multiple ODNs, enabling unified access and data interaction for different types of in-vehicle terminals such as cameras, radars, and displays.

[0077] Current automotive optical communication engineering practices commonly employ a single, pure tree topology architecture. A typical implementation involves a star-shaped fiber optic Ethernet network with a main switch at the center and several regional switches as access points within the vehicle's E / E architecture. Each regional switch aggregates sensors and actuators within its local area, which are then converged to the main switch for centralized processing. This pure tree topology is simple to deploy and has low implementation costs, making it the mainstream solution for current automotive optical communication.

[0078] However, the pure tree topology adopts a single-link direct connection architecture. When a single uplink or a single optical distribution network node fails, all cockpit display services connected to it will be directly interrupted, which will cause the display functions of terminals such as the central control screen, instrument screen, and passenger screen to fail, disrupting the continuity of multi-screen interaction and seriously reducing the reliability of driving experience and information interaction.

[0079] Based on the aforementioned technical problems, the technical concept of this application is as follows: During the research of in-vehicle optical communication solutions, the inventors discovered significant differences in the core transmission requirements of the intelligent driving domain and the cockpit domain: the intelligent driving domain has extremely high requirements for latency determinism, and the existing pure tree-structured single-link direct-connection architecture has few hops and short paths, which can meet the transmission needs of the intelligent driving domain's perception data; however, the cockpit domain has higher requirements for single-point failure tolerance. In a pure tree-structured architecture, when a single uplink or a single optical distribution network node fails, all cockpit display services accessed by it will be directly interrupted, leading to the failure of each display terminal's functions and disrupting the continuity of multi-screen interaction. Therefore, the inventors considered, while retaining the original tree-structured architecture of the intelligent driving domain and without increasing its transmission hop count, supplementing the cockpit domain with a backup design: laying backup optical fibers between adjacent cockpit domain ODNs, forming a closed backup loop, with the cockpit domain ODN serving as the ODN accessing the cockpit domain terminals. When the uplink of the cockpit domain corresponding to the cockpit domain ODN fails or its performance degrades, the cockpit domain service data is rerouted to the adjacent cockpit domain ODN via the backup fiber to complete the uplink. This solves the single point of failure problem in the cockpit domain without affecting the performance of the intelligent driving domain, thereby improving the reliability of the driving experience and information interaction.

[0080] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0081] Figure 1 Schematic diagram of the vehicle-mounted optical communication system provided in this application Figure 1 ,like Figure 1 As shown, the vehicle-mounted optical communication system 10 includes:

[0082] Intelligent Driving Domain OLT101, Cockpit Domain OLT102, Cockpit Domain ODN103 with connected cockpit domain terminals, and Intelligent Driving Domain ODN104 with connected intelligent driving domain terminals.

[0083] Among them, the cockpit domain terminal refers to the in-vehicle terminal equipment deployed inside the vehicle cabin, providing human-computer interaction, multimedia entertainment, and vehicle information display functions for drivers and passengers. Examples include the central control screen, the full LCD instrument panel, the passenger entertainment screen, the rear ceiling-mounted screen, and the in-vehicle audio interaction terminal.

[0084] Optionally, each cockpit domain ODN103 can simultaneously access one or more cockpit domain terminals. This application embodiment does not limit the number of cockpit domain terminals accessed by each cockpit domain ODN103.

[0085] Optionally, the vehicle-mounted optical communication system 10 may include one or more cabin domains ODN 103. This application embodiment does not limit the total number of cabin domains ODN 103.

[0086] Optionally, the cockpit domain ODN103 is typically deployed in distributed area nodes around the vehicle's cockpit (such as on both sides of the center console, A-pillars, B-pillars, and the sides of the roof) to connect to the cockpit domain terminal nearby, thus shortening the wiring length on the terminal side.

[0087] Among them, intelligent driving domain terminals refer to in-vehicle sensing terminal devices that serve autonomous driving functions and are used for environmental perception and driving status collection. Examples include forward-looking cameras, surround-view cameras, millimeter-wave radar, lidar, and ultrasonic radar.

[0088] Optionally, each intelligent driving domain ODN104 can simultaneously access one or more intelligent driving domain terminals. This application embodiment does not limit the number of intelligent driving domain terminals accessed by each intelligent driving domain ODN104.

[0089] Optionally, the vehicle-mounted optical communication system 10 may include one or more intelligent driving domains ODN 104. This application embodiment does not limit the total number of intelligent driving domains ODN 104.

[0090] Optionally, the intelligent driving domain ODN104 is typically deployed in the peripheral area where the intelligent driving domain terminals of the vehicle are concentrated (such as the front grille, rear bumper, and side fenders) to ensure that the transmission path from the intelligent driving domain terminal to the intelligent driving domain OLT101 is the shortest and has the fewest hops.

[0091] It is important to understand that if an ODN is connected to both a cockpit domain terminal and an intelligent driving domain terminal, then that ODN belongs to both the cockpit domain ODN103 and the intelligent driving domain ODN104.

[0092] The cockpit domain ODN103 is connected to the cockpit domain OLT102, forming the cockpit domain uplink. It can be understood that the cockpit domain uplink carries cockpit domain service data such as display, interaction, entertainment, and control feedback.

[0093] Among them, the Intelligent Driving Domain ODN104 and the Intelligent Driving Domain OLT101 are connected to form the Intelligent Driving Domain uplink. The Intelligent Driving Domain uplink carries Intelligent Driving Domain business data such as raw image data, point cloud data, driving status data, and intelligent driving control commands.

[0094] Optionally, the Intelligent Driving Domain ODN104 and Intelligent Driving Domain OLT101 adopt a tree-shaped single-hop direct connection architecture without additional backup fiber optic cables to ensure the deterministic transmission latency of Intelligent Driving Domain services.

[0095] It should be understood that OLT optical modules are configured one-to-one between the cabin domain ODN103 and the cabin domain OLT102, and between the intelligent driving domain ODN104 and the intelligent driving domain OLT101.

[0096] Understandably, the cockpit domain OLT102 includes a cockpit PON module and its corresponding OLT optical module, while the intelligent driving domain OLT101 includes an intelligent driving PON module and its corresponding OLT optical module. The PON module is responsible for scheduling, processing, and photoelectric conversion of service data within its corresponding domain, and is the core functional unit for the OLT to implement passive optical network management. To ensure physical isolation and independent scheduling of services in both domains, the intelligent driving PON module and the cockpit PON module do not share scheduling queues or uplink ports within the OLT.

[0097] Among them, backup optical fibers are laid between adjacent cabin domain ODN103, forming a backup loop that is closed at both ends. This loop is used to provide a detour transmission path for cabin domain service data when a single cabin domain uplink fails or its performance deteriorates, ensuring the continuity of cabin domain service transmission.

[0098] Each cabin domain ODN103 in the backup ring maintains adjacent ODN identifiers, ring port status, and a no-loopback flag. When cabin domain service data arrives at an adjacent cabin domain ODN103 via the backup fiber, the adjacent cabin domain ODN103 determines whether the service data has already been forwarded by other adjacent cabin domain ODN103s based on the no-loopback flag, preventing the same cabin domain service data from being repeatedly forwarded within the backup ring.

[0099] Optionally, the backup fiber does not carry services under normal circumstances. The OLT scheduler sends LinkTrace frames at a period of no more than 500 milliseconds to maintain and monitor the health status of its link, ensuring that the backup fiber is available when rerouting is required.

[0100] The vehicle-mounted optical communication system provided in this application includes an intelligent driving domain optical line terminal (OLT), a cockpit domain OLT, a cockpit domain ODN with access to the cockpit domain terminal, and an intelligent driving domain ODN with access to the intelligent driving domain terminal. The cockpit domain ODN is connected to the cockpit domain OLT, forming a cockpit domain uplink; the intelligent driving domain ODN is also connected to the intelligent driving domain OLT, forming an intelligent driving domain uplink; backup optical fibers are laid between adjacent cockpit domain ODNs, forming a closed backup loop. In this technical solution, the intelligent driving domain uplink adopts a tree-shaped direct connection architecture, which can ensure that the intelligent driving domain perception data is transmitted with the fewest hops, meeting its latency deterministic requirements; at the same time, backup optical fibers are laid only between adjacent cockpit domain ODNs to form a backup loop, eliminating the need to add backup optical fibers to the entire link, thus providing a detour transmission channel when a single cockpit domain uplink fails, effectively improving the fault tolerance capability of cockpit domain services. This solution addresses the single point of failure issue in the cockpit domain without increasing the transmission overhead of the intelligent driving domain, balancing dual-domain performance requirements with cabling cost control.

[0101] Optionally, in addition to the cockpit domain OLT and the intelligent driving domain OLT, a passive optical network (PON) module and a corresponding connected domain OLT can be added to carry vehicle-to-cloud communication and over-the-air (OTA) upgrade services, forming a physically isolated vehicle optical communication system encompassing the intelligent driving domain, cockpit domain, and connected domain. Under this extended architecture, the comprehensive evaluation calculation of the ODN deployment scheme, the cockpit domain uplink health assessment, and the service rerouting steps involved in subsequent embodiments are all applicable. Only the relevant service and link parameters of the extended connected domain need to be included in the initial ODN deployment scheme generation and health assessment dimensions.

[0102] Figure 2 Schematic diagram of the vehicle-mounted optical communication system provided in this application Figure 2 ,like Figure 2 As shown, the vehicle-mounted optical communication system has a total of 4 ODN nodes, which are distributed along the vehicle body. Each ODN can simultaneously access terminal devices in different domains.

[0103] ODN1 is deployed in the front left area of ​​the vehicle and belongs to both the cockpit domain ODN and the intelligent driving domain ODN. The intelligent driving domain terminals connected to ODN1 include two forward-facing cameras and two millimeter-wave radars, with each forward-facing camera having a transmission bandwidth of 6Gbps and each millimeter-wave radar having a transmission bandwidth of 0.4Gbps. The cockpit domain terminal connected to ODN1 is the central control screen, with a transmission bandwidth of 4Gbps. ODN1 connects to the corresponding optical module A1 of the intelligent driving domain OLT, forming the intelligent driving domain uplink; ODN1 also connects to the corresponding optical module C1 of the cockpit domain OLT, forming the cockpit domain uplink.

[0104] ODN2 is deployed in the front-center area of ​​the vehicle, belonging to both the cockpit domain ODN and the intelligent driving domain ODN. The intelligent driving domain terminals connected to ODN2 include one LiDAR and two surround-view cameras, with each LiDAR and surround-view camera having a transmission bandwidth of 2Gbps. The cockpit domain terminal connected to ODN2 is the instrument panel, with a transmission bandwidth of 1.5Gbps. ODN2 connects to the corresponding optical module A2 of the intelligent driving domain OLT, forming the intelligent driving domain uplink; ODN2 also connects to the corresponding optical module C2 of the cockpit domain OLT, forming the cockpit domain uplink.

[0105] ODN3 is deployed in the right rear area of ​​the vehicle and belongs to both the cockpit domain ODN and the intelligent driving domain ODN. The intelligent driving domain terminals connected to ODN3 include two surround-view cameras and two millimeter-wave radars, with each surround-view camera having a transmission bandwidth of 2Gbps and each millimeter-wave radar having a transmission bandwidth of 0.4Gbps. The cockpit domain terminal connected to ODN3 is the passenger-side screen, with a transmission bandwidth of 3Gbps. ODN3 connects to the corresponding optical module A3 of the intelligent driving domain OLT, forming the intelligent driving domain uplink; ODN3 also connects to the corresponding optical module C3 of the cockpit domain OLT, forming the cockpit domain uplink.

[0106] ODN4 is deployed in the rear area of ​​the vehicle and belongs to the cockpit domain ODN. The cockpit domain terminal connected to ODN4 is a ceiling-mounted screen, with a transmission bandwidth of 3Gbps. ODN4 is connected to the corresponding optical module C4 of the cockpit domain OLT to form the cockpit domain uplink.

[0107] Optionally, a backup ring is formed in the order of ODN1→ODN2→ODN3→ODN4→ODN1, and backup optical fibers are laid between adjacent ODNs.

[0108] The intelligent driving computing platform integrates an intelligent driving domain OLT optical module group, an intelligent driving PON module, and an intelligent driving SOC. A1-A3 belong to the intelligent driving domain OLT optical module group. The intelligent driving domain OLT optical module group also includes A4, which is a hot-standby optical module. When an optical module detects a fault (such as abnormal output power or photoelectric conversion failure), the OLT scheduler switches the corresponding ODN uplink from the faulty optical module to the hot-standby optical module. The hot-standby optical module then takes over the reception and photoelectric conversion of the optical signal, with a handover time of no more than 50ms.

[0109] The cockpit computing platform integrates a cockpit domain OLT optical module group, a cockpit PON module, and a cockpit SOC. C1-C4 mentioned above belong to the cockpit domain OLT optical module group.

[0110] In this embodiment, the intelligent driving domain maintains a one-to-one tree-structured single-hop link between the ODN and the OLT to prioritize latency determinism; the cockpit domain constructs a backup ring to exchange single-point fault tolerance capability for minimal additional transmission cost, thereby achieving differentiated matching of dual-domain transmission requirements.

[0111] Figure 3 Flowchart of the vehicle communication method provided in this application Figure 1 ,like Figure 3 As shown, the method includes:

[0112] S31. For each cabin domain ODN, obtain the optical power margin, bit error rate margin, and delay margin of the cabin domain uplink.

[0113] The optical power margin is used to characterize the received optical power margin of the uplink in the cockpit domain under the current operating state.

[0114] In one possible implementation, the received optical power and receiving sensitivity of the cabin domain OLT in the cabin domain uplink can be obtained, and then the optical power margin can be determined based on the received optical power and receiving sensitivity.

[0115] Specifically, the OLT scheduler collects the received optical power and receiving sensitivity of the uplink in the cockpit domain at a preset period (e.g., 1 second). The received optical power refers to the received optical power measured at the OLT end of the uplink in the cockpit domain, and the receiving sensitivity refers to the optical power value of the uplink in the cockpit domain measured at the OLT end.

[0116] Furthermore, the difference between the received optical power and the received sensitivity is calculated, then the absolute value of the received sensitivity is calculated, and finally the difference is divided by the absolute value of the received sensitivity to determine the optical power margin.

[0117] The above implementation method can accurately capture power reduction issues caused by increased uplink optical attenuation in the cockpit domain, loose connectors, and bent optical fibers, providing accurate and reliable power dimension data support for the health assessment of the cockpit domain uplink. This ensures that the health assessment can truly reflect the optical layer transmission status of the link and provides accurate parameter basis for subsequent rerouting decisions.

[0118] Among them, the bit error rate margin is used to characterize the remaining space between the link bit error performance and the service's allowed upper limit.

[0119] In one possible implementation, the measured bit error rate (BER) of the cockpit domain uplink and the BER threshold corresponding to the cockpit domain service data can be obtained. Then, the BER margin is determined based on the BER threshold and the measured BER.

[0120] Specifically, the OLT scheduler collects the measured bit error rate of the uplink in the cockpit domain at a preset period (e.g., 1 second). The measured bit error rate is the ratio of the number of erroneous bits to the total number of transmitted bits during the uplink transmission in the cockpit domain.

[0121] For example, the bit error rate threshold is 1×10⁻¹², 2×10⁻¹², 3×10⁻¹², etc., which can be preset based on empirical or experimental values. This application embodiment does not impose specific restrictions on this.

[0122] It is understood that different cockpit domain service levels correspond to different bit error rate thresholds, that is, different cockpit domain service data correspond to different bit error rate thresholds. The correspondence can be established in advance based on experimental data or obtained from other devices. This application embodiment does not impose specific restrictions on this.

[0123] In practical applications, the higher the service level of the cockpit domain, the more important it is, and the lower the corresponding bit error rate threshold. In other words, the bit error rate threshold is negatively correlated with the service level of the cockpit domain.

[0124] Specifically, the ratio of the bit error rate threshold to the measured bit error rate is calculated. Then, the logarithm of this ratio is taken to the base 10. Finally, the logarithm is divided by 3 to obtain the bit error rate margin.

[0125] Among them, the latency margin is used to characterize the remaining space between the actual latency of the link and the upper limit of the latency requirement of the cabin domain services.

[0126] The above implementation method can adapt to the differentiated bit error rate requirements corresponding to different cockpit domain service data, issue early warnings before the measured bit error rate exceeds the service tolerance limit, provide data basis for transmission quality dimension for health assessment, and effectively ensure the transmission accuracy of cockpit domain service data.

[0127] In one possible implementation, the actual uplink latency in the cockpit domain and the latency budget window corresponding to the cockpit domain service data can be obtained. Then, the latency margin is determined based on the actual latency and the latency budget window.

[0128] Specifically, the OLT scheduler collects the actual uplink latency of the cockpit domain at a preset period (e.g., 1 second). The actual latency refers to the measured end-to-end latency of the cockpit domain uplink from the ODN to the cockpit domain OLT.

[0129] For example, the latency budget window is 30ms, 33ms, 34ms, etc., which can be preset based on empirical or experimental values. This application embodiment does not impose specific limitations on this.

[0130] It is understood that different cockpit domain service levels correspond to different latency budget windows, that is, different cockpit domain service data correspond to different latency budget windows. The correspondence can be established in advance based on experimental data or obtained from other devices. This application embodiment does not impose specific restrictions on this.

[0131] In practical applications, the higher the cockpit domain service level, the more important it is, and the smaller the corresponding latency budget window. In other words, the latency budget window is negatively correlated with the cockpit domain service level.

[0132] Furthermore, the difference between the delay budget window and the actual delay is calculated, and then the difference is divided by the delay budget window to determine the delay margin.

[0133] Optionally, this solution can be deployed in conjunction with other physical layer optimization solutions in the same series, such as PAM-4 adaptive equalization and dynamic FEC switching. When deployed in conjunction with these solutions, the measured end-to-end latency used for latency margin calculation can be directly taken as the measured end-to-end latency of the link after dynamic FEC adjustment, ensuring that the latency margin can accurately reflect the actual link latency level after physical layer optimization.

[0134] The above implementation method can adapt to the differentiated latency requirements corresponding to different cockpit domain service data, promptly detect the risk of excessive link latency, especially adapt to the latency-sensitive characteristics of high-definition video and real-time interactive cockpit services, provide data basis for latency performance dimension for health assessment, and effectively ensure the real-time interactive experience and transmission smoothness of cockpit domain services.

[0135] S32. Determine the health of the cockpit domain uplink based on the optical power margin, bit error rate margin, and delay margin.

[0136] Among them, health is an evaluation index that comprehensively reflects the overall availability of the uplink in the cockpit domain.

[0137] In one possible implementation, the health score is determined by multiplying the optical power margin, bit error rate margin, and delay margin.

[0138] This calculation method is highly sensitive to performance bottlenecks in the cockpit domain uplink. Performance degradation in any dimension will lower the health status, enabling rapid identification of abnormal states in the cockpit domain uplink and making it suitable for core business scenarios in the cockpit domain with stringent reliability requirements.

[0139] In another possible implementation, the optical power margin, bit error rate margin, and delay margin can be weighted and summed to determine the health status.

[0140] This calculation method allows for adjusting the weighting coefficients of each dimension to adapt to the performance priorities of different services. For example, display services that are sensitive to latency can have their latency margin weight increased; control services that require high transmission accuracy can have their bit error rate margin weight increased, resulting in stronger scenario adaptability.

[0141] In another possible implementation, the value obtained by multiplying the optical power margin, bit error rate margin, and delay margin is averaged over a preset time window (e.g., a 5-second sliding window), and this average value is determined as the health status.

[0142] Optionally, the health window mean can be calculated using an exponentially weighted sliding window, where the weight of the most recent sample is no less than 1.5 times the weight of the earliest sample, so that the health window mean can more sensitively reflect the latest trend of link performance changes.

[0143] This calculation method introduces time-dimensional smoothing processing on the basis of product determination, which can suppress instantaneous fluctuations in the cockpit domain uplink and health jumps caused by occasional interference, avoid erroneous service rerouting, and improve the stability of cockpit domain uplink status determination.

[0144] Before executing the three health assessment methods mentioned above, the three parameters—optical power margin, bit error rate margin, and delay margin—can be preprocessed by cropping them to the [0,1] interval. Specifically, a parameter calculated as greater than 1 is assigned a value of 1, and a value less than 0 is assigned a value of 0, ensuring that all input parameters are under a unified numerical benchmark. This preprocessing is a normalization calibration operation used to eliminate differences in the dimensions and magnitudes of the three parameters, preventing a single indicator from having an excessively large numerical amplitude that dominates the health assessment result, and ensuring a balanced weighting of the three evaluation dimensions.

[0145] S33. If the health of the cockpit domain uplink is lower than the preset health threshold, the cockpit domain service data carried by the cockpit domain uplink will be rerouted to the adjacent cockpit domain ODN via the backup fiber, so that the adjacent cockpit domain ODN will upload the cockpit domain service data to the cockpit domain OLT.

[0146] For example, the preset health threshold can be 0.35, 0.36, 0.37, etc., which can be preset based on empirical or experimental values. This application embodiment does not impose specific restrictions on this.

[0147] In one possible implementation, if the average health value of a preset number of preset time windows is lower than a preset health threshold, the cockpit domain service data carried by the cockpit domain uplink will be rerouted to the adjacent cockpit domain ODN via a backup fiber.

[0148] For example, the preset quantity is 3, 4, 5, etc., which can be preset based on experience or experimental values. This application embodiment does not impose specific limitations on this.

[0149] The rerouting target can be selected in several ways. Either any adjacent cabin domain ODN can be selected as the ODN to handle the uplink of cabin domain service data, or the ODN to handle the uplink of cabin domain service data can be selected from two adjacent cabin domain ODNs by comparing parameters such as the current cabin domain uplink health, remaining available bandwidth, and service capacity.

[0150] In this implementation, the continuous multi-window judgment mechanism can filter out instantaneous interference in the cockpit domain uplink and the temporary drop in health caused by occasional data fluctuations, avoid erroneous triggering of rerouting switching, and ensure the continuity and stability of cockpit domain service transmission.

[0151] Optionally, the cockpit domain OLT can be deployed in a primary and backup dual OLT architecture. The primary OLT and the backup OLT synchronize the parameters of the uplink of each cockpit domain, such as health, through inter-domain optical links. This ensures that when the primary OLT fails, the backup OLT can seamlessly take over the link health monitoring and service rerouting scheduling functions, further improving the overall reliability of the system.

[0152] The vehicle-mounted communication method provided in this application is applied to vehicles equipped with the aforementioned vehicle-mounted optical communication system. For each cabin domain ODN, the optical power margin, bit error rate margin, and latency margin of the cabin domain uplink are obtained. Then, based on these margins, the health of the cabin domain uplink is determined. If the health of the cabin domain uplink is lower than a preset health threshold, the cabin domain service data carried by the uplink is rerouted via a backup fiber to an adjacent cabin domain ODN, so that the adjacent ODN can uplink the cabin domain service data to the cabin domain optical line terminal (OLT). In this technical solution, by collecting three core parameters—optical power margin, bit error rate margin, and latency margin—of the cabin domain uplink and comprehensively calculating the health of the uplink, the actual operating status and performance margin of the cabin domain uplink can be comprehensively and accurately assessed, avoiding the one-sidedness of judging by a single indicator. When the health status falls below a preset health status threshold, service rerouting is triggered. This can identify performance degradation in advance before the uplink in the cockpit domain is completely interrupted, and switch the cockpit domain service data to the adjacent cockpit domain ODN via backup fiber to complete the uplink. This enables early fault prediction and seamless switching, effectively reducing the impact of link failures on cockpit services and significantly improving the reliability and continuity of cockpit domain service transmission.

[0153] Figure 4 Flowchart of the vehicle communication method provided in this application Figure 2 ,like Figure 4As shown, prior to S31, the method further includes:

[0154] S41. Based on the deployment location of each on-board terminal in the vehicle, determine multiple initial ODN deployment schemes.

[0155] In one possible implementation, a set of terminal coordinates can be established based on the installation locations of all on-board terminals in various areas of the vehicle body. Multiple initial ODN deployment schemes are then generated, constrained by factors such as the deployable paths of the ODN, the number of ports, service affiliations, and the deployment areas of the cockpit domain computing platform and the intelligent driving domain computing platform. The cockpit domain computing platform is a controller hardware unit integrating a cockpit domain OLT, a cockpit PON module, and a cockpit SOC; the intelligent driving domain computing platform is a controller hardware unit integrating an intelligent driving domain OLT, an intelligent driving PON module, and an intelligent driving SOC. Each initial ODN deployment scheme represents the connection relationship between each ODN and the on-board terminal, indicating whether the on-board terminal belongs to either the cockpit domain terminal or the intelligent driving domain terminal.

[0156] S42. Based on the total cabling length, bandwidth utilization, and the maximum service bandwidth affected by a single ODN failure, determine the target ODN deployment scheme from multiple initial ODN deployment schemes.

[0157] The total cabling length can be obtained by summing the cabling lengths of the fiber optic connection links between each vehicle terminal and its access ODN. The bandwidth utilization rate can be determined by the ratio of the allocated service bandwidth of each ODN to its rated bandwidth. The maximum service bandwidth affected by a single ODN failure can be determined by the upper limit of the service bandwidth that needs to be migrated or interrupted after removing a single ODN.

[0158] For each initial ODN deployment scheme, its comprehensive evaluation score can be calculated using a three-factor comprehensive evaluation method. The calculation process is as follows: normalize the three indicators of total cabling length, bandwidth utilization, and maximum service bandwidth affected by a single ODN failure, respectively, and then multiply the three normalized indicators by their corresponding weight coefficients and sum them to obtain the comprehensive evaluation score of the scheme. Finally, the scheme with the smallest comprehensive evaluation score is selected as the target ODN deployment scheme.

[0159] The normalization method for the total cabling length is as follows: calculate the total cabling length from all vehicle terminals to the corresponding ODN under the current initial ODN deployment scheme, divide it by the minimum total cabling length among all initial ODN deployment schemes, and obtain the normalized value of the total cabling length dimension.

[0160] The normalization method for bandwidth utilization is as follows: take the maximum ratio of the uplink aggregated peak bandwidth to the rated uplink bandwidth of the ODN among all ODNs under the current initial ODN deployment scheme, and use it as the normalized value of the bandwidth utilization dimension.

[0161] The normalization method for the impact of a single ODN failure is as follows: calculate the maximum value of the service bandwidth affected by a single ODN failure under the current initial ODN deployment scheme, divide it by the total bandwidth of the whole vehicle service, and obtain the normalized value of the impact dimension of a single ODN failure.

[0162] For example, the weighting coefficients for the three dimensions of total cabling length, bandwidth utilization, and maximum service bandwidth affected by a single ODN failure are set to 0.4, 0.3, and 0.3 by default. The weighting coefficient for each dimension can be adjusted within the range of 0.1 to 0.6 according to the overall vehicle operating conditions.

[0163] Understandably, the weighting coefficients for the three dimensions can be applied in tiers according to vehicle speed; for example, the first set of parameters is used for the parking segment (vehicle speed 0 km / h); the second set of parameters is used for the low-speed segment (vehicle speed ≤ 30 km / h); and the third set of parameters is used for the medium-to-high-speed segment (vehicle speed > 30 km / h). The β weight for the medium-to-high-speed segment is no less than the β weight for the parking segment, to more strictly control the bandwidth utilization of each ODN under high-speed conditions.

[0164] In practical applications, the method for selecting the scheme with the minimum comprehensive evaluation score is as follows: when the total number of initial ODN deployment schemes does not exceed 64, the exhaustive method is used to traverse all schemes to obtain the optimal result; when the total number of initial ODN deployment schemes exceeds 64, the simulated annealing heuristic algorithm is used to solve the problem, with the initial temperature set to 1.0 and the cooling factor set to 0.95, and the termination condition being that the comprehensive evaluation score no longer decreases after 50 consecutive iterations.

[0165] S43. According to the target ODN deployment plan, deploy the cockpit domain ODN that connects to the cockpit domain terminal and the intelligent driving domain ODN that connects to the intelligent driving domain terminal to form an in-vehicle optical communication system.

[0166] In the above embodiments, before system deployment, a target ODN deployment scheme is selected from multiple initial ODN deployment schemes based on three dimensions: total cabling length, bandwidth utilization, and the maximum service bandwidth affected by a single ODN failure. This enables comprehensive optimization of the ODN layout from three aspects: cabling cost, resource utilization efficiency, and fault impact range. This approach can balance cost control, transmission performance, and fault tolerance during the system construction phase, providing a reasonable physical layout foundation for the subsequent construction of the cockpit domain backup ring, and improving the overall feasibility and cost-effectiveness of the vehicle-mounted optical communication system.

[0167] Optionally, in some embodiments, the above-mentioned health assessment and rerouting mechanism can converge at the firmware layer of the OLT scheduler and be implemented through three core operational tables: the ODN partitioning table, the link health table, and the rerouting status table. The structure and function of each table are described below:

[0168] The ODN partitioning table provides a static topology and parameter baseline for link health monitoring, storing the fixed results of the target ODN deployment scheme selected from multiple initial ODN deployment schemes. Specifically, it includes: the ID of each ODN, the total cabling length calculated by the target ODN deployment scheme, the maximum service bandwidth affected by a single ODN failure, and the verification results of relevant constraints.

[0169] The link health table is the data source for triggering rerouting decisions. It continuously caches real-time performance parameters of each cabin domain uplink at 1-second intervals. Specifically, it includes: optical power margin, bit error rate margin, latency margin, and the health score calculated based on these parameters.

[0170] The rerouting status table records the current operating status and historical switching information of each cockpit domain uplink. Specifically, it includes: the original link used for current service transmission (cockpit domain uplinks with a health level below a preset health level threshold), the backup link activated when the original link becomes unavailable (adjacent cockpit domain uplinks), the hysteresis counter value used to prevent frequent service switching, and the specific reason for the most recent rerouting switch.

[0171] To ensure the successful implementation of the above methods, before the start of production (SOP) for the vehicle model, it is necessary to calibrate the key parameters of the system operation based on the actual vehicle wiring environment and the optical loss characteristics of the components. These parameters should include at least the following: the weighting coefficients α, β, and γ corresponding to the three dimensions of total wiring length, bandwidth utilization, and the maximum service bandwidth affected by a single ODN failure; preset health thresholds; preset time windows; and preset quantities.

[0172] It should be noted that the aforementioned preset health threshold, hysteresis threshold, preset time window, preset quantity, and other thresholds and status variables are all version-controlled by the same parameter package and are updated synchronously as a whole during OTA upgrades to ensure version compatibility and consistency among parameters.

[0173] To more clearly explain the solutions shown in the above embodiments, a specific embodiment will be used for illustration below.

[0174] Figure 5 Flowchart of the vehicle communication method provided in this application Figure 3 ,like Figure 5 As shown, the method includes:

[0175] S51. Based on the deployment location of each on-board terminal in the vehicle, determine multiple initial ODN deployment schemes.

[0176] S52. Based on the total cabling length, bandwidth utilization, and the maximum service bandwidth affected by a single ODN failure, determine the target ODN deployment scheme from multiple initial ODN deployment schemes.

[0177] S53. According to the target ODN deployment plan, deploy the cockpit domain ODN that connects to the cockpit domain terminal and the intelligent driving domain ODN that connects to the intelligent driving domain terminal to form an in-vehicle optical communication system.

[0178] S54. For each cabin domain ODN, obtain the optical power margin, bit error rate margin, and delay margin of the cabin domain uplink.

[0179] S55. Determine the health of the cockpit domain uplink based on the optical power margin, bit error rate margin, and delay margin.

[0180] S56. Determine whether the average health value of a preset number of preset time windows is lower than the preset health value threshold.

[0181] If yes, execute S57; otherwise, execute S54.

[0182] Optionally, when a hard fault of optical signal loss occurs in the uplink of the cockpit domain, the OLT scheduler skips the criterion of the health sliding window mean and immediately triggers rerouting to minimize the interruption time of cockpit domain services.

[0183] S57. Reroute the cockpit domain service data carried by the cockpit domain uplink to the adjacent cockpit domain ODN via the backup fiber optic cable.

[0184] Optionally, the above rerouting operation can be performed during the idle period of cockpit domain services to avoid interrupting ongoing cockpit domain services.

[0185] Optionally, to avoid frequent switching due to intermittent failures of the uplink in the same cabin area, the OLT scheduler limits the number of rerouting attempts for the uplink in the same cabin area within a preset time period (e.g., 24 hours). When the number of rerouting attempts reaches the limit, the OLT scheduler locks the current cabin area uplink and reports an alarm to the vehicle diagnostic system, awaiting manual intervention.

[0186] In practical applications, the additional end-to-end latency after rerouting is no more than 5 milliseconds.

[0187] Optionally, when the health of all adjacent cabin domain ODNs is lower than a preset health threshold, the OLT scheduler switches the cabin domain service to a degraded bandwidth mode (e.g., reducing resolution or frame rate) and reports an alarm to the vehicle diagnostic system.

[0188] S58. After the rerouting takes effect, the OLT scheduler continuously collects the health status of the uplink in the cockpit domain.

[0189] S59. Determine whether the average health value of the sliding window for a preset number of preset time windows has reached the hysteresis threshold.

[0190] Optionally, the hysteresis threshold can be a preset multiple of the preset health threshold, such as 1.5 times, 2 times, 2.5 times, etc., which can be preset based on empirical or experimental values. This application embodiment does not impose specific restrictions on this.

[0191] For example, the hysteresis threshold can be 0.375, the preset multiple can be 1.5, and the preset quantity can be 6.

[0192] If yes, the OLT scheduler restores the uplink data upload function of the cockpit domain and then executes S54; if no, the cockpit domain service data of the uplink of the cockpit domain continues to be uploaded by the adjacent cockpit domain ODN and then executes S58.

[0193] In practical implementation, the determination of the aforementioned number of preset time windows can be achieved through a hysteresis counter. The hysteresis counter records the number of times the average health window value of the cockpit domain uplink continuously meets the determination condition. When the average health window value is lower than a preset health threshold, the hysteresis counter increments by 1, and is reset to zero after rerouting takes effect. After rerouting takes effect, when the average health window value reaches the hysteresis threshold, the hysteresis counter increments by 1, and is reset to zero after restoring the data upload function of the cockpit domain uplink. If, during the counting process, the average health window value of any preset time window fails to meet the determination condition, the hysteresis counter is immediately reset to zero and re-accumulated. By introducing a hysteresis counter, instantaneous fluctuations and occasional interference in the link can be effectively filtered, avoiding accidental triggering of rerouting or backswitching operations, and ensuring the continuity and stability of cockpit domain service transmission.

[0194] In practical applications, the same method can be used to calculate the health of the intelligent driving domain uplink. However, when the health of the intelligent driving domain uplink is lower than the preset health threshold, the intelligent driving domain business data will remain unchanged in the intelligent driving domain uplink and an alarm will be reported to the vehicle diagnostic system.

[0195] The entire process from S54 to S59 described above forms a closed loop within the OLT scheduler and is executed continuously at 1-second intervals, enabling real-time monitoring, fault switching, and automated management of the cockpit domain uplink.

[0196] The OLT scheduler reports an event record to the vehicle diagnostic system each time a rerouting, downgraded bandwidth switch or back-switching is completed. The event record contains at least the following fields: ODN identifier, trigger reason, average health window value before triggering, optical power margin at the triggering time, bit error rate margin, delay margin values ​​of each component, new link identifier, switching time and timestamp.

[0197] Figure 6 This is a schematic diagram illustrating the rerouting determination principle in the vehicle communication method provided in this application, as shown below. Figure 6 As shown, for the cockpit domain uplink, the received optical power and actual delay on the optical module side are obtained, and the optical power margin is determined based on the received optical power and receiving sensitivity. Simultaneously, the measured bit error rate (BER) on the cockpit domain ODN side is obtained, and the BER margin is determined based on the BER threshold and the measured BER. Further, the value obtained by multiplying the optical power margin, BER margin, and delay margin is determined as the health score. The OLT scheduler calculates the health score of the cockpit domain uplink using a sliding average over a preset time window, obtaining the average health score for each preset time window. If the average health score for a consecutive preset number of preset time windows is lower than the preset health score threshold, a rerouting decision is executed, rerouting the cockpit domain service data carried by the cockpit domain uplink to the adjacent cockpit domain ODN via backup fiber, and reporting an alarm to the vehicle diagnostic system.

[0198] Figure 7 This is a schematic diagram of the closed-loop state flow of the cockpit domain uplink in the vehicle communication method provided in this application, as shown below. Figure 7 As shown, it includes the following states:

[0199] Normal / Original Link Status: Cockpit domain service data is directly uplinked to the cockpit domain OLT via the cockpit domain uplink. The OLT scheduler continuously collects optical power margin, bit error rate margin, and latency margin at 1-second intervals, calculates the health sliding window average, and monitors it in real time.

[0200] Deterioration Status: This status is entered when the average health value of a single preset time window is lower than the preset health value threshold. The number of consecutive deterioration windows with the average health value of a single time window lower than the preset health value threshold is continuously counted to filter out instantaneous link fluctuations.

[0201] Rerouting Triggered State: This state is entered when the number of consecutive degraded windows reaches a preset number. A handover process is then executed, rerouting the cockpit domain service data carried by the current cockpit domain ODN to the adjacent cockpit domain ODN via backup fiber optic cable to complete uplink transmission. The intelligent driving domain uplink always maintains a tree-structured single-hop direct connection and does not participate in backup handover.

[0202] Backup ring steady state: After rerouting is completed, this state is entered, and cockpit domain service data continues to be transmitted via backup fiber.

[0203] Link Recovery in Progress: After the uplink in this cockpit domain is repaired, the average health window value of the uplink in this cockpit domain will be continuously monitored. This state is entered when the health window value is continuously greater than or equal to the hysteresis threshold, and the number of windows that meet the standard is accumulated.

[0204] Switchback Complete Status: After the cumulative number of qualified windows reaches the preset number, a service switchback operation is performed during the idle interval of the cockpit domain services, and finally the system returns to the normal original link status.

[0205] Taking an L2+ level passenger vehicle as the test object, the list of vehicle-mounted terminals and aggregated bandwidth are as follows:

[0206] The intelligent driving domain terminal includes two forward-facing cameras (total 6Gbps), four surround-view cameras (total 4Gbps), one lidar (2Gbps), and four millimeter-wave radars (total 0.8Gbps).

[0207] The cockpit terminal includes the central control screen (4Gbps), the instrument panel screen (1.5Gbps), the passenger screen (3Gbps), and the ceiling screen (3Gbps).

[0208] There are 5 initial ODN deployment schemes: D1 (4 ODNs, deployed in the front left, front middle, right rear, and rear positions), D2 (3 ODNs, deployed in the front left, front middle, and rear positions), D3 (5 ODNs, deployed in the front 2 + middle 1 + rear 2 positions), D4 (3 ODNs, deployed in the front, middle, and rear positions), and D5 (4 ODNs, deployed in the left, right, front, and rear positions).

[0209] With weighting coefficients α=0.4, β=0.3, and γ=0.3, a single ODN uplink rated bandwidth of 10Gbps, and a total vehicle service bandwidth of 24.3Gbps, the calculated comprehensive evaluation scores for D1, D2, D3, D4, and D5 are 0.86, 1.04, 0.93, 1.12, and 0.98, respectively. Therefore, D1, with the lowest comprehensive evaluation score, is selected as the target ODN deployment scheme.

[0210] Following the deployment of the target ODN, D1, the vehicle-mounted optical communication system was successfully deployed in the vehicle. After the vehicle was assembled and put into operation, by the 36th month, the cabin domain OLT detected that the average health window value of the cabin domain uplink corresponding to ODN3 continuously decreased from 0.62. At the 7th preset time window, the average health window value of the cabin domain uplink decreased to 0.21 (with an optical power margin of 0.42, a bit error rate margin of 0.51, and a latency margin of 0.97), and the average health window value for three consecutive preset time windows was lower than the preset health threshold of 0.25. The OLT scheduler then switched the cabin domain service (central control screen, 4Gbps) carried by ODN3 to ODN4 via the backup fiber. The actual switching time was 78ms, meeting the engineering target of less than 100ms.

[0211] The uplink of the intelligent driving domain corresponding to the intelligent driving domain service maintains the original tree-shaped single-hop architecture and does not participate in backup switching to ensure latency determinism.

[0212] After the maintenance personnel replaced the uplink fiber in the cabin domain corresponding to ODN3 during the next vehicle maintenance, the average health value of the uplink in the cabin domain rose to 0.41 within 6 preset time windows, which is higher than the health hysteresis threshold of 0.375 (used to avoid frequent service switching caused by link status fluctuations); the OLT scheduler completed the reswitching operation of the cabin domain services according to the preset strategy during the service idle interval.

[0213] When a vehicle is configured with high-bandwidth cockpit services (such as multi-channel 8K display services), the uplink rated bandwidth of a single ODN can be increased to 25Gbps, and the preset health threshold can be relaxed to 0.20 to adapt to the link performance evaluation standards and rerouting triggering strategies under high-bandwidth services, ensuring stable transmission of cockpit domain services under high-bandwidth scenarios.

[0214] The core capabilities of the above solution are entirely implemented by the OLT scheduler firmware, without any intrusive changes to the existing PON OLT and ODN hardware, making it easy to perform incremental deployment and feature launch via OTA in mass-produced E / E architectures.

[0215] Experimental verification shows that, compared with existing single tree topologies, the vehicle-mounted optical communication system and method provided in this application improve the availability of cockpit domain services from 0% to 100% in the case of single ODN uplink failure in the cockpit domain; compared with a single ring topology, the worst-case end-to-end latency of intelligent driving domain services is reduced from 23ms to 9ms (tree single hop), and loop synchronization overhead is eliminated; compared with statically partitioning ODN deployment schemes based on engineering experience, determining the target ODN deployment scheme from multiple initial ODN deployment schemes reduces the total length of the vehicle wiring harness from 32m. The bandwidth of the single ODN failure was reduced from 12Gbps to 7Gbps (a reduction of approximately 41.7%), and the maximum service bandwidth affected by a single ODN failure was reduced to 26m (a reduction of approximately 18.8%). Compared with passively triggering rerouting only after a hard fault alarm, the embodiment of this application triggers rerouting when the health of the uplink in the cockpit domain is lower than a preset health threshold (e.g., 0.25). The measured rerouting time is 78ms, which meets the engineering target of less than 100ms. Moreover, the hysteresis threshold and hysteresis counter strategy ensure that the number of rerouting times for the same uplink in the cockpit domain does not exceed 1 time within 24 hours.

[0216] The above solution makes no intrusive changes to the existing PON OLT and ODN hardware. All new capabilities are located in the OLT scheduler firmware layer and can be incrementally deployed in mass-produced E / E architectures via OTA.

[0217] In summary, the vehicle communication method provided in the above embodiments, based on existing ODN partition aggregation and OLT centralized processing, has the following inventive points:

[0218] (i) The uplink of the intelligent driving domain adopts a single-hop direct connection from the tree-structured ODN to the OLT to ensure the shortest latency path for intelligent driving domain services; the cabin domain ODNs are connected by backup optical fibers to form a local backup loop to ensure that the failure of a single cabin domain uplink does not interrupt cabin domain services.

[0219] (ii) Based on the three dimensions of total cabling length, bandwidth utilization, and maximum service bandwidth affected by a single ODN failure, find the target ODN deployment scheme that minimizes the total cabling length and ensures that the maximum service bandwidth affected by a single ODN failure does not exceed the threshold.

[0220] (iii) A unified health score is formed by multiplying the optical power margin, bit error rate margin and delay margin. The cockpit domain service data is triggered to reroute to the adjacent cockpit domain ODN via the backup fiber optic cable using a sliding window criterion with a preset time window, combined with the hysteresis threshold and hysteresis counter. After the original path is restored, the data is switched back to the original path.

[0221] Furthermore, the embodiments of this application have the following technical effects:

[0222] Firstly, the embodiments of this application achieve differentiated matching of dual-domain transmission requirements by retaining a tree-shaped single-hop direct connection architecture in the intelligent driving domain and laying backup optical fibers only between adjacent cockpit domain ODNs to form a local backup loop, thus taking into account both the latency determinism of intelligent driving domain services and the single-point fault tolerance of cockpit domain services.

[0223] Secondly, the embodiments of this application determine the target ODN deployment scheme from multiple initial ODN deployment schemes by considering three dimensions: total cabling length, bandwidth utilization, and the maximum service bandwidth affected by a single ODN failure. This achieves comprehensive optimization of ODN layout in terms of cabling cost, resource utilization efficiency, and fault impact range.

[0224] Third, after vehicle assembly and during use, factors such as link attenuation, temperature drift, and vibration can cause continuous changes in link performance. This application's embodiment calculates the health of the cockpit domain uplink by online acquisition of optical power margin, bit error rate margin, and delay margin. It employs a sliding window criterion with a preset time window, combined with a hysteresis threshold and a hysteresis counter, to proactively identify performance degradation and trigger rerouting before the cockpit domain uplink is completely interrupted. Simultaneously, it effectively suppresses erroneous handovers and frequent recursive handovers caused by instantaneous link fluctuations, ensuring the continuity and stability of cockpit domain service transmission.

[0225] Figure 8 A schematic diagram of the structure of the vehicle-mounted communication device provided in this application is shown below. Figure 8 As shown, the vehicle-mounted communication device 80 provided in this embodiment is applied to a vehicle equipped with the above-mentioned vehicle-mounted optical communication system. The vehicle-mounted communication device 80 includes:

[0226] The acquisition module 801 is used to acquire the optical power margin, bit error rate margin, and delay margin of the uplink of each cabin domain ODN.

[0227] The determination module 802 is used to determine the health of the cockpit domain uplink based on the optical power margin, bit error rate margin, and latency margin.

[0228] The rerouting module 803 is used to reroute the cabin domain service data carried by the cabin domain uplink to the adjacent cabin domain ODN via the backup fiber if the health of the cabin domain uplink is lower than the preset health threshold, so that the adjacent cabin domain ODN can uplink the cabin domain service data to the cabin domain OLT.

[0229] In one possible implementation, the acquisition module 801 is specifically used for:

[0230] Obtain the received optical power and receiving sensitivity of the cockpit domain OLT in the cockpit domain uplink.

[0231] The optical power margin is determined based on the received optical power and the receiving sensitivity.

[0232] In one possible implementation, the acquisition module 801 is specifically used for:

[0233] Obtain the measured bit error rate of the cockpit domain uplink and the bit error rate threshold corresponding to the cockpit domain service data.

[0234] The bit error rate margin is determined based on the bit error rate threshold and the measured bit error rate.

[0235] In one possible implementation, the acquisition module 801 is specifically used for:

[0236] Obtain the actual uplink latency in the cockpit domain and the latency budget window corresponding to the cockpit domain service data.

[0237] Determine the latency margin based on the actual latency and the latency budget window.

[0238] In one possible implementation, the determining module 802 is specifically used for:

[0239] The health score is determined by multiplying the optical power margin, bit error rate margin, and delay margin.

[0240] In one possible implementation, the rerouting module 803 is specifically used for:

[0241] The health of the uplink in the cockpit domain is calculated by moving average over a preset time window to obtain the average health value for each preset time window.

[0242] If the average health value of a preset number of preset time windows is lower than the preset health threshold, the cockpit domain service data carried by the cockpit domain uplink will be rerouted to the adjacent cockpit domain ODN via the backup fiber optic cable.

[0243] In one possible implementation, the vehicular communication device includes a deployment module that, before acquiring the optical power margin, bit error rate margin, and latency margin of the uplink for each cabin domain ODN, the deployment module is configured to:

[0244] Based on the deployment location of each in-vehicle terminal, multiple initial ODN deployment schemes are determined. Each initial ODN deployment scheme is used to represent the connection relationship between each ODN and the in-vehicle terminal, which belongs to either the cockpit domain terminal or the intelligent driving domain terminal.

[0245] Based on the total cabling length, bandwidth utilization, and the maximum service bandwidth affected by a single ODN failure, the target ODN deployment scheme is determined from multiple initial ODN deployment schemes.

[0246] According to the target ODN deployment plan, deploy the cockpit domain ODN that connects to the cockpit domain terminal and the intelligent driving domain ODN that connects to the intelligent driving domain terminal to form an in-vehicle optical communication system.

[0247] The vehicle communication device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0248] Figure 9 This is a structural diagram of the vehicle provided in this application. Figure 9 As shown, the vehicle 90 provided in this embodiment includes: an in-vehicle optical communication system 10, at least one processor 901, and a memory 902. Optionally, the vehicle 90 further includes a communication component 903. The processor 901, memory 902, and communication component 903 are connected via a bus 904.

[0249] In a specific implementation, at least one processor 901 executes computer execution instructions stored in memory 902, causing at least one processor 901 to perform the above-described method.

[0250] The specific implementation process of processor 901 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0251] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0252] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0253] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0254] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0255] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0256] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0257] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0258] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0259] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0260] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0261] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0262] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0263] Finally, it should be noted that other embodiments of this application will readily conceive of by those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes may be made without departing from its scope.

Claims

1. A vehicle-mounted optical communication system, characterized in that, include: Intelligent driving domain optical line terminal (OLT), cockpit domain OLT, cockpit domain optical distribution network (ODN) with cockpit domain terminals connected, and intelligent driving domain ODN with intelligent driving domain terminals connected; The cockpit domain ODN is connected to the cockpit domain OLT to form the cockpit domain uplink; the intelligent driving domain ODN is connected to the intelligent driving domain OLT to form the intelligent driving domain uplink. Backup optical fibers are laid between adjacent cabin domain ODNs, forming a closed backup loop.

2. A vehicle-mounted communication method, characterized in that, Applied to vehicles equipped with the in-vehicle optical communication system as described in claim 1, the method includes: For each cabin domain optical distribution network (ODN), obtain the optical power margin, bit error rate margin, and latency margin of the cabin domain uplink. The health of the cockpit domain uplink is determined based on the optical power margin, the bit error rate margin, and the delay margin. If the health of the cockpit domain uplink is lower than a preset health threshold, the cockpit domain service data carried by the cockpit domain uplink will be rerouted to the adjacent cockpit domain ODN via a backup fiber, so that the adjacent cockpit domain ODN will uplink the cockpit domain service data to the cockpit domain optical line terminal (OLT).

3. The method according to claim 2, characterized in that, Obtain the optical power margin of the cockpit domain uplink, including: Obtain the received optical power and receiving sensitivity of the cockpit domain OLT in the cockpit domain uplink; The optical power margin is determined based on the received optical power and the received sensitivity.

4. The method according to claim 2, characterized in that, Obtain the bit error rate margin of the cockpit domain uplink, including: Obtain the measured bit error rate of the cockpit domain uplink and the bit error rate threshold corresponding to the cockpit domain service data; The bit error rate margin is determined based on the bit error rate threshold and the measured bit error rate.

5. The method according to claim 2, characterized in that, Obtain the uplink latency margin in the cockpit domain, including: Obtain the actual uplink latency of the cockpit domain and the latency budget window corresponding to the cockpit domain service data; The latency margin is determined based on the actual latency and the latency budget window.

6. The method according to any one of claims 2-5, characterized in that, Determining the health of the cockpit domain uplink based on the optical power margin, the bit error rate margin, and the delay margin includes: The health score is determined by multiplying the optical power margin, the bit error rate margin, and the delay margin.

7. The method according to any one of claims 2-5, characterized in that, If the health of the cockpit domain uplink is lower than a preset health threshold, the cockpit domain service data carried by the cockpit domain uplink will be rerouted to the adjacent cockpit domain ODN via a backup fiber optic cable, including: The health of the uplink in the cockpit domain is calculated by a sliding average over a preset time window to obtain the average health value for each preset time window. If the average health value of a preset number of preset time windows is lower than the preset health threshold, the cockpit domain service data carried by the cockpit domain uplink will be rerouted to the adjacent cockpit domain ODN via a backup fiber.

8. The method according to any one of claims 2-5, characterized in that, Before obtaining the optical power margin, bit error rate margin, and delay margin of the uplink for each cabin domain ODN, the method further includes: Based on the deployment location of each vehicle-mounted terminal in the vehicle, multiple initial ODN deployment schemes are determined. Each initial ODN deployment scheme is used to represent the connection relationship between each ODN and the vehicle-mounted terminal, wherein the vehicle-mounted terminal belongs to the cockpit domain terminal or the intelligent driving domain terminal. Based on the total cabling length, bandwidth utilization, and the maximum service bandwidth affected by a single ODN failure, a target ODN deployment scheme is determined from the multiple initial ODN deployment schemes. According to the target ODN deployment scheme, a cockpit domain ODN that connects to the cockpit domain terminal and an intelligent driving domain ODN that connects to the intelligent driving domain terminal are deployed to form the vehicle-mounted optical communication system.

9. A vehicle-mounted communication device, characterized in that, Applied to a vehicle equipped with the in-vehicle optical communication system as described in claim 1, the device comprises: The acquisition module is used to acquire the optical power margin, bit error rate margin, and latency margin of the uplink of each cabin domain optical distribution network (ODN). The determination module is used to determine the health of the cockpit domain uplink based on the optical power margin, the bit error rate margin, and the delay margin. The rerouting module is used to reroute the cabin domain service data carried by the cabin domain uplink to the adjacent cabin domain ODN via the backup fiber if the health of the cabin domain uplink is lower than a preset health threshold, so that the adjacent cabin domain ODN can uplink the cabin domain service data to the cabin domain optical line terminal (OLT).

10. A vehicle, characterized in that, include: Memory, processor, and the vehicle-mounted optical communication system as described in claim 1; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 2-8.

Images