Patent Application
20190273649
Some mission critical systems include redundancies to prevent complete system failure when a critical component fails. For example, in an autonomously driven vehicle, a system failure could be fatal. Hence, the system should be designed such that there are sufficient redundancies built into the system to prevent a failure. The automotive industry is exploring the path towards autonomous driving. The realization of such driving functionality will constitute a paradigm shift in the reliability requirements for the communication inside a vehicle.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
In one embodiment, a device for proactively providing fault tolerance to a vehicle network is disclosed. The device includes a first interface to collect performance data from a plurality of network components of the vehicle network and a second interface to send reconfiguration instructions to the plurality of network components. The device may also include a database for storing the collected performance data, a processor to calculate a probability of failure of a network component in the plurality of network components based on the stored performance data.
In another embodiment, a method for proactively identifying a potential for fault in a network component is disclosed. The method includes collecting performance data from a performance sensor incorporated in the network component, storing collected data in a storage, calculating a probability of a failure of the network component based on the stored performance data and sending reconfiguration instructions to the network component or a network domain that includes the network component to cause a reconfiguration of the network component when the probability of the failure is higher than a preselected value.
In some examples, the device includes an interface to connect to a cloud based processing system and the cloud based processing system is configured to receive performance data from a plurality of external sources relating to network components that are the same or similar to the plurality of network components. The processor is configured to receive the performance data periodically, through the first interface, from network sensors incorporated in the plurality of network components. The processor is configured to calculate a probability of failure based on the stored performance data and externally stored performance data, wherein the externally stored performance data is collected from external sources relating to network components that are similar to the plurality of network components. The processor is configured to send reconfiguration instructions to one or more of the plurality of network components via the second interface.
In some embodiments, the plurality of network components is configured to immediately change configuration settings upon receiving the reconfiguration instructions from the processor. In other embodiments, the plurality of network components is configured to locally store the received reconfiguration instructions from the processor and to make changes to configuration settings when a failure in one of the plurality of network component is imminent.
In some examples, the performance data includes one or more of data bandwidth use, memory buffer utilization, buffer queue delays, switching delays, power consumption, and frame priorities.
In yet another embodiment, a vehicle including the device described above is disclosed. The vehicle includes a plurality of sensors coupled to a plurality of network components, a sensor fusion unit coupled to the plurality of network components and a plurality of performance sensors coupled to the plurality of network components.
So that the manner in which the above recited features of the present invention can be understood in detail, a more particular description of the invention, briefly summarized above, may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments. Advantages of the subject matter claimed will become apparent to those skilled in the art upon reading this description in conjunction with the accompanying drawings, in which like reference numerals have been used to designate like elements, and in which:
Note that figures are not drawn to scale. Intermediate steps between figure transitions have been omitted so as not to obfuscate the disclosure. Those intermediate steps are known to a person skilled in the art.
Many well-known manufacturing steps, components, and connectors have been omitted or not described in details in the description so as not to obfuscate the present disclosure.
It should be noted that even though the embodiments described herein use automotive systems for the ease of description, the techniques described herein may also be applied to any system that includes various components interconnected via a communication network. For example, the embodiments described herein may also be applicable to aircrafts and medical equipment.
Existing Quality-of-Service (QoS) assurance techniques for the in-vehicle network (IVN) are typically static in nature, component-centric, and configured on the vehicle's production line. For better fault tolerance and proactive correction of issues before they arise, there is a need for IVNs to dynamically cope with unforeseen circumstances, including a failure of the communication network itself or an out-of-spec usage due to a failure in another part of the vehicle. The embodiments described herein provide run-time handling of failures, as not all failure circumstances can be foreseen at design time. This heightened reliability requires a dynamic, zero-time adaptability of the IVN, in addition to the existing, pre-configured handling of the mixed-criticality communication from the different in-vehicle applications.
However, having such extensive redundancies may make the overall system costly and may still not be sufficient to cope with unforeseen circumstances because not all circumstances may be known to the designers of the system at design time. An IVN, even with built-in redundancies, may still be missing dynamic adaption to run-time changes in usages or a capability to handle a failure in the network itself. It should be noted that
The vehicle system 100 includes various sensors, e.g., a lidar sensor 112, a camera sensor 114 and a radar sensor 116. Even though only one sensor of each type is shown in
Performance sensors 122, 124, 126, 128 are added to the in-vehicle communication infrastructure to monitor key communication metrics that can be indicative of a potential future communication breakdown. These sensors 122, 124, 126, 128 continuously or periodically monitor the health of the network by collecting performance information. Performance metrics that may be measured include the bandwidth utilization, buffer queue delays, switching delays, power consumption, and frame priorities. The collected information is forwarded to the QoS processor 102.
The network components 110A, 110B, 110C, 108 are also dynamically reconfigurable through reconfiguration commands from the QoS processor 102. In some examples, a network component, e.g., 110A, 110B, 110C, 108 may immediately transition from its current configuration to the new configuration when instructed by the QoS processor 102. In another example, the network component, e.g., 110A, 110B, 110C, 108 may first store the new configuration in a backup configuration registry as a preliminary reconfiguration. When a failure is imminent, the network component can then seamlessly switch to the new configuration. In yet another example, the network component, e.g., 110A, 110B, 110C, 108 may migrate from its old configuration to its new configuration over a preselected period of time, depending on its functionality and its state at the moment of receiving a reconfiguration command.
A typical network component, e.g., 110A, 110B, 110C, 108 may include a status information interface, a configuration command interface and an associated network interface to couple to the QoS processor 102. The status information interface may be a physical interface coupled with a preselected communication protocol to provide the QoS processor 102 with preselected type of information. The QoS processor 102 may use this information to learn the historical characteristics of an information sending network component based on the information supplied through this interface. The QoS processor 102 may send reconfiguration commands to the network component based on historical summaries and a probability of failure. The configuration command interface along with a preselected protocol may be provided to enable the network component to accept reconfiguration commands from the QoS processor 102 so that the network component can update its settings, update its firmware or make necessary changes in transmitting sensor data to the sensor fusion based on the command received from the QoS processor 102.
A sensor fusion 106 is includes to combine sensory data from various sensors 112, 114, 116 such that the resulting information is less uncertain than would be possible than these data from these sensors were used individually. The data sources for a fusion process are not specified to originate from identical sensors. One can distinguish direct fusion, indirect fusion and fusion of the outputs of the former two. Direct fusion is the fusion of sensor data from a set of heterogeneous or homogeneous sensors, soft sensors, and history values of sensor data, while indirect fusion uses information sources like a priori knowledge about the environment and human input. The sensor fusion 106 includes processor to perform calculations on the data collected from various sensors.
For example, let x1 and x2 denote two sensor measurements with noise variances a12 and a22, respectively. One way of obtaining a combined measurement x3 is to apply the Central Limit Theorem (CLT), which is also employed within the Fraser-Potter fixed-interval smoother, namely:
x3=a32(a12 x1+a1−2 x2) where a32=a1−2+a1−2 is the variance of the combined estimate. The fused result is a linear combination of the two measurements weighted by their respective noise variances.
In probability theory, the central limit theorem (CLT) establishes that, in most situations, when independent random variables are added, their properly normalized sum tends toward a normal distribution (informally a “bell curve”) even if the original variables themselves are not normally distributed. The theorem is a key concept in probability theory because it implies that probabilistic and statistical methods that work for normal distributions can be applicable to many problems involving other types of distributions.
In some examples, other methods such as Kalman filter method, may be used for fusing the sensor data. An extensive discussion thereof is being omitted so as not to obscure the present disclosure. Note that similar statistical method may also be used by the QoS processor 102 to preprocess collected performance data and to calculate deviations over time to derive a probability of a failure.
The QoS processor 102 includes a processor 118 and a local database 120. Optionally the QoS processor may be coupled to an external network 150. If the QoS processor 102 is coupled to the external network 150, the QoS processor 102 may send and receive historical or preprocessed performance data in a database in the cloud. The QoS processor 102 may also use computational processing power at one or more computers in the cloud network coupled to the network 150. Among others, the advantage of using a cloud based central system for storing and processing raw or summarized performance data relating to sensors such that the lidar 112, the camera 114, the radar 116, the powertrain performance sensor 128 is that data from other vehicles for the same or similar sensors may be collected and a better decision may be made as to a potential of failure of a particular component proactively. For example, if more than an insignificant number of components coupled to a particular sensor has started to fail in other vehicles that are coupled to the network 150, the QoS processor 102 may take corrective actions prior to any potential failure of the same or similar component in the present vehicle. In some cases, if the operation of the particular component is not critical, at the very least, a warning signal me be provided to a user of the vehicle.
The local database 120 is used for storing data collected from performance sensors 122, 124, 126, 128. The data may be processed by the processor 118 prior to storing in the local database 120. The stored data may then be used for predicting a potential failure of a network component. The processor 118 is configured to receive the performance data from performance sensors and sending reconfiguration instructions to network components, e.g., 108, 110A, 110B, 110C based on a calculated probability of failure calculated by the processor 118 using the historical data stored in the local database 120 and/or in a cloud storage coupled to the network 150.
In some examples, the network components, e.g., 110A, 110B, 110C, 108 may periodically send performance and health information to the QoS processor 102 and the QoS processor 102 may periodically send system health information back to the network components. Communication watchdogs may additionally be used to detect a disruption in this two way communication and may signal failure to the QoS processor 102 or the network components 110A, 110B, 110C, and 108.
For easy understanding, in one example, the performance sensors 122, 124, 126, monitor the communication from the radar, camera, and lidar sensor groups to the sensor fusion 106, while network performance sensor 128 monitors the communication from the sensor fusion 106 to the powertrain and vehicle dynamics domain 104. Performance sensors monitor the amount of data generated by these sensor groups and the sensor fusion 106, and pass this information to the QoS processor 102. Sensors may also monitor the state of the physical communication medium, i.e., the wiring harness.
In case of the occurrence of an unforeseen event, such as a cable break or an error in a sensor that turns it into a babbling idiot (e.g., producing large amount of undecipherable data), the QoS processor 102 can isolate the faulty sensor group by reconfiguring the corresponding network component to apply more strictly policing the information stream from that sensor group, e.g., 110. Depending on the criticality of the individual information streams that run across the IVN, the QoS processor 102 may also dynamically change the priority of some data streams over another.
Another application scenario example is the prediction and prevention of a buffer overflow scenario. The buffer utilization value (associated counters and raising the counter value) is monitored by the performance sensors. Derivative changes to buffer utilization value over time period may also be monitored and delta change is recorded in the counter value over the defined time interval.
In some examples, the configuration (e.g., network adaptation) can be split into local action (executed at network switches of the vehicle network) versus global action (at network system level). A local action executed at the switch level can be straightforward actions depending on the counter values. However, a global action required more analysis and actions. For example, the QoS processor 102 may change the QoS level of frames coming from different sensors, depending on the potential value (e.g., redundant information) of the sensor information for a given application and decision context. The QoS level change may be implemented by raising the priority of the frames coming from high resolution sensors over low resolution one. Another level of configuration includes changing the configuration to reduce the data output traffic, enabling for example compressed sensing contrary to regular sensing, by eliminating the redundant information at the sensor level.
The QoS processor 102 may use a history of the metrics collected by the network performance sensors to detect a behavioral change that occurs more gradually over time. Rather than single values, the QoS processor 102 may use derived information, possibly obtained through inference from past behaviors of a single IVN, or from a fleet of IVNs collected through the network 150.
Some or all of these embodiments may be combined, some may be omitted altogether, and additional process steps can be added while still achieving the products described herein. Thus, the subject matter described herein can be embodied in many different variations, and all such variations are contemplated to be within the scope of what is claimed.
While one or more implementations have been described by way of example and in terms of the specific embodiments, it is to be understood that one or more implementations are not limited to the disclosed embodiments. To the contrary, it is intended to cover various modifications and similar arrangements as would be apparent to those skilled in the art. Therefore, the scope of the appended claims should be accorded the broadest interpretation so as to encompass all such modifications and similar arrangements.
The use of the terms “a” and “an” and “the” and similar referents in the context of describing the subject matter (particularly in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated into the specification as if it were individually recited herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the scope of protection sought is defined by the claims as set forth hereinafter together with any equivalents thereof entitled to. The use of any and all examples, or exemplary language (e.g., “such as”) provided herein, is intended merely to better illustrate the subject matter and does not pose a limitation on the scope of the subject matter unless otherwise claimed. The use of the term “based on” and other like phrases indicating a condition for bringing about a result, both in the claims and in the written description, is not intended to foreclose any other conditions that bring about that result. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention as claimed.
Preferred embodiments are described herein, including the best mode known to the inventor for carrying out the claimed subject matter. Of course, variations of those preferred embodiments will become apparent to those of ordinary skill in the art upon reading the foregoing description. The inventor expects skilled artisans to employ such variations as appropriate, and the inventor intends for the claimed subject matter to be practiced otherwise than as specifically described herein. Accordingly, this claimed subject matter includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed unless otherwise indicated herein or otherwise clearly contradicted by context.
