Multi-layer computing platform for vehicle

Abstract

A multi-tier computing platform for a vehicle includes a first computing tier including a plurality of electronic control units (ECUs), each ECU including an embedded system for selectively controlling one or more associated systems in a first set of electronic systems of the vehicle; and a second computing layer comprising a central computing unit (CCU) serving as a shared computing resource for a group of different computer programs for selectively controlling a second set of electronic systems of vehicles different from the first set, such that each system of the systems in the second group is configured to be controlled by one or more programs of the individually allocated strict subset of the group of computer programs. Different subgroups of the group relate to different systems in the second group of systems. The first set of systems includes an electronic system for controlling one or more of acceleration, deceleration and steering of the vehicle (i.e., a basic movement function of the vehicle), and the second set of systems includes an electronic system for controlling one or more comfort functions (i.e., functions beyond the basic movement function) of the vehicle, such as driver assistance, air conditioning or infotainment functions.

Description

Technical Field

[0001] This invention relates to the field of vehicle electronics (such as, but not limited to, automotive electronics). Specifically, this invention relates to computing systems for vehicles, and to a multi-layered computing platform including a central computing unit (CCU) and a vehicle including such a multi-layered computing platform. Background Technology

[0002] Modern vehicles (such as automobiles) typically include multiple different electronic components, including so-called electronic control units (ECUs), which are interconnected via one or more communication links or entire networks (such as, for example, well-known bus systems of the CAN or LIN type). Furthermore, Ethernet-based networks are becoming increasingly important in this context. It is important to note that while the abbreviation "ECU" is often used specifically to refer to the engine control unit in automotive technology, it is used in a broader sense here to refer to any electronic controller or control unit used in a vehicle, with the engine control unit being just one possible example.

[0003] Many ECUs are actually embedded systems, comprising hardware (such as a processing platform) and associated software running on that platform. Therefore, such ECUs form embedded systems, and when multiple ECUs are interconnected via a communication network, such a network can be called a distributed embedded system (network). While this “embedded” setup is particularly useful for providing the ability to perform real-time processing and for the optimal adaptation of a given ECU’s software to its corresponding processing platform, it is generally difficult to extend or scale such embedded systems or add new functionality.

[0004] The alternative proposed in this paper is based on the idea that, instead of using dedicated software running on dedicated hardware to provide a specific function (i.e., the function of a specific ECU), a central computing architecture is used where the different desired functions are provided by multiple different computer programs (especially application programs) running on the same central computing unit (CCU), which is therefore sharing computing resources.

[0005] In particular, as mentioned above, this CCU-based approach offers greater flexibility than traditional decentralized approaches in terms of expanding, scaling, or reducing vehicle functionality.

[0006] However, in CCU-based approaches, care must be taken to ensure that particularly critical functions (such as basic vehicle functions like driving, braking, and steering, or certain critical safety functions) are always operational, especially independent of the current workload or other state of the CCU. Summary of the Invention

[0007] Therefore, the object of the present invention is to provide an improved computing platform for vehicles that can reliably and simultaneously provide a large number of different functions of the vehicle.

[0008] The solution to this problem is provided by the teachings of the independent claims. Various preferred embodiments of the invention are provided by the teachings of the dependent claims.

[0009] A first aspect of this solution relates to a multi-layered computing platform for a vehicle. The computing platform includes: (i) a first computing layer (also referred to as the “vehicle chassis space”) comprising a plurality of electronic control units (ECUs), each ECU including an embedded system for selectively controlling one or more associated systems within a first set of electronic systems of the vehicle; and (ii) a second computing layer (also referred to as the “user space”) comprising a central computing unit (CCU) serving as a shared computing resource for a group of different computer programs for selectively controlling a second set of electronic systems of the vehicle that are at least partially different from the first set, such that each system in the second set is configured to be controlled by one or more programs in a separately assigned strict subgroup of the group of computer programs, wherein the different subgroups of the group relate to different systems within the second set of systems. The first set of systems includes electronic systems for controlling one or more of the vehicle’s acceleration, deceleration, and steering (i.e., the vehicle’s basic mobility functions), and the second set of systems includes electronic systems for controlling one or more (particularly digitized) further functions of the vehicle (i.e., functions beyond the basic mobility functions). For example, such additional features may include one or more comfort features, such as driver assistance, air conditioning, personalized room temperature, heated seats, sound or infotainment features, interior lights, connectivity to the vehicle cloud, and certain driver assistance features (e.g., adaptive cruise control, blind spot detection, or lane keeping assist). Further examples will be provided below.

[0010] As used herein, the term "computing platform" can specifically refer to the environment in which a piece of software is executed. It can be computing hardware or an operating system (OS), even a web browser and its associated application programming interface (API), or other low-level software, as long as the program code is executed using it. Computing platforms can have different levels of abstraction, encompassing computer architecture, OS, or runtime libraries. Therefore, a computing platform is the stage on which computer programs can run. It can specifically include or be based on multiple computers or processors.

[0011] As used herein, the term "computation layer" may specifically refer to a subgroup of computing platforms having multiple computing layers. Typically, each computing layer can be implemented using hardware (e.g., a specific processor or a group of processors) and / or software. Specifically, the first and second computing layers as defined above may each include both hardware and software.

[0012] As used herein, the term “central computing unit” or its abbreviation “CCU” may specifically refer to a computing device configured for use in a vehicle (such as an automobile) as an onboard computing unit to centrally control various functions of the vehicle, the computing device including (i) a distributed computing system (DCS), (ii) a communication switch and (iii) a power supply system, each as defined below: This distributed computing system comprises multiple co-located (e.g., within the same enclosure, such as a closed enclosure or an open enclosure, such as a rack), autonomous computing entities (CEs), each CE having its own single memory. These CEs are configured to communicate with each other via message passing through one or more communication networks (such as high-speed communication networks, e.g., PCI Express or Ethernet types) to coordinate the distribution of computing tasks to be performed by the DCS as a whole. Specifically, in the case of multiple communication networks, these networks can be coupled to enable message passing between sending CEs and receiving CEs via communication links involving two or more of the multiple networks. For example, a given message can be sent by a sending CE in PCI Express format to a gateway via one or more first communication paths in a PCI Express network, which then converts the message into Ethernet format and forwards the converted message to a receiving CE via one or more second communication paths in an Ethernet network.

[0013] The communication switch includes multiple independent (i.e., at least functionally independent) switching architectures, each of which is configured to variably connect a subgroup of CEs of the DCS or each CE to one or more of a plurality of interfaces for exchanging information via them with external communication nodes of the vehicle’s CCU (such as network endpoints, e.g., actuators or sensors, or intermediate network nodes, e.g., hubs for connecting multiple other network nodes).

[0014] The power supply system comprises multiple power supply subsystems for simultaneous operation, each of which is capable of individually and independently powering at least two (preferably all) of the DCS and switching architectures. In this document, “power supply” specifically refers to delivering power (or electricity, i.e., power) to an entity to be powered, and may optionally further include first generating power and / or converting it to a suitable power type or level, for example, through DC / DC, AC / DC, or DC / AC conversion, or conversion of the time-dependent nature of the power signal (signal shaping).

[0015] As used herein, the term "computing entity" (CE) (and its variants) refers to an autonomous computing unit capable of performing computational tasks independently and including at least one of its own processor and at least one of its own associated memory. In particular, each CE may be implemented separately from all other CEs. For example, it may be implemented in one or more circuits, such as in an integrated circuit (e.g., as a system-on-a-chip (SOC), system-in-package (SIP), multi-chip module (MCM), or chiplet) or in a chipset.

[0016] As used herein, the term "distributed computing system" (DCS) (and its variants) specifically refers to a computing system comprising multiple networked computing entities that communicate and coordinate their actions by passing messages to each other, enabling these computing entities to interact with each other to achieve a common goal. In particular, groups of individual CEs of the DCS can be configured to perform parallel task processing, such that the CEs in the group simultaneously execute a set of similar or different computing tasks. For example, each CE can individually execute a true subgroup of a set of computing tasks to be executed by the DCS as a whole, wherein the computing tasks executed by different CEs can be different.

[0017] As used in this article, the term “switching architecture” (and its variants) specifically refers to hardware used to variably connect multiple different nodes (such as nodes in a computer network) of a network to exchange data between them.

[0018] As used herein, the term "communication switch" (and variations thereof) includes at least two switching architectures and is configured to use these switching architectures alternately or simultaneously to variably connect multiple different nodes of a network (such as nodes of a computer network) to exchange data between them. A communication switch may specifically include, but is not limited to, one or more PCI Express (PCIe) switches and / or Compute Fast Link (CXL) as switching architectures.

[0019] As used herein, the term “switching” (and its variations) (included in the terms “switching architecture” and “communication switch”) generally refers to the variable connection of different nodes in a network to exchange data between them, and is not limited to any particular connection technology, such as circuit switching or packet switching, or any particular communication technology or protocol, such as Ethernet, PCIe, etc., unless otherwise expressly indicated herein in the given context.

[0020] As used herein, the term "embedded system" can specifically refer to a computer system—that is, a combination of computer processors, computer memory, and input / output peripherals—that has a dedicated function within a larger mechanical or electronic system (e.g., the overall electronic system of a vehicle). In other words, the embedded system is dedicated to one or more specific tasks within a strictly defined subgroup of tasks forming that larger mechanical or electronic system. An embedded system can be embedded specifically as part of a complete device, which typically includes electrical or electronic hardware as well as mechanical components. Because embedded systems typically control the physical operation of the machines embedded within a vehicle, such as the engine (or the entire powertrain), steering system, or braking system, they often have real-time computational constraints. Modern embedded systems are typically based on microcontrollers (i.e., microprocessors with integrated memory and peripheral interfaces), but general-purpose microprocessors (using external chips for memory and peripheral interface circuitry) are also common, especially in more complex systems. In either case, the processors used can range from general-purpose to processors specifically designed for a particular type of computation, or even processors custom-designed for the application at hand. A common standard category of dedicated processors is the digital signal processor (DSP).

[0021] In the specification and claims, terms such as "first," "second," and "third" are used to distinguish similar elements and are not necessarily used to describe a sequence or chronological order. It should be understood that such terms are interchangeable where appropriate, and the embodiments of the invention described herein can operate in other sequences besides those described or illustrated herein.

[0022] Unless otherwise required by the context, when the terms “comprising” or “including” or variations thereof, such as “comprising” or “including” or “including”, are used in this specification and claims, they do not exclude other elements or steps and should be interpreted in an open, inclusive sense, that is, as “including but not limited to”.

[0023] When an indefinite or definite article is used to refer to a singular noun, such as “one” or “a kind” or “the,” this includes the plural form of the noun, unless otherwise explicitly stated.

[0024] The phrases “in some embodiments,” “in one embodiment,” or “in an embodiment,” if any, appearing in the specification do not necessarily refer to the same embodiment. Furthermore, specific features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0025] Furthermore, unless explicitly stated otherwise, "or" refers to inclusive or, not exclusive or. For example, condition A or B is satisfied by any of the following: A is true (or exists) and B is false (or does not exist), A is false (or does not exist) and B is true (or exists), and both A and B are true (or exist).

[0026] The use of the terms "configuration" or "arrangement" to perform a specific function (and its corresponding variations), as they may be used herein, should be understood to mean that the relevant device or component is already in a configuration or setting capable of performing that function, or is at least adjustable—i.e., configurable—so that it can perform that function after appropriate adjustments. In this context, configuration can be performed, for example, by setting corresponding parameters of process sequences or hardware (HW) or software (SW) or combined HW / SW switches, to activate or deactivate the function or setting. In particular, the device may have multiple predetermined configurations or operating modes, such that configuration can be performed by selecting one of these configurations or operating modes.

[0027] Many of the functional units, building blocks, or systems described in this specification have been labeled as systems or units to specifically emphasize their implementation independence. For example, a system can be implemented as hardware circuitry including custom VLSI circuitry or gate arrays, off-the-shelf semiconductors (such as logic chips, transistors), or other discrete components. Systems or functional units can also be implemented in programmable hardware devices, such as field-programmable gate arrays, programmable array logic, programmable logic devices, etc.

[0028] Functional units, building blocks, and systems can also be implemented in software to be executed by various types of processors or in a hybrid hardware / software implementation. An identified means of executable code can, for example, comprise physical or logical blocks of one or more computer instructions, which can be organized, for example, as objects, procedures, or functions. However, the executable files of the identified means do not necessarily have to be physically located together, but can include dissimilar instructions stored in different locations that, when logically connected, encompass the means and perform the stated purpose of the means. In practice, the means of executable code can be a single instruction or many instructions, and can even be distributed across several different code segments, between different programs, and across several storage devices. Similarly, operational data can be identified and illustrated within the means herein, and can be implemented in any suitable form and organized within any suitable type of data structure. Operational data can be collected as a single data set, or can be distributed across different locations, contained across different storage devices, and can exist at least in part simply as electrical signals on a system or network.

[0029] Therefore, according to the computing platform application hierarchy concept of the first aspect, at least some safety-critical basic mobility functions of the vehicle are processed by a first computing layer based on various ECUs, each ECU including an embedded system for selectively controlling one or more associated systems in a first set of electronic systems of the vehicle. In this way, these critical functions are achieved using highly proven and conservative methods used in most modern automobiles.

[0030] On the other hand, a highly flexible second computing layer, which can even be reconfigured in-situ, is used to implement at least some comfort-related functions. This particularly allows for the appropriate addressing of the increasing complexity of vehicle technology in areas where traditional ECU methods may no longer be sufficient in the foreseeable future. In particular, scalability and ensuring high reliability of the entire system despite increased complexity, while meeting space and / or weight requirements, especially in electric vehicles, can be provided even if traditional ECU methods fail. Furthermore, the first computing layer can be configured to operate independently of the second computing layer, ensuring that its operation is not affected or compromised even if the second computing layer fails. The computing platform of the first aspect is thus able to reliably and flexibly provide a wide range of different functions across current and future vehicle generations without compromising the safety of the vehicle and its occupants. Moreover, the multi-layered concept allows for the largely independent development of each layer, which in particular decouples the development of basic mobility functions associated with the first computing layer (e.g., primarily vehicle-specific engineering) from the development of further functions of the second layer (e.g., comfort functions) (e.g., primarily electronic and software engineering, which can even be vehicle-independent, e.g., for at least some infotainment-related functions).

