Architecture for automation and fail operational automation

#Embodiments described herein are related to vehicle automation.

#Advances in vehicle automation are proceeding at a rapid pace as more companies become involved in development of automation solutions. Generally, vehicle automation can require highly accurate sensing of the environment in which the vehicle is operating (e.g. the road course, other vehicles, stationary objects, obstructions in the roadway, etc.). The control mechanisms for the vehicle are also required to be highly accurate and resistant to failure when components within the vehicle fail, retaining control of the vehicle and continuing safe operation or bringing the vehicle safely to a stop. These challenges also need to be addressed with an economical and efficient system that can be mass-produced.

#In an embodiment, an automation system for a vehicle may employ a variety of diversities to enhance reliability, accuracy, and stability in automating operation of the vehicle. For example, in an embodiment, an automation system for a vehicle may include multiple sensor pods with overlapping fields of view. Each sensor pod may include multiple different sensors in an embodiment, providing diverse views of the environment surrounding the vehicle. The overlapping fields of view may help in the event of a failure of a sensor pod, since the area monitored by the failed sensor pod is at least partially covered by a still-functioning sensor pod. The overlapping fields of view may also provide multiple views of an object in the environment, which may permit validation of various sensor pods and/or the discard of data from a sensor pod that does not agree with the others, in an embodiment. A set of sensor pods with overlapping fields of view may also transmit their object data at different points in time, providing diversity in time. Redundancy in other areas, such as the network switches which connect the sensor pods to an automation controller, may also aid in provided fail operational functionality. In some embodiments, multiple sensor processing algorithms may be used to provide diversity in the algorithmic sense as well.

#The following detailed description makes reference to the accompanying drawings, which are now briefly described.

#FIG. 1 is a block diagram of one embodiment of a vehicle with one embodiment of an automation system.

#FIG. 2 is a block diagram of another embodiment of a vehicle with another embodiment of an automation system.

#While embodiments described in this disclosure may be susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit to the scope of the description. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include”, “including”, and “includes” mean including, but not limited to. As used herein, the terms “first,” “second,” etc. are used as labels for nouns that they precede, and do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) unless specifically stated.

#Within this disclosure, different entities (which may variously be referred to as “units,” “circuits,” other components, etc.) may be described or claimed as “configured” to perform one or more tasks or operations. This formulation—[entity] configured to [perform one or more tasks]—is used herein to refer to structure (i.e., something physical, such as an electronic circuit). More specifically, this formulation is used to indicate that this structure is arranged to perform the one or more tasks during operation. A structure can be said to be “configured to” perform some task even if the structure is not currently being operated. A “clock circuit configured to generate an output clock signal” is intended to cover, for example, a circuit that performs this function during operation, even if the circuit in question is not currently being used (e.g., power is not connected to it). Thus, an entity described or recited as “configured to” perform some task refers to something physical, such as a device, circuit, memory storing program instructions executable to implement the task, etc. This phrase is not used herein to refer to something intangible. In general, the circuitry that forms the structure corresponding to “configured to” may include hardware circuits. The hardware circuits may include any combination of combinatorial logic circuitry, clocked storage devices such as flops, registers, latches, etc., finite state machines, memory such as static random access memory or embedded dynamic random access memory, custom designed circuitry, analog circuitry, programmable logic arrays, etc. Similarly, various units/circuits/components may be described as performing a task or tasks, for convenience in the description. Such descriptions should be interpreted as including the phrase “configured to.”

#The term “configured to” is not intended to mean “configurable to.” An unprogrammed FPGA, for example, would not be considered to be “configured to” perform some specific function, although it may be “configurable to” perform that function. After appropriate programming, the FPGA may then be configured to perform that function.