Patent Description:
<CIT> discloses a system for performing multi-level video processing within a vehicle including a pre-processing module for determining an encoding mode and enabling one or more levels of encoding based on the encoding mode. The pre-processing module further receives a video stream from a camera attached to the vehicle via a vehicular communication network and encodes the video stream based on the encoding mode to produce a packet stream output. The system further includes a video decoder for receiving the packet stream output and decoding the packet stream output in accordance with the encoding mode to produce a decoded video output.

<CIT>discloses a multichip radar system, comprising a plurality of configurable ICs, and a digital interface therebetween, each configurable IC being configurable to operate as a master IC and as a slave IC. The configurable ICs may be similar or identical, and have an allocated measurement range. Each configurable IC comprises: a down-converter; an ADC; a digital signal processor; and a transmitter to transmit a radar signal. One is configured as a master IC and to transmit a radar signal and each of the other configurable ICs to operate as a slave IC. Each configurable IC is adapted to use a common Local Oscillator signal, a common clock signal, and a common timing signal for determining at least the start of the common sampling window. A method of operating such a multichip radar system is also disclosed, as is a configurable IC or radar IC suitable for such a system.

Automotive Safety Integrity Level (ASIL) is a risk classification scheme defined by the ISO <NUM> - Functional Safety for Road Vehicles standard. This is an adaptation of the Safety Integrity Level used in IEC <NUM> for the automotive industry. This classification helps defining the safety requirements necessary to be in line with the ISO <NUM> standard. The ASIL is established by performing a risk analysis of a potential hazard by looking at the Severity, Exposure and Controllability of the vehicle operating scenario. The safety goal for that hazard in turn carries the ASIL requirements. There are four ASILs identified by the standard: ASIL A, ASIL B, ASIL C, ASIL D. ASIL D dictates the highest integrity requirements on the product and ASIL A the lowest.

In recent years, technology companies have begun developing and implementing technologies that assist drivers in avoiding accidents and enabling an automobile to drive itself. So called "self-driving cars" include sophisticated sensor and processing systems that control the vehicle based on information collected from the car's sensors, processors, and other electronics, in combination with information (e.g., maps, traffic reports, etc.) received from external networks (e.g., the "Cloud"). As self-driving and driver-assisting technologies grow in popularity and use, so will the importance of protecting motor vehicles from malfunction. Due to these emerging trends, new and improved solutions that better identify, prevent and respond to misinformation on modern vehicles, such as autonomous vehicles and self-driving cars, will be beneficial to consumers.

For example, camera, radar, and LIDAR sensors may be located around a car to observe the environment. These sensors are all combined via "sensor fusion" to produce the tactical aspects of self-driving, such as increase speed, lane change, break, etc. ASIL-D can be achieved with redundancy of multiple SoCs. The sensors will be fed to multiple SoCs in this model to achieve ASIL-D.

In an Autonomous Vehicle System, a camera sensor may feed multiple SoCs for redundancy processing. Camera control requires a feedback loop of a host SoC updating the camera configuration for future frames based on analysis of the current frame. When the sensor feeds two SoCs, the two SoCs may send differing sensor configuration parameters or updates to the sensor. This may create a malfunction or confusion to the receiving SoCs. From an automotive safety perspective, a common safety feature is to check to see that for a given received image frame, the camera sensor settings applied on the captured frame match those issued by the host SoC. For example, a feedback loop from a SoC to a camera sensor may include auto white balance and auto exposure settings configured in camera sensor registers based on previous camera video stream data. Other configuration information may be updated as well (i.e., HDR mode vs. linear mode). Along with pixel data from camera sensors, embedded data containing information about the configuration settings applied to the sensor to capture the pixel data in the frame is sent across the link from the camera sensor to the SoC. A safety challenge is encountered wherein the system is unable to determine which SoC settings are to be applied to control the feedback loop and which SoC settings to perform safety check validation upon. If different SoCs, or the same SoCs with different algorithms, control the feedback loop, conventional systems are unable to determine which SoC controls the settings to the sensor on the feedback loop or how to communicate this to the sensor.

Accordingly, there is a need for systems, apparatus, and methods that overcome the deficiencies of conventional approaches including the methods, system and apparatus provided hereby.

The following presents a simplified summary relating to one or more aspects and/or examples associated with the apparatus and methods disclosed herein.

In accordance with the present invention, a method and a device as set forth in the independent claims is provided.

