Power and data center (PDC) for automotive applications

Abstract

This disclosure relates to power and data center PDCs for automotive applications. The PDC can act as a combined data concentrator and power distributor, delivering scalable and affordable network / power redundancy to the automotive electrical / electronic architecture (E / EA) of a partially or fully autonomous vehicle. In some embodiments, the vehicle, including the intelligent E / EA, is divided into zones, each zone comprising one or more PDCs and one or more sensors, actuators, controllers, speakers, or other devices coupled to and powered by these zone PDCs. Each PDC collects and processes (or transmits via) raw or pre-processed sensor data from sensors in its zone. These sensors provide their data to the PDC via cost-effective short-range data links. In some embodiments, actuators in each zone are coupled to their respective zone PDCs and receive their control data from those PDCs via a high-speed data bus or data link.

Description

[0001] This application is a divisional application of Chinese patent application No. 201910585550.7, entitled "Power and Data Center (PDC) for Automotive Applications". Technical Field

[0002] This disclosure generally relates to automotive electrical / electronic architecture (E / EA), and specifically to E / EA for autonomous driving. Background Technology

[0003] The Society of Automotive Engineers (SAE) International has outlined progressive levels of autonomous driving for vehicles. These levels include: Level 0: No automation; Level 1: Driver assistance required; Level 2: Partial automation options available; Level 3: Conditional automation; Level 4: High automation; and Level 5: Full automation. Vehicles at Level 3 and above require fail-safe or fail-operational E / EA.

[0004] One way to design a fault-safe or fault-operation E / EA is to introduce redundancy into the E / EA by doubling the number of critical components, such as power supplies, data networks, controllers, and diagnostic devices. However, many high-end vehicles today have limited space for the packaging of redundant components, making doubling critical components impractical. Doubling critical components would also increase the vehicle's weight and the complexity of the wiring harness.

[0005] Another solution is to equip conventional automotive electrical centers (e.g., using fuses and relays) with diagnostic equipment and integrate switching capabilities into every power and data path of the vehicle. However, such a design would be impractical and expensive. Summary of the Invention

[0006] The disclosed PDC includes a combined data concentrator and power divider that delivers scalable and affordable network / power redundancy to the automotive E / EA supporting partially or fully autonomous vehicles. In some embodiments, vehicles including intelligent E / EAs are divided into zones, each zone including one or more PDCs and one or more sensors, actuators, controllers, speakers, or other devices coupled to and powered by these zone PDCs. Each PDC collects and processes (or transmits via) raw or pre-processed sensor data from one or more sensors in its zone. Sensors provide their data to the PDC via cost-effective short-range data links. In some embodiments, one or more actuators in each zone are coupled to their respective zone PDCs and receive their control data from the PDCs via a high-speed data bus or data link.

[0007] In some embodiments, an automotive electrical and electronic system includes: a plurality of computing platforms coupled together in a multi-ring self-healing network, wherein at least one computing platform provides autonomous driving capabilities for the vehicle; a plurality of power distribution cells (PDCs) coupled to the multi-ring self-healing network, each PDC including a data interface, a power interface, and a sensor interface, the sensor interface receiving sensor data from one or more sensors, the data interface feeding the sensor data to the multi-ring self-healing network, and the power interface distributing power to one or more sensors; and a plurality of power supply rings, each coupled to a different power source or source system, the plurality of power rings being coupled to the computing platforms and the PDCs.

[0008] In some embodiments, a method includes: distributing power to one or more sensors of a vehicle via a power interface of a PDC included in the vehicle; receiving sensor data from the one or more sensors via a sensor interface of the PDC; feeding the sensor data from an output port of the PDC into a multi-ring data network coupled to the PDC and coupled to at least one computing platform that provides autonomous driving capabilities for the vehicle; determining at least one operation associated with autonomous driving of the vehicle by the at least one computing platform, the at least one operation being determined at least in part based on the received sensor data; and causing the vehicle to perform the at least one operation associated with autonomous driving of the vehicle by the at least one computing platform.

[0009] In some embodiments, a PDC includes: a sensor interface including a redundant sensor data port; a data network interface including a redundant network data port; a processor coupled to the sensor interface and the data network interface, the data processor being configured to receive sensor data from the redundant sensor data port, to process the sensor data, and to output the processed sensor data on the redundant network data port; and a power switch coupled to the redundant network power supply rail, the redundant sensor power supply rail, and the processor, the processor being configured to cause the power switch to disconnect the first network power supply rail and connect the second network power supply rail.

[0010] In some embodiments, an automotive electrical and electronic system includes a first PDC, a first computing platform, and a first data platform. The first PDC includes a first sensor interface and a first data interface. The first sensor interface is configured to receive sensor data from one or more sensors, and the first data interface is configured to transmit the sensor data. The first PDC is connected to the first computing platform via a first path, which includes the first data platform; the first PDC is also connected to the first computing platform via a second path, which is different from the first path and does not include the first data platform; and the first data interface of the first PDC is configured to transmit sensor data to the first computing platform via the first and second paths.

[0011] One or more embodiments of the disclosed PDC offer one or more of the following advantages. The PDC reduces the average wire length in the E / EA, which optimizes the overall weight of the harness and the cable harness diameter. Integrating a smaller electronic control unit (ECU) into the PDC reduces the number of power supply wires, the number of network connections, and the required package space. The PDC reduces the cost and weight of the vehicle. The PDC allows the vehicle to be divided into zones, enabling the use of smaller harnesses (“kits”) in these zones to connect loads, sensors, and actuators to the PDC. These “kits” support automated manufacturing processes for the harnesses (as opposed to manual processes), meeting the traceability requirements of ISO 26262. Because the PDC has multiple power and network connections using different topologies (and in some embodiments, different physical layers), the reliability of the vehicle's E / EA is increased, thereby providing benefits for Class 3 / 4 / 5 vehicles.

[0012] Details of the disclosed implementation are set forth in the accompanying drawings and the following description. Other features, objects, and advantages will be apparent from this description, the drawings, and the claims. Attached Figure Description

[0013] Figure 1A The diagram illustrates an E / EA system architecture for data distribution in a vehicle with autonomous driving capabilities and using four PDCs, according to some embodiments.

[0014] Figure 1B The diagram illustrates an E / EA system architecture for data distribution in a vehicle with autonomous driving capabilities and using four PDCs, according to some embodiments.

[0015] Figure 1C The diagram illustrates an E / EA system architecture for data distribution in a vehicle with autonomous driving capabilities and using six PDCs, according to some embodiments.

[0016] Figure 1D The diagram illustrates an E / EA system architecture for data distribution in a vehicle with autonomous driving capabilities and using six PDCs, according to some embodiments.

[0017] Figure 1E The figure illustrates a method for using according to some embodiments. Figure 1D The E / EA system architecture features Controller Area Network Flexible Data (CAN-FD) fallback and power management.

[0018] Figure 1F The diagram illustrates a method for using, according to some embodiments, by Figure 1D The E / EA system architecture uses a redundant sensor ring topology.

[0019] Figure 1G The diagram illustrates a method for using, according to some embodiments, by Figure 1D The E / EA system architecture uses a redundant service ring topology.

[0020] Figure 1H The diagram illustrates an E / EA system architecture for data distribution in a vehicle with autonomous driving capabilities and using four PDCs, according to some embodiments.

[0021] Figure 2A The diagram illustrates an automotive E / EA system architecture, according to some embodiments, for power distribution in a vehicle with autonomous driving capabilities and using four PDCs.

[0022] Figure 2B The diagram illustrates an automotive E / EA system architecture, according to some embodiments, for power distribution in a vehicle with autonomous driving capabilities and using four PDCs.

[0023] Figure 2C The diagram illustrates an automotive E / EA system architecture, according to some embodiments, for power distribution in a vehicle with autonomous driving capabilities and using six PDCs.

[0024] Figure 2D The diagram illustrates an automotive E / EA system architecture, according to some embodiments, for power distribution in a vehicle with autonomous driving capabilities and using six PDCs.

[0025] Figure 2E The diagram illustrates an automotive E / EA system architecture, according to some embodiments, for power distribution in a vehicle with autonomous driving capabilities and using four PDCs.

[0026] Figure 3A The illustration shows a vehicle in fail-safe operation prior to a PDC failure, according to some embodiments.

[0027] Figure 3B The illustration shows fail-safe operation of a vehicle following a PDC failure, according to some embodiments.

[0028] Figure 3C The illustration shows a vehicle in fail-safe operation prior to a PDC failure, according to some embodiments.

[0029] Figure 3D The illustration shows fail-safe operation of a vehicle following a PDC failure, according to some embodiments.

[0030] Figure 3E The illustration shows a fail-safe operation of a vehicle with six PDCs prior to a PDC failure, according to some embodiments.

[0031] Figure 3F The illustration shows a fail-safe operation of a vehicle with six PDCs following a PDC failure, according to some embodiments.

[0032] Figure 4A The illustration shows a vehicle in fail-safe operation prior to a failure of the Secure Connected Gateway (SCGW) according to some embodiments.

[0033] Figure 4B The illustration shows a fail-safe operation of a vehicle following an SCGW failure, according to some embodiments.

[0034] Figure 4C The illustration shows a vehicle in fail-safe operation prior to an SCGW failure, according to some embodiments.

[0035] Figure 4D The illustration shows a fail-safe operation of a vehicle following an SCGW failure, according to some embodiments.

[0036] Figure 4E The illustration shows a fail-safe operation of a vehicle with six PDCs prior to a PDC failure, according to some embodiments.

[0037] Figure 4F The illustration shows a fail-safe operation of a vehicle with six PDCs following a PDC failure, according to some embodiments.

[0038] Figure 5A The illustration shows a vehicle in fail-safe operation prior to a failure of the Automated Driving Server (ADS) according to some embodiments.

[0039] Figure 5B The illustration shows fail-safe operations of a vehicle following an ADS failure, according to some embodiments.

[0040] Figure 5C The illustration shows a fail-safe operation of a vehicle prior to an ADS failure, according to some embodiments.

[0041] Figure 5D The illustration shows fail-safe operations of a vehicle following an ADS failure, according to some embodiments.

[0042] Figure 5E The illustration shows a fail-safe operation of a vehicle with six PDCs prior to a PDC failure, according to some embodiments.

[0043] Figure 5F The illustration shows a fail-safe operation of a vehicle with six PDCs following a PDC failure, according to some embodiments.

[0044] Figure 6A The illustration shows a vehicle in fail-safe operation prior to a power supply failure, according to some embodiments.

[0045] Figure 6B The illustration shows a fail-safe operation of a vehicle following a power supply failure, according to some embodiments.

[0046] Figure 6C The illustration shows a vehicle in fail-safe operation prior to a power supply failure, according to some embodiments.

[0047] Figure 6D The illustration shows a fail-safe operation of a vehicle following a power supply failure, according to some embodiments.

[0048] Figure 6E The illustration shows a fail-safe operation of a vehicle with six PDCs prior to a PDC failure, according to some embodiments.

[0049] Figure 6F The illustration shows a fail-safe operation of a vehicle with six PDCs following a PDC failure, according to some embodiments.

[0050] Figure 7 This is a conceptual block diagram of the PDC architecture based on some embodiments.

[0051] Figure 8 This is a conceptual block diagram of a PDC architecture according to some embodiments, which includes a power board and a data board.

[0052] Figure 9 This is a conceptual block diagram of a PDC architecture without a PDC IO System-on-Chip (SoC) according to some embodiments.

[0053] Figure 10 This is a conceptual block diagram illustrating the fail-safe operation of a dual-ring self-healing network topology in the event of a PDC failure, according to some embodiments.

[0054] Figure 11This is a flowchart illustrating a process performed by the PDC during normal operation according to some embodiments.

[0055] Figure 12 This is a flowchart illustrating a process for monitoring data network faults by a PDC according to some embodiments.

[0056] Figure 13 This is a flowchart illustrating a process for monitoring power network faults by a PDC according to some embodiments.

[0057] Figure 14A The diagram illustrates a concept of an Open Car Server Alliance (OCSA) server system according to some embodiments.

[0058] Figure 14B This is a conceptual block diagram illustrating the OCSA server system hardware (HW) according to some embodiments.

[0059] Figure 14C This is a conceptual block diagram illustrating OCSA server system software (SW) according to some embodiments.