[0031] While it is certainly conceivable that in the future, even the most safety-critical functions of a vehicle, such as braking or steering, may be implemented entirely in the CCU or another multi-purpose computing layer or computing platform, thus completely breaking away from the traditional architecture based on embedded systems / ECUs, this solution is particularly well-suited as a temporary solution to effectively combine the need for high levels of safety and reliability with the flexibility of computing platforms used in vehicles (e.g., automobiles).

[0032] In the following description, preferred embodiments of the computing platform of the first aspect are described. Unless explicitly excluded or technically impossible, these embodiments may be combined with each other or with the second aspect of the invention (described below).

[0033] In some embodiments, the computing platform further includes a first interface between the first computing layer and the second computing layer for exchanging information between them according to one or more defined protocols. Other terms used hereinafter for the first interface are “universal chassis interface” or its abbreviation “CCI”. CCI can be, in particular, a protocol-based interface, i.e., an interface using one or more predefined (preferably standardized) communication protocols that can be used across a range of vehicles, and possibly even across vehicles from different manufacturers. CCI can be used to control, and in particular, filter, the exchange of information between the first and second computing layers, and / or vice versa.

[0034] Specifically, in some relevant embodiments, the first interface includes at least one security function to protect the first computing layer from unauthorized access by or through another layer of the computing platform. For example, the CCI may be configured to provide one or more network security functions to ensure that potentially dangerous commands, computer viruses, or data manipulation do not occur across the CCI. Specifically, such a security concept could therefore include a firewall that ensures the extremely security-related first computing layer is protected from potentially dangerous intrusions from any higher computing layer, particularly directly from or via a second computing layer, because such higher computing layers(s) may have connections to the computing platform or even the world outside the vehicle, such as internet connections or connections to external data sources (such as memory modules or devices), and thus may be more vulnerable to attack.

[0035] In some embodiments, a first computing layer is configured to communicate a first data set defined by a second computing layer—e.g., repeatedly, continuously, or event-triggered—that includes one or more parameters indicating the current or past state of one or more systems in the first set or actions performed by them. In this way, the second computing layer can access these parameters to use them as the basis for performing its tasks, for example, by using these parameters or functions thereof as input to one or more programs running on the CCU. For example, a parameter indicating the current speed of a vehicle can be used as an input parameter to control the volume of a vehicle's infotainment function.

[0036] Specifically, in some embodiments of these embodiments, the first data set includes one or more parameters indicating one or more of the following: steering angle, vehicle speed, vehicle acceleration, vehicle speed level, powertrain status, wheel speed, vehicle tilt angle, current or past status of one or more safety-related systems in the first set, or actions performed by them.

[0037] In some embodiments, the second computing layer is configured to communicate a second data set defined by the first computing layer—for example, repeatedly, continuously, or event-triggered—that includes one or more parameters indicating a desired state or action to be performed by one or more systems in the first set of systems. Specifically, the second data set may include one or more parameters indicating one or more of the following: a desired steering angle, a desired accelerator value, a desired braking value, a desired speed level, and a desired suspension level. More specifically, the one or more parameters indicating a desired state or action to be performed by one or more systems in the first set of systems may be selected or adjusted by a user through a user interface.

[0038] Therefore, the second computing layer can specifically control the functionality of the first computing layer by communicating desired states or actions to be performed. Similarly, any potentially existing further, and especially higher, computing layers can indirectly provide one or more of those parameters via the second computing layer to communicate with the first computing layer via CCI for control or other purposes. For example, those parameters can be received by the second computing layer from a higher (third) computing layer (see below) and from there further communicated to the first computing layer via CCI.

[0039] In some embodiments, the first interface (CCI) is configured to synchronize the update rate of parameter-based information from the transmitting layer and the information reception rate from the receiving layer for exchanging information between a first computing layer and a second computing layer, and / or vice versa. In other words, the first computing layer can be the transmitting layer, and the second computing layer can be the receiving layer, and / or vice versa. This synchronization helps prevent any information transmitted via the CCI from being lost because the receiving layer is not ready to receive the information when it is being communicated via the CCI (i.e., transmitted). Therefore, this synchronization can be used to enhance the reliability of the entire computing platform and thus the reliability of the functions of the vehicle it controls. Specifically, the update rate can even be configurable, for example, based on the current workload of the CCU or a portion thereof, to allow for optimized management of available computing resources.

[0040] In some embodiments, the second computing layer includes one or more cluster hubs, each configured to communicatively connect one or more sensors and / or actuators of the vehicle to the CCU. In this way, the second computing layer can be organized hierarchically to enable efficient connectivity of multiple sensors and / or actuators to the CCU. Specifically, this avoids the need for each sensor / actuator to be directly and individually connected to the CCU, e.g., via a single trace or wiring on a printed circuit board. Furthermore, the cluster hubs can be configured to perform certain selected tasks on the signals or other information exchanged through them, thereby reducing the load on the CCU, e.g., signal processing load or data formatting load. Such a concept can be referred to as "edge computing."

[0041] Specifically, at least one of the cluster hubs may be configured to perform one or more of the following functions related to the cluster to which it is connected: (i) reporting one or more capabilities of the cluster to the CCU; (ii) aggregating signals from different sensors or actuators of the cluster, acting as a communication gateway, particularly a protocol converter, between the CCU and the cluster; (iii) managing (one-way or two-way) messaging between the CCU and the cluster; (iv) preprocessing information provided by the cluster's sensors or actuators; (v) postprocessing information to be communicated to the cluster's sensors or actuators; and (vi) providing power to at least one actuator and / or sensor of the cluster (e.g., based on PoE, PoC, and / or energy harvesting mechanisms).

[0042] In some embodiments, the computing platform further includes a third computing layer (e.g., referred to as a “dense computing space”), wherein the third computing layer includes one or more dedicated computing units for controlling one or more electronic systems in a third group of vehicle electronic systems that are different from the first and second group systems. In this context, “different” means that the third group includes at least one electronic system that is not included in the first or second group. The third computing layer may specifically have one or more specific properties that are not available in the first or second computing layer. Specifically, it can be adapted to high-performance applications that require high-performance computing and / or high-performance communication paths (such as optical communication paths, e.g., optical waveguides or optical fibers). Therefore, the third computing layer can be used to further extend the capabilities and / or capacity of the entire computing platform by providing dedicated additional functionality.

[0043] In some embodiments, the computing platform further includes a second interface between the second and third computing layers for exchanging information between them according to one or more defined protocols. This information can be exchanged, particularly cascaded between the first and third computing layers, with the second computing layer acting as an intermediary layer for transmitting information between the first and third computing layers and / or vice versa, across the first and second interfaces. Thus, the second interface enables inter-layer communication at least between the second and third computing layers, and optionally even indirectly between the first and third computing layers. The latter is particularly useful if one or more systems or functions in the system of the third computing layer need to interact with one or more systems in the system of the first computing layer. This may occur, for example, if the third computing layer is configured to define or (co-defined with the second computing layer) one or more parameters of the second data set discussed above.

[0044] Specifically, in some embodiments, the third computing layer is configured to request or trigger functionality of the second computing layer by communicating corresponding request or trigger information via the second interface. This can also be used, in particular, to implement the common definition of one or more parameters of the second group described above. The trigger information may specifically be a signal or code that causes the second computing layer to perform a specific task associated with the trigger information.

[0045] In some embodiments, at least one computing unit of the third computing layer is configured to be directly connected to one or more sensors or actuators associated with the third computing layer via one or more high-speed communication paths. Such high-speed communication paths may be specifically configured to communicate information at a rate of 1 Mbit / sec or higher (e.g., 100 Mbit / s or higher). This allows for high-speed data communication between sensors / actuators, which may be necessary for real-time applications (e.g., in the context of highly automated driving or even autonomous driving applications).

[0046] In some embodiments, one module of the CCU includes one or more (especially all) computing units of the third computing layer. In this way, computing units of the second and third computing layers can be spatially co-located, particularly within the same rack of the CCU. This is particularly useful in the context of maintaining, repairing, and replacing individual modules.

[0047] In some embodiments, the first set of systems (i.e., the system of the first computing layer) includes one or more electronic systems for implementing one or more of the following basic functions of the vehicle: drivetrain, suspension, shock absorption, engine control, and energy supply.

[0048] In some embodiments, the first group of systems includes one or more electronic systems for implementing one or more of the following safety functions of the vehicle: collision detection, functions for responding to a detected collision, one or more airbags, anti-lock braking, and electronic stability control. Such safety functions may also be combined with one or more of the basic vehicle functions described above, for example, to define an emergency shutdown function for one or more systems of the vehicle or even the vehicle as a whole, which is activated upon detection of a collision. Such shutdown activation may specifically include one or more of the following: unlocking one or more door locks and initiating an automatic emergency call.

[0049] All the identified electronic systems that may be included in the first group have in common that they relate to the basic mobility or safety functions of a vehicle (such as a car or motorcycle), making it advantageous to rely on established technologies that have been proven over time (such as those defined by the first computing layer) in achieving the goal of high reliability and safety levels.

[0050] In some embodiments, the second set of systems specifically includes one or more electronic systems for implementing one or more of the following functions of the vehicle: infotainment, navigation, driver assistance, lighting, vehicle interior lighting, servo assistance for steering or braking, user interface, locking system, communication, configurable vehicle interior, mirrors, and over-the-air updates of computer programs or data for one or more electronic systems of the vehicle. Therefore, the second computing layer can be used for a very wide range of different functions, such as comfort functions, which can even be reconfigured in the field, for example, via over-the-air updates.

[0051] In some embodiments, the third group of systems specifically includes one or more electronic systems for implementing one or more of the following functions of the vehicle: high degree of automation or autonomous driving of the vehicle; artificial intelligence-based functions, such as AI-based location determination functions for the vehicle based on imaging, sound, and / or other attributes detected by sensors around the vehicle. The third group may be specifically selected to utilize specific capabilities and capacities available only in the third computing layer, such as high-speed communication paths or specific processing capabilities, such as dedicated high-speed or AI computing units.

[0052] In some embodiments, the CCU includes multiple modules and connection means (such as a backplane) for communicatively interconnecting the modules, wherein at least one of the modules can be releasably connected to the connection means to allow removal, addition, and / or replacement of such modules, thereby providing a high degree of flexibility. The connection means may specifically be a passive connection means, for example, a passive backplane. This is particularly advantageous for achieving the goal of a long lifespan for the CCU. The definition of the term "passive connection means," along with the associated technical effects and related advantages, will be discussed further below.

[0053] In some embodiments, the CCU is configured as an on-board computing unit for a vehicle (such as an automobile) to centrally control various functions of the vehicle, including, in particular, a second set of electronic systems, wherein the CCU includes: (i) A distributed computing system (DCS) comprising multiple co-located, autonomous computing entities (CEs), each of which has its own single memory, wherein the CEs are configured to communicate with each other via message passing through one or more communication networks to coordinate the allocation of computing tasks to be performed by the DCS as a whole. (ii) A communication switch comprising multiple independent switching architectures, each configured to variably connect a subgroup of CEs of the DCS or each CE to one or more interfaces for exchanging information with external communication nodes of the vehicle's CCU via such interfaces; and (iii) A power supply system comprising a plurality of power supply subsystems for simultaneous operation, each of which is capable of individually and independently powering the DCS and at least two switching architectures in the switching architecture.

[0054] Such a CCU can offer many advantages, including one or more of the following: (i) Easy scalability of computing power (more CEs can be added or removed, and computing tasks can be optimally distributed among available CEs).

[0055] (ii) High efficiency in performing a variety of different types of computing tasks. For example, one or more CEs can be specifically adapted to perform certain specific tasks, such as machine learning, image rendering, real-time processing, general-purpose computing, etc., all with options for sequential and parallel processing, so that computing tasks can be selectively performed by multiple appropriately adapted specialized CEs within the DCS. Furthermore, the total amount of computing power allocated by the DCS to a particular computing task can be variably adapted "in operation"; (iii) High flexibility in performing a variety of different and even varying types of computational tasks. In the conventional automotive ECU “world,” each ECU is typically designed to fulfill a small and limited number of specific, fixed, and dedicated functions, implemented by the underlying ECU hardware and proprietary software typically written specifically for that hardware. Both the hardware and software are intended to remain virtually unchanged until the vehicle reaches the end of its lifespan—potentially with the exception of minor software updates related to bug fixes or very small feature expansions. This solution overcomes these limitations and not only enables flexible allocation of computational tasks among CE groups but also allows for the expansion or modification of the computational tasks and thus the functions that the CCU can support. In particular, the software defining such functionality can be easily updated or upgraded (e.g., “over-the-air” downloads, OTA) to enable such expansion or modification, and even new software can be easily added. Such software-level changes can be performed very frequently, even when needed. Furthermore, by adding, replacing, or removing individual CEs or groups of CEs, even the underlying computational hardware can be easily adapted to support the changed or new functional groups.

[0056] (iv) High performance and power efficiency: Due to co-location, the communication links between CEs can be kept short, enabling high-speed communication between them with minimal power loss and high signal quality. Therefore, high performance, power efficiency, and reliability of the DCS as a whole can be achieved.

[0057] (v) High reliability, due to the high degree of flexibility and redundancy in both the allocation of computing tasks to selected CEs and redundant power supplies.

[0058] Preferred embodiments of the CCU are described below, and these embodiments may be combined with each other in any way unless explicitly excluded or technically impossible.

[0059] In some embodiments, the multiple CEs include a group of two or more master CEs configured to operate redundantly, such that they synchronously perform the same computational tasks or data path coordination tasks, so that the CCU can function normally as long as at least one of the master CEs is functioning normally. Due to redundancy, normal operation of the CCU can be maintained even if all but one master CE fails. Specifically, this can even be achieved without interruption in the event of the failure of one or more master CEs (except for at least one).