In one aspect of the invention, a sensor control apparatus comprises: a first System on Chip (SoC) configured to generate a first sensor configuration value for a sensor parameter; a second SoC configured to generate a second sensor configuration value for the sensor parameter; a sensor communicatively coupled to the first SoC and the second SoC; and a control logic circuit communicatively coupled to the first SoC, the second SoC, and the sensor, wherein the control logic circuit is configured to select between the first SoC and the second SoC as a host SoC and to apply to the sensor one of the first configuration value or the second configuration value for the sensor parameter based on the selected host SoC; and a monitor communicatively coupled to the control logic circuit, the sensor, the first SoC, and the second SoC, wherein the monitor is configured to: record a number of register updates from the selected host SoC in a predefined window; determine if the number of register updates in the predefined window exceeds a threshold; deselect the selected host SoC when the number of register updates in the predefined window does not exceed the threshold; and broadcast a release signal to the control logic circuit, the first SoC , and the second SoC when the selected host SoC is deselected.

In another aspect of the invention, a method for controlling a sensor comprises: generating a first sensor configuration value for a sensor parameter by a first System on Chip (SoC) communicatively coupled to a sensor and a control logic circuit; generating a second sensor configuration value for the sensor parameter by a second SoC communicatively coupled to the sensor and the control logic circuit; selecting between the first SoC and the second SoC as a host SoC; and applying one of the first configuration value or the second configuration value for the sensor parameter based on the selected host SoC to the sensor, recording, by a monitor communicatively coupled to the control logic circuit, the sensor, the first SoC, and the second SoC, a number of register updates received from the selected host SoC in a predefined window; determining, by the monitor, if the number of register updates in the predefined window exceeds a threshold; deselecting, by the monitor, the selected host SoC when the number of register updates in the predefined window does not exceed the threshold; and broadcasting, by the monitor, a release signal to the control logic circuit, the first SoC, and the second SoC when the selected host SoC is deselected.

In still another aspect of the invention, a non-transitory computer-readable medium comprising instructions that when executed by a processor cause the processor to perform a method as defined above, when running on a sensor control apparatus as defined above.

A more complete appreciation of aspects of the disclosure and many of the attendant advantages thereof will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings which are presented solely for illustration and not limitation of the disclosure, and in which:.

In accordance with common practice, the features depicted by the drawings may not be drawn to scale. Accordingly, the dimensions of the depicted features may be arbitrarily expanded or reduced for clarity. In accordance with common practice, some of the drawings are simplified for clarity. Thus, the drawings may not depict all components of a particular apparatus or method. Further, like reference numerals denote like features throughout the specification and figures.

The exemplary methods, apparatus, and systems disclosed herein mitigate shortcomings of the conventional methods, apparatus, and systems, as well as other previously unidentified needs. For example, a sensor control apparatus may include a sensor control logic that selects a host System on Chip from among a plurality of System on Chips to provide input, such as parameters, for the sensor while preventing the sensor from applying input from non-selected System on Chips to avoid a sensor from receiving conflicting input that may affect the sensor operation. The sensor control apparatus may provide a method to allow a single sensor to broadcast what SoC has control of the sensor without additional inter-SoC bus(es) for communication, enable another SoC to take control of the sensor when the owning SoC intentionally or unintentionally relinquishes control, and provide additional system level functional safety checks in an autonomous vehicle environment.

In overview, the various examples disclosed herein include methods, as well as computing systems configured to execute the methods, for monitoring and analysis of sensor information in a vehicle to efficiently identify, prevent, correct, or otherwise respond to various abnormal conditions and behaviors in/of the vehicle, such as sensor malfunctions. A computing system may be configured to monitor a sensor in or near the vehicle to collect the sensor information, analyze the collected sensor information to generate an analysis result, and determine whether a behavior of the sensor or computing system is abnormal based on the generated analysis result.

The computing system may be, or may be implemented in, a mobile computing device, the vehicle's control systems, or a combination thereof. The monitored sensors may include any combination of closely-integrated vehicle sensors (e.g., camera sensor, radar sensor, LIDAR sensor, etc.). The term sensor may include a sensor interface (such as a serializer or deserializer), a camera sensor, a radar sensor, a LIDAR sensor or similar sensor.

The term "system on chip" (SoC) is used herein to refer to a single integrated circuit (IC) chip that contains multiple resources and/or processors integrated on a single substrate. A single SoC may contain circuitry for digital, analog, mixed-signal, and radio-frequency functions. A single SoC may also include any number of general purpose and/or specialized processors (digital signal processors, modem processors, video processors, etc.), memory blocks (e.g., ROM, RAM, Flash, etc.), and resources (e.g., timers, voltage regulators, oscillators, etc.). SoCs may also include software for controlling the integrated resources and processors, as well as for controlling peripheral devices.

Over the past several years, the modern automobile has been transformed from a self-propelled mechanical vehicle into a powerful and complex electro-mechanical system that includes a large number of sensors, processors, and SoCs that control many of the vehicle's functions, features, and operations. Modern vehicles now also are equipped with a vehicle control system, which may be configured to collect and use information from the vehicle's various systems and sensors to automate all or a portion of the vehicle's operations.