[0060] Figure 15 This is a flowchart illustrating a process for establishing a logical connection from a component to a computing platform, according to some embodiments.

[0061] Figure 16A The figure illustrates a star topology using an ADS as a peripheral plug-in station according to some embodiments.

[0062] Figure 16B The figure illustrates a star topology that includes a subset of redundant data links for certain sensors, according to some embodiments.

[0063] Figure 17 This is a flowchart of a process for selecting a subset of redundant sensors configured in a star topology, according to some embodiments.

[0064] Figure 18 The figure illustrates a computer system according to some embodiments.

[0065] Figure 19 The diagram illustrates an E / EA system architecture according to some embodiments, which utilizes an Open Server Platform (OSP) and provides a scalable topology with fault-tolerant design.

[0066] Figure 20 Further illustrations according to embodiments Figure 19 The E / EA system architecture shown here focuses on key technical attributes for achieving feature growth and redundancy.

[0067] Figure 21 The figure illustrates the OSP system architecture according to an embodiment.

[0068] Figure 22 The figure illustrates the OSP software stack according to an embodiment.

[0069] Figure 23 The figure illustrates the PDC functional domain according to an embodiment.

[0070] Figure 24 The diagram illustrates the key aspects of OSP hybrid for implementing vehicle lifecycle management according to an embodiment.

[0071] Figure 25 The figure illustrates OSP functional safety certification for implementing vehicle lifecycle management according to an embodiment.

[0072] Figure 26 This is a data network view of an alternative scalable E / EA architecture for Level 2 vehicles, according to an embodiment.

[0073] Figure 27 According to the embodiments Figure 26 The power network view of the alternative scalable E / EA architecture is shown.

[0074] Figure 28 This is a data network view of an alternative scalable E / EA architecture for Level 3 vehicles, according to an embodiment.

[0075] Figure 29 According to the embodiments Figure 28 The power network view of the alternative scalable E / EA architecture is shown.

[0076] The same reference symbols used in the various figures denote the same elements. Detailed Implementation

[0077] Reference will now be made in detail to the embodiments illustrated in the accompanying drawings. Numerous specific details are set forth in the following detailed description to provide a thorough understanding of the various described embodiments. However, it will be apparent to those skilled in the art that the described embodiments can be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail to avoid unnecessarily obscuring aspects of the embodiments.

[0078] "One or more" includes: functions performed by a single element; functions performed by more than one element, for example, in a distributed manner; several functions performed by a single element; several functions performed by several elements; or any combination of the foregoing.

[0079] It will also be understood that while the terms first, second, etc., are used in some instances to describe various elements herein, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, a first processor may be referred to as a second processor, and similarly, a second processor may be referred to as a first processor, without departing from the scope of the described embodiments. Both the first processor and the second processor are processors, but they are not the same processor.

[0080] The terminology used in the description of the various embodiments described herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used in the description of the described embodiments and the appended claims, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and / or” as used herein refers to and includes any one of the associated listed items and all possible combinations of one or more of the associated listed items. It will be further understood that the terms “includes” and “comprising”, when used in this application, specify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0081] As used herein, depending on the context, the term "if" may optionally be interpreted as "when," "once," "in response to determination," or "in response to detection." Similarly, depending on the context, the phrase "if determined" or "if [the stated condition or event] is detected" may optionally be interpreted as "once determined," "in response to determination," or "once [the stated condition or event] is detected," or "in response to detection of [the stated condition or event]."

[0082] Overview

[0083] The disclosed PDC is a combined data concentrator, router, and power divider that delivers scalable and affordable network / power redundancy to automotive E / EA supporting partially or fully autonomous vehicles. The PDC communicates bidirectionally with other PDCs and computing nodes via vehicle networks, buses, or data links. In some embodiments, the PDC includes circuitry and / or one or more processors configured to distribute power and receive, process, and / or transmit digital signals, analog signals, and / or data.

[0084] In some embodiments, the vehicle, including the intelligent E / EA, is divided into zones (e.g., placed at each corner of the vehicle chassis), wherein each zone includes one or more PDCs and one or more sensors (e.g., radar, lidar, stereo / mono camera, sonar), which are coupled to and powered by their respective zone PDCs. Each PDC collects and processes (or transmits via) raw or pre-processed sensor data from one or more sensors in its zone. The sensors provide their data to the PDCs via cost-effective short-range data links, including but not limited to: Controller Area Network (CAN) bus, CAN Flexible Data Rate (CAN-FD) bus, Camera Serial Interface (CSI), and Low Voltage Differential Signaling (LVDS). In some embodiments, one or more actuators in each zone are coupled to their respective zone PDCs and receive their control data from the PDCs via a high-speed data bus or data link.

[0085] In some embodiments, each region's (multiple) PDCs feed or transmit their collected sensor data (e.g., data packets) into a ring network. In some embodiments, the ring network is a multi-ring (e.g., dual-ring) self-healing data network. The ring network includes PDCs and one or more computing platforms for performing various vehicle functions (e.g., computing platforms for providing autonomous driving capabilities). Data traffic can travel in different directions on the same ring or different rings. For example, data packets can travel clockwise around a first ring and counterclockwise around a second ring, or both rings can transmit in the same clockwise or counterclockwise direction. Data traffic can be the same data (e.g., redundant data traffic), or it can be different data traffic. In some embodiments, data packets can be transmitted bidirectionally from one PDC to another, from one computing platform to another, from one PDC to another, and from one PDC to another computing platform, and from one PDC to a sensor or any other device. In some embodiments, one or more PDCs or computing platforms can broadcast data packets to other PDCs and computing platforms through the ring network.

[0086] As used herein, the term "self-healing" refers to the ability of a multi-ring data network to automatically bypass the faulty portion of the ring to allow data to continue flowing or be routed to other PDCs and computing platforms, as referenced. Figure 10 A more comprehensive description. As used herein, the term “failure” includes a ring degraded to below an acceptable level, such as below the Quality of Service (QoS) threshold variance.

[0087] If a PDC or ring component fails, the active PDC can reduce its corresponding output data frame rate, or instruct the sensors to reduce their output data frame rate to compensate for data latency, such as that caused by a long data path. In some embodiments, link degradation is detected by the PDC. In response to this detection, the PDC can retransmit data (e.g., packets) and / or (e.g., using compression) reduce the bandwidth and / or transmission rate of the data stream destined for the computing platform or remote operator. If the PDC fails, as referenced... Figure 10 As described, the PDC can transmit data on a redundant ring. The PDC can also instruct / request other sensors coupled to the PDC or to another PDC to reduce their respective bandwidth and / or transmission rate. In some embodiments, both the sensors and the PDC can reduce their bandwidth or transmission rate to ensure delivery to the computing platform.

[0088] In some embodiments, if a regional PDC malfunctions (e.g., the PDC is damaged as a result of a collision), a crossing sensor provides a minimum level of sensor coverage for the region. As used herein, a “crossing” or “crisscrossing” sensor refers to the coupling of at least one sensor in the first region to at least one PDC in the second region and the coupling of at least one sensor in the second region to at least one PDC in the first region. With a crossing sensor, the vehicle will have limited sensor coverage (e.g., limited radar data) in the damaged area, allowing the vehicle to perform safe mode maneuvers (e.g., “limphome” mode) at the expense of reduced vehicle functionality (e.g., reduced vehicle speed). In some subsequent embodiments, various types of sensors, including lidar, cameras, sonar, etc., can be “crossed.”

[0089] In some embodiments, redundant high-speed data links are used to couple the PDC to the computing platform. For example, two HDBaseT data links can be used to couple each PDC to a neighboring PDC and / or to one or more computing platforms. In this configuration, the failure of a single HDBaseT link will not result in sensor data loss. Latency can be compensated for by increasing camera data compression or reducing the frame rate. In some embodiments, a CAN-FD link can be used as a backup for HDBaseT. In some embodiments, a single HDBaseT data link and a single Ethernet data link are used to couple the computing platform together. In this configuration, the failure of all HDBaseT data links may result in functional failure without causing overall system failure. In some embodiments, redundancy is achieved using different protocols at several different physical layers.

[0090] In some embodiments, the PDC operates as a data router and / or performs processing. When operating as a router (e.g., in a fault mode), the PDC passes unprocessed raw sensor data to one or more computing platforms and other PDCs. In some embodiments, the PDC performs sensor data fusion and other data processing (e.g., lossless or lossy data compression, data formatting, and data transformation) by processing the raw sensor data locally in the PDC hardware using various filters, algorithms, transformations, and processes before feeding the sensor data to the multi-ring network. In this embodiment, the PDC essentially operates as a distributed computing node and provides a clock for fusing data. For example, the PDC can generate an object list by fusing stereo camera output data and LiDAR output data, and then send the object list through a ring network to a computing platform performing perception functions for autonomous driving. This reduces the load on the computing platform, allowing the computing platform to perform other functions. In some embodiments, the PDC includes circuitry in its data interface to measure network link performance to detect any QoS degradation.

[0091] In some embodiments, the PDC performs lossy or lossless data compression on the raw or processed sensor data before transmitting it to the data network. Lossy compression may be desirable if data is being transmitted for a remote control application. The PDC may also transmit lossless data to a computing platform in the vehicle while simultaneously transmitting lossy data to the remote operator.

[0092] In some embodiments, the PDC is configured to monitor sensor drift or other sensor calibration parameters and initiate recalibration of these parameters. If the PDC detects sensor drift or offset exceeding a desired threshold, it can proactively decide not to transmit data from the damaged sensor to the ring network. In some embodiments, the detection of sensor drift or offset is used by the PDC to predict sensor failure, enabling proactive steps by the PDC or one or more computing platforms in the vehicle to prevent sensor failure or initiate workaround solutions before failure occurs.

[0093] In addition to data redundancy, some embodiments of the disclosed PDC also deliver power redundancy to the E / EA by operating as a power divider for one or more sensors and actuators in the region. The PDC can be coupled to one or more power rails, each with its own backup battery. Moving power distribution from a centralized power source or supply system (e.g., vehicle electrical center) to each PDC allows the first-stage power electronics (e.g., filtering stage) to be moved from sensor hardware to PDC hardware, with the benefit of using less expensive sensors in the E / EA (due to fewer electronic components). Furthermore, coupling the battery to the PDC reduces or eliminates the need for fuses on the battery (which could burn out the ring segment to which the battery is coupled), as referenced... Figures 7-9 As described, PDC will use, for example, smart power switches to handle short-circuit protection.

[0094] In some embodiments, the E / EA includes two or more power loops supplying power to the PDC and computing platform from two or more redundant power sources (e.g., batteries) or supply systems (e.g., vehicle electrical center). In subsequent embodiments, each PDC has two power inputs, each coupled to one of the two power loops. The power inputs may be coupled (e.g., galvanic connections) within the PDC hardware and can be rapidly isolated relative to each other in response to a failure of one of the power sources or supply systems. In some embodiments, the PDC power inputs may use switching paths including diagnostics to support connected sensors and actuators. For example, the PDC may include smart switching devices that measure the rate of change of the PDC's input / output voltage and / or current, as well as temperature, and perform rapid switching in response to these changes to ensure that the computing platform and PDC receive power in the event of a power source or supply system failure. Smart switching can be used on any load connected to the PDC, and smart switching allows for smaller diameter cables, thus saving vehicle manufacturing costs. Smart switching also allows for thinner power cables and eliminates the need for fuse boxes.

[0095] In some embodiments, a small electronic control unit (ECU) controlling a single vehicle function (e.g., power liftgate, electric trailer hitch, power sun visor) or multiple vehicle functions (e.g., headlight or taillight control, seat control, trailer module) can be integrated into the PDC hardware. For example, loads, sensors, and actuators in a region that are controlled and supplied by the PDC and do not necessarily meet ISO 26262 requirements (e.g., comfort functions) can be supplied by the PDC hardware and software. The benefits of embedding small ECU functions into the PDC hardware include fewer total ECUs per vehicle and smaller wiring harnesses between the PDC and loads, sensors, and actuators. Smaller wiring harnesses can be manufactured more economically through automated manufacturing.

[0096] System Architecture