[0060] In some embodiments, the plurality of CEs further includes one or more slave CEs, and each master CE includes a resource coordination function configured to: (i) variably define the allocation of computing tasks in a group comprising one or more (particularly all) slave CEs, and optionally in a group comprising all master CEs, and (ii) communicate such allocation to at least each CE that should perform one or more selected computing tasks according to the defined allocation via messaging over a communication network. Thus, while a master CE may selectively allocate computing tasks to all or one subgroup of slave CEs in the DCS, master CEs do not selectively allocate computing tasks to each other. Instead, if a computing task is allocated to a master CE, such allocation will only result in all master CEs synchronously executing the (same) allocated computing task. In this way, redundancy provided by the master CE group is maintained, while the possibility of selectively allocating computing tasks among slave CEs (and optionally also among the master CE group as a whole) provides a high degree of flexibility and enables optimized allocation of computing tasks within the DCS.

[0061] Specifically, in some embodiments, the corresponding resource coordination functions of one or more master CEs are further configured to (i) receive periodic reports of currently active computing tasks performed by one or more slave CEs, and (ii) limit the allocation of said computing tasks based on the reports. This supports the limitation of allocation for current or upcoming computing tasks to be optimized by the DCS, as such allocation can therefore be limited based on the actual available computing power and capacity of a single slave CE or a group of slave CEs as a whole. This is particularly beneficial for avoiding bottleneck situations, for example, where the capacity of a dedicated CE within a group of slave CEs is quite limited. Such a dedicated CE can be, for example, a graphics processing unit (GPU) or a slave CE specifically designed and / or configured to run algorithms in the field of artificial intelligence (e.g., deep learning algorithms, etc.).

[0062] In some embodiments, the corresponding resource coordination function of one or more primary CEs is further configured to limit the allocation of computing tasks based on the amount of energy currently supplied to the CEs and / or switching architecture by the power supply system. In this way, optimized allocation of computing tasks can be achieved even when less than 100% of the power is available due to power shortages and all CEs need to operate at maximum speed. Specifically, this may occur if the remaining available power level is insufficient to power all CEs simultaneously or support all concurrent or upcoming computing tasks. The resource coordination function can be configured to limit the allocation of computing tasks in such cases such that selected computing tasks are abandoned, suspended, or moved to another CE (particularly allowing the CE of the previous task to be shut down or placed in a low-power idle or hibernation mode, etc., to reduce the current power consumption of the DCS).

[0063] In some embodiments, the corresponding resource coordination function is further configured to limit the allocation of the computational tasks, such that the computational tasks are allocated in parallel (i.e., redundantly) to different slave CEs. The overall result of the computational tasks can then be derived from the individual results generated by the involved slave CEs through a voting process based on one or more defined voting criteria, such as processor core load and / or power consumption of the slave CEs. This improves the level of security by executing the algorithm in parallel rather than through costly hardware redundancy compared to classic embedded systems (ECUs).

[0064] In some embodiments, the CCU includes a central fault management function configured to: (i) select a specific primary CE from a group of two or more primary CEs as the current priority primary CE; (ii) have CEs in the CE group perform computational tasks according to the allocations defined by the current priority primary CE, while discarding allocations defined by all other primary CEs; and (iii) if a failure of the current priority primary CE or its associated switching architecture is detected, select another primary CE determined to be functioning normally as the new priority primary CE, such that the allocations defined by the new priority primary CE replace the allocations defined by the malfunctioning current primary CE. The central fault management function can be implemented, particularly in multiple redundant, especially separate and / or independent instances. In some embodiments of these embodiments, selecting the current priority primary CE includes determining from the outset that the specific primary CE to be selected as the priority primary CE is functioning normally. If this is not the case, another primary CE is selected as the priority primary CE from the outset, provided that it is found to be functioning normally. In this way, a very high level of overall reliability and / or availability of the CCU can be ensured from the outset.

[0065] In some embodiments, the central fault management function is further configured to detect malfunctions of the DCS or communication switch based on monitoring information representing one or more of the following: (i) malfunctions detected by a single fault management function of a subsystem (such as a module, e.g., a computing module, a single CE, or a switching architecture) or a single component (such as a semiconductor device) of the CCU; (ii) voltage, current, clock signal, and / or data rate in one or more power lines or signal paths between the power supply system and the DCS (such as signal paths in one or more switching architectures); and (iii) malfunctions detected by the power supply system. In this way, fault (malfunction) detection can be selectively applied, for example, at the most critical location in the CCU and distributed across multiple levels of the CCU, whether at the overall CCU system level, the level of a single module or functional unit of the CCU, or more specifically at the level of a single component or even a signal path or power line. Specifically, when a failure is detected somewhere in the CCU, fault detection can be used to trigger (actively) the use of redundancy built into the CCU. Therefore, a high level of fault detection can be achieved to support the overall reliability and network security of the CCU as a whole and its individual sub-units.

[0066] In some embodiments, the central fault management function is further configured to: (i) classify any detected malfunction according to a predetermined classification scheme to generate corresponding classification information for each classification representing one or more fault categories assigned to the classification scheme for that malfunction; and (ii) react to any detected malfunction based on one or more fault categories assigned to such malfunction. Thus, the CCU can selectively react to any detected malfunction through the central fault management function. In particular, such reaction can be either a priori defined, for example, according to a fault response plan defined as a function of one or more fault categories, or even provisionally or otherwise variablely defined, for example, based on a trained machine learning-based algorithm that takes one or more fault categories assigned to the detected malfunction as input values ​​and provides an output specifying an appropriate reaction, such as one or more countermeasures suitable for mitigating or even avoiding adverse consequences caused by the malfunction.

[0067] In some embodiments, the central fault management function is further configured to: (i) monitor the temporal evolution of one or more differences related to signal propagation and / or signal integrity between two equal signals propagating simultaneously through two or more synchronously operating switching architectures; and (ii) based on the monitored temporal evolution of these differences, determine at least one of (ii-1) an aging indicator indicating the age or aging process of at least one switching architecture and (ii-2) an indicator of a network attack against the CCU; and (iii) activate one or more countermeasures when a potential critical aging condition or network threat is detected based on one or more indicators.

[0068] Because instructions are executed synchronously within the switching architecture, monitoring parameters can be defined and evaluated, even those that monitor minute differences in signal integrity and runtime behavior (fault-free, error-free, failure-free) between switching architectures. These differences are inherent because, in practice, it is virtually impossible for switching architectures to be 100% identical. Instead, each CCU, containing its switching architecture, is subject to numerous manufacturing tolerances that exist even in today's most complex manufacturing processes, such as semiconductor manufacturing and packaging processes. Given its high complexity, where integrated circuits typically contain millions or even billions of gates, the CCU can be considered a physically unclonable function (PUF). If monitoring reveals that the monitored values ​​change over time, this can be interpreted either as an aging indicator or, depending on a threshold, as an indication of an activated cyber threat, such as a hardware Trojan. Therefore, if such a cyber threat or a potential critical aging condition is detected based on one or more indicators, countermeasures can be initiated, such as risk mitigation steps, like issuing relevant warnings, or even a controlled shutdown of the CCU or a portion thereof, as in the failure scenarios or security management scenarios described in this paper.

[0069] In some embodiments, each primary CE has a single, exclusively associated switching architecture in the switching architecture, which is configured to connect the corresponding primary CE to one or more interfaces for exchanging information with external communication nodes of the CCU. Furthermore, selecting a particular primary CE as the current priority primary CE involves selecting from multiple switching architectures the one associated with the current priority primary CE as the single, currently active switching architecture for communicating data to be further processed (e.g., processed by the CE or node), while data communicated via any other switching architecture is discarded. In this way, full redundancy can be maintained for each primary CE containing its corresponding switching architecture, particularly in the sense of "hot standby," where all primary CEs and switching architectures operate virtually simultaneously, allowing the functionality of the current priority primary CE and its associated currently active switching architecture to be immediately taken over by another primary CE and its associated (other) switching architecture, simply by adjusting the allocation of primary CEs and currently active switching architectures accordingly. This adjustment can be made immediately, i.e., without significant delay, ensuring that the CCU as a whole remains available to perform its tasks even if a primary CE or its associated switching architecture becomes unusable.

[0070] In some of these embodiments, the single, exclusively associated switching architecture can be a variable choice, for example, via software and / or hardware switches, such as via FPGA-(re)programming, but in such a way that at any given time, only a single (currently) exclusively associated switching architecture exists for each master CE. This approach can be particularly useful if a previously associated switching architecture malfunctions or fails but the associated master CE does not. Thus, by updating the association, the master CE can continue to operate, albeit with another newly associated switching architecture within the switching architecture.

[0071] In some embodiments, each of one or more primary CEs has two or more switching architectures exclusively associated with that primary CE, and is configured to variably connect the primary CE to one or more interfaces for exchanging information with external communication nodes of the CCU via them. In this way, a further level of redundancy can be provided, i.e., the respective primary CE can continue to perform its duties even if one or more but one of its associated switching architectures malfunctions or fails.

[0072] In some embodiments, each of one or more switching architectures has two or more master CEs exclusively associated with that switching architecture, which is configured to variably connect each of these associated master CEs to one or more interfaces for exchanging information with external communication nodes of the CCU via them. In this way, a further level of redundancy can be provided, i.e., the respective switching architecture can continue to perform its duties even if one or more but one of its associated master CEs malfunctions or fails.

[0073] In particular, the additional redundancy levels for the primary CE and the switching architecture can even be combined such that two or more primary CEs are exclusively associated with two or more switching architectures in the switching architecture.