For example, manufacturers now equip their automobiles with an Advanced Driver Assistance System (ADAS) that automates, adapts, or enhances the vehicle's operations. The ADAS may use information collected from the automobile's sensors (e.g., accelerometer, radar, LIDAR, geospatial positioning, etc.) to automatically detect a potential road hazard, and assume control over all or a portion of the vehicle's operations (e.g., braking, steering, etc.) to avoid detected hazards. Features and functions commonly associated with an ADAS include adaptive cruise control, automated lane detection, lane departure warning, automated steering, automated braking, and automated accident avoidance.

In various implementations, a processor in the computing system may be coupled to all (or many) of the vehicle's sensors and systems via wired and/or wireless links, including the mobile devices of its passengers. The processor may collect information from a large number of diverse and disparate sensors/systems, and use a combination of the collected information to determine whether there are abnormalities in sensor outputs, system outputs, system operations, etc..

<FIG> illustrates a sensor control apparatus in accordance with some examples of the disclosure. As shown in <FIG>, a sensor control apparatus <NUM> may include a sensor <NUM> (e.g., a camera, a radar, a LIDAR, etc.), a control logic circuit <NUM> communicatively coupled to the sensor <NUM>, a first System on Chip (SoC) <NUM> communicatively coupled to the sensor <NUM> and the control logic circuit <NUM>, a second SoC <NUM> communicatively coupled to the sensor <NUM> and the control logic circuit <NUM>. The first SoC <NUM> may be configured to generate a first sensor parameter, such as analog gain, digital gain, black level, polarized white light setting, general status, and debug status. The second SoC <NUM> may be configured to generate a second sensor parameter, such as analog gain, digital gain, black level, polarized white light setting, general status, and debug status. These sensor parameters may be used to control operation of the sensor <NUM>. The control logic circuit <NUM> may be configured to select between the first SoC <NUM> and the second SoC <NUM> as a host SoC. The control logic circuit <NUM> may be configured to transmit parameters generated by the selected host SoC to the camera, such as the first sensor parameters or the second sensor parameters. The host SoC's generated parameters may be used to control operation of the sensor <NUM> by using the parameters generated by the host SoC instead of parameters generated by a non-selected SoC. While one sensor and two SoCs are illustrated in this example, it should be understood that more than one sensor and/or more than two SoCs may be included in the sensor control apparatus <NUM>.

The sensor control apparatus <NUM> may include a first serializer <NUM> and a first deserializer <NUM> coupled between the sensor <NUM>, the first SoC <NUM> and the second SoC <NUM>. The first serializer <NUM> and the first deserializer <NUM> may be configured to convert between serial data and parallel interfaces in both directions to provide data transmission over a single or differential line by minimizing the number of I/O pins and connections. The first serializer <NUM> and the first deserializer <NUM> may convert parallel data into serial data (and vice versa) so that they can travel over media that does not support parallel data or used in order to save bandwidth. The first serializer <NUM> and the first deserializer <NUM> may transmit sensor data and embedded data between the sensor <NUM>, the first SoC <NUM> and the second SoC <NUM>. The sensor data may be pixel data from an active frame in the case of a camera and the embedded data may be register settings, statistics, safety data, and Media Access Control data for the sensor <NUM>, the first SoC <NUM>, and the second SoC <NUM>. The sensor control apparatus <NUM> may also include a microcontroller unit <NUM> configured to make second level decisions on automotive safety issues in conformance with ASIL-D.

<FIG> illustrates a sensor control apparatus with two links to a sensor in accordance with some examples of the disclosure. As shown in <FIG>, a sensor control apparatus <NUM> (e.g., sensor control apparatus <NUM>) may include a sensor <NUM> (e.g., a camera, a radar, a LIDAR, etc.), a control logic circuit <NUM> communicatively coupled to the sensor <NUM>, a first System on Chip (SoC) <NUM> communicatively coupled to the sensor <NUM> and the control logic circuit <NUM>, a second SoC <NUM> communicatively coupled to the sensor <NUM> and the control logic circuit <NUM>. The first SoC <NUM> may be configured to generate a first sensor parameter, such as analog gain, digital gain, black level, polarized white light setting, and exposure time. The second SoC <NUM> may be configured to generate a second sensor parameter, such as analog gain, digital gain, black level, polarized white light setting, and exposure time. These sensor parameters may be used to control operation of the sensor <NUM>. The control logic circuit <NUM> may be configured to select between the first SoC <NUM> and the second SoC <NUM> as a host SoC. The control logic circuit <NUM> may be configured to transmit parameters generated by the selected host SoC to the camera, such as the first sensor parameters or the second sensor parameters. The host SoC's generated parameters may be used to control operation of the sensor <NUM> by using the parameters generated by the host SoC instead of parameters generated by a non-selected SoC. While one sensor and two SoCs are illustrated in this example, it should be understood that more than one sensor and/or more than two SoCs may be included in the sensor control apparatus <NUM>.