[0097] Figure 1A The figure illustrates an E / EA system architecture 100a, according to one embodiment, for data distribution in an autonomous vehicle using four PDCs. The E / EA system architecture 100a can be integrated into various types of vehicles. As defined herein, "vehicle" includes, but is not limited to: fuel-powered, electric, and hybrid passenger vehicles, trucks, buses, taxis, two-wheeled or three-wheeled vehicles (e.g., motorcycles, ATVs), construction or agricultural equipment (e.g., cement trucks, dump trucks, tractors, plows, harvesters, grain trucks), military vehicles (e.g., combat tanks, infantry fighting vehicles, armored personnel carriers, unmanned combat vehicles, armored combat support vehicles, etc.), marine vessels (e.g., ships, submarines, hovercraft), automated delivery robots, and drones.

[0098] In the illustrated embodiment, the E / EA system architecture 100a includes an Automated Driving Server (ADS) 101, a Connected Server Platform (CSP) 102, a Secure Connectivity Gateway (SCGW) 103, a Propulsion and Chassis Server (PCS) 104, PDCs 105a-105d, radars 106a-106h, lidars 107a-107e, and cameras 108a-108h (e.g., stereo or monochrome cameras). ADS 101, CSP 102, SCGW 103, and PCS 104 are also collectively referred to as a “computing platform”.

[0099] The ADS 101 includes hardware and software for performing several autonomous driving tasks, including but not limited to: route planning, trajectory planning and verification, perception processing, decision logic, implementation of control laws, localization, intersection handling, behavior inference based on the plan, lateral / longitudinal control, computation of real-world / environment models, and sensor data fusion.