[0074] In some embodiments, the CCU further includes a safety management function configured to, when it is determined that the power currently available from the power management system is insufficient to properly support all ongoing or upcoming scheduled computing tasks, selectively allocate the remaining power still available from the power supply system among the computing tasks and / or different components of the CCU. This safety measure is particularly useful in emergency situations, such as in the event of partial system failure, for example after a car accident, or a sudden defect in a critical subsystem or component of the CCU, or if external influences (such as very cold temperatures reducing the battery's power supply capability) adversely affect the balance between required and available power in the CCU. For example, in the event of a detected car accident, the power required to move or guide the car to a safe location (e.g., a roadside or nearby parking lot) is more important than continuing for purely convenience functions (such as air conditioning or entertainment functions). Therefore, providing the remaining power to the computing tasks required to move the car to a safe location will generally take precedence over providing power to convenience functions.

[0075] Specifically, in some embodiments, the safety management function is configured to determine the selective allocation of the remaining power based on the classification information. In this way, a previously defined optimized power allocation scheme can be used, which defines the selective power allocation based on scenarios associated with one or more categories. This enables the safety management function, and therefore the CCU itself, to respond quickly, optimally, and pre-planned to safety-related scenarios, if they should occur.

[0076] In some embodiments, the CCU (i) is further configured to perform one or more predefined emergency functions when its normal function is impaired or interrupted (e.g., if all main CEs fail simultaneously), and (ii) includes an emergency power source configured to power at least one emergency function when the power supply system is unable to provide sufficient power to support at least one predefined emergency function of the CCU. Impairment or interruption of the normal functioning of the CCU can be specifically determined when the fault management system detects any malfunction, or more specifically, only when the fault management system detects malfunction that meets one or more predefined criteria, such as malfunctions from a set of predefined critical malfunctions. Examples of emergency functions may be activating or shutting down potentially hazardous components of the vehicle or initiating an emergency call (such as calling “110” or “112” in Germany or “911” in the United States).

[0077] In some embodiments, one of the switching architectures (e.g., a third switching architecture not redundantly powered by the power supply subsystem described above) is configured as an emergency switching architecture, such that: (i) an emergency power source is configured to power the emergency switching architecture when the power supply system is unable to provide sufficient power to support emergency functions; and (ii) the emergency switching architecture is configured to variably connect only CEs in a true subgroup of CEs (the subgroup containing at least one slave CE, e.g., one or more exclusive slave CEs among the slave CEs) to one or more of a plurality of interfaces for exchanging information with external communication nodes (e.g., those of vehicles) of the CCU via them.

[0078] In this way, in the event of impairment or interruption of normal CCU function (emergency situation), the emergency operating mode of the CCU can remain available in many cases, where selected emergency functions powered by the emergency power source (such as stopping the vehicle in a controlled manner, e.g., pulling it to the side of the street or road and bringing it to a stop, activating warning lights, etc.) are available, while any functions handled by one or more other CEs outside the CE subgroup during normal operation will automatically terminate due to lack of power supply, and therefore no resource control functions need to be involved for this purpose. This also helps to optimize the use of the remaining energy budget of the emergency power source by avoiding the power consumption allocated to less important functions of CEs outside the subgroup. The CCU can be specifically configured such that the emergency switching architecture is managed by at least one of the main CEs. In this document, “managing” the switching architecture can specifically include one or more of the following: (i) activating and / or deactivating the switching architecture, (ii) selecting or otherwise defining a specific operating mode of the switching architecture (from a set of multiple available modes), and maintaining or transferring the switching architecture to such selected / defined mode. A given operating mode can specifically define the relevant specific communication path used to transmit information to be communicated via the switching architecture between its inputs and one or more of its selected outputs.

[0079] In some embodiments, one or more of the (i) central fault management function and (ii) security management function are redundantly implemented through their respective multiple independent instances, wherein each of the main CEs has a distinct instance of one of the associated instances (each of the aforementioned functions). In this way, further hardening of the CCU against failure can be achieved.

[0080] In some embodiments, at least one of the switching architectures further includes an associated bridge for at least one of the interfaces, for converting information to be communicated via the respective interface between different communication technologies (e.g., communication standards or protocols such as Ethernet, PCI Express (PCIe), CAN, or LIN). This allows for a hybrid system involving multiple communication technologies within the CCU itself, and also allows for (typically wireless) communication with external communication nodes of the CCU (such as vehicle sensors or actuators) or even external nodes of the vehicle (such as traffic control infrastructure or other vehicles).

[0081] In some embodiments, each of the switching architectures is designed as a PCI Express switching architecture. Among the advantages achievable in this way are high data rates, high reliability due to point-to-point connections (as opposed to bus-type connections), and hot-plug capability, which, combined with the ability to quickly and easily switch or replace modules (such as the compute modules of the CCU, each with one or more CEs) is particularly useful. Furthermore, PCI Express technology allows for the separation of concerns using what is specifically called a non-transparent bridge (“NTB”): specifically, in some embodiments, at least one of the CEs includes a plurality of PCI Express root ports, each communicatively connected to at least one of the switching architectures designed as a PCI Express switching architecture. In particular, one or more of the PCI Express switching architectures may include a PCI Express interface operable as a PCI Express non-transparent bridge (“NTB”) to establish a communication path between a first CE communicatively connected to the PCI Express non-transparent bridge via an associated PCI Express root port of that CE and a second CE communicatively connected to the PCI Express switching architecture. Thus, these embodiments allow data transfer between endpoints in different PCIe hierarchies.

[0082] In the context of PCI Express (PCIe) technology, from a functional perspective, Non-Transparent Bridges (NTBs) and Transparent Bridges (TBs) share the commonality of providing communication paths between independent PCIe hierarchies. However, unlike TBs, NTBs ensure that downstream network devices are not transparent (invisible) to upstream devices through their non-transparent effect. This allows the master CE and the corresponding switching architecture-related devices (downstream) to act and appear as an intelligent control entity. The communication path between the downstream hierarchy / bus enables data to be directly transmitted to the upstream side of the bus "without the master CE acting as an intermediary" (the data flow path does not need to run through the master CE first). Therefore, similar to point-to-point bridge mechanisms, transactions can be forwarded across the bus without obstacles based on NTBs, while the corresponding resources remain hidden.

[0083] In summary, these embodiments allow for greater flexibility in the system design and operation of the CCU. The latter is particularly significant because data can now be exchanged even between endpoints in different PCI Express hierarchies, thus enabling efficient workload sharing between different CEs belonging to different PCI Express hierarchies.

[0084] In some embodiments, the CCU is further configured to perform a boot or reset procedure in which communication nodes connected to at least one PCI Express switching architecture are fully enumerated such that, upon completion of the procedure, these communication nodes have assigned identification codes that allow them to be distinguished by other communication nodes and / or the PCI Express switching architecture itself. In this way, the possibility of easily making such distinctions is realized from the outset, i.e., upon recovery after CCU booting or resetting, such that enumeration is fully available once the CCU is (again) in full operational mode.

[0085] In some embodiments, the CCU is configured to operate two or more (particularly all) CEs according to the same shared clock. This is particularly useful for dynamically allocating ongoing or upcoming computational tasks among CEs, as it eliminates the need for additional—particularly time-consuming, power-consuming, or space-consuming—synchronization measures or pipelines to achieve rapid dynamic allocation of computational tasks. Specifically, the master CE may preferably operate according to the same shared clock to achieve a high degree of synchronization.

[0086] In some embodiments, each power supply subsystem in the power supply subsystem individually includes at least one of its own power sources and power control arrangements for controlling the supply of power from that at least one of its own power sources to all CEs and switching architectures, or at least to its subgroups associated with the respective power supply subsystem. Therefore, each power supply subsystem thus achieves a high degree of independence, specifically, it can power the CCU, or at least most of it, even if it is the only (still) operating power supply subsystem due to a power supply subsystem failure. Thus, the overall reliability of the CCU is further improved.

[0087] In some embodiments, each power control arrangement in the power control arrangement is configured to control the power supply from at least one of its own power sources to different subsystems (e.g., CE or switching architecture) or components (e.g., semiconductor chips, such as system-on-a-chip, SOC) of the CCU, selectively as a function of the amount of energy that at least one of its own power sources is currently able to provide.

[0088] In some embodiments, the CCU further includes a supply controller configured to: (i) determine, based on state information representing the current state of each power supply subsystem, the distribution of individual power supply contributions to be supplied by each power supply subsystem such that these contributions collectively satisfy the current target power level of the CCU; and (ii) control the power supply subsystems such that each of them supplies power according to its determined individual power supply contribution.

[0089] Specifically, the supply controller can be configured to control the power control arrangement of two or more (especially all) power supply subsystems so that they each supply a corresponding individual power supply contribution determined by their respective power sources. The controller can be specifically configured to determine this distribution based on a voting scheme for selecting a particular power supply subsystem as a single power source or according to a load-sharing scheme, which requires two or more power supply subsystems to supply power simultaneously, each according to its individual power supply contribution defined by the distribution.

[0090] In some embodiments, the CCU includes security functions configured to apply one or more of the following: (i) encrypting or obfuscating data to be communicated via the switching architecture; (ii) authenticating at least one device that is directly or indirectly connected to one or more switching architectures as communication nodes; and (iii) securely offloading security tasks associated with the security functions to a dedicated security component of the CCU other than the CE. While options (i) and (ii) are specifically designed to improve the overall security of the CCU, for example, by providing protection against unauthorized access to data communicated or computed within the CCU, option (iii) primarily addresses efficiency and speed, as security tasks that would otherwise consume the computing power of one or more CEs can be offloaded to the dedicated security component. As a dedicated component, the security component can be specifically optimized, for example, based on specific hardware, to perform the relevant security tasks more efficiently than the CE (which typically needs to be capable of performing a wider variety of different computing tasks), thereby improving even the overall efficiency of the CCU. Furthermore, these dedicated security components can have special (e.g., hardware-based) security features not available on the CE.

[0091] In some embodiments, the CCU is configured to co-locate the CEs within the same shared housing structure. Furthermore, one or more CEs, individually or together with one or more other CEs, are incorporated into a corresponding replaceable module that can be individually inserted into and removed from the housing structure. This has the advantage that the CCU is not only “centralized” from an abstract computational perspective but also physically “centralized.” This contrasts with the classical approach of today, where numerous different controllers (ECUs) are physically distributed throughout the vehicle, each ECU dedicated to performing selected computational tasks relevant only to specific vehicle functions. The co-location approach according to these embodiments is particularly useful for the initial installation, maintenance, repair, updating, and upgrading of the CCU, as it allows for the spatially integrated and modular provision and access to the CCU's subsystems, particularly modules. For example, if more computational power than initially available is required to enable further computationally intensive functions recently acquired by the vehicle owner (i.e., after vehicle delivery), one or more associated computing modules can be easily replaced by a more powerful module (e.g., a module with more or more advanced CEs). Similarly, due to centralized and modular approaches, malfunctioning modules can be easily replaced. Furthermore, providing a shared housing structure helps reduce weight, minimize connector variations, and enable central software updates (rather than localized updates for each ECU). Additionally, the entire vehicle manufacturing process can be simplified by integrating a pre-configured modular CCU instead of several ECUs located in different parts of the vehicle.

[0092] In some embodiments, two or more (in particular all) main CEs are incorporated into the same module within a module. Such a module can be designated, for example, as a "main module," and is particularly useful if optimization is needed to maximize the number of other modules within a CCU in a given specific setting.

[0093] In some embodiments, the CCU further includes a service module configured to also be housed in the housing structure, the service module including at least one (especially all) of a power supply subsystem, a switching architecture, and an interface.

[0094] For example, the CCU's spatial configuration can be defined such that there is one main module (comprising two or more main CEs) and an additional number N of other computing modules ("extension modules"), each module including one or more slave CEs, such that the overall arrangement of the modules results in a compact form factor. Another module could be, for example, a service module. Specifically, in some embodiments, the service module is designed as a replaceable module that can be individually inserted into and removed from the housing structure. Therefore, in this case, the service module can also be easily replaced, removed for repair or maintenance, or upgraded by replacing it with a more advanced version.

[0095] In some embodiments, the housing structure includes a rack with two or more compartments, each compartment accommodating a corresponding module from the modules. For example, in the case of N=4, i.e., if there are a total of six modules (main module, service module, and N=4 expansion modules), the compartments of the rack can be arranged in two rows and three columns (or vice versa).

[0096] In some embodiments, the housing structure further includes a connection means, such as a backplate, configured to: (i) provide one or more physical communication paths for at least one of the communication networks to exchange messages between CEs co-located in the housing structure and each of which is communicatively connected to the connection means as a corresponding communication node of the at least one communication network; and / or (ii) connect at least one of the CEs co-located in the housing structure to the power supply system to provide power to the at least one CE. This approach is particularly useful when combined with the concept of simple module replaceability, as it enables plug-and-play functionality where all necessary connections for the replaceable module can be implemented as detachable connections, for example, using suitable connectors between the module and the connection means, such as plug-and-receptacle type connectors.

[0097] In some embodiments, the connection device is a passive connection device, such as a passive backplane, which exclusively includes components that cannot achieve power gain.

[0098] As used herein, the term "passive connection device" may specifically refer to a circuit board, such as a printed circuit board (PCB), which includes multiple connectors, particularly for exchanging signals carrying information, such as electrical or optical signals modulated based on the information to be carried, and, in terms of its components, the circuit board exclusively includes passive components, i.e., components that cannot achieve power gain. For example, and not limited to, connectors, electrical or optical traces, purely optical signal splitters and / or combiners, resistors, and capacitors are generally passive components, while transistors or integrated circuits, such as CPUs or system-on-a-chip (SoCs), are active devices. Specifically, the connection device may even lack any active or passive components (such as components to be attached to the PCB, e.g., by soldering, like SMD or PCB-embedded components), except for electrical or optical traces, e.g., on the printed circuit board, and connectors, in order to enable (particularly substantially transparent) exchange of electrical or optical signals or power via the connection device. Such a design is particularly advantageous with regard to very high fail-safety, because there are no components with typically (too short) finite average lifetimes and / or high susceptibility to failure. Then there is no need to cool any components.

[0099] Using passive connection devices offers several advantages, including a high level of reliability because there are no active components that are likely to fail over time. Therefore, when a CCU is installed in a given vehicle, the likelihood of needing to repair or replace the connection device can remain very low, at least on average, because passive components typically tend to fail at a much lower frequency than active components.

[0100] A second aspect of the invention relates to a vehicle that includes a computing platform comprising the first aspect (e.g., any one or more of the embodiments described herein).

[0101] Therefore, the description of the computing platform of the first aspect provided in this paper is similarly applicable to the vehicle of the second aspect. Attached Figure Description

[0102] Further advantages, features, and applications of the present invention are provided in the following detailed description and accompanying drawings, wherein: Figure 1A An embodiment of this solution illustrates a first block diagram, which illustrates the functional building blocks of an exemplary CCU and the associated high-level communication structures for communicating within the CCU and with external nodes of the CCU. Figure 1B A more detailed illustration is provided. Figure 1A Some functional building blocks of the CCU; Figure 2AAn embodiment of this solution illustrates a first view of the second block diagram, which shows more details of the functional building blocks of the CCU in Figure 1, with a focus on the redundant settings of power supply and power supply coordination, control coordination and computation coordination within the CCU. Figure 2B The diagram shows a second view of the block diagram in Figure A, but the focus now is on anomaly detection in the power supply domain; Figure 2C The diagram illustrates the redundancy concept of multiple instances with each primary CE and / or each associated switching architecture; Figure 3 The diagram illustrates a classic strict hierarchical communication scheme in the existing technology based on PCI Express communication technology; Figure 4A An exemplary adaptation communication scheme based on PCI Express technology is illustrated according to an embodiment of this solution. Figure 4B Various exemplary communication links implemented by the adapted communication hierarchy structure of Figure 4 are illustrated according to embodiments of this solution. Figure 5 A third block diagram is illustrated according to an embodiment of this solution, which shows more details of an exemplary CCU (e.g., the CCU of Figure 1), particularly its communication switch; Figure 6 An exemplary housing concept of an exemplary CCU (e.g., the CCU of FIG1) is illustrated according to an embodiment of this solution; Figure 7 A schematic illustration shows an exemplary embodiment of the computing platform; Figure 8 schematically illustrated Figure 7 An exemplary embodiment of the first computing layer of a computing platform; Figure 9 schematically illustrated Figure 7 An exemplary embodiment of a synchronization scenario between the first and second computing layers of a computing platform; Figure 10 schematically illustrated Figure 7 An exemplary embodiment of the second computing layer of a computing platform; Figure 11 schematically illustrated Figure 7 An exemplary embodiment of the third computing layer of a computing platform; Figure 12A The illustration schematically depicts a vehicle (car) including the computing platform shown in Figure 1; and Figure 12B The illustrations depict vehicles (especially automobiles) equipped with CCUs and various suitable locations for placing the CCUs within the vehicles.

[0103] In the accompanying drawings, the same reference numerals are used for the same or corresponding elements of the computing platform described herein. For clarity, the following detailed description is structured into sections introduced by headings in each case. However, these headings should not be construed as limiting the content of the corresponding sections or any of the drawings described therein. Detailed Implementation

[0104] Central Computing Unit (CCU) Figure 1A and Figure 1B A (first) block diagram 100 is shown, illustrating selected functional building blocks of an exemplary CCU 105 and related high-level communication structures for communicating within the CCU 105 and with external communication nodes 140, 145, 150 and 155 / 160.

[0105] CCU 105 includes (i) a computer module cluster 110, which includes a main computing module 115, one or more general-purpose computing modules 120 and one or more special-purpose modules 125, (ii) a service module 135, and (iii) a connection device 130, such as a backplane (which may be particularly a passive backplane), for interconnecting these modules with each other and with the service module 135.

[0106] The interconnection provided by the connection device 130 may specifically include a power connection for exchanging power P (such as electrical power), a data connection for exchanging data D (e.g., Ethernet, PCI, or PCIe), and a control connection for exchanging control information C (e.g., I...). 2 C) An alarm connection for exchanging alarm information A, and a power management connection for exchanging power management information I.

[0107] exist Figure 1A In this example, the external communication nodes of the CCU include a first endpoint cluster 140, which is optically connected to the CCU 105 (e.g., via fiber optic communication link O), and a second endpoint cluster 145, which is connected to the CCU 105 via a wireless communication link W (e.g., Bluetooth, WLAN, ZigBee, or a cellular mobile connection link). Another endpoint cluster 150 (which may specifically be or include a regional hub for interconnecting the CCU to other endpoints) can be connected via a cable connection. Yet another endpoint cluster 160 may be connected to the CCU 105 via a separate intermediate wireless transceiver 155.

[0108] Furthermore, two or more endpoints in an endpoint cluster can be directly linked to each other via a communication link not involving CCU 105, as illustrated by the wireless link W between endpoint clusters 150 and 160. Each endpoint is a node within a communication network formed by communication links that connect endpoints directly or indirectly to CCU 105 or to each other. In particular, an endpoint can be or includes one or more actuators, sensors, and intermediate network nodes, such as a hub for connecting multiple other endpoints. As used herein, the term “endpoint cluster” refers to a group of endpoints that are directly or indirectly connected to the same network node via corresponding communication links so that they can all exchange information with that common node. Typically, the common node will have some kind of hub function, i.e., act as an intermediate node in the communication links between other nodes connected to it.