The sensor control apparatus <NUM> may include a first serializer <NUM> and a first deserializer <NUM> coupled between the sensor <NUM> and the first SoC <NUM>. The sensor control apparatus <NUM> may also include a second serializer <NUM> and a second deserializer <NUM> coupled between the sensor <NUM> and the second SoC <NUM>. The first serializer <NUM> and the first deserializer <NUM> may transmit sensor data and embedded data between the sensor <NUM> and the first SoC <NUM>. The second serializer <NUM> and the second deserializer <NUM> may transmit sensor data and embedded data between the sensor <NUM> and the second SoC <NUM>. This enables communication between the sensor <NUM> and one of the first SoC <NUM> and the second SoC <NUM> in case one of the serializer/deserializer links is disabled. The sensor control apparatus <NUM> may also include a microcontroller unit <NUM> configured to make second level decisions on automotive safety issues in conformance with ASIL-D.

<FIG> illustrates an example SoC <NUM> (e.g., first SoC <NUM>, first SoC <NUM>, second SoC <NUM>, and second SoC <NUM>) architecture that may be used in mobile devices implementing the various examples herein. The SoC <NUM> may include a number of heterogeneous processors, such as a digital signal processor (DSP) <NUM>, a modem processor <NUM>, a graphics processor <NUM>, a mobile display processor (MDP) <NUM>, an applications processor <NUM>, and a resource and power management (RPM) processor <NUM>. The SoC <NUM> may also include one or more coprocessors <NUM> (e.g., vector co-processor) connected to one or more of the heterogeneous processors <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>. Each of the processors <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> may include one or more cores, and an independent/internal clock. Each processor/core may perform operations independent of the other processors/cores. For example, the SoC <NUM> may include a processor that executes a first type of operating system (e.g., FreeBSD, LINUX, OS X, etc.) and a processor that executes a second type of operating system (e.g., Microsoft Windows). In some embodiments, the applications processor <NUM> may be the SoC's <NUM> main processor, central processing unit (CPU), microprocessor unit (MPU), arithmetic logic unit (ALU), etc. The graphics processor <NUM> may be the graphics processing unit (GPU).

The SoC <NUM> may include analog circuitry and custom circuitry <NUM> for managing sensor data, analog-to-digital conversions, wireless data transmissions, and for performing other specialized operations, such as processing encoded audio and video signals for rendering in a web browser. The SoC <NUM> may further include system components and resources <NUM>, such as voltage regulators, oscillators, phase-locked loops, peripheral bridges, data controllers, memory controllers, system controllers, access ports, timers, and other similar components used to support the processors and software clients (e.g., a web browser) running on a computing device. The SoC <NUM> also includes specialized circuitry (CAM) <NUM> that includes, provides, controls and/or manages the operations of one or more cameras (e.g., a primary camera, webcam, 3D camera, etc.), the video display data from camera firmware, image processing, video preprocessing, video front-end (VFE), in-line JPEG, high definition video codec, etc. The CAM <NUM> may be an independent processing unit and/or include an independent or internal clock.

The system components and resources <NUM>, analog and custom circuitry <NUM>, and/or CAM <NUM> may include circuitry to interface with peripheral devices, such as cameras, electronic displays, wireless communication devices, external memory chips, etc. The processors <NUM>, <NUM>, <NUM>, <NUM>, <NUM> may be interconnected to one or more memory elements <NUM>, system components and resources <NUM>, analog and custom circuitry <NUM>, CAM <NUM>, and RPM processor <NUM> via an interconnection/bus module <NUM>, which may include an array of reconfigurable logic gates and/or implement a bus architecture (e.g., CoreConnect, AMBA, etc.). Communications may be provided by advanced interconnects, such as high performance networks-on-chip (NoCs).

The SoC <NUM> may further include an input/output module (not illustrated) for communicating with resources external to the SoC <NUM>, such as a clock <NUM> and a voltage regulator <NUM>. Resources external to the SoC <NUM> (e.g., clock <NUM>, voltage regulator <NUM>) may be shared by two or more of the internal SoC processors/cores (e.g., a DSP <NUM>, a modem processor <NUM>, a graphics processor <NUM>, an applications processor <NUM>, etc.).