[0100] CSP 102 is a scalable automotive server platform that includes hardware and software for running a variety of applications, such as Advanced Driver Assistance Systems (ADAS) applications, infotainment applications, and user applications (e.g., or Applications, video distribution, IP routing, microservices, behavior inference for planning, and human-machine interface (HMI) management.

[0101] The SCGW 103 includes hardware and software for securely managing cloud and peer-to-peer connectivity with various data services, including but not limited to: over-the-air (OTA) software updates, remote operator / remote control services, data analytics services, map database services, location services, entertainment services, security services, and original equipment manufacturer (OEM) services. The SCGW 103 also securely manages peer-to-peer connectivity with other vehicles, urban infrastructure (e.g., parking lights), roadside beacons, home networks, and more.

[0102] PCS 104 includes hardware and software for controlling vehicle driving functions such as acceleration, braking and steering.

[0103] For reference Figure 10 To describe it more fully, computing platforms 101-104 are coupled in a dual-ring self-healing network topology. This dual-ring network topology provides the required data redundancy for Level 3 / 4 / 5 autonomous driving. The data links between the computing platforms, PDC, and sensors are... Figure 1A The illustrations shown in the figure indicate this. In some embodiments, as previously described, the PDC 105a-105d also operate as a distributed computing node by performing functions such as data compression, sensor data fusion, and small ECU functions.

[0104] In some embodiments, computing platforms 101-104 and PDCs 105a-105d are coupled together via a first set of redundant data links (e.g., 8 Gbit / s HDBaseT, 10 Gbit / s Ethernet). Computing platforms 101-103 are coupled together via a second set of data links (e.g., 1 Gbit / s Ethernet). In some embodiments, radars 106a-106h are coupled to their respective regions PDCs 105a-105d via a CAN-FD bus. LiDAR sensors 107a-107e are coupled to their respective regions PDCs 105a-105d via a 1 Gbit / s Ethernet. Cameras 108a, 108b, 108c, 108g, and 108h are coupled to their respective regions PDCs 105a-105d via a CSI bus.

[0105] In some embodiments, forward-facing cameras 108d and 108f are directly coupled to ADS 101 via Low Voltage Differential Signaling (LVDS), and forward-facing camera 108e is also directly coupled to computing platform 103 via LVDS. In the event of a ring fault in which the forward-facing cameras are directly connected to ADS 101, the forward-facing cameras 108d and 108f remain operational. Alternatively, when the forward-facing cameras 108d and 108f are attached to the PDC, a partial ring fault may result in limited coverage depending on the nature of the fault but not necessarily due to redundant ring topology. For example, a full ring fault renders all sensors attached to the ring, but not those directly attached to ADS 101, unavailable. This could also be a fail-safe approach for a full ring fault in which some of the cameras are directly attached to ADS 101, thus at least some sensor coverage is maintained (e.g., using forward-facing cameras 108d and 108f), which allows the vehicle to perform a safe stop.

[0106] The vehicle can be divided into N regions, where each region includes one or more PDCs coupled to one or more sensors covering that region. In the illustrated embodiment, vehicle 100a is divided into six regions: front right, front left, rear right, rear left, left side, and right side. In the illustrated embodiment, additional redundancy is provided at the front and rear of the vehicle through “cross-sensoring.” For example, radar 106a in the rear left region is coupled to PDC 105d in the rear right region, and radar 106g in the rear right region is coupled to PDC 105a in the rear left region. Similarly, at the front of the vehicle, radar 106c in the front left region is coupled to PDC 105c in the front right region, and radar 106e in the front right region is coupled to PDC 105b in the front left region.

[0107] The E / EA 100a provides affordable network redundancy through a dual-ring self-healing network topology that includes PDCs and a computing platform. Cost-effective short-range data lines are used between sensors and PDCs. If a PDC fails due to a vehicle collision or other catastrophic event, the crossover of front / rear radar sensors provides minimal radar coverage. PDCs can operate as distributed computing nodes by performing sensor data fusion and / or data compression (e.g., lossless or lossy compression of camera data). Redundant data links are established from each PDC to neighboring PDCs and / or the computing platform, thus preventing single-link failures that could lead to sensor data loss (e.g., due to vehicle collisions, short circuits, or other catastrophic events). In fail-safe operation, increased data compression or lower frame rates can be used to increase network bandwidth and transmission rates. In the event of a single PDC failure, a CAN-FD bus can be used to couple the active PDC to the SCGW 103. Redundant high-speed data buses such as HDBaseT and Ethernet data links can be used to couple the computing platform together, thereby preventing all HDBaseT or Ethernet link failures from causing a system-wide failure.

[0108] Figure 1B The figure illustrates an E / EA system architecture 100b for data distribution in a vehicle with autonomous driving capabilities using four PDCs, according to some embodiments. In this embodiment, sensors are coupled to a computing platform and PDCs via redundant sensor loops, and the computing platforms are coupled to each other via redundant computing loops. Additional cameras 108i and 108k are located on the left and right sides of the vehicle, respectively. Additional cameras 108l and 108j are also located at the rear and front of the vehicle, respectively. Note that cameras 108a and 108g have been moved towards the front of the vehicle to be close to the driver and passenger doors. Furthermore, sonars 109a-109c are coupled to PDC 105b, sonars 109d-109f are coupled to PDC 105c, sonars 109g-109i are coupled to PDC 105d, and sonars 109j-109l are coupled to PDC 105a. In some embodiments, the PDC 105a-105d uses a Local Interconnect Network (LIN) bus to couple each sonar in their respective sonars. The LIN bus handles low-end multiplexed communication connections, while the CAN-FD bus is used for high-end operations requiring fast and efficient connections, such as error handling.

[0109] Compared to E / EA system architecture 100a, camera 108d is coupled to PDC 105b instead of ADS 101, and camera 108e is coupled to ADS 101 instead of SCGW 103. Cameras 108d-108f can have different fields of view and sensors with different resolutions (e.g., different numbers of pixels), such as 100° / 1.7MP, 120° / 7.4MP, and 28° / 7.4MP. Compared to E / EA system architecture 100a, PCS 104 is coupled to another platform ADS 101, CSP 102, and SCGW 103 via a redundant computing ring instead of PDC 105b and 105c, and radar 106h is coupled to PDC 105a instead of PDC 105d. Redundant data links between sensors, PDCs, and computing platforms are provided by... Figure 1B The legend above indicates this.

[0110] Figure 1C The diagram illustrates an E / EA system architecture 100c, according to some embodiments, for data distribution in a vehicle with autonomous driving capabilities using six PDCs. Placing four PDCs 105a-105d in each corner of the vehicle chassis, as shown in E / EA 100a, optimizes electronic costs, but potentially precludes automated wiring harness manufacturing due to the length of some sensor data paths. E / EA system architecture 100c includes additional PDCs 105e and 105f on the left and right sides of the vehicle. Adding two additional PDCs 105e and 105f allows for automated wiring harness production and improves functional safety by resulting in fewer sensor losses due to PDC failures. Generally, any number of PDCs can be included in the E / EA system architecture to scale the E / EA according to the optimization focus. In some embodiments, the target vehicle category / size, along with the possible number of sensors and electrical loads, can define the optimal number of PDCs to be included in the E / EA.

[0111] E / EA system architecture 100c includes the same number and types of sensors as E / EA system architecture 100b, but the data links for some sensors are shortened due to the additional PDCs 105e and 105f. For example, radar 106b and cameras 108i and 108a are now coupled to PDC 105e instead of PDCs 105a and 105b, and radar 106f and cameras 108k and 108g are now coupled to PDC 105f instead of PDCs 105c and 105d. PDC 105e is further coupled to computing platforms CSP 102, SCGW 103, and PDC 105b via a redundant computing ring and to forward-facing cameras 108d and 108e. PDC 105f is further coupled to CSP 102, PDC 105c, and forward-facing camera 108f.

[0112] Figure 1D The figure illustrates an E / EA system architecture 100d for data distribution in a vehicle with autonomous driving capabilities using six PDCs, according to some embodiments. In this embodiment, PDCs 105a-105f are coupled in a sensor ring, and ADS 101, CSP 102, SCGW 103a, and PCS 104 are coupled together in a server ring. This E / EA differs from the previously described architecture by including six audio speakers 111a-111f and one or more displays coupled to CSP 102, which are coupled to PDCs 105a-105f for receiving audio data. While the speakers 111a-111f are shown as active in this embodiment, in another embodiment, the speakers 111a-111f may be passive speakers, wherein amplification circuitry is included in PDCs 105a-105f to reduce heat generated by the active speaker circuitry.

[0113] The E / EA system architecture 100d also includes a remote transceiver unit (RTU) 110 and antennas for various wireless communication technologies. The RTU 110 includes one or more wireless transceiver chips and supporting circuitry. These wireless communication technologies include, but are not limited to: Bluetooth, car-to-car, WiFi, 5G, Global Navigation Satellite System (GNSS) (e.g., GPS), FM stereo, satellite radio, and any other communication hardware. In some embodiments, the antennas may be unidirectional, omnidirectional, multiple-input multiple-output (MIMO), antenna arrays, or any other type of antenna. In some embodiments, the antennas may be configurable and steerable. The RTU 110 is coupled to the SCGW 102 via two or more data links for redundancy.

[0114] Figure 1E The figure illustrates a method for using according to some embodiments. Figure 1D The E / EA system architecture 100d features CAN-FD fallback and power management. In the event of a failure of ADS 101 and CSP 102, the CAN-FD bus will couple PDC 105a-105f with SCGW 103. This configuration will allow information (e.g., sensor data) to be transmitted to the remote operator via RTU 110. This configuration also allows PDC 105a-105f to distribute power to their corresponding sensors to ensure sensor coverage across all areas of the vehicle.

[0115] Figure 1F The figure illustrates a method for using according to some embodiments. Figure 1D The E / EA system architecture 100d employs a redundant sensor ring topology. In this embodiment, the sensor ring includes six PDCs 105a-105f, an ADS 101, a CSP 102, and an SCGW 103. A redundant bridge couples PDC 105b to PDC 105c.

[0116] Figure 1G The figure illustrates a method for using according to some embodiments. Figure 1D The E / EA system architecture 100d features a redundant service ring topology. As shown, in this server ring, ADS 101, CSP 102, SCGW 103, and PCS 104 are coupled together for redundancy in the event of a sensor ring failure.

[0117] Figure 1H The figure illustrates an E / EA system architecture 100h according to some embodiments for data distribution in a vehicle with autonomous driving capabilities using four PDCs 105a-105d. E / EA 100h is similar to E / EA 100d, but lacks the left-side PDC 105e and right-side PDC 105f, as well as audio amplifiers 111b and 111e. Audio amplifier 111c and LiDAR 106b are coupled in series to PDC 105b, and audio amplifier 111d and LiDAR 106f are coupled in series to PDC 105c.

[0118] Figure 2A The diagram illustrates an embodiment of an automotive E / EA system architecture 100a for power distribution in a vehicle with autonomous driving capabilities and using four PDCs. In addition... Figure 1A In addition to the computing platform, sensors, and PDC shown in the image, Figure 2ARedundant electrical centers and power distribution (ECPDs) 201a and 201b, and redundant power supplies 202a and 202b (e.g., batteries) are also shown. The redundant ECPDs 201a and 201b provide safe power distribution for high-voltage circuits and manage battery power. Figure 2A As shown, ECPD 201a distributes a filtered 12-volt supply to CSP 102 and SCGW 103, and a stable voltage (e.g., 5V) supply to the forward-facing cameras 108d, 108e, and 108f. Figure 2A As shown, ECPD 201a, 201b, power supplies 202a, 202b, PDC 105a-105d, and ADS 101 are coupled to a redundant power supply loop (e.g., 12V).

[0119] PDCs 105a-105d distribute power (e.g., a stable 5V supply) to each of their respective area sensors and cross sensors. For example, PDC 105a provides power to its respective area sensors (sensors 107a, 108a, 108h) and cross sensor (sensor 106g), PDC 105b provides power to its respective area sensors (sensors 107b, 107c, 108b) and cross sensor (sensor 106e), PDC 105c provides power to its respective area sensors (sensors 106d, 107d, 108c) and cross sensor (sensor 106c), and PDC 105d provides power to its respective area sensors (sensors 106h, 107d, 108d) and cross sensor (sensor 106a).

[0120] The above Figure 1A and Figure 2A The E / EA 100a described herein provides affordable power redundancy through the use of a redundant power loop and a hybrid approach involving the vehicle electrical center and PDC. Redundant power supplies (e.g., 12V batteries) power the PDC and computing platform. Sensors are supplied with a stable and filtered power supply (e.g., 5V). No sensor or computing platform is lost due to a single power supply failure.

[0121] Figure 2B The diagram illustrates an embodiment of an automotive E / EA system architecture 100b for power distribution in a vehicle with autonomous driving capabilities and using four PDCs. In this embodiment, compared to Figure 2AIn an embodiment of E / EA 100a, ECPD 201a has been removed, and ECPD 201b is coupled to a 12-volt power supply loop, camera 108i, and PDC 105b. PDCs 105a-105d are each coupled to two redundant power loops and distribute power (e.g., a 12V supply) to each of their respective area sensors and cross sensors. In some embodiments, PDCs 105a-105f use power over coax (POC) to power at least some of their area sensors (e.g., cameras). For example, PDC 105a uses a POC to power cameras 108a and 108l. Cameras 108b, 108d, and 108i are powered by PDC 105b using a POC, and cameras 108e and 108f are powered by ADS 101. PDCs 105a-105f supply filtered 12V to computing platforms 101-104. Power supplies 202a and 202b are directly coupled to PDCs 105b and 105d, respectively.

[0122] Figure 2C The figure illustrates an embodiment of an automotive E / EA system architecture 100c for power distribution in a vehicle with autonomous driving capabilities that uses six PDCs 105a-105f. Figure 2C ECPD 201b and redundant power supplies 202a, 202b (e.g., batteries) are shown. PDCs 105a-105f distribute power (e.g., 12V supply) to each of their respective area sensors and cross sensors. PDCs 105e, 105f and computing platforms 101-104 are all coupled to a first 12V filtered power loop. PDCs 105a-105f are coupled to a second 12V power loop. PDCs 105a-105f distribute power (e.g., 12V supply) to each of their respective area sensors and cross sensors. In some embodiments, PDCs 105a-105f use a POC to power at least some of their area sensors (e.g., cameras). Cameras 108d, 108e are powered by PDC 105e, and camera 108f is powered by PDC 105f.

[0123] Figure 2DThe diagram illustrates an embodiment of an automotive E / EA system architecture 100d for power distribution in a vehicle with autonomous driving capabilities and using six PDCs. Each PDC 105a-105f is dedicated to a specific area of ​​the vehicle, and power from power supplies 202a, 202b is distributed to their respective area sensors. Note that the RTU 110 is powered by the SCGW 103. Also note that cross-connected sensors are used between the right front and left front areas, and between the right rear and left rear areas, to ensure at least minimum radar coverage in these areas in the event of a PDC failure.

[0124] Figure 2E The diagram illustrates an embodiment of an automotive E / EA system architecture 100e for power distribution in a vehicle with autonomous driving capabilities and using four PDCs. Each PDC 105a-105d is dedicated to a specific area of ​​the vehicle, and power from power supplies 202a, 202b is distributed to their respective area sensors. Note that the RTU 110 is powered by the SCGW 103. Also note that cross-connected sensors are used between the right front and left front areas, and between the right rear and left rear areas, to ensure at least minimum radar coverage in these areas in the event of a PDC failure.

[0125] According to some embodiments, Figure 3A The diagram illustrates the fail-safe procedures performed on the vehicle prior to the PDC 105b malfunction, and Figure 3B The diagram illustrates fail-safe operation of the vehicle following a PDC 105b malfunction. Note that due to the PDC 105b malfunction (indicated by a large "X"), camera 108b and lidar units 107b and 107c are disabled (e.g., due to loss of data link, power, or both), but lidar unit 106c remains active due to its coupling with PDC 105c. Therefore, the front left area remains covered by lidar after the PDC 105b malfunction. Note that PCS 104 continues to receive sensor data from PDC 105c, allowing the driving system to remain operational. Although lidar unit 107c is disabled, the front area of ​​the vehicle remains covered by camera 106d.

[0126] According to some embodiments, Figure 3C The diagram illustrates the fail-safe procedures performed on the vehicle prior to the PDC 105b malfunction, and Figure 3D The diagram illustrates fail-safe operation of the vehicle following a PDC 105b failure. While sensors coupled to the PDC 105b are no longer available (e.g., due to lost data links, power, or both), the E / EA compensates for the complete loss of the PDC 105b. For example, radar 106c coupled to the PDC 105c provides minimal radar coverage in the damaged area.

[0127] According to some embodiments, Figure 3E The diagram illustrates fail-safe operation of a vehicle with six PDCs prior to PDC failure, and Figure 3F The diagram illustrates fail-safe operation of a vehicle with six PDCs following a PDC failure. While sensors coupled to PDC 105b are no longer available (e.g., due to lost data links, power, or both), E / EA compensates for the complete loss of PDC 105b. For example, radar 106c coupled to PDC 105c provides minimal radar coverage in the damaged area.

[0128] According to some embodiments, Figure 4A The diagram illustrates the fail-safe procedures performed on the vehicle prior to the SCGW 103 fault, and... Figure 4B The diagram illustrates fail-safe operation of the vehicle following an SCGW 103 malfunction. Note that radars 106b and 106d, and camera 108e are disabled due to the SCGW 103 malfunction (indicated by a large "X") (e.g., due to a lost data link, power, or both). While camera 108e is disabled, cameras 108d and 108f remain operational to cover the front area of ​​the vehicle. Although radars 106b and 106d are disabled, cameras 108a, 108b, 108c, and 108e remain operational to cover the right and left sides of the vehicle due to their position on the vehicle and the direction they are pointing.

[0129] In some embodiments, camera sensors 108a, 108b, 108c, and 108e can have their respective fields of view adjusted (e.g., widened) by their respective PDCs to further compensate for losses in radar 106b and 106f. Computational platforms 101, 102, and 104 still receive sensor data from PDCs 105a-105c, thus allowing critical vehicle driving systems to remain operational. All CAN-FD connections from SCGW 103 to PDCs 105a-105d are disabled but replaced by HDBaseT data links.

[0130] According to some embodiments, Figure 4C The diagram illustrates the fail-safe procedures performed on the vehicle prior to the SCGW 103 fault, and... Figure 4D The diagram illustrates fail-safe operation of the vehicle following a SCGW 103 failure. E / EA will function without the SCGW 103. Although the CAN connection from the SCGW 103 to the PDCs 105a-105f is missing, CAN traffic can still be conducted on HDBaseT. Because the SCGW 103 is not directly coupled to any sensors, all sensors remain available, and their data can be transmitted to the computing platform and other PDCs on the sensor ring.

[0131] According to some embodiments, Figure 4E The diagram illustrates the fail-safe operation of a vehicle with six PDCs prior to a failure of the computing platform (e.g., 103), and Figure 4F The diagram illustrates fail-safe operation of a vehicle with six PDCs following a computing platform failure. Although the connection to RTRU 110 is lost with the failure of SCGW 103, PDCs 105a-105f, ADS 101, CSP102, and PCS 104 can continue to communicate with each other without SCGW 103.

[0132] According to some embodiments, Figure 5A The diagram illustrates the vehicle's fail-safe procedures prior to the ADS 101 fault, and... Figure 5B The diagram illustrates fail-safe operation of the vehicle following a failure of ADS 101. Note that due to the failure of ADS 101 (indicated by a large "X"), emergency trajectory and driving controls from CSP 102 are in "limp home" mode (e.g., remote control or assistance via a remote operator). While forward-facing cameras 108d and 108e are disabled, camera 108 remains operational. All other sensors remain available to CSP 102.

[0133] According to some embodiments, Figure 5C The diagram illustrates the vehicle's fail-safe procedures prior to the ADS 101 fault, and... Figure 5D The diagram illustrates fail-safe operation of the vehicle following a failure of ADS 101. E / EA is capable of compensating for the complete loss of ADS 101. Emergency trajectory and driving control from CSP 102 are used in "limp home" mode. Only the two forward-facing cameras are unavailable. All other sensors remain available to CSP 102. In some embodiments, CSP 102 can provide the latest optimal trajectory, which is stored and periodically updated.

[0134] According to some embodiments, Figure 5E The diagram illustrates the fail-safe operation of a vehicle with six PDCs prior to a failure of the computing platform (e.g., 101), and Figure 5F The diagram illustrates fail-safe operation of a vehicle with six PDCs following a computing platform failure. The E / EA is capable of compensating for the complete loss of ADS 101. Emergency trajectory and driving control from CSP 102 are used in Limp Home mode. Only the two forward-facing cameras are unavailable. All other sensors remain available to CSP 102. RTU 110 also remains operational and can be used to communicate with a remote operator who can assist the vehicle in Limp Home mode.

[0135] According to some embodiments, Figure 6A The diagram illustrates the fail-safe operation of the vehicle prior to the power supply 202a fault, and... Figure 6B The diagram illustrates fail-safe operation of the vehicle following a power supply 202a failure. Note that due to the failure of power supply 202a (indicated by a large "X"), the redundant power ring topology uses power supply 202b to power PDCs 105a-105d and computing platforms 101-104. No sensors or computing platforms are disabled due to the failure of power supply 202a.

[0136] According to some embodiments, Figure 6C The diagram illustrates the fail-safe operation of the vehicle prior to the power supply 202a fault, and... Figure 6D The diagram illustrates fail-safe operation of the vehicle following a power supply failure 202a. The E / EA is capable of compensating for the complete loss of power supply 202a. A ring topology supplies all PDCs from a second power supply 202b. All sensors and computing platforms are available after a power failure. In some embodiments, in the event of a power failure (e.g., a short circuit), one or more segments of the ring connected to power supply 202b may have to be slashed to a lower voltage.

[0137] According to some embodiments, Figure 6E The diagram illustrates fail-safe operation of a vehicle with six PDCs prior to a power supply (e.g., 202a) failure, and Figure 6F The diagram illustrates fail-safe operation of a vehicle with six PDCs following a power supply failure. The E / EA is capable of compensating for the complete loss of power supply 202a. A ring topology supplies all PDCs from a second power supply 202b. All sensors and computing platforms are available after the power failure. In some embodiments, in the event of a power failure (e.g., a short circuit), one or more segments of the ring connected to power supply 202b may have to be slashed to a lower voltage.

[0138] PDC architecture

[0139] Figure 7 This is a conceptual block diagram of a PDC architecture 700 according to some embodiments. The PDC architecture 700 includes three integrated circuit chips: a PDC IO SoC 701, a PDC data SoC 702, and a smart 5V power switch (SPS) 703. The SPS 703 includes power input terminals 705a and 705b for coupling to a 12V power loop and redundant power output terminals 709 for supplying a stable and filtered voltage (e.g., 5V) to cameras, radar, and lidar.

[0140] The PDC IO SoC 701 includes a radar port 708a for communicating with a radar and an SCGW port 708b for communicating with an SCGW 102. In the illustrated embodiment, each of the radar ports 708a is coupled to a 3 Mbit / s dual CAN-FD bus, and the SCGW port 708b is coupled to a 3 Mbit / s single CAN-FD bus.

[0141] The PDC data SoC 702 includes interfaces 704a and 704b configured to couple to an HDBaseT 4GBit / se 1x unshielded twisted-pair (UTP) high-speed bus. In some embodiments, interfaces 704a and 704b are field-programmable gate arrays (FPGAs) programmed with logic to implement various physical (PHY) layers, including but not limited to HDBaseT, Digital Hardware Device Interface (DHDI), Peripheral Component Interconnect Fast (PCIe), and the VA6000. Utilizing native networking capabilities over a single UTP cable up to 15 meters (50 feet), the VA6000 enables symmetrical tunneling of multimedia content. The VA6000 can be used as a point-to-point tunneling solution for several applications running simultaneously on a single cable or in a daisy-chain topology and is suitable for use in automotive infotainment networks. PCIe is a high-speed serial computer extension bus standard. HDBaseT is a standard for ultra-high-definition video and audio transmission, Ethernet, control, and universal serial bus over a single long-distance cable.

[0142] The PDC data SoC 702 also includes camera ports 706a and 706b, and LiDAR ports 707a and 707b. Camera ports 706a and 706b are configured to be coupled to a camera data bus (e.g., 1 Gbit / s CSI), and LiDAR ports 707a and 707b are configured to be coupled to an Ethernet network (e.g., 1 Gbit / s Ethernet).

[0143] During operation, the PDC IO SoC 701 sends control signals to the SPS 703 via a first serial communication interface (e.g., Inter-Integrated Circuit (I2C) control signal), and the PDC data SoC 702 sends control signals to the PD IO SoC 701 via a second serial communication interface (e.g., a 1Gbit / s Serial Gigabit Media Independent (SGMI) interface).

[0144] Figure 8This is a conceptual block diagram of a PDC architecture 800 according to some embodiments, which includes a power board 801 and a data board 802. The PDC architecture 800 is similar to the PDC architecture 700, but includes a 4-port PCIe switch 804 and smart switches 803a-803c. The PCIe switch 804 provides add-drop multiplexing (ADM) and connectivity to HDBaseT data FPGAs 704a and 704b. In the event of a short circuit or other power failure event in the loop, smart switch 803a protects 703, and smart switches 803b and 803c disconnect the power loop.

[0145] Figure 9 This is a conceptual block diagram of a PDC architecture 900 without a PDC IO SoC 701, according to some embodiments. The PDC architecture 900 integrates the functionality of the PDC IO SoC 701 and the HDBaseT interface (FPGA) into the PDC data SoC 702, thereby reducing the chipset from three chips to two chips and eliminating the need for separate data and power boards.

[0146] refer to Figures 7-9 The described PDC architecture can be contained in a single housing or multiple housings. For example, a first housing may include data processing circuitry and software, and a physically separate second housing may include power distribution circuitry.

[0147] Figure 10 This diagram illustrates a conceptual block diagram of a dual-ring self-healing network topology in the event of a PDC failure, according to some embodiments. In the illustrated embodiment, the dual-ring self-healing network 1000 includes a computing platform 1001 (e.g., ADS 101), a computing platform 1003 (e.g., CSP 102), PDC1 1002a (area A), PDC2 1002b (area B), and sensors 1004a-1004f. In this embodiment, there are two areas A and B. Sensors 1004a-1004c and PDC1 1002a serve area A, and sensors 1004d-1004f and PDC2 1002b serve area B. Data links 1005a-1005c include a first data ring, and data links 1006a-1006c include a second data ring. According to... Figure 10 The orientation of the components shown in the figure indicates that data flows clockwise through data links 1005a-1005c and counterclockwise through data links 1006a-1006f.

[0148] Assuming PDC1 1002a fails (indicated by a large "X"), the circuits (e.g., intelligent switching circuits) in computing platform 1001 and PDC2 1002b will automatically initiate a "self-healing" process. This process, along with data links 1005b, 1005c, 1006a, and 1006b, forms a new loop as shown at points 1007a and 1007b. Correspondingly, if PDC1 1002a (or data links 1005a and 1006c) fails, the dual-loop self-healing network 1000 automatically forms a new loop, allowing computing platform 1001, computing platform 1003, and PDC2 1002b to continue transmitting data to each other through this new loop, while the vehicle transitions to a safe mode and slows down. After the new ring is formed, in some embodiments, the active PDC2 1002b slows down its frame rate and commands the sensors 1004d-1104f to slow down their frame rates to compensate for the data latency caused by the increased distance between the PDC2 1002b and the computing node 1001.

[0149] In some embodiments, the vehicle's electrical and electronic system (e.g., 100a) includes a first PDC (e.g., 105a, 105b, 105c, 105d, 105e, 105f, 1002a, or 1002b), a first computing platform (e.g., 101, 102, 103, 104, 1001, or 1003), and a first data platform (e.g., 101, 102, 103, 104, 1001, 1003, 105a, 105b, 105c, 105d, 105e, 105f, 1002a, or 1002b). In some embodiments, the first PDC includes circuitry and / or one or more processors configured to process data (e.g., receive data, transmit data, and / or perform calculations) and allocate power. In some embodiments, the first computing platform includes circuitry and / or one or more processors that primarily process data and perform calculations for autonomous driving. In some embodiments, the first computing platform does not allocate power to other system components. In some embodiments, the first data platform is a second PDC (e.g., 105a, 105b, 105c, 105d, 105e or 105f) or a second computing platform (e.g., 101, 102, 103 or 104).

[0150] The first PDC is connected to the first computing platform via two different paths, which include the first path (e.g., Figure 1B The middle sensor loop, in clockwise order from PDC 105b to ADS 101, and the second path (e.g., Figure 1BThe portion of the sensor loop from PDC 105b to ADS 101 in a counter-clockwise direction includes a first data platform (e.g., 105c or SCGW 103) and a second path does not include the first data platform (e.g., 105c or SCGW 103).

[0151] In some embodiments, the first PDC is connected to the first computing platform without utilizing intermediate PDCs or computing platforms. In some embodiments, the first PDC is connected to the first computing platform via one or more other PDCs or computing platforms. In some embodiments, the path is a continuous communication link between two points in the system (e.g., the first PDC and the first computing platform), wherein the communication link includes any system components (cable connections, PDCs, computing platforms, etc.) between the two points.

[0152] The first PDC includes a first sensor interface (e.g., 701, 708a, 706a, 706b, 707a, 707b) configured to receive sensor data from one or more sensors (e.g., 107a, 108a, 108h, 106g) and a first data interface (e.g., 702, 704a, 704b) configured to transmit the sensor data. In some embodiments, the first data interface includes multiple output ports (e.g., 704a and 704b are connected to different paths of the network ring).

[0153] A first data interface of a first PDC is configured to transmit sensor data to a first computing platform via a first path and a second path (e.g., the first data interface provides a connection to a communication link between the first PDC and the first computing platform). In some embodiments, the first data interface of the first PDC is configured to transmit sensor data to the first computing platform via a first path while simultaneously transmitting sensor data to the first computing platform via a second path. In some embodiments, the first data interface of the first PDC is configured to transmit sensor data to the first computing platform via only one path at a time (e.g., the first PDC can transmit sensor data to the first computing platform via either path).

[0154] In some embodiments, the first PDC is configured to: transmit sensor data to the first computing platform via the first path based on a determination that the first path is not faulty (e.g., the first path is operating at or above a threshold level); and transmit sensor data to the first computing platform via the second path based on a determination that the second path is faulty (e.g., the second path is downgraded to below a threshold level).

[0155] In some embodiments, the first path, the second path, the first PDC, and the first computing platform form a first ring network (e.g., 100a). Figure 1A ), 100b Figure 1B ), 100c ( Figure 1C ), 100d ( Figure 1D ), 100f ( Figure 1F ) or 100h ( Figure 1H The first ring network is configured to transmit sensor data. For example, in the first ring network, a first end of a first path (e.g., a first PDC) is a second end of a second path, and a second end of the first path (e.g., a first computing platform) is a first end of the second path (e.g., the first path ends at the beginning of the second path, and the second path ends at the beginning of the first path; the first and second paths begin at the same first location and end at the same second location). In some embodiments, the start and end of a path are interchangeable (e.g., correspondingly, the first end of the first path may be referred to as the start or end of the first path, and the second end of the first path may be referred to as the end or start of the first path).

[0156] In some embodiments, the system includes a second PDC, which is included in either the first or second path (e.g., the second PDC is in the second path but not in the first path, or in the first path but not in the second path). In some embodiments, the system includes a first sensor (e.g., 106a-106h, 107a-107e, 108a-108f, or 1004a-1004f) and a second sensor. The first sensor is connected to the first PDC, and the second sensor is connected to the second PDC. The physical distance from the first sensor to the first PDC is less than the physical distance from the first sensor to the second PDC (e.g., the first sensor is in a first region of the vehicle, the first PDC is in the first region of the vehicle, and the second PDC is in a second region of the vehicle). The physical distance from the second sensor to the first PDC is less than the physical distance from the second sensor to the second PDC (e.g., the second sensor is in the same region as the first sensor; the second sensor is cross-coupled (coupled to PDCs in different regions)). In some embodiments, the first sensor is connected to the first PDC without utilizing an intermediate PDC or computing platform. In some embodiments, the second sensor is connected to a second PDC without utilizing an intermediate PDC or computing platform.

[0157] In some embodiments, the first PDC is connected to the second PDC without utilizing an intermediate PDC or computing platform (see, for example...). Figure 1F(105b and 105c are connected by redundant bridges). In some embodiments, the first computing platform is configured to: receive power via the first PDC based on a determination that the first PDC is functioning (e.g., the first PDC is operating at or above a threshold level; the first PDC is not in a fault state); and receive power via the second PDC based on a determination that the first PDC is not functioning (e.g., the first PDC is not operating or is operating below a threshold level; the first PDC is in a fault state). In some embodiments, the system is configured to: provide power to the first computing platform via the first PDC based on a determination that the first PDC is functioning; and provide power to the first computing platform via the second PDC based on a determination that the first PDC is not functioning.

[0158] In some embodiments, the system includes a second computing platform and a third computing platform, and the system is configured such that the first computing platform is routed via a third path including the third computing platform (e.g., 101). Figure 1B The portion of the central computing ring (counterclockwise from 102 to 103) is connected to the second computing platform, and the first computing platform is connected via a fourth path (e.g., Figure 1B The central computing ring (from 102 to 103 in a clockwise direction) is connected to the second computing platform. This fourth path differs from the third path and does not include the third computing platform (e.g., 101). In some embodiments, the second computing platform is the first data platform.

[0159] In some embodiments, the third path, the fourth path, the first computing platform, the second computing platform, and the third computing platform form a second ring network (e.g., Figure 1B The computational ring or Figure 1G (Server ring in the system). In some embodiments, the third path does not include the first PDC and the fourth path does not include the first PDC (e.g., the server ring does not include the PDC).

[0160] In some embodiments, the system includes a first power supply loop (e.g., Figures 2A-2E The first power supply ring includes a first PDC and a first power source (e.g., 201a, 201b, 202a, or 202b) connected to it. A first computing device is coupled to the first power supply ring. In some embodiments, the first power source is tapped to the power supply ring (e.g., a power ring in the first power supply ring). Figure 2A In 202a) or connected to the first PDC (e.g., Figure 2B (202a) in some embodiments. In some embodiments, the first computing device is connected to a power supply ring (e.g., a component connected to a power supply ring, such as...). Figure 2A 102 or Figure 2B 104 in the middle), or the first computing device is part of the power supply ring (such as, Figure 2A 104 in the middle).

[0161] In some embodiments, the system includes a second power source coupled to a first power supply ring. In some embodiments, a first PDC is configured to: receive power from the first power source based on a determination that the first power source is functioning (e.g., the first power source is operating at or above a threshold level; the first power source is not in a fault state); and receive power from the second power source based on a determination that the first power source is not functioning (e.g., the first power source is not operating or is operating below a threshold level; the first power source is in a fault state). In some embodiments, a first computing platform is configured to: receive power from the first power source (e.g., via the first PDC) based on a determination that the first power source is functioning (e.g., the first power source is operating at or above a threshold level; the first power source is not in a fault state); and receive power from the second power source (e.g., via the second PDC) based on a determination that the first power source is not functioning (e.g., the first power source is not operating or is operating below a threshold level; the first power source is in a fault state). In some embodiments, the system is configured to: provide power from the first power source to the first computing platform based on a determination that the first power source is functioning; and provide power from a second power source (e.g., via a second PDC) to the first computing platform based on a determination that the first power source is not functioning.

[0162] PDC process

[0163] Figure 11 This is a flowchart illustrating process 1100 performed by the PDC during normal operation according to some embodiments. Process 1100 can be found in references. Figures 7-10 The described PDC architecture implementation. Process 1100 begins by receiving sensor data from one or more sensors via the sensor interface of the PDC (1101). In some embodiments, the data input port and data output port of the PDC are coupled to two or more redundant self-healing data loops.

[0164] Process 1100 continues with the following steps: Sensor data is transmitted via the output port of the PDC to a ring network (e.g., a multi-ring self-healing network) coupled to the PDC and at least one computing platform (1102). In some embodiments, multiple PDCs are assigned to cover areas of the vehicle. Each PDC acts as a data concentrator and router for sensors in its area. The PDC collects raw or pre-processed sensor data and transmits it to the ring network. In some embodiments, the PDC compresses the raw sensor data before transmitting it to the ring network or performing sensor fusion.

[0165] Process 1100 continues with the following steps: at least one autonomous driving operation is determined by at least one computing platform based at least in part on the received sensor data (1103). In some embodiments, the computing platform is an automated driving server (e.g., ADS 101) that includes hardware and software for performing several autonomous driving tasks, including but not limited to: route planning, trajectory planning and verification, perception processing, decision logic, implementation of control laws, localization, intersection handling, behavior planning, lateral / longitudinal control, computation of real-world / environment models, and sensor data fusion.

[0166] Process 1100 continues with the following steps: the vehicle performs at least one autonomous driving operation (1104) by at least one computing platform. For example, ADS 101 may generate a route to a destination or calculate maneuvers around objects detected on an object map.

[0167] Figure 12 This is a flowchart illustrating a process 1200 performed by a PDC for monitoring a data network in a vehicle, according to some embodiments. Process 1200 can be found in references. Figures 7-10 The described PDC architecture implementation.

[0168] Process 1200 begins by monitoring the data network in the vehicle (1201). The process continues with the following steps: determining whether a fault exists in the data network (1202). Based on the determination that a fault exists in the data network, (multiple) PDCs are configured as described in the reference... Figures 3A-3F , Figures 4A-4F , Figures 5A-5F as well as Figure 10 The data network is reconfigured as described (1203).

[0169] Figure 13 This is a flowchart illustrating a process performed by a PDC for monitoring a power network in a vehicle, according to some embodiments. Process 1300 can be found in reference... Figures 7-10 The described PDC architecture implementation.

[0170] Process 1300 begins by monitoring the power network in the vehicle (1301). Process 1300 continues with the following steps: determining whether a fault exists in the power network (1302). Based on the determination that a fault exists in the power network, (multiple) PDCs are configured as described in the reference... Figures 6A-6F The power network is reconfigured as described (1303).

[0171] Implementation of data links using transparent components

[0172] Figure 14A The illustration depicts a concept for an Open Automotive Server Alliance (OCSA) server system, based on some embodiments. The OCSA server system concept aims to help the automotive industry standardize how software and hardware updates are tested and deployed in future vehicles.

[0173] Autonomous vehicles can be updated on-site to keep them up-to-date. In existing systems, hardware can only be updated if a new version of the hardware is available that is compatible with the space allocated for that hardware and the existing interface to the vehicle's E / EA. The OCSA server system concept addresses this problem by using PDC to abstract I / O functions from physical I / O (e.g., I / O virtualization) to enable server updates. In some embodiments, OCSA provides at least the following advantages: 1) I / O configuration does not change with updates to server components; 2) new server hardware adapts seamlessly in new vehicles and in legacy applications; and 3) updates can be completed at any time during vehicle production; model year synchronization is not required.

[0174] refer to Figure 14A The existing hardware / software business model in the automotive industry requires software to be developed only on a target system (e.g., a specific vehicle model and manufacturing) and tested only along with other applications. Under this model, any small change to the software or hardware requires a new test run. Using the OCSA concept, software development is performed on a computer-based reference system where the application software is independent of the target hardware and can be developed on a computer system (e.g., a personal computer). Furthermore, testing of the application software can be performed in a reference environment independent of any other application. OCSA enables the identification of standardized sources of computing power for vehicles. OCSA-compatible devices are adaptable across various vehicles and can be changed at any time. Software can be reused without modification and without requiring specialized certification. OCSA reduces the engineering required to deploy the latest computing devices in vehicles.

[0175] In some embodiments, the OCSA server platform: 1) abstracts software from hardware to maximize software reusability and portability (future-sensitive and backward-compatible); 2) reduces complexity by developing software and hardware in parallel; 3) uses a cloud-based OTA platform with built-in security mechanisms to configure, provision, and update software; and 4) scales software and hardware with a flexible server architecture, where the number and size of compute blocks vary.