[0109] CCU 105 further includes (in Figure 1A and Figure 1B (Not shown in the diagram) Communication switch and power supply system. These building blocks of the CCU105 will be referred to in Figures 2 to 3 below. Figure 5 Further discussion.

[0110] Now for reference Figure 1B It illustrates in more detail Figure 1A The computing module cluster 110 comprises modules 115, 120, and 125. First, module 115 is selected, which functions as the main computing module and includes (and thus in co-location) at least a first computing entity (CE) 115a and a separate second computing entity 115b, and optionally one or more other CEs 115c. All these CEs are autonomous and independent of each other, in the sense that they all have comparable, ideally identical computing power and their respective individual memories, such that each of these CEs can be used as a corresponding replacement for another of these CEs.

[0111] In further discussion, for simplicity and without limitation, an exemplary case is considered in which no other CE 115c exists in the main computing module 115 besides CE 115a and 115b. Each of CE 115a and 115b can be implemented in a respective separate hardware unit, such as a semiconductor chip, for example, a system-on-a-chip (SOC).

[0112] The two CEs 115a and 115b (e.g., via corresponding software (multiple computer programs)) are configured to operate redundantly in such a way that they synchronously execute the same computational tasks so that the CCU can function properly as long as at least one of CEs 115a and 115b is functioning correctly. Therefore, there is redundancy between CEs 115a and 115b not only in terms of redundant hardware but also in terms of the computational tasks they synchronously execute, so that if one of CEs 115a and 115b fails (with or without warning), the other corresponding CE can immediately step in and thus maintain the computational function of the main computing module 115 based on the synchronous execution of the same computational task it is already performing.

[0113] Now, before continuing to explain the remaining building blocks of the main computing module 115, refer to the general-purpose computing module 120. Module 120 includes at least one autonomous CE 120a and optionally one or more other CEs 120b. CEs 120a and 120b are designed as general-purpose computing entities, that is, computing entities designed to perform all kinds of different computing tasks rather than being limited to performing one or more specific types of computing tasks (such as graphics or audio processing or running artificial neural networks or other artificial intelligence algorithms). Each of CEs 120a and 120b has its own memory and is capable of autonomously performing the computing tasks assigned to it, independent of the other CEs.

[0114] In addition, each module 120 includes a corresponding individual fault management system (FMS) 120c, which is configured to detect malfunctions occurring within or at least involving module 120, such as hardware and / or software errors or defects. FMS 120c is further configured to communicate any such detected malfunctions to the main computing module 115 via alarm information A through connection device 130.

[0115] Turning now to the multiple special-purpose modules 125, in contrast to the multiple general-purpose computing modules 120, the special-purpose modules 125 are specifically designed to perform one or more selected tasks, such as computational or communication tasks, and are generally less suitable or even unable to perform general-purpose computing tasks like those of modules 115 and 120. For example, one or more of the multiple special-purpose modules 125 may be or include a graphics processing unit (GPU), a module specifically designed to run one or more artificial intelligence algorithms, a neural processing unit (NPU), an in-memory computing unit (IMCU), or a local hub module. Thus, the special-purpose module 125 may specifically include one or more CEs 125a and / or one or more communication interfaces 125b for establishing communication links, such as links to endpoints or endpoint clusters. Each CE 125a has its own memory and is capable of autonomously performing the computational tasks assigned to it, independent of other CEs.

[0116] In addition, each of the (multiple) modules 125 includes a corresponding individual fault management system (FMS) 125c, which is configured to detect malfunctions occurring within or at least involving module 125, such as hardware- and / or software-based errors or defects. FMS 125c is further configured to communicate any such detected malfunction to the main computing module 115 via alarm information A through connection device 130.

[0117] While the computing module cluster 110 may therefore include one or more general-purpose computing modules 120 and / or one or more special-purpose modules 125, and / or even other modules, in a simplified form it can be implemented without such additional modules, such that only the main module 115 is retained as a computing module. In particular, the computing module cluster 110 or any one or more of its computing modules 120, 125 may be implemented based on a set of interconnected chiplets as its components.

[0118] Returning to the main computing module 115, among all modules, this module 115—among other roles—is responsible for allocating tasks (including, in particular, computing tasks) to the various modules 115, 120, and 125 of the computing module cluster 110. This allocation process thus provides resource coordination functionality 115d for the computing module cluster 110. CEs 115a and 115b can therefore be designated as "master CEs," while the other CEs within modules 120 and 125, being the recipients of this task allocation process, can therefore be designated as "slave CEs" because they are to execute the tasks assigned to them by the master CE(s).

[0119] The task assignment defined by (multiple) master CEs 115a / 115b is communicated to the slave CE via message passing through the connection device 130, thereby communicating, for example, the corresponding control information C and / or data D.

[0120] Specifically, the resource coordination function may include a process in which the main computing module 115 receives periodic reports of the main software operations (including parallel and sequential operations) of all CCU processes (running on the CE group), and the current priority main CE 115a assigns tasks among and to each CE based on these reports (while another main CE 115b synchronously runs the same process, although its associated task assignments are discarded). Alternatively or additionally, the allocation may depend on the amount of available energy currently available to power the CCUs.

[0121] Although such allocation could even include assigning computational tasks to the main CE 115a,b itself, such allocation would treat both main CE 115a,b similarly so that both would execute the self-allocated tasks synchronously, thereby maintaining full redundancy in the operation of both main CE 115a,b.

[0122] In summary, the CE groups for each module (see reference below) Figure 6 An exemplary embodiment of the CCU will be explained in more detail (these modules are co-located) thus forming a distributed computing system (DCS), wherein computing tasks to be executed by the DCS as a whole can be variably assigned to different CEs within the computing module cluster 110, and wherein such assignment is communicated by passing messages between the involved CEs.

[0123] The main computing module 115 further includes a central fault management system (CFMS) 115f, which is configured to receive fault-related anomalies detected within the DCS via alarm information A provided by one or more of the FMSs of other modules or even from alarm information A provided by its own single FMS 115g. The CFMS 115f is configured to classify and classify such alarm information A and initiate countermeasures, such as reassigning computing tasks from the faulty CE or module to another module, or prioritizing tasks when remaining computing power is insufficient, so as to support more important tasks at the expense of less important tasks.

[0124] The main computing module 115 further includes a safety management system (SMS) 115e, which is configured to make decisions on necessary safety measures (i.e., safety status escalation, including real-time scheduling) and to activate these necessary safety measures when needed to bring the CCU and / or its assisted controlled vehicle 800 into a safe state. Therefore, the safety management system 115e may particularly rely on alarm information A available from the CFMS as input, which in turn integrates alarm information received from the individual FMSs of the various modules of the CCU 105.

[0125] For example, if alarm message A (or some other information available to SMS 115e) indicates a power shortage in the power supply system of CCU 105, SMS 115e may decide to use all remaining power to guide vehicle 800 to the roadside while shutting off power to all non-essential systems of vehicle 800. These non-essential systems might be related to, for example, air conditioning or entertainment systems, and modules of CCU 105 that are not required for the essential task of safely guiding vehicle 800 to the roadside. These essential tasks might include, for example, turning on warning lights and tasks related to vehicle 800's braking system.

[0126] The Central Fault Management System (CFMS) 115f and the Resource Coordination Function (RCOS) are preferably implemented redundantly across multiple instances, such that a failure in one instance can be compensated for by another. Specifically, each CE 115a and 115b may have a distinct instance of such an associated system, such that each of CEs 115a and 115b is autonomous, containing an autonomous CFMS 15f and RCOS.

[0127] Each of the RCOS 115d, SMS 115e, CFMS 115f, and FMS 115g can be specifically implemented, wholly or partially, as one or more computer programs designed to run synchronously (in separate instances) on each of the main CEs 115a and 115b. Hybrid implementations are also possible, where dedicated hardware is provided in addition to one or more processors for running the software to selectively offload certain tasks, such as offloading to a high-performance dedicated system-on-chip (SoC).

[0128] Figure 2A An embodiment of this solution illustrates a second block diagram 200 showing more details of the functional building blocks of the CCU of FIG1, with emphasis on its redundancy settings.

[0129] As referenced above Figure 1A and Figure 1B As already discussed, the compute module cluster 110 includes two or more master compute modules (CEs) within its main compute module 115, which in this example are master CEs 115a and 115b. Therefore, redundancy is available at the master CE level.

[0130] In addition, the CCU 105 includes a communication switch, which in turn comprises multiple independent switching architectures. Figure 2AIn this example, there are two independent and autonomous (primary) switching architectures 225a and 225b, and a third switching architecture 225c for emergency situations. All switching architectures 225a, b, and c are housed within service module 135. Each switching architecture 225a, b, and c includes hardware for variably connecting multiple different nodes (such as nodes in a computer network) to variably exchange data between them. In this example, the network includes modules of computing module cluster 110 and various endpoints or endpoint clusters thereof as nodes, such as... Figure 1A , Figure 4A / B and Figure 5 As shown in any one or more of the diagrams. Each of the (master) switching architectures 225a and 225b is signal-connected to a master CE associated with the master computing module 115, so that it can selectively switch the flow of information between the respective master CE 115a or 115b and other nodes in the network, such as nodes 120, 125, and 140 to 160. Specifically, the switching architecture can be designed as a PCI Express (PCIe) compliant switch (PCIe switch). The same applies to the third switching architecture 225c, although it may have limited connectivity. For example, it may only connect to the subgroups of the endpoint group and / or only connect to the subgroups from the CEs 120a, 120b, 125a group, or even not connect to any of these CEs.

[0131] For security purposes, network connections between the switching architecture and other nodes in the network can be protected by one or more security features 230a,b and 235a,b, such as authentication, packet inspection, encryption, digital signatures and / or obfuscation, and may involve offloading to a designated security device. Specifically, security features can be implemented as building blocks of the corresponding associated switching architecture, such as... Figure 2A , Figure 2B As shown, authentication and packet detection are provided as protection functions on the architecture endpoint side in each of security blocks / functions 235a and 235b, while one or more other security functions may be provided on the CE side of switching architectures 225a, 225b and 225c in each of security blocks / functions 230a and 230b.

[0132] The main computing module 115, with main CEs 115a and 115b, and the switching architectures 225a, 225b, and 225c with their associated security functions / blocks, collectively define the computing task coordination domain 205 of the CCU 105, where computing tasks can be variably distributed among the modules of the computing module cluster 110. The CCU can be specifically configured to fully enumerate all nodes in the network during the boot and / or reset processes, such that upon completion of these processes, all nodes possess a defined identity within the network, e.g., an assigned identification code by which they can be unambiguously identified within the network. The enumeration process can be specifically performed under the guidance of the communication switch and / or the main computing module 115.

[0133] To avoid any confusion, at any given point in time, only one of the primary CEs 115a and 115b (e.g., by a relevant identifier) ​​is designated as the current priority primary CE. This means that other entities in the CCU will only "follow" its commands (such as the assignment of computational tasks) and ignore any commands from any other primary CE. In Figure 2, primary CE 115a is currently designated as the current priority primary CE, while primary CE 115b is not.

[0134] This is Figure 2A The diagram uses shading to indicate that the current priority master CE 115a and all other building blocks of block diagram 200 that are particularly associated with the current priority master CE 115a are shown with "downward" shading and reference numeral attribute "a" (e.g., "225a"), while the other master CE 115b and all other building blocks of computing task coordination domain 205 that are particularly associated with the other master CE 115b are shown with "upward" shading and reference numeral attribute "b" (e.g., "225b").

[0135] If a malfunction is detected in the current priority master CE 115a or its associated switching architecture 225a, then (e.g., via built-in self-test) another master CE 115b that is functioning normally is identified as the new priority master CE, and the new priority master CE takes over the role previously held by the malfunctioning current master CE. The same applies to associated switching architectures. For example, if a malfunction is detected in the current priority master CE 115a and / or its associated switching architecture 225a, for example due to a hardware defect, then the previously redundant master CE 115b and its associated switching architecture 225b are identified as now having priority and taking over the role previously held by the master CE 115a and its associated switching architecture 225a.

[0136] Furthermore, in emergency situations, such as when another switching architecture 225b (now acting as the new priority switching architecture) is also found to be malfunctioning, the third switching architecture 225c can be identified as now gaining priority and taking over the role of the previous priority switching architecture 225a or 225b. If the third switching architecture 225c has limited connectivity, as described above, then when the third switching architecture 225c takes over, all unconnected endpoints and CEs will automatically disconnect from the switching functionality of the service module 135. In this way, the CCU can focus on emergency tasks without even needing to be involved in resource coordination functions. The CCU 105 (e.g., its service module 135) may include other power sources, such as an emergency power source 240c. It may be specifically designed to be a temporary power source with only a limited capacity than the main power sources 240a and 240b, but with sufficient capacity to power at least the third switching architecture 225c (if in operation).

[0137] Turning to the power supply system for the CCU 105, there are two (or more) redundant, independent power sources 240a and 240b, each capable of individually providing sufficient power (such as electrical power) to the CCU 105 to support all its functions, at least under normal operating conditions. In normal operation, all these power sources are configured to operate simultaneously to jointly provide a redundant and therefore highly reliable power supply to the CCU 105. Power sources 240a and 240b can be components of the CCU 105 itself, or they can be external to it, for example, as a vehicle battery external to the CCU.

[0138] To further support the redundancy concept upon which CCU 105 is based, a single independent power network exists for each power source 240a and 240b (see [link to relevant documentation]). Figure 2A and Figure 2B The "primary" path and "redundant" path in the CCU105 are used to distribute power supplied by the corresponding power sources 240a or 240b among the physical components requiring power in the CCU105, including but not limited to all CEs in each computing module and all switching architectures 225a and 225b. Specifically, each power source 240a and 240b and its corresponding power network are configured to simultaneously power all switching architectures, thereby achieving full redundancy and maintaining the operation of the CCU 105 even in the event of failure of one switching architecture or one power source.

[0139] Current limiters 245a,b can be provided within the power network to ensure that any current flowing in the power lines of CCU 105 (particularly the power lines in its service module 135) remains below correspondingly defined current thresholds to prevent any current-based damage or malfunction that may occur if the current level rises above these corresponding thresholds. The power network, and optionally power sources 240a, 240b (if part of CCU 105), defines a power supply domain 220 for CCU 105, which provides a high degree of reliability due to its redundant configuration.

[0140] The various hardware components of the CCU 105 may have different voltage requirements for their power supply. Therefore, the power system of the CCU 105 may further include various redundantly provided voltage generation units, each configured to provide the same set of different power supply voltage levels required, and distributed via a backplane to architectures 225a,b,c. For example, a first voltage level may be 3.3V to power a first group of devices (such as the CCU 105's Ethernet to PCIe bridge), a second voltage level may be 1.8V to power a second group of devices (such as the CCU 105's microcontrollers and NOR flash memory devices), a third voltage level may be 0.8V to power a third group of devices (such as the CCU 105's DRAM memory devices), and so on. This allows the CCU 105's control coordination domain 210 to control the voltage levels of the entire service module 135, as well as the voltage levels directly supplied by 145a / b and generated within the computing cluster 110, through control by the computing task coordination domain 205.

[0141] Specifically, voltage generation units 250b and 255b generate the same set of voltages. Voltage generation unit 250b provides the entire set of voltage levels to architecture 225b, and voltage generation unit 255b provides the same entire set of voltage levels to controller 260b. The controller compares the voltage set supplied by voltage generation unit 250b to architecture 225b with the voltage set received from voltage generation unit 255b—these two should be the same. However, if the controller determines that the voltage level sets do not match, a problem is detected, and the controller can initiate a reaction, for example, shutting down one or more components. The same applies to voltage generation units 250a and 255a, with necessary modifications.

[0142] All voltage generation units 250 / 255 a / b generate output voltage groups independently based on a load sharing or voting process related to the power supplied simultaneously from power sources 240a and 240b. For example, power supply sharing can be applied when both power supplies are found to be stable, while voting can be applied when one power supply is unstable.

[0143] Furthermore, CCU 105 (i.e., its service module 135) includes two or more redundant controllers, such as microcontrollers 260a and 260b, for controlling selected functions of service module 135. Specifically, microcontrollers 260a and 260b can be configured to use power management information I to control the power supply for communication switches having switching architectures 225a and 225b.

[0144] Service module 135 further includes a monitoring function, which is redundantly implemented in at least two independent instances (e.g., hardware components 265a and 265b). This monitoring may specifically include one or more of current monitoring, voltage monitoring, and clock monitoring. Such monitoring may specifically relate to the power output of voltage generation units 250a,b and 255a,b. The monitoring results are provided to controllers 260a,b, where they are analyzed, and control signals C that define the response to the analysis results and / or, in the event of a detected malfunction, alarm information (signal) A may be issued and communicated to relevant other components of CCU 105, such as CFMS 115f in main computing module 115 and / or other safety functions of CCU 105 (if any). CFMS 115f can thus react accordingly, such as by reassigning current or upcoming computing tasks to CEs unaffected by the detected malfunction.

[0145] Controllers 260a,b, voltage generation units 250a,b and 255a,b, and monitoring unit 265a,b can therefore be designated as the control coordination domain 210 of service module 135. In practice, components on the priority path (i.e., those associated with the current priority master CE 115a) and components on the redundant path (i.e., those associated with the current other master CE 115b) are now grouped separately, and for each master CE 115a,b, a corresponding associated architectural power coordination domain can be defined, including the components of the associated group. In Figure 2, only one of these architectural power coordination domains is drawn (dashed box) and indicated by reference numeral 215.

[0146] like Figure 2BAs shown (power supply paths are not shown here to reduce the complexity of the figures), current limiters 245a,b may be specifically equipped with diagnostic output functionality to generate and output diagnostic data based on the operation of the respective current limiter and / or the characteristics of the power it receives or provides. The diagnostic data can then be provided to controllers 260a,b for further analysis and to initiate appropriate responses. For example, if the diagnostic data indicates a failure or malfunction of one or more components of CCU 105 that may affect the normal operation of the current priority primary CE and / or its associated switching architecture, the priority may be changed from one primary CE 115a or 115b and its associated switching architecture 225a or 225b to another primary CE 115b or 115a and its associated switching architecture 225b or 225a.

[0147] like Figure 2C As shown, Figure 2A and Figure 2B The setup illustrated in the diagram can be further enhanced by adding a level of redundancy beyond the basic redundancy provided by the concept of two or more pairs 170a, 170b (each pair having an associated primary CE 115a (or 115b) and an associated switching architecture 225a (or 225b)), as described above. This further level of redundancy is based on concept 201, which provides this intra-pair redundancy by redundantly (i.e., in multiple instances) providing the primary CE and / or switching architecture for the pair, and also by providing configuration switches 270a, 270b for switching between different configurations of the pair for each such pair.

[0148] Therefore, if the redundant primary CE and / or redundant switching architecture within a given pair fails, the pair as a whole remains operational due to the remaining one or more other primary CEs and / or switching architectures. The prioritization concept of basic redundancy between pairs discussed above can be similarly applied to further levels of redundancy within a given pair 170a (or 170b). Thus, if a pair 170a (or 170b) has multiple redundant primary CEs 115a and 115b, they can be operated to perform the same computational task simultaneously, with one of the primary CEs 115a-1 and 115a-2 (or 115b-1 and 115b-2) designated as the priority primary CE for that pair 170a (or 170b). This also applies to the switching architecture of each pair when the pair has multiple switching architectures 225a-1 and 225a-2 (or 225b-1 and 225b-2).

[0149] As an example, Figure 2CThe illustration shows two separate pairs of such pairs 170a and 170b. Unless such a pair consists of a single master CE (e.g., master CE 115a-1) and a single switching architecture (e.g., switching architecture 225a-1) (“I-shape”), it comprises its own configuration switch 270a (or 270b) and either two (or more) associated master CEs (such as master CEs 115a-1 and 115a-2 (or 115b-1 and 115b-2)) or two (or more) associated switching architectures (such as switching architectures 225a-1 and 225a-2 (or 225b-1 and 225b-2)). The configuration switch 270a (or 270b) is operable to variably switch between at least two different possible configurations of the corresponding pair 170a (or 170b).

[0150] Exemplary shapes for each pair of 170a (or 170b) are: (i) multiple main CEs 115a-1 and 115a-2 (or 115b-1 and 115b-2) and a single switching architecture 225a-1 (or 225b-1) (“Y-shaped”); (ii) a single main CE 115a-1 (or 115b-1) and multiple switching architectures 225a-1 and 225a-2 (or 225b-1 and 225b-2) (“inverted Y-shaped”); and multiple main CEs 115a-1 and 115a-2 (or 115b-1 and 115b-2) and multiple switching architectures 225a-1 and 225a-2 (or 225b-1 and 225b-2) (“X-shaped”). Pairs of 170a and 170b may typically have the same or different shapes at a given point in time. For example, pair 170a can have a Y-shape, while pair 170b can simultaneously have an X-shape. If pair 170a (or 170b) has a shape other than an I-shape, it can be configured using its configuration switch 270a (or 270b), specifically based on the operating state of its components, such as error-free operation or malfunction / failure. For example, if pair 170a has an X-shape or an inverted Y-shape, and a failure of switching architecture 225a-2 is detected, configuration switch 270a can be (re)configured so that it now connects another (error-free) switching architecture 225a-2 to the current priority master CE of that pair, such as master CE 115a-1.

[0151] Now for reference Figure 3 The illustration shows an exemplary conventional strict hierarchical communication scheme 300 based on the standardized PCI Express (PCIe) communication technology for communication between different nodes in a PCIe network, specifically including two different computing entities, such as central processing units (CPUs) 305 and 310.

[0152] CPU 305 includes management functions 305a (e.g., for scheduling computing tasks), processing functions 305b for executing scheduled computing tasks, and a PCIe root complex 305c having three PCIe root ports 315-1, 315-2, and 315-3.

[0153] Similarly, CPU 310 includes management functions 310a (e.g., for scheduling computing tasks) and processing functions 310b for executing scheduled computing tasks, as well as a PCIe root complex 310c having three PCIe root ports 320-1, 320-2 and 320-3.

[0154] All communication flows between this CPU (e.g., CPU 305) and any endpoint 330 in the PCIe network associated with that CPU should use one or more of its root ports 315-1, 315-2, and 315-3 via the CPU's root complex 305c. In addition to PCIe endpoints 330, there may be intermediate hubs in the PCIe network, such as one or more PCIe switches 325.

[0155] Therefore, each CPU 305 and 310 has its own communication hierarchy, containing its own address space and / or clock domain, for communication between any two nodes in its PCIe network, such that, due to this hierarchy, every communication between two nodes in the same network must necessarily go through the root complex of the associated CPU.

[0156] Communication between nodes in different communication hierarchies is achieved through an inter-CPU communication link 335 running between CPUs 305 and 310. Therefore, if a first endpoint 330 in the communication hierarchy of CPU 305 needs to communicate with a second endpoint 330 in the communication hierarchy of another CPU 310, the communication path should run as follows: - The communication hierarchy from the first endpoint upstream through the CPU 305. - Through root complex 305c with associated root port 315, - Through the management functions of CPU 305, - Then it further passes through the inter-CPU communication link 335 to the second CPU 310, and - There, through its 310a management functions, it directs traffic downstream. - Its root complex 310c and its associated root port 320, - And finally to the second endpoint.

[0157] Therefore, because the endpoints of different communication layers are isolated from the CPU of the corresponding other CPU, this communication is not very efficient and may suffer from particularly high latency.

[0158] and Figure 3 Compared to conventional methods, embodiments of this solution can achieve the following: Figure 4A and Figure 4B The illustrated PCIe communication scheme 400. Also in this exemplary scheme 400, there are two PCIe hierarchies, each with its own address space and corresponding single root complexes 405c and 410c. In scheme 400, Figure 3 The first CPU 305 is powered by the main CE (e.g., Figure 1B The main CE 115a) is replaced, and the second CPU 310 is replaced by the slave CE (e.g., Figure 1B Replaced from CE 120a).

[0159] The master CE 115a includes management functions 405a, processing functions 405b, and a PCIe root complex 405c with three PCIe root ports 405d-1, 405d-2, and 405d-3. Similarly, the slave CE 120a includes management functions 410a, processing functions 410b, and a PCIe root complex 410c with three PCIe root ports 410d-1, 410d-2, and 410d-3, as well as a resource coordination system block 415d including resource coordination functions (RCOS). All nodes in scheme 400 share a common clock, i.e., they are in the same clock domain.

[0160] In each communication hierarchy, there is a PCIe switch 415 having one or more non-transparent PCIe bridges (NTBs) 420a for connection to an associated CE and one or more non-transparent PCIe bridges (NTBs) 425a for direct or indirect connection to one or more endpoints or another corresponding communication hierarchy (i.e., its root complex). Figure 3 The CPU-to-CPU communication link 335 is now obsolete and can be discarded.

[0161] Now for special reference Figure 4B This illustrates three exemplary communication paths implemented by the adapted PCIe communication scheme 400.

[0162] The first communication path 435 enables communication between a selected endpoint 430-1 in the hierarchy of the main CE 115a and the slave CE 120a (specifically its processing function 410b). The first communication path 435 runs from endpoint 430-1 to the PCIe switch 415a in the same hierarchy, and from there via NTB 425a to the root point 410d-2 of the root complex 410c of another CE (i.e., the slave CE 120a), from where it finally runs to the processing function 410b.

[0163] The second communication path 440 enables communication between a selected endpoint 430-2 in the hierarchy from CE 120a and the processing function 410b from CE 120a. Therefore, the second communication path remains within the same hierarchy from endpoint 430-2 to PCIe switch 415b to root node 410d-1, and from there through root node 410d-2 to its processing function 410b (i.e., from the processing function of CE 120a), like... Figure 3 The situation is the same as usual.

[0164] The third communication path 445 enables communication between a selected endpoint 430-2 in the hierarchy of CE 120a and another selected endpoint 430-1 in the hierarchy of the main CE 115a. The third communication path 445 runs from endpoint 430-2 to PCIe switch 415b in the same hierarchy, to root point 410d-1 of root complex 410c of CE 120a, and further to root point 410d-2, from where it reaches PCIe switch 415a via NTB 425a, and from there it finally proceeds to processing function 405b.

[0165] All these communication paths, especially the first and third paths that interconnect different hierarchical structures, can be managed by the management function 405a of the main CE 115a. Therefore, scheme 400 uses NTB to achieve “direct” point-to-point communication between distributed locations (included in different hierarchical structures) within the same clock domain, while the communication paths are centrally managed, and in particular configured.

[0166] Figure 5 A third block diagram 500 illustrating more details of an exemplary CCU, particularly its communication switch with service module 135, is shown according to an embodiment of this solution. The CCU has a computing module cluster 110, which includes a main computing module 115, three general-purpose computing modules 120, and a single special-purpose module 125, each as described above. Figure 1A and Figure 1B The corresponding type mentioned above.

[0167] Each module in the compute module cluster 110 is linked to two PCIe switches 415a and 415b. Each of the PCIe switches 415a and 415b is equipped with multiple NTB 420a / 420b on the CE side and multiple other NTB 425a / 425b on the endpoint side. Therefore, the setup is similar to [previous configuration]. Figure 4A / 4B settings, although optionally with different numbers of NTBs.

[0168] Furthermore, the CCU of block diagram 500 includes corresponding bridges 505 for one or more (particularly all) endpoint-side NTBs 425a,b, for switching between different communication technologies used in relevant communication paths running through the corresponding NTBs. For example, such a bridge can be configured to perform a switch from Ethernet communication technology to PCIe technology. Specifically, in Figure 5 In the example, the bridge is configured to perform a conversion from Ethernet communication technology on the endpoint side to PCIe technology on the CE side of the NTB.

[0169] Therefore, PCIe technology is used for communication between modules in the computing module cluster 110 and with PCIe switches 415a,b and toward bridge 505, while Ethernet technology is used for communication between bridge 505 and endpoints 430. The latter can be specifically arranged spatially or through some other common attributes (such as shared functionality, address space, or clock) in the endpoint cluster 515. An Ethernet switch 510 can be arranged between bridge 505 and endpoint cluster 515 to variably connect selected individual endpoints 430 to selected bridges 505. The group of PCIe switches 415a,b and bridge 505 can be specifically implemented within a single SoC or through a chiplet solution, wherein the PCIe switches 415a,b and bridge 505 are distributed across multiple chiplets, each chiplet carrying one or more of these components.

[0170] Therefore, each module of the computing module cluster 110 is connected to each of the two switching architectures, each of which includes a corresponding PCIe switch 415a,b, various NTBs 420a / 425a or 420b / 425b, and multiple bridges 505. In this way, the desired redundancy is achieved, where each endpoint 430 can be reached through each of the communication architectures and from any module of the computing module cluster 110 (and vice versa).

[0171] Figure 6An exemplary housing 600 of an exemplary CCU (e.g., CCU 105 of FIG1) is illustrated according to an embodiment of this solution. Housing 600 includes a rack-type housing structure 605 having multiple compartments, each compartment preferably accommodating modules of CCU 105, such as computing modules or service modules of computing module cluster 110, in a replaceable manner. In this example, six compartments (slots) are arranged in the architecture and collectively (co-located, particularly adjacently) accommodate the main computing module 115, two general-purpose computing modules 120, two special-purpose modules 125, and a service module 135.

[0172] While the first end of housing structure 605 includes a corresponding opening for inserting or removing modules for each compartment, the opposite end of housing structure 605 includes a connection device 130 configured to provide a connection for exchanging one or more power P, data D, control information C, alarm information A, or power management information I between different modules.

[0173] The connecting device 130 may in particular have a substantially planar shape and may therefore be referred to as a “backplate”. Between the connecting device 130 and the opposite rear of the module, each module has one or more connectors 610 to provide the aforementioned connection. In particular, the connectors may be designed as detachable connectors, such that the module can be inserted and connected by (i) pushing them into their respective compartments until one or more associated connectors are engaged, and (ii) removed and disconnected by pulling them out of the compartments and thus detaching the connection.

[0174] Computing platform Now for reference Figure 7 and Figure 8 An exemplary computing platform 700 according to an embodiment of this solution includes three different computing layers 710, 720 and 730.

[0175] The first computing layer 710, which may also be referred to as the “bottom” layer, includes a first group of one or more electronic systems 810 to 835 (e.g., ECUs) to support the vehicle 1200 (see [link]). Figure 12A , Figure 12B Basic movement functions, such as steering, acceleration, and deceleration, for example, braking.

[0176] Furthermore, the first group, and therefore the first computing layer 710, may also include one or more electronic systems to support one or more advanced mobility functions designed to enhance the capabilities of basic mobility functions, such as anti-lock braking systems (ABS), electronic stability control (ESC), or acceleration slip control (ADR), or other systems for enhancing the drivetrain, suspension, shock absorption, engine control, and energy supply capabilities of the computing platform 700 and therefore the vehicle 1200 using the platform. Additionally, the first group of systems may also include one or more electronic systems for implementing one or more of the following safety functions of the vehicle 1200: collision detection, functions for responding to a detected collision, and one or more airbags.

[0177] For example, such as Figure 8 As shown, the first computing layer 710 may include a system 810 for engine control, an ABS system 815, a combined electronic stability control / drive traction control (ESC / ASR) system 820, a lane departure warning system 825, and an energy supply controller 830, for example, for controlling the electrical energy supply from various sources (such as batteries, fuel cells, and / or generators coupled to the engine of vehicle 1200). The first computing layer 710 may further include a system 835 for controlling the shock-absorbing and / or suspension elements of vehicle 1200. Each of these systems 810 to 835 is connected to a communication network 805, such as a bus, for example, a CAN or LIN bus, or an Ethernet network, to enable signal or data communication between these various systems.

[0178] Furthermore, the first interface unit 715 is coupled to the communication network 805, wherein the interface unit 715 defines a first interface within the computing platform 700, the first interface being configured to enable... Figure 7 As shown, information 705 is exchanged in a controlled manner between the first computing layer 710 and the second (higher) computing layer 720, and / or vice versa. The first interface (unit) 715 may also be referred to as the "General Chassis Interface," CCI, because it allows higher computing layers of the computing platform 700, particularly the second computing layer 720, to interface with the first computing layer, which is primarily responsible for controlling typical (i.e., general) chassis functions, as described above.

[0179] Information that can be exchanged across CCI 715, for example according to one or more defined protocols (such as Ethernet), may specifically relate to a defined first data set including one or more parameters indicating the current or past state of one or more of the systems 810 to 835 in the first set, or actions performed by them. Specifically, the first data set may include one or more parameters indicating one or more of the following: steering angle, vehicle speed, vehicle acceleration, vehicle speed level, powertrain state, wheel speed, vehicle tilt angle 1200, and the current or past state of one or more safety-related systems in the first set, or actions performed by them. Therefore, any one or more of these parameters can be used as input data for a second computing layer to support functionality defined by the second computing layer 720 of the computing platform 700 or any higher layer (such as a third computing layer 730).

[0180] In the opposite direction, the second computing layer 720 can be configured to communicate a second data set defined by the first computing layer 710. This second data set includes one or more parameters indicating a desired state or action to be performed by one or more of the systems 810 to 835 in the first group. Specifically, the second data set may include one or more parameters indicating one or more of the following: a desired steering angle, a desired accelerator value, a desired braking value, a desired speed level, and a desired suspension level. In this way, the second computing layer 720 can set, adjust, or at least request specific parameter settings for the systems of the first computing layer 710. It is even possible that the second computing layer 720, or any higher computing layer 730, is configured to receive user input to define such desired parameter settings associated with the desired state or action of the first computing layer 710. For example, the first group can be at least partially selected or adjusted by the user through a user interface belonging to or connected to the second computing layer 720.

[0181] CCI 715 may specifically include cybersecurity features, such as firewall functionality and / or intrusion detection, prevention, and / or impact restriction features, to protect against unauthorized electronic access to the first computing layer 710 via the second computing layer 720. This is particularly important if the second computing layer 720 or any higher computing layer connected to it is designed to communicate with one or more entities outside the vehicle and therefore outside the control of the vehicle manufacturer. For example, these higher computing layers 720 and / or 730 may be designed to communicate with cloud environments (such as servers used to provide navigation information or media content) via the Internet and may therefore be more vulnerable to cyberattacks than the first computing layer 710 itself.

[0182] Now for reference Figure 9When information is exchanged between the first computing layer 710 and the second computing layer 720, there may be a need to synchronize this communication, especially regarding the update or sampling rate of information 705 to be communicated across CCI 715.

[0183] Figure 9 An exemplary scenario 900 is illustrated, where Table 905, from the perspective of the second computation layer 720, shows the corresponding current sampled parameter values, previous sampled values, time span since the last update, and sampling rate for the parameter (i.e., for time-discrete sampling) for several different information sources (sensors), as received from the first computation layer 710 via CCI 715. For example, a parameter might be detected by a sensor used to determine the RPM of a vehicle engine, and the current RPM sample is 2465, while the previously detected RPM sample was 2455.

[0184] Table 910 illustrates the same situation from the perspective of the first computation layer 710. While the sampled values ​​are of course the same, the time span since the last update—that is, the last sampling—and even the sampling rate may differ from those of the second computation layer 720, as can be seen by comparing the last two columns of Tables 905 and 910. In this example, the sampling of various parameters in different rows of Table 910 occurs at different points in time, and the sampling rate is not the same for all parameters. Conversely, in Table 905, the values ​​of “last update” and “sampling rate” do not refer to sampling by the sensor itself, but rather to parameter data received from the first computation layer 710 across CCI 715, which is based on a fixed common sampling rate (e.g., 100 Hz) and occurs simultaneously for all parameters.

[0185] Therefore, the first interface CCI 715 can alternatively be configured to synchronize the update rate of the parameter-based information of the transmitting layer (e.g., layer 710) and the information receiving rate of the receiving layer (e.g., layer 720) to exchange information between the first computing layer 710 and the second computing layer 720, and / or vice versa. Synchronization will have the effect that the update rate for sampling sensor values ​​and the update rate for receiving sampled values ​​(or values ​​derived therefrom) received by the receiving layer (as indicated by the exchanged information 705) are at least substantially the same.

[0186] Now for reference Figure 10 An exemplary embodiment of the second computing layer 720 includes a central computing unit (CCU) 105, which has a modular design in which multiple different modules 105a to 105f are combined within a common housing 600, for example, a rack-type housing structure 605 (see [link to documentation]). Figure 6The housing structure 605 and optionally other sections of the CCU 105 form its fixed portion. Conversely, at least one, preferably several, of modules 105a to 105f are releasably and replaceably connected to the housing structure 605, allowing them to be easily removed via releasable mechanical, electrical, and / or optical connectors. This enables hardware-based reconfiguration, repair, or enhancement of the CCU 105 by adding, removing, or replacing one or more modules with respect to the fixed portion. Specifically, one of the modules (e.g., module 105b) may be an energy supply unit for supplying energy to at least one, preferably all, of the other modules 105a and 105c to 105f. The energy supply module 105b may be specifically part of the fixed portion of the CCU 105, but it is also envisioned to be releasably and replaceably connected to the housing, allowing it to be easily removed, replaced, etc.

[0187] The CCU 105 is designed as the central computing entity of the second computing layer 720 of the computing platform 700, and is configured to provide on-demand computing to multiple different other functional units of the vehicle 1200 based on the flexible software-defined resource and process management and / or control functions of the CCU 105. Specifically, the CCU 105 may be designed to communicate with such other functional units via one or more, preferably standardized, high-speed communication links 1020 (such as one or more high-speed bus systems or several individual communication links, such as Ethernet links, for example, for data rates of 10 Mbit / s or higher). Furthermore, the CCU 105 may include a multi-core operating system comprising a main core and multiple other cores, wherein the main core is configured to simultaneously control at least two of the multiple other cores, which run concurrently.

[0188] Another module in the module (e.g., module 105a) may include a general-purpose computing device, such as one or more general-purpose microprocessors. In particular, module 105a may be used as the main computing resource of CCU 105, and is configured to distribute computing needs among multiple computing resources of CCU 105 (including computing resources of other modules in the module of CCU).

[0189] For example, module 105c may include dedicated computing devices, such as a graphics processing unit (GPU) and / or a dedicated processor for running artificial intelligence-based algorithms (e.g., algorithms that implement one or more artificial neural networks). Furthermore, modules 105d, 105e, and 105f may include other general-purpose or dedicated computing resources / devices and / or memory.

[0190] Module 105d may include a security controller for protecting data and / or programs within CCU 105 and restricting access thereto, and module 105e may include one or more interface controllers or communication devices for connecting CCU 105 to one or more communication links with other devices outside CCU, such as actuators 1010, sensors 1015, or cluster hubs 1010 (hubs), for aggregating / routing or separating signals from / to several actuators 1010 and / or sensors 1015 to form a cluster centered on the hub, each cluster including several actuators 1010 and / or sensors 1015.

[0191] When using this cluster / hub concept, it can be implemented specifically based on a tree topology, where various actuators 1010 and / or sensors 1015 are connected via associated connections 1025 to one or more hubs or multiple cascaded hubs to the CCU, for example, to its module 105e. The hub 1010 (which may be referred to, for example, as a “zone electrical controller” (ZeC)) can specifically have the function of aggregating signals from different sources (such as actuators 1010 and / or sensors 1015), and can thus also be configured to act as a gateway between different communication protocols (such as CACN, LIN, and Ethernet). Therefore, significant wiring can be saved, and a central computing mechanism can be used to provide processing capabilities for handling signals from / to the actuators 1010 and / or sensors 1015, particularly for controlling one or more functions of the vehicle 1200 based on these signals. However, a hubless or hybrid topology is also possible, in which some or all of the actuators 1010 and / or sensors 1015 are directly connected to the CCU 105 without any intermediate hubs 1010.

[0192] Module 105f may include, for example, a communication interface for implementing interface functions to the third computing layer 730. In fact, module 105f itself may also include one or more computing units of the third computing layer 730, such that the second computing layer 720 and the third computing layer 730, although defined as separate computing layers with a single function and structure, are physically aggregated in the same physical device, i.e., in the housing 600 of CCU 105.

[0193] One of the modules may further include or be configured to link to (i) a first interface unit 715 for connecting the second computing layer 720 to the first computing layer 710 and (ii) a second interface unit 725 for connecting the second computing layer 720 to the third computing layer 730 in a controlled manner (e.g., according to one or more defined protocols) and exchanging information 735 therewith.

[0194] Figure 11An exemplary embodiment of the third computing layer 730 of the computing platform 700 is schematically illustrated. The computing layer 730 may be specifically configured to support highly automated or even autonomous driving, that is, to replace one or more or even all driver actions through automation.

[0195] For this purpose, the third computing layer 730 may include a set of dedicated sensors 1110 for identifying features of the vehicle 1200’s environment, such as lanes, traffic lights and signs, other vehicles, pedestrians, obstacles such as construction sites, etc. For example, the set of sensors 1110 may include one or more video cameras, lidar or radar sensors, or other sensors, such as microphones or accelerometers or gyroscopes, configured to detect one or more features of the vehicle 1200’s environment or aspects of its motion.

[0196] The third computing layer 730 further includes at least one computing unit 1105, which is connected to the CCU 105 of the second computing layer 720 via the second interface unit 725, and indirectly connected to the first computing layer 710 via the CCU 105 and the first interface unit 715 to exchange signals and / or data with it. The second interface unit 725 may be specifically referred to as a “universal user space interface” (CUI) because it may be specifically used to communicate vehicle function calls initiated by the third computing layer 730 to one of the lower computing layers 720 and 710 to request the execution of such vehicle functions, such as acceleration or braking, similar to what a human driver would do.

[0197] vehicle Figure 12A The diagram illustrates the following: Figures 7 to 11 An exemplary vehicle 1200 of the computing platform 700. However, to reduce complexity, only some components of the second computing layer 720 are illustrated, while the components of the corresponding first computing layer 710 and third computing layer 730 are not explicitly shown.

[0198] While in principle the Central Computing Unit (CCU) 105 can be located anywhere within the vehicle 1200, there are certain preferred locations, particularly given safety requirements and the need for easy access to facilitate the easy removal and replacement of modules within the CCU 105's housing. Therefore, the CCU 105 can be located in or near the glove box, or in the central control console of the vehicle 1200, i.e., in or near the center of the passenger compartment of the vehicle 1200, ensuring that the CCU 105 is well protected against external mechanical impacts, for example, in the event of a vehicle accident, and is easily accessible.

[0199] Figure 12ASeveral hubs 1005 of the second computing layer and associated communication links 1020 to the CCU 105 are also shown. Each of these hubs 1015 can be connected to multiple actuators 1010 and / or sensors 1015, such as Figure 10 As shown in more detail below.

[0200] Figure 12B Another simplified view of vehicle 1200 is shown, where boxes 1205, 1210, and 1215 identify three distinct exemplary locations within vehicle 1200 that are particularly well-suited for housing CCU 105 within vehicle 1200. Locations 1205 and 1215 are arranged on or near the (virtual) centerline of vehicle 1200, which extends midway along the vehicle's primary extension dimension (y-dimension) between the two sides of vehicle 1200. Location 1205 is situated between the two front seats, for example, in the center console of vehicle 1200, while location 1215 is situated below the rear seats or seat benches of the second or third row. These central locations (at least in the x and y dimensions) are particularly advantageous in terms of safety and protection against damage or destruction in the event of an accident. They are also easily accessible for maintenance, repair, or replacement purposes, particularly when one or more of modules 105a to 105f need to be removed from CCU 105 (particularly from its housing 600).

[0201] Other exemplary locations 1210 are also highly accessible and well protected against collisions from virtually any direction. This location 1210 is also particularly well-suited for establishing wireless communication links with communication nodes outside the vehicle 1200 (such as communication nodes of traffic infrastructure or other vehicles, for example, for vehicle-to-vehicle communication) because, due to its proximity to the windshield, it is generally less affected by the electromagnetic shielding of the vehicle 1200 itself.

[0202] Therefore, CCU 105 can be located in or near the glove box, or in the central control unit of vehicle 1200, that is, in or near the center of the passenger compartment of vehicle 1200, so that CCU 105 is well protected against external mechanical impact, for example, in the event of a vehicle accident, and is easily accessible.

[0203] List of reference numerals First block diagram of 100 CCU and external communication nodes of CCU 105 (especially the second computing layer 720) Central Computing Unit, CCU 105a-f Hardware entity (module), including a replaceable module with a CCU. 110 Computing Module Cluster, Distributed Computing System 115 Main Computing Module 115a First (Main) CE 115a-1 First instance of the first primary CE 115a-2 Second instance of the first master CE 115b Second (Main) CE 115b-1 First instance of the second main CE 115b-2 Second instance of the second main CE 115c Optional one or more other (primary) CEs 115d Resource Coordination Function / System (RCOS) 115e Security Management System (SMS) 115f Central Fault Management System (CFMS) 115g main computing module's (single) fault management system (FMS) 120 General-purpose computing module 120a Module 120 (from) CE 120b Module 120 may contain one or more other (from) CE Module 120c (Single) Fault Management System (FMS) 125 Specialty modules, such as GPUs, AI modules, NPUs, in-memory computing units, or local hub modules. 125a Module 125 (from) CE 125b communication interface, such as optical or wireless interface. Module 125c (Single) Fault Management System (FMS) 130 Connecting devices, especially backplate 135 Service Module 140 endpoint clusters, optical connectivity 145 Endpoint Cluster (Remote), Wireless Connection 150 endpoint clusters, such as area hubs, connected via cables. 150A Wireless Transceiver 155 standalone wireless transceivers 160 Endpoint Cluster (Remote) 200 Second block diagram used to illustrate the functional domain of CCU 201 Redundancy Concept 205 Computational Task Coordination Domain 210 Control and Coordination Domain 215 Architecture Power Coordination Domain 220 power supply domain 225a First Switching Architecture 225a-1 First Instance of the First Switching Architecture 225a-2 Second instance of the first switching architecture 225b Second Switching Architecture 225b-1 First Instance of the Second Switching Architecture 225b-2 Second instance of the second switching architecture 225c Third Switching Architecture 230a,b safety features, CE side 235a,b Safety features, endpoint side 240a,b (Main) Power Source 240c Emergency Power Source 245a,b Current limiters 250a,b First Voltage Generation Unit 255a,b Second Voltage Generation Unit 260a,b controllers, for example, microcontrollers 265a,b Monitoring units, for example, for monitoring current, voltage and / or clock. 270a,b Configuration Switch 300 Classic (Conventional) PCIe Communication Solution 305 First CPU 305a CPU Management Functions 305b CPU 305 processing capabilities 305c CPU, the root complex of 305 310 Second CPU 310a CPU 310 management functions 310b CPU 310 processing capabilities 310c CPU 310 root complex 315 root ports of the 305C composite Root ports of 320-root composite 310c 325 PCIe Switch 330 PCIe endpoints 335 CPU Inter-CPU Communication Link 400-compatible PCIe communication solution 405a Main CE 115a Management Functions 405b Main CE 115a Processing Functions 405c main CE 115a root complex Root port of 405d root complex 405c 410a Management functions from CE 120a 410b Processing functions from CE 120a 410c from the root complex of CE 120a Root port of 410d root complex 410c 415a,b PCIe switches as switching architecture 420a,b Non-transparent PCIe bridge (NTB), CE side 425a,b Non-transparent PCIe bridge (NTB), end-side 430 (communication) endpoint 435 First Communication Path 440 Second Communication Path 445 Third Communication Path Third block diagram of 500 CCUs and endpoint clusters 505 bridges, such as PCIe / Ethernet bridges 510 switches, for example, Ethernet switches 515 Endpoint Cluster 600 housing 605 Shell Structure 610 connector 700 Computing Platform 705 Information exchanged between layers 710 and 720, such as the first data group. 710 First Computational Layer 715 First Interface (Unit), CCI 720 Second Computational Layer 725 Second Interface (Unit), CUI 730 Third Computational Layer 735 Information exchanged between layers 720 and 730, such as the second data group. 805 The communication network of the first computing layer 710, for example, a bus 810-835 Electronic systems at the first computing layer, such as ECUs. 900 Synchronous Scenes 905 Parameter table for the second computing layer 720 910 Parameter table for the first computing layer 710 1005 (Cluster) Hub 1010 (multiple) actuators 1015 (multiple) sensors 1020 (high-speed) communication link 1025 signal connection 1105 Computational unit 730 of the third computing layer 1110 Electronic system of the third computing layer 730 1115 Communication path in the third computing layer 730 1200 vehicles, especially cars, such as EVs 1205 First exemplary location for CCU 1210 Second exemplary location for CCU 1215 Third exemplary location for CCU A. Alarm message C Control Information D data I Power Management Information P (electrical) power.

Claims

1. A multi-layer computing platform (700) for a vehicle (1200), the computing platform (700) comprising: A first computing layer (710) includes a plurality of electronic control units (ECUs), each ECU including an embedded system for selectively controlling one or more associated systems in a first set of electronic systems (810,...,835) of the vehicle (1200); as well as A second computing layer (720) includes a central computing unit (CCU) (105) which serves as a shared computing resource for a group of different computer programs for selectively controlling a second group of electronic systems (1005, 1010, 1015) of the vehicle (1200) that are different from the first group, such that each system in the second group is configured to be controlled by one or more programs in a strictly assigned subgroup of the group of computer programs, wherein the different subgroups of the group refer to different systems in the second group of systems; The first set of systems includes electronic systems for controlling one or more of the acceleration, deceleration, and steering of the vehicle (1200); and The second set of systems includes electronic systems (1005, 1010, 1015) for controlling one or more further functions of the vehicle (1200).

2. The computing platform (700) according to claim 1, further comprising a first interface (715) between the first computing layer (710) and the second computing layer (720) for exchanging information (705) between them according to one or more defined protocols.

3. The computing platform (700) according to claim 2, wherein, The first interface (715) includes at least one security function to protect the first computing layer (710) from unauthorized access by or through another layer of the computing platform (700).

4. The computing platform (700) according to claim 2 or 3, wherein, The first computing layer (710) is configured to communicate a first data set defined by the second computing layer (720), the first data set including one or more parameters indicating the current or past state of one or more systems in the first set or actions performed by them.

5. The computing platform (700) according to claim 4, wherein, The first data set includes one or more parameters indicating one or more of the following: steering angle, vehicle (1200) speed, vehicle (1200) acceleration, vehicle (1200) speed level, powertrain status, wheel speed, vehicle (1200) tilt angle, current or past status of one or more safety-related systems in the first set, or actions performed by them.

6. The computing platform (700) according to any one of claims 2 to 5, wherein, The second computing layer (720) is configured to communicate a second data set defined by the first computing layer (710), the second data set including one or more parameters indicating the desired state or action to be performed by one or more systems in the first set.

7. The computing platform (700) according to claim 6, wherein, The second data set includes one or more parameters indicating one or more of the following: desired steering angle, desired accelerator value, desired braking value, desired speed level, and desired suspension level.

8. The computing platform (700) according to claim 6 or 7, wherein, At least one of the parameters indicating the desired state or action to be performed by one or more systems in the first group can be selected or adjusted by the user through a user interface.

9. The computing platform (700) according to any one of claims 2 to 8, wherein, The first interface (715) is configured to synchronize the update rate of the parameter group-based information (705) of the transmission layer and the information reception rate of the reception layer for exchanging information (705) between the first computing layer (710) and the second computing layer (720), and / or vice versa.

10. The computing platform (700) according to any one of the preceding claims, wherein, The second computing layer (720) includes one or more cluster hubs (1005), each cluster hub (1005) being configured to connect one or more sensors (1015) and / or actuators (1010) of the vehicle (1200) to the CCU (105) in a cluster communication manner.

11. The computing platform (700) according to claim 10, wherein, At least one of the cluster hubs (1005) is configured to perform one or more of the following functions related to the cluster connected to the CCU (105): reporting one or more capabilities of the cluster to the CCU (105); aggregating signals from different sensors (1015) or actuators (1010) of the cluster, acting as a communication gateway between the CCU (105) and the cluster; managing message passing between the CCU (105) and the cluster; preprocessing information provided by the sensors (1015) or actuators (1010) of the cluster; postprocessing information to be communicated to the sensors (1015) or actuators (415) of the cluster; and providing power to at least one actuator (1010) and / or sensor (1015) of the cluster.

12. The computing platform (700) according to any one of the preceding claims further includes a third computing layer (730), the third computing layer including one or more dedicated computing units (1105) for controlling one or more electronic systems (1110) in a third set of electronic systems of the vehicle (1200) that are different from the first set and the second set of systems.

13. The computing platform (700) according to claim 12, further comprising a second interface (725) between the second computing layer (720) and the third computing layer (730) for exchanging information (735) between them according to one or more defined protocols.

14. The computing platform (700) according to claim 13, wherein, The third computing layer (730) is configured to request or trigger the functions of the second computing layer (720) by communicating corresponding request or trigger information via the second interface (725).

15. The computing platform (700) according to any one of claims 12 to 14, wherein, At least one computing unit of the third computing layer (730) is configured to be directly connected to one or more sensors (1015) or actuators (1010) associated with the third computing layer (730) via one or more high-speed communication paths (1115).

16. The computing platform (700) according to any one of the preceding claims, wherein, The CCU (105) includes multiple modules and a connection device (130) for communicatively interconnecting the modules, wherein the modules can be releasably connected to the connection device (130) to allow removal, addition and / or replacement of each module.

17. The computing platform (700) according to claim 16 in conjunction with any one of claims 12 to 15, wherein, One module of the CCU (105) includes one or more computing units of the third computing layer (730).

18. The computing platform (700) according to any one of the preceding claims, wherein, The first set of systems includes one or more electronic systems (810,...,835) for realizing one or more of the following basic functions of the vehicle (1200): transmission, suspension, shock absorption, engine control, and energy supply.

19. The computing platform (700) according to any one of the preceding claims, wherein, The first set of systems includes one or more electronic systems (810,...,835) for implementing one or more of the following safety functions of the vehicle (1200): collision detection, functions for responding to a detected collision, one or more airbags, anti-lock braking, and electronic stability control.

20. The computing platform (700) according to any one of the preceding claims, wherein, The second group of systems specifically includes one or more electronic systems for implementing one or more of the following functions of the vehicle (1200): infotainment, navigation, driver assistance, lighting, vehicle interior lighting, servo assistance for steering or braking, user interface, locking system, communication, configurable vehicle (10) interior, mirror, and over-the-air download updates of computer programs or data for one or more electronic systems of the vehicle (10).

21. The computing platform (700) according to any one of the preceding claims, wherein, The third group of systems (1110) specifically includes one or more electronic systems for realizing one or more of the following functions of the vehicle (1200): highly automated or autonomous driving of the vehicle (1200), artificial intelligence-based functions.

22. The computing platform (700) according to any one of the preceding claims, wherein, The CCU is configured as an onboard computing unit for a vehicle (1200), such as an automobile, to centrally control different functions of the vehicle (1200), and the CCU (105) includes: A distributed computing system DCS (110) includes multiple co-located, autonomous computing entities CE (115a, 115b, 115c, 120a, 120b), each of which has its own single memory, wherein the CE (115a, 115b, 115c, 120a, 120b) are configured to communicate with each other via message passing through one or more communication networks to coordinate the allocation of computing tasks to be executed by the DCS (110) as a whole; A communication switch comprising multiple independent switching architectures (225a, 225b, 225c), each switching architecture being configured to variably connect a subgroup of CEs (115a, 115b, 115c, 120a, 120b) of the DCS (110) or each CE to one or more of a plurality of interfaces (125b) for exchanging information via them with external communication nodes (140, 145, 150, 160) of the CCU of the vehicle (1200); and A power supply system comprising a plurality of power supply subsystems for simultaneous operation, each power supply subsystem being capable of individually and independently powering at least two of the DCS (110) and the switching architectures (225a, 225b, 225c).

23. A vehicle (1200) comprising a computing platform (700) according to any one of the preceding claims.

Images