In some examples, the SoC <NUM> may be included in a computing device, which may be included in an automobile. The computing device may include communication links for communication with a telephone network, the Internet, and/or a network server. Communication between the computing device and the network server may be achieved through the telephone network, the Internet, private network, or any combination thereof.

The SoC <NUM> may also include additional hardware and/or software components that are suitable for collecting sensor data from sensors, including speakers, user interface elements (e.g., input buttons, touch screen display, etc.), microphone arrays, sensors for monitoring physical conditions (e.g., location, direction, motion, orientation, vibration, pressure, etc.), cameras, compasses, GPS receivers, communications circuitry (e.g., Bluetooth®, WLAN, WiFi, etc.), and other well-known components (e.g., accelerometer, etc.) of modern electronic devices.

<FIG> illustrates a sensor in accordance with some examples of the disclosure. As shown in <FIG>, a sensor <NUM> (e.g., sensor <NUM> and sensor <NUM>) may include an I2C <NUM> that provides a bus for intra-board communication between the sensor <NUM> and a serializer/deserializer (not shown) and SoCs (not shown), an address decoder <NUM> coupled to the I2C <NUM>, a first register <NUM>, a second register <NUM>, a third register <NUM>, a fourth register <NUM>, a fifth register <NUM>, and a sixth register <NUM>. Although six registers are shown in <FIG>, it should be understood that the sensor <NUM> may include more than six registers depending on the number of parameters used by the sensor <NUM> and the number of SoCs providing parameters to the sensor <NUM>. The sensor <NUM> may also include a sensor interface <NUM> that provides a pixel array and a data path for interfacing with sensing elements (not shown) of the sensor <NUM>.

The first register <NUM> may be configured to store a first lock bit <NUM> and a first master ID bit or bits <NUM> that allows the sensor <NUM> to identify, lock, and store parameters from a selected host SoC (not shown). The second register <NUM> may be configured to store a second lock bit <NUM> and a second master ID bit or bits <NUM> that allows the sensor <NUM> to identify, lock, and store parameters from a selected host SoC (not shown). While two such registers <NUM> and <NUM> are shown, it should be understood that more than two such registers may be included in sensor <NUM> depending on the number of SoCs providing parameter inputs to the sensor <NUM>.

The third register <NUM> may be configured to store a sensor parameter, such as analog gain, from each of the SoCs providing input to the sensor <NUM>. The fourth register <NUM> may be configured to store a sensor parameter, such as digital gain, from each of the SoCs providing input to the sensor <NUM>. The fifth register <NUM> may be configured to store a sensor parameter, such as exposure time, from each of the SoCs providing input to the sensor <NUM>. The sixth register <NUM> may be configured to store a sensor parameter, such as a register configuration, from each of the SoCs providing input to the sensor <NUM>. While four such registers are shown, it should be understood that more than four may be included depending on how many parameters are providing input to sensor <NUM> and each such register may be configured to store parameters for the number of SoCs providing input to the sensor <NUM>.

The sensor <NUM> also includes a first AND logic element <NUM> coupled to the first register <NUM>, a second AND logic element <NUM> coupled to the second register, a first multiplexer <NUM> coupled to the third register <NUM>, a second multiplexer <NUM> coupled to the fourth register <NUM>, a third multiplexer <NUM> coupled to the fifth register <NUM>, and a fourth multiplexer <NUM> coupled to the sixth register <NUM>. Thus, the sensor <NUM> may include an AND logic element for each SoC associated register and a multiplexer for each parameter associated register.

The AND logic elements <NUM> and <NUM> in conjunction with the multiplexers <NUM>-<NUM> enable the sensor <NUM> to select which SoC parameters are providing input to the sensor element. Thus, if the first register <NUM> and the second register <NUM> enable a lock on control of the sensor settings where each SoC owns a context/address space (in the third through sixth registers <NUM>, <NUM>, <NUM>, <NUM>) in the sensor <NUM> where it has its own set of configuration registers for the sensor <NUM> that it may write to without interfering with the SoC that has locked the sensor <NUM>. For example, a first command to sensor <NUM> from each SoC is to write "Lock Bit" to SENSOR_MASTER register address (e.g., the first register <NUM> and the second register <NUM>). The Power/Wake Up time could vary per SoC - first SoC to lock sensor "wins". Setting the lock bit (e.g., lock bits <NUM>,<NUM>) prevents any other SoC from locking the sensor <NUM>. Optionally, each SoC can perform a read to its SENSOR_MASTER register to see if it was able to lock the sensor <NUM>. If for a SoC it reads the Lock Bit and it is not set, then the SoC knows that another SoC has locked the sensor <NUM>. Each SoC may write its desired settings into its context/address space and may unlock and allow another SoC to gain lock by de-asserting its own Lock Bit. This enables all SoCs to understand who owns the sensor settings or why local SoC sensor settings are not being applied when observing the register configuration settings that are sent over the embedded data. Also sensor <NUM> may broadcast when lock is removed so other SoCs can initiate a lock on the sensor <NUM>. For example, SENSOR_MASTER register bit information may be transferred as embedded data and broadcast to all SoCs receiving the data stream from the sensor <NUM>. Either hardware or software in the SoC can check the embedded data to "know" which SoC has locked and is in control of the sensor <NUM>. Each SoC's feedback loop processing input to update the sensor settings may still run, issuing its own settings into its allocated context/address space on the sensor <NUM>.