[0176] For example, the OCSA hardware platform can be a scalable automotive server hardware platform that allows for scaling of the number and size of SoCs. High-speed data links (e.g., PCI-E or Thunderbolt 3) can be used to connect the SoCs. HDBaseT and Ethernet links can be used for inputs (e.g., cameras) and outputs (e.g., displays). 8Gbit / s–10Gbit / s HDBaseT or Ethernet can be used to connect to the ADS. Additionally, the number of 1Gbit / s and 100Mbit / s Ethernet ports is scalable.

[0177] The OCSA software platform includes: a hypervisor with a service OS (domain 0) that abstracts hardware for other virtual machines; a flexible HMI manager in domain 1 that handles a flexible number of screens and tiles; and optional... Partitioning can handle applications and Services; a microservices platform that runs containerized software and is deployed at runtime; Greengrass™ cores for running IoT-connected applications. Web Services (AWS) λ functionality; a fixed number of virtual machines (VMs) with microservice VMs and Greengrass cores that can be deployed before runtime, and a flexible number of VMs.

[0178] Figure 14B This diagram illustrates a conceptual block diagram of OCSA server system hardware according to some embodiments. In this embodiment, the vehicle component data link is implemented as a transparent PCIe interface 1400 (e.g., a PCIe switch) using HDBaseT or any other PCIe physical connection. Each vehicle component has a data endpoint to which it is connected within the PDC SoC.

[0179] In the illustrated embodiment, the hardware components include a camera data decoder, a display and image processing unit (GPU) SoC, an AI accelerator SoC, an SDN router SoC, a security processor (ASIL D), HDBaseT PCIe chip 1, HDBaseT PCIe chip 2, HDBaseT chip 3, and HDBaseT PCIe chip 4. Also coupled to the PCIe interface 1400 are the ADS 101 and host CPU SoC_1, host CPU SoC_2, ..., host CPU SoC_n. The host CPUs communicate with each other using high-speed CPU-to-CPU links. HDBaseT chips 1 and 2, and HDBaseT chips 3 and 4 provide single / redundant interfaces for the sensor ring and server ring, respectively, to the host CPU SoC and the PDC IO processor. The SDN router SoC handles all network connectivity and system health. Low-latency HDBaseT direct PCIe links couple the PDC to other service devices. Virtual drives in the PDC provide a unified sensor view.

[0180] The SoC receives data from components and may or may not perform data processing / transformation algorithms (e.g., data size compression, radar sensor computation algorithms, etc.). Each vehicle computing platform requires data from components to establish a transparent link within a PCIe-based component data link from the PDC SoC to the computing platform. The computing platform initiates drivers for each transparent component data link, and the component behaves like a logical device to the computing platform. In this embodiment, the PDC operates as a component hub to the computing platform (e.g., similar to a plug-in station to a mobile device). The PDC SoC uses PCIe mechanisms (e.g., I / O virtualization) to transfer processed and unprocessed component data (e.g., sensor data) to one or more physical locations on one or more vehicle computing platforms. The PDC SoC controls the logical devices used for component data and allows access to the component data, and also uses logic sensor drivers to implement control and system diagnostics for the entire component.

[0181] In some embodiments, the PDC and computing platform enable multiple component data links to transfer data from these components to multiple computing platforms. PCIe achieves this feature by multicasting from a data source to multiple PCIe devices. Data does not need to be transmitted multiple times using the same component data link. Instead, data is replicated at the component, which is the first connection between the component and the computing platform, thereby saving data bandwidth on the component data link. Data may be replicated multiple times at different PDCs or computing platforms. However, only one computing platform can exercise control over the component. All other computing platforms are able to receive component data in an unchanged form.

[0182] The PDC can also master multiple component data drivers to transfer data from one component to multiple computing platforms using different data processing / transformation algorithms or different routes within the component data link ring structure. PCIe enumeration is performed by a PCIe core subsystem that searches the bus, applies modifications (if necessary) based on the identifier (ID) of the endpoint device, and then loads the driver with the matching ID in its discovery function. In some embodiments, bus-padding is used, and the number of PCIe buses and memory segments are reserved for potential future devices with "hot-plugging" capabilities without interruption, making the system highly scalable.

[0183] Figure 14C This diagram illustrates a conceptual block diagram of OCSA server system software according to some embodiments. In some embodiments, a hypervisor separates multiple software domains on each SoC device. In some embodiments, the hypervisor is a VM monitor (VMM) implemented in computer software, firmware, or hardware and runs a VM. The hypervisor presents a virtual operating platform to a guest operating system and manages the execution of the guest operating system. Multiple instances of various operating systems can share virtualized hardware resources, including but not limited to: and These instances can all run on a single SoC.

[0184] like Figure 14C As shown, OSCA hardware vendors provide fully abstracted hardware and flexible HMI managers implemented on virtual machines VM0 and VM1 respectively. OSCA software vendors develop their software on a computer-based reference system. For example, the application manager runs on virtual machine VM2 and supports several software applications (e.g., (Application). The microservice manager runs on virtual machine VM3 and supports several microservices. Virtual machine VM4 supports... AWS Web Services (AWS) lambda functionality. VM5 supports infotainment and navigation applications. VM6 supports instrument cluster applications (e.g., using QNX, integrity, and secure Linux). VM7 supports ADAS applications. AWS Greengrass is software that extends AWS cloud capabilities to on-premises devices, enabling those devices to collect and analyze data closer to information sources while securely communicating with each other on their local networks. Developers using AWS Greengrass can create serverless code (AWS lambda functionality) in the cloud and then deploy the code to devices for local execution of their applications.

[0185] Figure 15This is a flowchart illustrating a process 1500, according to some embodiments, for connecting a logical connection from a component (e.g., a sensor coupled to a PDC) to a computing platform (e.g., an ADS server 101). Process 1500 begins by establishing a transparent component data link (1501) between the PDC and one or more computing platforms. Process 1500 continues with the following steps: 1502: Starting a driver for the transparent component data link. For example, the driver may be started by one or more computing platforms. Process 1500 continues with the following steps: Transferring component data via the transparent component data link to one or more computing platforms or from one or more computing platforms (1503).

[0186] Figure 16A The diagram illustrates a star topology using an ADS as a peripheral plug-in station according to some embodiments. In the illustrated topology, each sensor radiates from the ADS in a "hub and spoke" configuration. The illustrated topology is a Level 4 / 5 sensor configuration without redundancy. This star topology is largely inflexible because it does not allow data to be repurposed beyond automated driving without incurring significant overhead. Redundancy in such star topologies can be achieved in several ways. In some embodiments, every component of the star topology is redundant, meaning the topology will include redundant power and data supplied to each sensor, as well as redundant computation, which will result in a high-cost system. See reference... Figure 16B As described, some embodiments include one or more redundant subsets that depend on different subsets of sensors to achieve redundancy.

[0187] Figure 16B The diagram illustrates a star topology including a first subset of redundant data links for sensors, according to some embodiments. This embodiment has a lower level of redundancy for autonomous driving computing (the subset) than the previously described PDC-based topology. Figure 16B The star topology shown provides a first level of data redundancy, which uses a first subset of sensors available in case of failure. Note that only data redundancy is shown in Figure 16, and the actual system will also default to a first level of power redundancy, which uses the first set of power components. Additionally, a second level of redundancy may exist, which uses a second (potentially reduced) subset of sensors in case of failure of sensors in the first subset of sensors. While reducing the number of sensors will decrease the functionality of the autonomous vehicle, the vehicle will still have the ability to provide at least a "limp" home function or a "limp" to safety function.

[0188] Figure 17This is a process 1700 according to some embodiments for selecting a subset of redundant sensors configured in a star topology. Process 1700 begins by detecting a fault in the vehicle's automotive E / EA system (1701), wherein the system is configured in a star topology; and subsequently, based on the detection of the fault, process 1700 continues by the following steps: selecting a redundancy level for the system, the selection including selecting a subset of redundant sensors in the star topology for use when operating the vehicle (1702).

[0189] Example computer system

[0190] Figure 18 The diagram illustrates a computer system 1800 (e.g., a PDC (or a portion of a PDC) or a computing platform (or a portion of a computing platform)). In some embodiments, the computer system 1800 is a dedicated computing device. This dedicated computing device is hardwired to perform the techniques described above (e.g., some or all of the operations in processes 1100, 1200, 1300, 1500, and / or 1700, or operations implementing other techniques described above), or the dedicated computing device includes digital electronic devices (such as one or more application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs)) permanently programmed to perform these techniques, or the dedicated computing device may include one or more general-purpose hardware processors programmed to perform these techniques according to programming instructions in firmware, memory, other storage, or a combination thereof. Such dedicated computing devices may also combine custom hardwired logic, ASICs, or FPGAs with custom programming to implement these techniques. In some embodiments, the dedicated computing device is a desktop computer system, a portable computer system, a handheld device, a network device, or any other device containing hardwired and / or program logic for implementing these techniques.