<FIG> illustrates a sensor with a monitor in accordance with some examples of the disclosure. As shown in <FIG>, a sensor <NUM> (e.g., sensor <NUM>, sensor <NUM>, and sensor <NUM>) may include an I2C <NUM> that provides a bus for intra-board communication between the sensor <NUM> and a serializer/deserializer (not shown) and SoCs (not shown), an address decoder <NUM> coupled to the I2C <NUM>, a first register <NUM>, a second register <NUM>, a third register <NUM>, a fourth register <NUM>, a fifth register <NUM>, and a sixth register <NUM>. Although six registers are shown in <FIG>, it should be understood that the sensor <NUM> may include more than six registers depending on the number of parameters used by the sensor <NUM> and the number of SoCs providing parameters to sensor <NUM>. The sensor <NUM> may also include a sensor interface <NUM> that provides a pixel array and a data path for interfacing with sensing element (not shown) of the sensor <NUM>.

The third register <NUM> may be configured to store a sensor parameter, such as analog gain, from each of the SoCs providing input to the sensor <NUM>. The fourth register <NUM> may be configured to store a sensor parameter, such as digital gain, from each of the SoCs providing input to the sensor <NUM>. The fifth register <NUM> may be configured to store a sensor parameter, such as exposure time, from each of the SoCs providing input to the sensor <NUM>. The sixth register <NUM> may be configured to store a sensor parameter, such as a register configuration, from each of the SoCs providing input to the sensor <NUM>. While four such registers are shown, it should be understood that more than four may be included depending on how many parameters are input to sensor <NUM> and each such register may be configured to store parameters for the number of SoCs providing input to the sensor <NUM>.

The AND logic elements <NUM> and <NUM> in conjunction with the multiplexers <NUM>-<NUM> enable the sensor <NUM> to select which SoC parameters are input to the sensor element. Thus, if the first register <NUM> and the second register <NUM> enables a lock on control of sensor settings where each SoC owns a context/address space (in the third through sixth registers <NUM>, <NUM>, <NUM>, <NUM>) in the sensor <NUM> where it has its own set of configuration registers for the sensor <NUM> that it may write to without interfering with the SoC that has locked the sensor. For example, a first command to sensor <NUM> from each SoC is to write "Lock Bit" to SENSOR_MASTER register address (e.g., the first register <NUM> and the second register <NUM>). The Power/Wake Up time could vary per SoC - first SoC to lock sensor "wins". Setting the lock bit (e.g., lock bits <NUM>, <NUM>) prevents any other SoC from locking the sensor <NUM>. Optionally, each SoC can perform a read to its SENSOR_MASTER register to see if it was able to lock the sensor <NUM>. If for a SoC it reads the Lock Bit and it is not set, then the SoC knows that another SoC has locked the sensor <NUM>. Each SoC may write its desired settings into its context/address space and may unlock and allow another SoC to gain lock by de-asserting its own Lock Bit. This enables all SoCs to understand who owns the sensor settings or why local SoC sensor settings are not being applied. Also sensor <NUM> may broadcast when lock is removed so other SoCs can initiate a lock on the sensor <NUM>. For example, SENSOR_MASTER register bit information may be transferred as embedded data and broadcast to all SoCs receiving the data stream from the sensor <NUM>. Either hardware or software in the SoC can check the embedded data to "know" which SoC has locked and is in control of the sensor <NUM>. Each SoC's feedback loop processing input to update the sensor settings may still run, issuing its own settings into its allocated context/address space on the sensor <NUM>.

The sensor <NUM> may also include additional sets of registers intended to be used to change actual context/configuration from a single SoC (at frame boundaries in a camera sensor, for example). This additional context set can be used to enable safety checks at the system level. Sensor <NUM> may include a system safety check or threshold check. For example:.