[0191] In some embodiments, computer system 1800 includes a bus 1802 or other communication mechanism for transmitting information and a hardware processor 1804 coupled to the bus 1802 and used for processing information. Hardware processor 1804 is, for example, a general-purpose microprocessor. Computer system 1800 also includes main memory 1806 (such as random access memory (RAM) or other dynamic storage device) coupled to the bus 1802 for storing information and instructions to be executed by processor 1804. In some embodiments, main memory 1806 is used to store temporary variables or other intermediate information during execution of instructions to be executed by processor 1804. Such instructions, when stored in a non-transitory storage medium accessible to processor 1804, present computer system 1800 as a dedicated machine customized to perform the operations specified in those instructions.

[0192] In some embodiments, the computer system 1800 further includes a read-only memory (ROM) 1808 or other static storage device coupled to the bus 1802 and used for storing static information and instructions for the processor 1804. A storage device 1810 is provided, coupled to 1802 for storing information and instructions; the storage device 1810 is such as a magnetic disk, optical disk, solid-state drive, or three-dimensional cross-point memory.

[0193] In some embodiments, the computer system 1800 is coupled to a display 1812 via a bus 1802 for displaying information to a computer user. The display 1812 is, for example, a cathode ray tube (CRT), liquid crystal display (LCD), plasma display, light-emitting diode (LED) display, or organic light-emitting diode (OLED) display. An input device 1814, including alphanumeric and other keys, is coupled to the bus 1802 for transmitting information and command selections to the processor 1804. Another type of user input device is a cursor controller 1816, such as a mouse, trackball, touch-enabled display, or cursor arrow keys, which transmits directional information and command selections to the processor 1804 and controls cursor movement on the display 1812. This input device typically has two degrees of freedom on two axes (a first axis (e.g., the x-axis) and a second axis (e.g., the y-axis)), allowing the device to specify a position in a plane.

[0194] According to some embodiments, the techniques described herein are executed by computer system 1800 in response to processor 1804 executing one or more sequences of one or more instructions contained in main memory 1806. Such instructions are read into main memory 1806 from another storage medium (such as storage device 1810). Execution of the sequence of instructions contained in main memory 1806 causes processor 1804 to perform the process steps described herein. In some embodiments, hardwired circuitry is used in place of software instructions, or in combination with software instructions.

[0195] As used herein, the term "storage medium" refers to any non-transitory medium that stores data and / or instructions that enable a machine to operate in a particular manner. Such storage media include non-volatile and / or volatile media. Non-volatile media include, for example, optical discs, magnetic disks, solid-state drives, or three-dimensional cross-point memory, such as storage device 1810. Volatile media include dynamic memory, such as main memory 1806. Common forms of storage media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tape or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical medium with a perforated pattern, RAM, PROMs and EPROMs, flash memory-EPROMs, NV-RAMs, or any other memory chip or cassette memory.

[0196] Storage media are distinct from transmission media (e.g., transient computer-readable media) but can be used in conjunction with transmission media. Transmission media participate in the transfer of information between storage media. For example, transmission media include coaxial cables, copper wires, and optical fibers, including wires containing bus 1802. Transmission media can also take the form of sound waves or light waves, such as those generated during radio wave and infrared data communication.

[0197] In some embodiments, various forms of media involve carrying one or more sequences of one or more instructions to processor 1804 for execution. For example, the instructions are initially carried on a disk or solid-state drive of a remote computer. The remote computer loads these instructions into its dynamic memory and transmits them over a telephone line using a modem. A modem local to computer system 1800 receives data over the telephone line and converts the data into an infrared signal using an infrared transmitter. An infrared detector receives the data carried in the infrared signal, and appropriate circuitry places the data on bus 1802. Bus 1802 carries the data to main memory 1806, from which processor 1804 fetches instructions and executes them. Instructions received by main memory 1806 may optionally be stored on storage device 1810 before or after execution by processor 1804.

[0198] Computer system 1800 also includes a communication interface 1818 coupled to bus 1802. Communication interface 1818 provides bidirectional data communication coupling to network link 1820, which is connected to local network 1822. For example, communication interface 1818 is an Integrated Services Digital Network (ISDN) card, a cable modem, a satellite modem, or a modem for providing data communication connectivity to a corresponding type of telephone line. As another example, communication interface 1818 is a local area network (LAN) card for providing data communication connectivity to a compatible LAN. In some embodiments, a wireless link is also implemented. In some such embodiments, communication interface 1818 transmits and receives electrical, electromagnetic, or optical signals carrying streams of digital data representing various types of information.

[0199] Network link 1820 typically provides data communication to other data devices via one or more networks. For example, network link 1820 provides a connection via local network 1822 to host computer 1824 or to a cloud data center or facility operated by Internet Service Provider (ISP) 1826. ISP 1826 then provides data communication services via a worldwide packet data communication network (now commonly referred to as the "Internet" 1828). Both local network 1822 and Internet 1828 use electrical, electromagnetic, or optical signals carrying digital data streams. Signals through various networks, as well as signals on network link 1820 and through communication interface 1818, are example forms of transmission media carrying digital data to and from computer system 1800. In embodiments, network 1820 includes cloud 202 or a portion of cloud 202 as described above.

[0200] Computer system 1800 sends messages and receives data including program code through networks(s), network link 1820, and communication interface 1818. In some embodiments, computer system 1800 receives code for processing. The received code is executed by processor 1804 upon receipt and / or stored in storage device 1810 and / or other non-volatile memory for later execution.

[0201] Figure 19The diagram illustrates an E / EA system architecture according to an embodiment, which utilizes an Open Server Platform (OSP) and provides a scalable topology with fault-tolerant design. The E / EA architecture separates the hardware innovation cycle from the software innovation cycle, enabling hardware to be developed and delivered independently of software. It allows existing software to be migrated to new hardware without modification, provides efficient computing resource sharing to enable the coexistence of safety-critical and non-safety-critical workloads on the same machine, and offers affordable redundancy with a three-tier fault-tolerant design that replicates only those components absolutely necessary for safe fault-tolerant operation. The E / EA architecture replaces the conventional distributed monolithic embedded software / hardware approach with a modular, open, and centralized intelligent vehicle architecture.

[0202] The advantages of the E / EA architecture include decoupling software from hardware, allowing for independent hardware and software lifecycles and providing flexibility for dynamic feature sets and computational needs, thus improving scalability. Another advantage is the use of a PDC to separate I / O from centralized computing resources providing I / O, enabling affordable redundancy. Another advantage is the use of a central computing cluster providing a common platform with standardized interfaces and secure gateways for connectivity. Another advantage is a unified power and data backbone that provides modularity and automotive wiring harness technology and design for redundant networks via a dual-ring topology. Another advantage is using the PDC as a "universal plug-in station" and for sensor and area consolidation.

[0203] refer to Figure 19 The E / EA architecture comprises six PDCs covering different areas within the vehicle. Each PDC acts as a patch station for sensors within that area. The PDCs communicate with the OSP ADAS / AD server via a sensor ring and a single interface. The sensor ring is implemented using redundant 8Gbit / s PCI Fast or 10Gbit / s Ethernet. The OSP ADAS / AD, along with the SCGW OSP AD / UX and PCC, is coupled within a self-healing server ring. The server ring is also implemented using redundant 8Gbit / s PCI Fast or 10Gbit / s Ethernet. The RTU handles external communications and receives audio and software updates. (See reference...) Figure 24 and Figure 25 As described, software updates received by the RTU are routed to the SCGW and stored in the Central Vehicle Storage (CVS) unit. Audio (e.g., satellite radio) is transmitted by the RTU to the PDC, where it can be distributed to other components, including the CVS unit. In an embodiment, each PDC includes audio electronics (e.g., audio amplifiers, warning tone generators, low latency sounds, audio clients, AVB slave devices) and is coupled to one or more speakers to deliver audio.

[0204] Figure 20 Further illustrations according to embodiments Figure 19 The E / EA system architecture shown focuses on key technical attributes that enable feature growth and redundancy. These key attributes include: standardized system abstraction concepts and interfaces, multiple I / O centralizations with regional control, a single interface to the AD server, a centralized general-purpose computing cluster implementing OSP, a power ring topology for delivering redundant power supplies, a symmetric self-healing data ring topology providing redundant data networks, overall functional safety, fast response, fast wake-up features, and an SCGW for external communications (software updates, audio, V2X communication, WiFi, GPS, etc.) with security features (e.g., implementing "firewalls," "sandboxes," or "proxy" servers) to defend against malicious attacks on the vehicle.

[0205] Figure 21 The diagram illustrates an OSP system architecture according to an embodiment. The OSP system architecture provides redundant network connectivity with low overhead. The OSP sensor interface is PCIe-based, using HDBaseT as the physical layer. The sensor behaves as a PCIe component enabled by driver software in the PDC and is native to the OSP. The OSP architecture provides low overhead / latency for sensor data from the source CPU to the OSP CPU. The sensor can be used with two redundant server devices without any hardware overhead. In the event of a connection error between the PDCs, sensor data is routed in a ring structure via a DHD link.

[0206] Figure 22 The diagram illustrates an OSP software stack according to an embodiment. The OSP software stack installed in the vehicle provides an "on-wheel data center." Safety-critical applications and non-safety-critical applications operate in different domains. Safety-critical applications (e.g., applications related to ADAS and OEM safety) communicate with lower stack layers through a safety middleware. Non-safety-critical applications (e.g., infotainment, user experience, HMI manager, and other applications) communicate with lower stack layers through a hypervisor. The operating system (O / S) (e.g., Linux) includes a secure dynamic partition. A cloud-based platform providing SaaS, PaaS, and IaaS services, including OTA for software updates and digital twins, is also shown, referencing... Figure 24 and Figure 25 Describe it.

[0207] OSP is highly scalable for OEMs and other third-party applications. Hypervisors and dynamic security partitioning manage secure and non-secure domains on the same hardware. Shared underlying computing resources allow for silicon optimization, reducing cost and power consumption, and "plug-and-play" drives make adding new edge devices effortless.

[0208] Figure 23 The diagram illustrates the PDC functional domains according to an embodiment. In this embodiment, PDC capabilities are divided into two functional domains: body control and mobility. The distinction between these two functional domains is defined by how they are controlled. Body control functions are centrally controlled by the SCGW via a CAN-FD connection. Mobility functions are controlled by the OSP via a sensor loop. The OSP and SCGW are then linked via a server loop. Multiple PDCs are linked to the OSP via the sensor loop. Each PDC has its own separate CAN-FD connection to the SCGW.

[0209] Vehicle lifecycle management

[0210] Figure 24 The figure illustrates the hybrid criticality of OSP for implementing vehicle lifecycle management according to an embodiment. Figure 24 The open server software architecture shown implements vehicle lifecycle management. A secure dynamic hardware partitioning layer is used to share hardware for functional safety-related software. A security middleware is used to abstract the functional safety-related software from the hardware. An open-source management program with abstraction and HMI domains is used to abstract other software and hardware.

[0211] Figure 25 The diagram illustrates OSP functional safety certification for implementing vehicle lifecycle management according to an embodiment. Using this architecture, hardware and machine middleware are certified by certified test cases, applications are certified at the code level via tested references, and machine resource inventory is automatically generated and certified.

[0212] More specifically, hardware and middleware are developed separately from application software and tested and certified using certified test suites. Application software is developed separately from the target hardware and tested in a simulated environment. Certification is completed at the code level and through a reference environment. Software integration of the required application software is performed at the "end of line" by a cloud application (virtual twin). The software application is scheduled by the virtual twin application, which has an instance for each complete vehicle. Each ECU (such as a PDC, OSP, or other ECU) is configured separately by the virtual twin application. Each ECU requires a resource inventory, which includes a time-triggered table to run software threads in the multi-core environment at the correct time and in the correct order. The resource inventory is also used to manage other resources, such as memory, network throughput, interrupt rate, etc. The resource inventory is available throughout the ECU to allow all applications to run without interference. The resource inventory is tested and certified ECU-by-ECU by the cloud application.

[0213] All possible software applications for all possible ECUs in a vehicle are programmed into the CVS unit, which is connected to the vehicle's SCGW unit. The SCGW receives a list of software content for all ECUs in the vehicle, along with a certified resource list. The SCGW then transmits the software applications along with the resource list to the ECUs. The SCGW first synchronizes the software applications on the CVS unit with cloud applications to obtain the latest version on the CVS unit. After this initial SW programming of the ECUs, the vehicle is ready for use and will perform a self-test to prove that these ECUs have been correctly programmed.

[0214] Field software updates can be performed at the software component level on every ECU in the vehicle. The virtual twin application schedules new applications for the ECUs by first generating and certifying a new resource inventory. The virtual twin application then first transmits the new application along with the resource inventory to the CVS unit in the vehicle. The SCGW exchanges the application and updates the resource inventory on the ECU. This process ensures that the certification for the ECU remains valid after the update.

[0215] Alternative Level 2 and Level 3 E / EA architecture

[0216] Figure 26 This is a data network view of an alternative scalable E / EA architecture for a Level 2 vehicle according to an embodiment. The E / EA architecture includes a sensor ring connecting six PDCs and a server ring connecting an OSP UX / ADAS server, PCC, and SCGW. The E / EA architecture also includes a CVS unit for storage and an RTU for external communication. Four PDCs at the front and rear of the vehicle are each coupled to three ultrasonic sensors and to an audio speaker. The PDC at the front left is coupled to a forward-facing radar. The PDC at the front right is coupled to a forward-facing camera. PDCs on the right and left sides of the vehicle are each coupled to a camera. The OSP UX / ADAS server is coupled to one or more output devices (e.g., a display). The SCGW is coupled to the RTU and CVS unit. In this embodiment, the server ring is implemented using 1 Gbit / s Ethernet, and the sensor ring is implemented using 4 Gbit / s PCIe. Redundancy in the data network is achieved via a CAN-FD link between the PDCs and the SCGW.

[0217] Figure 27 According to the embodiments, it is used for Figure 26The diagram shows a power network view of an alternative scalable E / EA architecture. Six PDCs are coupled to a 12V supply loop. The OSP UX / ADAS server, SCGW, PCC, and CVS unit are coupled to a filtered 12V supply loop. Sensors are coupled to the PDCs via a 5V supply. Cameras receive power from their respective PDCs using coaxial cable power-on-charge (PoC). The battery is coupled to the PDC on the front left.

[0218] Figure 28 This is a data network view of an alternative scalable E / EA architecture for a Level 3 vehicle according to an embodiment. The E / EA architecture includes a sensor ring connecting six PDCs and a server ring connecting an OSP UX / ADAS server, an OSP AD / UX server, a PCC, and an SCGW. The E / EA architecture also includes a CVS unit for storage and an RTU for external communication. Four PDCs at the front and rear of the vehicle are each coupled to three ultrasonic sensors and to an audio speaker. The PDC at the front left is coupled to a forward-facing radar and a camera pointing to the rear left of the vehicle. The PDC at the front right is coupled to a camera pointing to the rear right of the vehicle and to a lidar sensor. PDCs on the right and left sides of the vehicle are each coupled to multiple cameras. The OSP AD / UX server is coupled to one or more output devices (e.g., a display). The SCGW is coupled to the RTU and the CVS unit. In this embodiment, the server ring is implemented using 1 Gbit / s Ethernet, and the sensor ring is implemented using 4 Gbit / s PCIe. Data network redundancy is achieved via a CAN-FD link between the PDCs and the SCGW.

[0219] Figure 29 According to the embodiments, it is used for Figure 28 The diagram shows a power network view of an alternative scalable E / EA architecture. Six PDCs are coupled to a 12V supply loop. The OSP UX / ADAS server and OSP AD / UX server, SCGW, PCC, and CVS unit are coupled to a filtered 12V supply loop. Sensors are coupled to the PDCs via a 5V supply. Cameras receive power from their respective PDCs using a PoC. The LiDAR sensor is powered by a filtered 12V supply from the PDC on the front left. The battery is coupled to the PDC on the front left.

[0220] While this document contains numerous specific implementation details, these details should not be construed as limiting the scope of possible claims, but rather as descriptions of features specific to particular embodiments. Certain features described in the specification within the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments. Furthermore, while features may be described above as operating in certain combinations and even initially claimed in this way, one or more features from a claimed combination may be omitted from that combination in some cases, and the claimed combination may be for sub-combinations or variations thereof.

[0221] Although logical flows or operations are depicted in a specific order in the accompanying drawings (e.g., operations in processes 1100, 1200, 1300, 1500, and / or 1700), this should not be construed as requiring such operations to be performed in the specific order shown or in sequential order, or that all illustrated operations be performed or other operations may not be performed to achieve the desired result. Operations illustrated separately are optionally combined into a single operation, and features illustrated as a single operation are optionally performed as separate operations. Furthermore, processes may be combined such that one or more operations of a process are included in another process or multiple other processes. In some cases, multitasking and parallel processing may be advantageous. Moreover, the separation of various software components in the embodiments described above should not be construed as requiring such separation in all embodiments, and it should be understood that the described software components can generally be integrated together in a single software program or multiple software programs.

Claims

1. A system for a vehicle, the system comprising: The vehicle's electrical and electronic systems are divided into multiple zones, each corresponding to a different physical area of ​​the vehicle. Each zone includes at least one regional power and data center coupled to multiple computing platforms. The power and data center for each region include: A power interface configured to distribute power from multiple power sources or supply systems of the vehicle to multiple sensors of the vehicle; At least one sensor interface, said sensor interface being configured to: Sensor data is received from at least the following sensors: (i) a first sensor associated with the same region as the regional power and data center; and (ii) a second sensor associated with a different region as the regional power and data center. The sensor data is processed by at least one of the following operations: fusing the sensor data, transforming the sensor data, preprocessing the sensor data, or compressing the sensor data; and At least one data interface configured to transmit the sensor data to multiple regional power and data centers and the multiple computing platforms.

2. The system as claimed in claim 1, wherein, At least one of the plurality of computing platforms is configured to provide autonomous driving capabilities to the vehicle.

3. The system as described in claim 1, wherein, In one or more housings, each of the plurality of regional power and data centers includes the at least one data interface and the at least one sensor interface.

4. The system as claimed in claim 1, wherein, The power interface includes circuitry configured to perform the following operation: measure at least one of an input voltage or input current from the power supply loop or an output voltage or output current to the power supply loop to detect a power fault associated with at least one of the plurality of computing platforms or the plurality of regional power and data centers.

5. The system as described in claim 4, wherein, The power interface is configured to measure the input voltage or the input current or the output voltage or the output current by measuring the rate of change of at least one of the input voltage or the input current or the output voltage or the output current.

6. The system of claim 1, wherein, The power interface of the regional power and data center includes at least a portion of a power circuit that provides a stable and filtered voltage supply to at least one of the one or more sensors.

7. The system as claimed in claim 1, wherein, At least one of the plurality of regional power and data centers is configured to: A portion of the sensor data is received via the at least one sensor interface of the at least one regional power and data center; Compress a portion of the sensor data; as well as The compressed portion of the sensor data is transmitted to the plurality of computing platforms and the plurality of regional power and data centers via the at least one data interface of the at least one regional power and data center.

8. The system of claim 1, wherein, At least one of the plurality of regional power and data centers is configured to: Processed sensor data from at least one of the plurality of sensors is received via at least one sensor interface of the at least one regional power and data center; as well as The processed sensor data is transmitted to the plurality of computing platforms and the plurality of regional power and data centers via the at least one data interface of the at least one regional power and data center.

9. The system as claimed in claim 1, wherein, At least one of the plurality of regional power and data centers is configured to: Receive raw sensor data from two or more sensors; The raw sensor data is processed to provide fused sensor data; as well as The fused sensor data is transmitted through at least one data interface.

10. The system of claim 1, wherein, At least one of the plurality of regional power and data centers includes one or more controller circuits coupled to one or more actuators configured to provide one or more vehicle functions.

11. The system of claim 1, wherein, At least one of the plurality of regional power and data centers is coupled to at least one of the plurality of computing platforms or another of the plurality of regional power and data centers via two or more redundant data links, wherein each of the two or more redundant data links is configured to use a protocol or physical layer different from the layers used by the two or more redundant data links to each other.

12. The system of claim 11, wherein, The electrical and electronic system is further configured to: avoid transmitting the sensor data to the at least one of the two or more redundant data links where the fault is detected, based on the detection of a fault in at least one of the redundant data links.

13. The system of claim 1, wherein, The system is configured to cause one or more sensors to slow down their respective data transmission rates based on the detection of a fault in at least one of the plurality of computing platforms or the plurality of regional power and data centers.

14. The system of claim 1, wherein, The system is configured to cause the vehicle to enter a fail-safe mode based on the detection of a fault in at least one of the plurality of computing platforms or the plurality of regional power and data centers.

15. The system of claim 1, wherein, A specific area power and data center among the plurality of area power and data centers includes at least two power inputs operable to connect within the area power and data center and to isolate the at least two power inputs relative to each other in response to detection of a fault in the power source or system of the specific area power and data center.

16. The system of claim 1, wherein, The sensor interface of the regional power and data center includes at least one of the circuitry or software for receiving and processing raw or pre-processed sensor data from two or more different sensors using two or more physical layers or protocols.

17. The system of claim 1, wherein, The electrical and electronic system also includes: A network configured to distribute sensor data transmitted via at least one sensor interface of each of the plurality of regional power and data centers, and to distribute the sensor data to the plurality of computing platforms; and Multiple power supply rings, separate from the network and configured to send power allocations generated by the vehicle's power source or system to the multiple computing platforms and the multiple regional power and data centers.

18. A method of operating regional power and data centers in areas of a vehicle, said vehicle being divided into multiple areas, each area corresponding to a different physical area of ​​said vehicle, said method comprising: Power is distributed from multiple power sources or supply systems of the vehicle to multiple sensors via the power interface of the regional power and data center. Sensor data transmitted from at least the following sensors are received through the sensor interface of the regional power and data center: (i) a first sensor, which is associated with the regional power and data center in the same region, and (ii) a second sensor, which is associated with the regional power and data center in a different region. The sensor data is processed by at least one of the following operations: fusing the sensor data, transforming the sensor data, preprocessing the sensor data, or compressing the sensor data; as well as The sensor data is transmitted to the regional power and data center via the data interface of the regional power and data center, and also to at least one computing platform.

Images