As shown in <FIG>, the sensor <NUM> may include a monitor <NUM> coupled to the I2C <NUM> and the address decoder <NUM>, a safety manager circuit <NUM> coupled to the I2C <NUM> and the address decoder <NUM>, a first threshold compare register <NUM> coupled to the safety manager circuit <NUM>, a second threshold compare register <NUM> coupled to the safety manager circuit <NUM>, and a third threshold compare register <NUM> coupled to the safety manager circuit <NUM>. While three threshold compare registers are shown, it should be understood that more than or less than three may be included depending on the number of registers for which updates will be compared to a threshold value. The safety manager circuit <NUM> may include a timer (not shown). The monitor <NUM> and the safety manager circuit <NUM>, in conjunction with the threshold compare registers <NUM>-<NUM>, are used according to the invention to record a number of register updates from the host SoC; determine if the number of register updates exceeds a threshold; deselect the host SoC when the number of register updates does not exceed the threshold; and broadcast a release signal to the control logic circuit, the first SoC, and the second SoC when the host SoC is deselected.

For example, sensor <NUM> may include a safety check by:.

<FIG> illustrates a partial method for controlling a sensor in accordance with some examples of the disclosure. As shown in <FIG>, a partial method <NUM> of controlling a sensor (e.g., sensor <NUM>, sensor <NUM>, sensor <NUM>, and sensor <NUM>) begins in block <NUM> with generating a first sensor configuration value for a sensor parameter by a first System on Chip (SoC) communicatively coupled to a sensor and a control logic circuit. The partial method <NUM> continues in block <NUM> with generating a second sensor configuration value for the sensor parameter by a second SoC communicatively coupled to the sensor and the control logic circuit. The partial method <NUM> continues in block <NUM> with selecting between the first SoC and the second SoC as a host SoC. The partial method <NUM> may conclude in block <NUM> with applying one of the first configuration value or the second configuration value for the sensor parameter based on the selected host SoC. Optionally, the partial method <NUM> continues in block <NUM> with recording, by a monitor communicatively coupled to the control logic circuit, the sensor, the first SoC, and the second SoC, a number of register updates received from the selected host SoC. The partial method <NUM> continues in block <NUM> with determining, by the monitor, if the number of register updates exceeds a threshold. The partial method <NUM> continues in block <NUM> with deselecting, by the monitor, the selected host SoC when the number of register updates does not exceed the threshold. The partial method <NUM> may conclude in block <NUM> with broadcasting, by the monitor, a release signal to the control logic circuit, the first SoC, and the second SoC when the selected host SoC is deselected or also include block <NUM> with transmitting, by the control logic circuit, information about the selected host SoC to a non-selected SoC. While broadcasting a release signal has been shown in <FIG>, it should be understood that each SoC may alternatively scan one or more of the registers in the sensor to determine which SoC has a lock on the sensor.

<FIG> illustrates various electronic devices that may be integrated with any of the aforementioned SoCs in accordance with some examples of the disclosure. For example, a mobile phone device <NUM>, an automotive vehicle <NUM>, a mobile vehicle such as a watercraft <NUM> or an aircraft <NUM> may include an integrated device <NUM> as described herein. The integrated device <NUM> may be, for example, any of the integrated circuits, SoCs, registers, logic circuits described herein. The devices <NUM>, <NUM>, <NUM>, and <NUM> illustrated in <FIG> are merely exemplary. Other electronic devices may also feature the integrated device <NUM> including, but not limited to, a group of devices (e.g., electronic devices) that includes mobile devices, hand-held personal communication systems (PCS) units, portable data units such as personal digital assistants, global positioning system (GPS) enabled devices, navigation devices, set top boxes, music players, video players, entertainment units, fixed location data units such as meter reading equipment, communications devices, smartphones, tablet computers, computers, wearable devices, servers, routers, electronic devices implemented in automotive vehicles (e.g., autonomous vehicles), or any other device that stores or retrieves data or computer instructions, or any combination thereof.

It will be appreciated that various aspects disclosed herein can be described as functional equivalents to the structures, materials and/or devices described and/or recognized by those skilled in the art. For example, in one aspect, an apparatus may comprise a processing means (see, e.g., <NUM> and <NUM> in <FIG>), a means for sensing (see, e.g., <NUM> in <FIG>), coupled to the processing means, and a control means (see, e.g., <NUM> in <FIG>) coupled to the sensing means and the processing means. Such an apparatus may further include a means for monitoring (see, e.g., <NUM> and <NUM> in <FIG>) coupled to the sensing means.

One or more of the components, processes, features, and/or functions illustrated in <FIG> may be rearranged and/or combined into a single component, process, feature or function or incorporated in several components, processes, or functions. Additional elements, components, processes, and/or functions may also be added without departing from the disclosure. It should also be noted that <FIG> and its corresponding description in the present disclosure is not limited to dies and/or ICs. In some implementations, <FIG> and its corresponding description may be used to manufacture, create, provide, and/or produce integrated devices. In some implementations, a device may include a die, an integrated device, a die package, an integrated circuit (IC), and/or a SoC.

In this description, certain terminology is used to describe certain features. The term "mobile device" or "mobile computing device" can describe, and is not limited to, a navigation device, a communications device, a mobile device, a mobile phone, a smartphone, a personal digital assistant, a tablet computer, a computer, a wearable device, a laptop computer, a mobile vehicle, an automotive device in an automotive vehicle. Further, the terms "user equipment" (UE), "mobile terminal," "mobile device," and "wireless device," can be interchangeable.

The wireless communication between electronic devices can be based on different technologies, such as code division multiple access (CDMA), W-CDMA, time division multiple access (TDMA), frequency division multiple access (FDMA), Orthogonal Frequency Division Multiplexing (OFDM), Global System for Mobile Communications (GSM), 3GPP Long Term Evolution (LTE), Bluetooth (BT), Bluetooth Low Energy (BLE) or other protocols that may be used in a wireless communications network or a data communications network. Bluetooth Low Energy (also known as Bluetooth LE, BLE, and Bluetooth Smart) is a wireless personal area network technology designed and marketed by the Bluetooth Special Interest Group intended to provide considerably reduced power consumption and cost while maintaining a similar communication range. BLE was merged into the main Bluetooth standard in <NUM> with the adoption of the Bluetooth Core Specification Version <NUM> and updated in Bluetooth <NUM> (both expressly incorporated herein in their entirety).

" Any details described herein as "exemplary" is not to be construed as advantageous over other examples. Likewise, the term "examples" does not mean that all examples include the discussed feature, advantage or mode of operation. Furthermore, a particular feature and/or structure can be combined with one or more other features and/or structures. Moreover, at least a portion of the apparatus described hereby can be configured to perform at least a portion of a method described hereby.

The terminology used herein is for the purpose of describing particular examples and is not intended to be limiting of examples of the disclosure. It will be further understood that the terms "comprises," "comprising," "includes," and/or "including," when used herein, specify the presence of stated features, integers, actions, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, actions, operations, elements, components, and/or groups thereof.

It should be noted that the terms "connected," "coupled," or any variant thereof, mean any connection or coupling, either direct or indirect, between elements, and can encompass a presence of an intermediate element between two elements that are "connected" or "coupled" together via the intermediate element.

Any reference herein to an element using a designation such as "first," "second," and so forth does not limit the quantity and/or order of those elements. Rather, these designations are used as a convenient method of distinguishing between two or more elements and/or instances of an element. Also, unless stated otherwise, a set of elements can comprise one or more elements.

Further, many examples are described in terms of sequences of actions to be performed by, for example, elements of a computing device. Additionally, these sequence of actions described herein can be considered to be incorporated entirely within any form of computer-readable storage medium having stored therein a corresponding set of computer instructions that upon execution would cause an associated processor to perform the functionality described herein.

In addition, for each of the examples described herein, the corresponding form of any such examples may be described herein as, for example, "logic configured to" perform the described action.

Further, those of skill in the art will appreciate that the various illustrative logical blocks, modules, circuits, and algorithm actions described in connection with the examples disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and actions have been described above generally in terms of their functionality.

The methods, sequences and/or algorithms described in connection with the examples disclosed herein may be incorporated directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art including non-transitory types of memory or storage mediums.

The various illustrative logical blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein.

Claim 1:
A sensor control apparatus (<NUM>), comprising:
a first System on Chip, SoC, (<NUM>) configured to generate a first sensor configuration value for a sensor parameter;
a second SoC (<NUM>) configured to generate a second sensor configuration value for the sensor parameter;
a sensor (<NUM>) communicatively coupled to the first SoC (<NUM>) and the second SoC (<NUM>);
a control logic circuit (<NUM>) communicatively coupled to the first SoC (<NUM>), the second SoC (<NUM>), and the sensor (<NUM>), wherein the control logic circuit (<NUM>) is configured to select between the first SoC (<NUM>) and the second SoC (<NUM>) as a host SoC and to apply to the sensor (<NUM>) one of the first sensor configuration value or the second sensor configuration value for the sensor parameter based on the selected host SoC; and
a monitor (<NUM>) communicatively coupled to the control logic circuit (<NUM>), the sensor (<NUM>), the first SoC (<NUM>), and the second SoC (<NUM>), wherein the monitor (<NUM>) is configured to:
record a number of register updates from the selected host SoC in a predefined window;
determine if the number of register updates in the predefined window exceeds a threshold;
deselect the selected host SoC when the number of register updates in the predefined window does not exceed the threshold; and
broadcast a release signal to the control logic circuit (<NUM>), the first SoC (<NUM>), and the second SoC (<NUM>) when the selected host SoC is deselected.