CN109428663B

CN109428663B - System and control device for synchronization

Info

Publication number: CN109428663B
Application number: CN201811001650.2A
Authority: CN
Inventors: C·米切萨勒; L·艾克雷德勒
Original assignee: Infineon Technologies AG
Current assignee: Infineon Technologies AG
Priority date: 2017-08-31
Filing date: 2018-08-30
Publication date: 2020-08-07
Anticipated expiration: 2038-08-30
Also published as: DE102018121226A1; CN109428663A

Abstract

The present disclosure relates to a system and a control device for synchronization. For example, a sensor may determine an expected time for receiving an upcoming synchronization signal based on two or more synchronization signals provided by a control device. The sensor may perform a measurement of the sensor signal at a point in time such that sensor data corresponding to the measurement of the sensor signal at the point in time is available a selectable period of time before receiving the upcoming synchronization signal.

Description

System and control device for synchronization

Cross Reference to Related Applications

This application is a part-on-application (CIP) of U.S. patent application No.15/692,974 filed on 31.8.2017, which is based on 35u.s.c. § 119 claiming priority of U.S. provisional patent application No.62/444,687 filed on 10.1.2017, the contents of which are incorporated herein by reference in their entirety.

Technical Field

The present disclosure relates to the field of sensors, and more particularly, to synchronization mechanisms for high-speed sensor interfaces.

Background

Sensors (e.g., speed sensors, position sensors, angle sensors, temperature sensors, current sensors, etc.) may be used to provide feedback information in the electromechanical system by, for example, operating as an interface between the mechanical and electrical domains. In some cases, the physical location of the sensor depends on mechanical constraints of the electromechanical system, such as available physical space, accessibility to the sensing target (e.g., target wheel, axle stub, etc.). Thus, in some applications, the sensors cannot be integrated with an Electronic Control Unit (ECU) and must operate as stand-alone (i.e., remote) sensors connected to the ECU via a wired interface.

Disclosure of Invention

According to some possible embodiments, a sensor may include one or more components for determining a sampling pattern based on a set of synchronization signals received by the sensor, where the sampling pattern may identify an expected time for receiving an upcoming synchronization signal; and triggering performance of a sensor operation associated with the upcoming synchronization signal based on the sampling pattern, wherein the performance of the sensor operation may be triggered before the upcoming synchronization signal is received.

According to some possible embodiments, a system may include a sensor to: determining a sampling pattern based on a set of synchronization signals received by the sensor, wherein the sampling pattern can identify a time at which an upcoming synchronization signal is expected to be received by the sensor; and performing sensor operations associated with the upcoming synchronization signal based on the sampling pattern, wherein the sensor operations may be performed such that sensor data associated with the sensor operations is ready to be transmitted at a time when the upcoming synchronization signal is expected to be received.

According to some possible embodiments, a method may comprise: determining a sampling pattern based on receiving a set of synchronization signals, wherein the sampling pattern can identify an expected time for receiving an upcoming synchronization signal; and triggering performance of a sensor operation associated with the upcoming synchronization signal based on the sampling pattern, wherein the performance of the sensor operation may be triggered before the upcoming synchronization signal is received by the sensor.

According to some possible embodiments, a system may include: a sensor for: determining an expected time for receiving an upcoming synchronization signal based on two or more synchronization signals provided by a control device; and performing a measurement of a sensor signal at a point in time such that sensor data corresponding to the measurement of the sensor signal at the point in time is available at a selectable time period (or time interval) before receiving the upcoming synchronization signal.

According to some possible embodiments, a sensor may comprise one or more components for: determining an expected time for receiving an upcoming synchronization signal, wherein the expected time may be determined based on a set of synchronization signals provided by a control device associated with the sensor; sampling a sensor signal at a point in time such that sensor data calculated based on sampling the sensor signal at the point in time is available a selectable period of time before the sensor receives the upcoming synchronization signal; calculating the sensor data based on sampling the sensor signal at the point in time; and providing the sensor data after receiving the upcoming synchronization signal.

According to some possible embodiments, a control device may comprise one or more components for: providing a set of synchronization signals to a set of sensors, wherein the set of synchronization signals can define a sampling pattern for identifying a projected time associated with another synchronization signal; providing the further synchronization signal; and receiving sensor data from sensors in the set of sensors after providing the further synchronization signal, wherein the sensor data is available at the sensors before the further synchronization signal is received by the sensors based on the sampling pattern.

Drawings

FIGS. 1A and 1B are schematic diagrams of an overview of example embodiments described herein;

FIG. 2 is a schematic illustration of an example environment in which systems and/or methods described herein may be implemented;

FIG. 3 is a flow diagram of an example process for triggering sensor operations associated with an upcoming synchronization signal based on a sampling pattern associated with receiving the synchronization signal;

FIG. 4 is a schematic diagram of an example embodiment associated with the example process shown in FIG. 3;

FIG. 5 is a flow diagram of an example process for selectively adjusting a delay time for triggering sensor operations associated with an upcoming synchronization signal;

FIG. 6 is a schematic diagram of an example embodiment associated with the example process shown in FIG. 5;

FIG. 7 is a schematic diagram illustrating an example application of the sensor system described herein;

FIG. 8 is a schematic diagram of an example embodiment associated with a synchronous mode of operation as described with reference to the example process of FIG. 3;

FIGS. 9A and 9B are schematic diagrams of an example format of signals that may be provided by the ECU of FIG. 2; and is

FIG. 10 is a schematic diagram of an example environment including a listen-only ECU as described herein.

Detailed Description

The following detailed description of example embodiments refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements.

The interface between the sensor and the ECU (e.g., a wired interface between a remote sensor and the ECU) is an important component in the sensor system. For example, the interface may significantly affect the robustness of the sensor system, as the interface significantly contributes to the overall time to Failure (FIT) rate of the sensor system, and may significantly affect the cost of the sensor system by increasing the cost of producing, assembling, and/or maintaining the sensor system. As another example, the interface may significantly affect the performance of the sensor system, as the interface may act as a bottleneck for information transfer in the sensor system.

With respect to impact on performance, in some cases, the performance of the sensor system may be limited by the connection bandwidth (e.g., the total baud rate available) and/or the loss of synchronization between the sensor and the ECU. In some cases, the connection bandwidth problem can be solved by introducing advanced connection schemes. However, loss of synchronization between the sensor and the ECU remains a major limitation in the achievable performance of the sensor system.

In general, the transmission of information between sensors and an ECU may be handled by configuring the sensors to automatically provide a stream of sensor data (referred to herein as a continuous data stream), e.g., without a request from the ECU, or by configuring the sensors to provide sensor data based on receiving a request from the ECU.

In the case of a continuous data stream, both the sampling time (e.g., the time at which the sensor samples or measures the sensor signal) and the time at which transmission of the sensor data is initiated are determined by the clock of the sensor, which operates in the sensor clock domain. Here, the ECU needs to receive the sensor data in real time even though the ECU may not need the sensor data until a later point in time (later time when the ECU is to perform a calculation operation using the sensor data). Therefore, the ECU must perform an operation of synchronizing the sensor data with the clock of the ECU210, the clock of the ECU210 operating in an ECU clock domain different from the sensor clock domain.

With this approach, there is a variable delay between the sensor sampling the sensor signal and the use of the sensor data by the ECU. Contributors to this delay time include: the amount of time required for the sensor to perform a data calculation after sampling the sensor signal, the amount of time required for the sensor to send sensor data after performing a data calculation, and the amount of "wait" time between completion of transmission of the sensor data and use of the sensor data by the ECU.

Due to asynchronous operation of the sensors and the ECU (e.g., due to operation in different clock domains), the delay time may vary between one and two times the sum of the amount of time required for the sensors to perform data calculations and the amount of time required to transmit sensor data (referred to herein as sensor time). In the case where the sensor update rate (e.g., the rate at which transmission of sensor data is provided by the sensor) is higher than the ECU cycle time (e.g., the amount of time required for the ECU to perform one calculation cycle), the wait time may vary between zero (e.g., when transmission of sensor data is completed precisely at the point in time at which the sensor data is to be used by the ECU) and an amount of time equal to the sensor time. The wait time may be kept theoretically constant if the sensor time is an integer multiple of the ECU cycle time. However, due to tolerances of the sensor and ECU clock domains, the integer multiple will not be constant and, therefore, the latency will vary at each cycle, thereby introducing variations in the delay time.

In some cases, latency time may be reduced by increasing the speed of the sensor (e.g., to reduce the amount of time to perform data calculations) and/or increasing the bandwidth of the interface (e.g., to reduce the amount of time to send sensor data). Here, if the dynamics of the sensor system are known, the deviations in sensor time caused by different operating conditions can be compensated by implementing estimation algorithms in the ECU. However, a variable portion of the delay time (i.e., latency) may not be compensated for in this manner. Thus, continuous data flow techniques for transmitting information between the sensors and the ECU may introduce excessive and/or variable synchronization errors at the ECU (e.g., between about 0 degrees and 2.55 degrees for angle sensors).

Configuring the sensors to provide sensor data based on receiving a request from the ECU (i.e., rather than a continuous data stream) may reduce or eliminate synchronization errors caused by the clock domains of the sensors and the ECU. For example, using conventional techniques for such synchronization schemes, the ECU may provide a synchronization signal to the sensors. Here, receiving the synchronization signal by the sensor causes the sensor to sample (i.e., measure) the sensor signal, perform data calculations, and then transmit the sensor data to the ECU. In this case, there is no synchronization error in the sensor data decoded by the ECU (e.g., because the sensor is synchronized with the ECU based on the synchronization signal provided by the ECU). However, this conventional technique has many disadvantages.

One disadvantage of the conventional technique is that the utilization of the sensor interface bus is relatively low because there is no communication on the bus during the time period that the sensor samples the sensor signals and performs data calculations. This also results in a reduction of the maximum possible update rate for a given interface bandwidth.

Similarly, another disadvantage of conventional techniques is that since the ECU needs to access the sensor interface bus twice per update period (e.g., once to provide a synchronization signal and then again to receive sensor data), the utilization of the sensor interface bus may be reduced because the sensor interface bus must be available for transmission by the sensor at the expected point in time (e.g., the time at which the sensor data is expected to be transmitted).

Another disadvantage of the conventional technique is that the ECU provides a synchronization signal well before the sensor data is sent by the sensors. In some cases, such delays introduce potential errors in the sensor system.

Yet another disadvantage of the conventional technique is that the ECU needs to switch between performing two different operations: a first operation associated with providing a synchronization signal and a second operation associated with receiving and processing sensor data. In some cases, interrupting one operation (e.g., the second operation) to switch to another operation (e.g., the first operation) may require consuming the computational power of the ECU and should therefore be avoided when possible.

Another drawback of conventional techniques is the limitation on the achievable sensor update rate. For example, in some sensor systems (e.g., rotor position sensors for drive applications), a relatively high sensor update rate (e.g., transmission of one complete sensor data every 33 microseconds (μ β)) may be required. Here, the sensor update rate is affected by the amount of delay associated with receiving the synchronization signal, the amount of time to sample the sensor signal, the amount of time to perform the calculations, and the amount of time to transmit the sensor data. In a common sensor using the conventional synchronization techniques described above, the update rate may be, for example, approximately one complete transmission every 45 microseconds (μ β) (or worse). Thus, a relatively high sensor update rate may not be achievable using conventional synchronization techniques.

To achieve an improved sensor update rate (i.e., compared to conventional techniques), the amount of time required to transmit sensor data or to sample the sensor signal and perform calculations may be reduced. However, due to limitations regarding the bandwidth of the sensor interface, increasing the transmission speed may not be feasible or will occur at unreasonably high cost (e.g. changing the physical layer). Similarly, while reductions in sampling time and/or computation time may be achieved with faster signal processing, increasing the speed of signal processing may also occur at unreasonably high cost (e.g., implementing advanced processing, implementing parallel processing, etc.).

It should be noted that while there are many techniques for governing the transmission of sensor data (e.g., Incremental Interface (IIF), Serial Peripheral Interface (SPI), one-sided nibble transmission (send), short pulse width modulation code (SPC), Pulse Width Modulation (PWM), analog, etc.), these techniques are not able to provide acceptable interface bandwidth and/or immunity to electromagnetic environments (EME) that are required for use by remote sensors that require relatively high update rates (e.g., 33 μ s or better).

In some cases, an analog interface is used when a relatively high update rate is required. However, while analog interfaces can provide acceptable update rates, analog interfaces have a number of disadvantages. For example, the analog interface may require additional wires to facilitate data transfer (e.g., additional cost and/or complexity as compared to a digital interface), may be subject to electromagnetic distortion, and/or may be incompatible with the particular data processing techniques used in the sensor system (e.g., digital processing techniques). Additionally, the analog interface may not be able to transmit other information associated with the sensor. For example, the analog interface may not be able to transmit diagnostic information associated with the sensor, such as information associated with self-diagnostics, temperature information, information associated with examining a range of sensor input data (e.g., magnetic field strength), and the like.

Some embodiments described herein provide techniques for synchronizing sensors (e.g., remote sensors) with an ECU via a digital interface while achieving improved sensor update rates (e.g., as compared to conventional synchronization techniques described above). In some embodiments, such improved synchronization may be achieved by configuring the sensors based on a triggering technique for self-adjustment in anticipation of an upcoming synchronization signal, as described in further detail below.

Additionally, some embodiments described herein provide techniques for synchronizing multiple sensors (e.g., multiple remote sensors) with an ECU, where each of the multiple sensors synchronously samples their respective sensor signals (e.g., such that each of the multiple sensors simultaneously samples their respective sensor signals). In some embodiments, multiple sensors may be operated in this synchronization mode based on broadcast synchronization features configured in the sensor system, as described in further detail below.

Fig. 1A and 1B are schematic diagrams of an overview of an example embodiment 100 described herein. As shown in fig. 1A, the sensors are connected to the ECU via a sensor interface bus (e.g., such that the sensors can provide sensor data to the ECU via the sensor interface bus). In the example embodiment 100, to synchronize the sensors with the ECU, the sensors are configured to anticipate a synchronization (sync) signal (before such signal is provided by the ECU) in order to allow improved sensor update rates while achieving synchronization via the digital interface, as described below.

As shown by reference numeral 105, the ECU provides a set of synchronization signals (e.g., including a first synchronization signal and a second synchronization signal) to the sensors (e.g., when the sensor system is powered on). For example, as shown, the ECU may provide a first synchronization signal that is received by the sensor at a first time. Here, the sensor may perform a sensor operation (e.g., sampling a sensor signal, calculating sensor data, etc.), and may transmit the first sensor data to the ECU (not shown in fig. 1A). The ECU may then send a second synchronization signal that is received by the sensor at a second (e.g., later) time. Again, the sensor may perform a sensor operation, and the second sensor data may be transmitted to the ECU (not shown in fig. 1A).

As illustrated by reference numeral 110, the sensor may anticipate a third (e.g., upcoming) synchronization signal based on receiving the first synchronization signal and the second synchronization signal. For example, in some embodiments, the sensor may determine a sampling pattern associated with the synchronization signal received from the ECU based on the first synchronization signal and the second synchronization signal. The sampling pattern may identify, for example, an expected amount of time between receiving a given pair of synchronization signals from the ECU. Here, the sensor may anticipate the third synchronization signal based on a sampling pattern with respect to the synchronization signal received from the ECU. For example, the sensor may identify a point in time at which the sensor expects to receive the third synchronization signal from the ECU based on the sampling pattern.

As shown by reference numeral 115, the sensor may trigger a sensor operation associated with the third synchronization signal based on anticipation of the third synchronization signal. In other words, the sensor may start to perform the sensor operation before the sensor receives the third synchronization signal from the ECU.

In some embodiments, the sensor may trigger the sensor operation based on a point in time at which the sensor expects to receive the third synchronization signal. For example, the sensor may store, have access to, or otherwise determine an amount of time required for the sensor to perform a sensor operation (e.g., an amount of time required to sample a sensor signal and calculate sensor data). Here, since the sensor has identified when the third synchronization signal is expected, the sensor may determine a point in time that triggers a sensor operation associated with the third synchronization signal such that the third sensor data is ready for transmission at or near the point in time that the third synchronization signal is received. Thus, the sensor may trigger a sensor operation associated with the third synchronization signal prior to receiving the third synchronization signal from the ECU. A detailed example of this technique is described below with reference to fig. 1B.

As shown by reference numeral 120, the sensor receives a third synchronization signal from the ECU. Here, since the sensor has triggered the sensor operation associated with the third synchronization signal before receiving the third synchronization signal, the third sensor data may be ready for transmission at or near the point in time at which the third synchronization signal is received. Thus, as illustrated by reference numeral 125, the sensor may provide the third sensor data with reduced delay (i.e., almost immediately after receiving the third synchronization signal).

FIG. 1B is a schematic diagram further illustrating the example technique described in FIG. 1A. To fig. 1B, the sensor has determined a sampling pattern associated with receiving a synchronization signal from the ECU (e.g., an expected amount of time between receiving a given synchronization signal and receiving the next synchronization signal).

As illustrated by reference numeral 130, the sensor may anticipate receipt of the synchronization signal X based on the sampling pattern and trigger performance of the sensor operation associated with the synchronization signal X accordingly. For example, based on the sampling pattern, the sensor may determine that, in order to prepare the sensor data X for transmission at or near the point in time at which the sensor receives the synchronization signal X, the sensor is to trigger performance of the sensor operation (e.g., determination of the sensor data X) at time tSampleX. It should be noted that time tSampleX precedes the time tSyncX at which the ECU sends the synchronization signal X, and therefore precedes the time at which the sensor receives the synchronization signal X. As shown, the sensor data X is ready to be transmitted when the sensor receives a synchronization signal X via the sensor interface bus (e.g., after Rx SyncX), and the sensor sends the sensor data X (e.g., immediately after receiving the synchronization signal X). As shown, in some embodiments, the sensor may be configured to implement time buffering, for example, to ensure that the sensor data X is ready for transmission before receiving the synchronization signal X.

As illustrated by reference numeral 135, the sensor may anticipate receipt of the synchronization signal Y (i.e., the next synchronization signal) based on the sampling pattern and trigger performance of the sensor operation associated with the synchronization signal Y accordingly. As shown, based on the sampling pattern, the sensor may defer triggering performance of the sensor operation until time tSampleY in order to prepare the sensor data Y for transmission at or near the point in time at which the sensor receives the synchronization signal Y (e.g., after transmission by the ECU at time tSyncY). In this manner, the amount of delay between sampling of the sensor signals and transmission of corresponding sensor data is reduced. In addition, as shown, the time period for which the sensor determines the sensor data Y overlaps with the time period for which the sensor transmits the sensor data X. In other words, the "next" sensor data may be determined while the "current" sensor data is being transmitted, which allows for an improved sensor update rate, as described below.

The sensor may proceed in the manner described above for transmitting sensor data Y, and as shown by reference numeral 140, may proceed in a similar manner for anticipating the synchronization signal Z and transmitting sensor data Z associated with the synchronization signal Z. Additional details regarding the process described above are described below.

In this manner, the sensors may be synchronized with the ECU via the digital interface while achieving an improved sensor update rate (e.g., as compared to the conventional synchronization techniques described above).

In some embodiments, utilization of the sensor interface bus is improved because use of the sensor interface bus for transmitting synchronization signals and transmitting corresponding sensor data is reduced or eliminated. In addition, the sensor interface bus is more efficiently utilized, since the point in time at which the sensor interface bus should be available for transmission by the sensor closely or immediately follows the transmission of the synchronization signal.

Additionally, the amount of time between transmitting the synchronization signal and transmitting the corresponding sensor data is reduced, which may reduce potential errors in the sensor system.

In addition, using the techniques described herein, the achievable sensor update rate is increased. For example, by anticipating the synchronization signal and triggering the performance of the sensor operation in the manner described above, a significant amount of delay associated with a given sensor cycle is eliminated. Thus, the rate at which the sensor completes the cycle of determining and transmitting sensor data is improved, thereby facilitating a relatively high sensor update rate (e.g., one complete transmission every 33 μ s, or better).

As indicated above, fig. 1A and 1B are provided as examples only. Other examples are possible and may differ from what is described with respect to fig. 1A and 1B.

Fig. 2 is a schematic diagram of an example environment 200 in which techniques and/or apparatus described herein may be implemented. As shown in FIG. 2, environment 200 may include a set of sensors 205-1 through 205-N (N ≧ 1) (collectively referred to herein as sensors 205, and individually referred to as sensors 205) connected to ECU210 via a sensor interface bus 215 (referred to herein as bus 215).

The sensor 205 includes a housing associated with one or more components of the sensor for measuring one or more characteristics (e.g., velocity of the object, position of the object, angle of rotation of the object, amount of pressure, temperature, amount of current, etc.). As shown, the sensor 205 includes a sensing device 220 and a transceiver (Tx/Rx) 225. In some embodiments, the sensors 205 may include two or more sensing devices 220 and Tx/Rx 225 (i.e., the sensors 205 may include a sensor cluster). In some embodiments, the sensor 205 is remote from the ECU210 and thus connected to the ECU210 via a bus 215 (e.g., via a wired connection). Additionally or alternatively, the sensor 205 may be a local sensor (e.g., such that the sensor 205 is connected to the ECU210 via a short connection, integrated on the same chip as the ECU210, etc.).

Sensing device 220 includes a device capable of performing a sensing function (e.g., sampling sensor signals, calculating and/or determining sensor data, etc.). In some embodiments, the sensing device 220 is capable of performing operations associated with a synchronization signal that is expected to be provided by the ECU210, and triggering a sensing function based on the expected synchronization signal, as described herein. In some implementations, the sensing device 220 can include one or more sensing elements, analog-to-digital converters (ADCs), Digital Signal Processors (DSPs), memory components, and digital interfaces that enable performance of sensing functions and/or enable operations associated with anticipation of synchronization signals by the sensing device 220.

The transceiver 225 includes components via which devices (e.g., sensors 205, ECU 210) can send and receive information. For example, the transceiver 225 may comprise a differential line transceiver or similar type of device. In some embodiments, the transceiver 225 includes a transmit (Tx) component that allows the sensor 205 to transmit information (e.g., sensor data, information identifying a delay time associated with anticipating a synchronization signal, etc.) to the ECU210 via the bus 215 and a receive (Rx) component that allows the sensor 205 to receive information (e.g., a synchronization signal) from the ECU210 via the bus 215. In some embodiments, the transceiver 225 may include a line driver for enabling either the Tx component (to transmit information) or the Rx component (to receive information) at a given time. In some embodiments, the sensor 205 may not include the transceiver 225. For example, the sensor 205 may not include the transceiver 225 when the sensor 205 is a local sensor 205 and/or when the length of the connection between the sensor 205 and the ECU210 is relatively short (e.g., as compared to an application in which the sensor 205 is a remote sensor).

The bus 215 includes a sensor interface bus for carrying information between the sensors 205 and the ECU 210. In some embodiments, bus 215 may include a connection (e.g., including one or more wires and connectors) to ECU210 via its sensors 205. In some embodiments, the bus 215 may include a set of connections, each associated with one or more sensors 205 connected to the ECU210 (e.g., when multiple sensors 205 are connected to the ECU210 via one or more buses 215). In some implementations, a given connection may be capable of carrying signals from the ECU210 to the sensors 205 and carrying signals from the sensors 205 to the ECU210 (e.g., via the same wires or via different wires).

ECU210 includes one or more devices associated with controlling one or more electrical systems and/or electrical subsystems based on sensor data provided by sensors 205 (e.g., control devices). As shown, the ECU210 may include a transceiver 225 and a controller (μ C) 230. In some embodiments, controller 230 may be capable of calibrating, controlling, adjusting, etc. one or more electrical systems and/or electrical subsystems based on sensor data transmitted by sensors 205. For example, in some embodiments, the controller 230 may include an electronic/Engine Control Module (ECM), a Power Control Module (PCM), a Transmission Control Module (TCM), a brake control module (BCM or EBCM), a Central Control Module (CCM), a Central Timing Module (CTM), a General Electronic Module (GEM), a Body Control Module (BCM), a Suspension Control Module (SCM), or other electrical system or electrical subsystem of the vehicle. In some implementations, the controller 230 can include one or more components associated with transmitting, receiving, generating, providing, and/or storing information (e.g., synchronization signals, sensor data, information identifying delay times associated with anticipating synchronization signals, etc.), as described herein. For example, controller 230 may include a general sensor interface chip (USIC) component, one or more Direct Memory Access (DMA) components, a Random Access Memory (RAM) component, a Field Oriented Control (FOC) component, a space vector PWM (svpwm) component, a PWM output component, a general purpose input/output (GPIO) component, a pattern memory component, a pattern generator component, and/or the like.

As described above, the transceiver 225 includes components via which devices (e.g., sensors 205, ECU 210) can send and receive information. In some embodiments, the transceiver 225 includes a Tx component that allows the ECU210 to transmit information (e.g., synchronization signals) to the sensors 205 via the bus 215 and an Rx component that allows the ECU210 to receive information (e.g., sensor data, information identifying delay times associated with anticipating synchronization signals, etc.) from the sensors 205 via the bus 215. In some embodiments, the transceiver 225 may include a line driver for enabling either the Tx component (to transmit information) or the Rx component (to receive information) at a given time.

The number and arrangement of the devices shown in fig. 2 are provided as examples. In practice, there may be additional devices and/or components, fewer devices and/or components, different devices and/or components, or devices and/or components arranged differently than those shown in fig. 2. For example, in some embodiments, environment 200 may include a plurality of sensors 205, each connected to ECU210 via one or more associated buses 215. In addition, two or more devices and/or components shown in fig. 2 may be implemented within a single device and/or component, or a single device and/or single component shown in fig. 2 may be implemented as multiple distributed devices and/or components. Additionally or alternatively, a set of devices and/or components (e.g., one or more devices and/or components) of fig. 2 may perform one or more functions described as being performed by another set of devices and/or components of fig. 2.

Fig. 3 is a flow diagram of an example process 300 for triggering sensor operations associated with an upcoming synchronization signal based on a sampling pattern associated with receiving the synchronization signal. In some embodiments, one or more of the process blocks of fig. 3 may be performed by the sensor 205.

As shown in fig. 3, process 300 may include determining a sampling pattern based on a set of received synchronization signals (block 310). For example, the sensor 205 may determine the sampling pattern based on a set of synchronization signals received from the ECU 210.

The sampling pattern may include a pattern that identifies an expected amount of time between receiving synchronization signals provided by the ECU 210. For example, the sampling pattern may identify an expected amount of time between receiving a given synchronization signal and the next synchronization signal (when the synchronization signals are expected to be at regular intervals). As another example, the sampling pattern may identify a first expected amount of time between receipt of the first synchronization signal and receipt of the second synchronization signal, a second expected amount of time between receipt of the second synchronization signal and receipt of the third synchronization signal, and a third expected amount of time between receipt of the third synchronization signal and receipt of the fourth synchronization signal (e.g., when the synchronization signals are expected to be in a repeating sequence of three different intervals). In some implementations, the sampling pattern can define a synchronization period associated with receiving a synchronization signal (e.g., a length of time between receiving a given pair of synchronization signals).

In some implementations, the sensor 205 can determine the sampling pattern based on receiving a set of synchronization signals. For example, the sensor 205 may receive a first synchronization signal at a first time, a second synchronization signal at a second time, and a third synchronization signal at a third time. Here, the sensor 205 may determine the sampling pattern as an average (e.g., a weighted average) of a time difference between the third time and the second time and a time difference between the second time and the first time. Additionally or alternatively, the sensor 205 may determine the sampling pattern based on a (e.g., repeating) pattern that identifies time differences between pairs of the synchronization signals.

In some implementations, the sensor 205 can update and/or modify the sampling pattern based on receiving additional synchronization signals. Continuing with the example described above, the sensor 205 may determine the sampling pattern as a weighted average of the time difference between the third time and the second time and the time difference between the second time and the first time (e.g., where the time difference between the third time and the second time receives more weight than the time difference between the second time and the first time). Here, upon receiving the fourth synchronization signal at a fourth (e.g., later) time, the sensor 205 may update the sampling pattern by determining a weighted average of the time difference between the fourth time and the third time, the time difference between the third time and the second time, and the time difference between the second time and the first time (e.g., where the time difference between the fourth time and the third time receives more weight than the time difference between the third time and the second time, and the time difference between the second time and the first time).

In some implementations, the sensor 205 can determine when the sampling pattern is, for example, powered up, activated, reset, etc. of the sensor 205. For example, after power up, the sensor 205 may receive a first synchronization signal, perform an associated sensor operation, and provide first sensor data. The sensor 205 may receive the second synchronization signal, perform an associated sensor operation, and provide second sensor data. In this example, the sensor 205 may determine the sampling pattern based on a time of receiving the first synchronization signal and a time of receiving the second synchronization signal (e.g., concurrently with performing a sensor operation associated with the second synchronization signal). As another example, after power up, the sensor 205 may perform a first sensor operation to determine first sensor data, perform a second sensor operation to determine second sensor data, receive a first synchronization signal, and provide the first sensor data. The sensor 205 may then receive the second synchronization signal and provide second sensor data. In this example, the sensor 205 may determine the sampling pattern based on a time of receiving the first synchronization signal and a time of receiving the second synchronization signal.

As described below, based on the sampling pattern, the sensor 205 may identify an expected time for receiving the third synchronization signal and trigger a sensor operation associated with the third synchronization signal (e.g., prior to receiving the third synchronization signal). In some embodiments, after receiving the third synchronization signal, the sensor 205 may update, modify, recalculate, etc. the sampling pattern based on the time at which the third synchronization signal was received.

In some implementations, the sampling pattern can be used to identify an expected time for receiving an upcoming synchronization signal (e.g., the sensor 205 can expect a time to receive the upcoming synchronization signal). For example, the sensor 205 may identify the expected time based on the sampling pattern and the time at which the previous (e.g., most recent) synchronization signal was received. As a particular example, if the sensor 205 receives a synchronization signal at a particular time, the sensor 205 may determine an expected time associated with an upcoming (e.g., next) synchronization signal by adding the amount of time between receiving synchronization signals identified by the sampling pattern to the particular time at which the synchronization signal was received. Here, the result of adding the amount of time identified by the sampling pattern to the particular time at which the synchronization signal was received may identify an expected time of the upcoming synchronization signal.

In some implementations, the format of the signal (e.g., the synchronization signal, the signal carrying a particular address, etc.) may allow the signal to carry only information identifying the address (e.g., the broadcast address, the address associated with the particular sensor 205, etc.). For example, the format of the signal may allow the signal to carry a value (e.g., an 8-bit value) representing an address. Alternatively, the format of the signal may allow the signal to carry information identifying the address and one or more other items of information (e.g., a read/write flag, a set of Cyclic Redundancy Check (CRC) bits, etc.). In some embodiments, the format of the signal may depend on the capabilities of the ECU210 (e.g., depending on whether the USIC of the ECU210 may be triggered on a hardware interrupt). Additional details regarding possible signal formats are described below with reference to fig. 9A and 9B.

As further shown in fig. 3, the process 300 may include triggering sensor operations associated with the upcoming synchronization signal based on the sampling pattern (block 320). For example, the sensor 205 may trigger sensor operations associated with the upcoming synchronization signal based on the sampling pattern. In some embodiments, sensor operation may include, for example, sampling sensor signals and calculating sensor data based on the sampling of the sensor signals (hereinafter collectively referred to as determining sensor data).

In some implementations, the sensor 205 can trigger sensor operations associated with an upcoming synchronization signal based on an expected time for receiving the upcoming synchronization signal identified based on the sampling pattern. For example, the sensor 205 may store, have access to, or determine an amount of time required for the sensor 205 to perform a sensor operation (e.g., an amount of time required to sample a sensor signal and calculate sensor data). As a particular example, in some implementations, the sensor 205 may determine the amount of time required for the sensor 205 to perform a sensor operation based on averaging the amount of time associated with different cycles of sensor operation performed by the sensor 205. In some implementations, the amount of time required for the sensor 205 to perform the sensor operation may be relatively consistent for each sensor cycle (e.g., such that the sensor 205 may store information identifying the amount of time and reuse the information).

Continuing with the above example, the sensor 205 may determine an expected time for receiving the upcoming synchronization signal based on the sampling pattern. Here, based on the amount of time required for the sensor 205 to perform the sensor operation and the expected time for receiving the upcoming synchronization signal, the sensor 205 may determine an amount of time that the sensor 205 should wait (e.g., a delay time) before triggering performance of the sensor operation associated with the upcoming synchronization signal. In some implementations, the delay time may be an amount of time the sensor 205 is to wait after completing one cycle of sensor operation (e.g., associated with a previously received synchronization signal) before initiating another cycle of sensor operation. In some implementations, the sensor 205 may be configured to determine the delay time such that sensor data associated with the upcoming synchronization signal is ready for transmission at or near (e.g., before) the time at which the sensor 205 expects to receive the upcoming synchronization signal. In some implementations, as indicated in block 315 of fig. 3, the sensor 205 may wait an amount of time identified by the delay time before triggering performance of the sensor operation.

In some implementations, the sensor 205 may be configured to implement time buffering in the delay time (e.g., an additional amount of time) to ensure that sensor data associated with an upcoming synchronization signal is ready to be transmitted before the synchronization signal (e.g., to prevent timing errors, prevent late transmission of sensor data, improve utilization of the bus 215, etc.). In some embodiments, the sensor 205 may be configured to automatically adjust the delay time to ensure that a time buffer is provided, as described below with reference to fig. 5 and 6.

In this manner, the sensor 205 may anticipate the upcoming sensor signal and trigger performance of the sensor operation associated with the upcoming synchronization signal prior to receiving the upcoming synchronization signal.

As further shown in fig. 3, process 300 may include sending sensor data associated with sensor operations after receiving an upcoming synchronization signal (block 325). For example, the sensor 205 may send sensor data associated with the sensor operation after the sensor 205 receives an upcoming synchronization signal (e.g., after the sensor 205 completes performing the sensor operation). In some embodiments, the sensor data may include: information identifying an actual time buffer associated with an upcoming synchronization signal, as described elsewhere herein. In some implementations, the sensor 205 can transmit sensor data associated with an upcoming synchronization signal during a time period that at least partially overlaps (i.e., is concurrent with) a time period during which the sensor 205 waits for another upcoming synchronization signal.

In some embodiments, as indicated in fig. 3, process 300 may be repeated in association with anticipating additional (e.g., later) synchronization signals.

In some embodiments, the plurality of sensors 205 may be configured to: operating in a synchronous mode in which multiple sensors sample their respective sensor signals at approximately the same time. For example, the sensor 205-1 and the sensor 205-2 may each receive a first synchronization signal (e.g., a broadcast signal) provided by the ECU 210. Here, the sensor 205-1 may provide first sensor 205-1 data (e.g., previously determined sensor data) based on the first synchronization signal, and the sensor 205-2 may provide the first sensor 205-2 data (e.g., previously determined sensor data) based on another signal (e.g., a subsequent signal addressed to the sensor 205-2) provided by the ECU 210. Next, both the sensor 205-1 and the sensor 205-2 may receive a second synchronization signal (e.g., a second broadcast signal) provided by the ECU 210. Here, the sensor 205-1 may provide second sensor 205-1 data (e.g., previously determined sensor data) based on the second synchronization signal, and the sensor 205-2 may provide second sensor 205-2 data (e.g., previously determined sensor data) based on another signal (e.g., another subsequent signal addressed to the sensor 205-2).

In this example, as described above, both sensor 205-1 and sensor 205-2 may determine a sampling pattern, and may determine an expected time for receiving an upcoming synchronization signal based on the sampling pattern. Here, based on the expected time for receiving the upcoming synchronization signal, the plurality of sensors 205 may each determine a delay time before triggering performance of the respective sensor operation associated with the upcoming synchronization signal. For example, as described above, each sensor 205 may identify a time to trigger performance of a sensor operation based on an expected time for receiving an upcoming signal and an amount of time required for determining sensor data by the sensor 205. As another example, each sensor 205 may identify a time to trigger performance of a sensor operation based on an expected time for receiving an upcoming signal and synchronization timing information configured on the sensor 205. Here, the synchronization timing information may identify a point in time before the expected time at which the sensor 205 is to trigger performance of the sensor operation (e.g., an amount of time from the expected time to offset triggering of performance of the sensor operation).

In some implementations, the delay times determined by the plurality of sensors 205 may cause sampling of the respective sensor signals associated with determining sensor data for the upcoming sensor signal to be synchronized (i.e., performed at approximately the same time) among the plurality of sensors 205. For example, when the amount of time required to determine sensor data by each sensor 205 matches (e.g., within a threshold amount of time, such as about 1 μ β), the sampling of the respective signals in combination determines that the sensor data for the upcoming sensor signal is synchronized (i.e., performed at approximately the same time) between the sensors 205. As another example, when the same synchronization timing information (e.g., information identifying the same amount of time of a bias trigger) is configured on each sensor 205, sampling of the respective signals in combination with determining sensor data for the upcoming sensor signal may be synchronized between the sensors 205. A detailed example of the synchronization operation is described in detail below in conjunction with fig. 8.

In some embodiments, the synchronization mode may be initiated by the ECU210 using a set of synchronization initiation signals (referred to herein as synchronization initiation signals). For example, the ECU210 may transmit the set of synchronization signals, and the sensor 205 may be configured to begin operating in the synchronization mode based on receiving the set of synchronization signals (i.e., the set of synchronization signals may trigger the synchronization mode operation of the sensor 205). In some embodiments, the set of synchronization signals may include a synchronization initiation interrupt followed by an extended synchronization byte. In some embodiments, the sync initiation interrupt may include a multi-bit (e.g., 13-bit) dominant symbol (e.g., representing a value of 0) indicating that the sensor 205 is to "listen" to the extended sync byte. In some embodiments, the extended synchronization bytes may include bytes (e.g., having a value of 1010101) used to synchronize the sensor 205 with the master clock. In some embodiments, the ECU210 may provide the synchronization signal after providing the set of synchronization start signals. In some embodiments, the ECU210 may initiate the synchronization mode during a startup phase associated with the sensor system. Additionally or alternatively, the ECU210 may initiate the synchronization mode after the startup phase (e.g., if synchronization is lost during operation, the ECU210 may restart the synchronization mode by sending another set of synchronization startup signals).

Although fig. 3 shows example blocks of the process 300, in some implementations, the process 300 may include additional blocks, fewer blocks, different blocks, or blocks arranged differently than those depicted in fig. 3. Additionally or alternatively, two or more of the blocks of the process 300 may be performed in parallel.

Fig. 4 is a schematic diagram of an example implementation 400 associated with the example process 300 shown in fig. 3. For the exemplary embodiment 400, the sensor 205 has identified a sampling pattern that identifies an amount of time between receiving a given pair of synchronization signals provided by the ECU210 based on the previously received synchronization signals.

As shown in the lower portion of the sensor 205 task schedule of fig. 4, the sensor 205 has triggered the performance of a sensor operation (CalcX) associated with the synchronization signal X based on anticipating the receipt of the synchronization signal X according to the sampling pattern. As shown in the ECU210 task schedule, the ECU210 sends a synchronization signal X (syncx) after the sensor 205 has started determining the sensor data X. As represented by the bus 215 communication time, the sensor 205 receives the synchronization signal X via the bus 215.

As further illustrated by the lower portion of the sensor 205 task schedule, the sensor data X is ready before the sensor 205 receives the synchronization signal X. Thus, as represented by the upper portion of the sensor 205 task schedule and the bus 215 communication schedule, the sensor 205 transmits sensor data X immediately after receiving the synchronization signal X (transx). As further shown by the ECU210 task schedule, the ECU210 may be receiving the sensor data X and performing one or more operations associated with the sensor data X (e.g., preprocessing, Field Oriented Control (FOC) calculations, space vector pwm (svpwm), etc.).

As further illustrated by the lower portion of the sensor task schedule, the sensor 205 may anticipate the synchronization signal Y (i.e., the next synchronization signal) based on the sampling interval and may trigger sensor operations associated with the synchronization signal Y (e.g., SampleY and CalcY) prior to receiving the synchronization signal Y. As shown, the sensor 205 may wait a certain amount of time (e.g., a delay time) before triggering a sensor operation associated with the synchronization signal Y so that the sensor data Y is ready to be transmitted before the sensor 205 receives the synchronization signal Y. The sensors 205 and the ECU210 may proceed in a manner similar to that described above in order to allow the ECU210 to receive the sensor data Y and the sensor data Z (e.g., associated with subsequent synchronization signals).

In some implementations, as described below, the sensor 205 may adjust the delay time in order to implement a transmission at a time that ensures that a given item of sensor data associated with an expected synchronization signal is ready to receive the expected synchronization signal at the sensor 205.

As indicated above, fig. 4 is provided as an example only. Other examples are possible and may differ from what is described with respect to fig. 4.

Fig. 5 is a flow diagram of an example process 500 for selectively adjusting a delay time for triggering sensor operations associated with an upcoming synchronization signal. In some implementations, one or more of the process blocks of fig. 5 may be performed by the sensor 205.

As shown in fig. 5, process 500 may include starting a counter when sensor data associated with an upcoming synchronization signal is ready for transmission (block 510). For example, the sensor 205 may start a counter when sensor data associated with an upcoming synchronization signal is ready for transmission.

In some implementations, the sensor 205 may start a counter when the sensor 205 determines sensor data for an upcoming synchronization signal. For example, referring to fig. 4, the sensor 205 may start a counter when the sensor 205 determines sensor data X associated with an upcoming synchronization signal X (e.g., the sensor 205 may start the counter at the end of the CalcX box on the lower portion of the sensor 205 task schedule before the sensor 205 receives the synchronization signal X).

As further shown in fig. 5, process 500 may include stopping a counter upon receiving an upcoming synchronization signal (block 520). For example, the sensor 205 may stop the counter upon receiving an upcoming synchronization signal.

In some implementations, the sensor 205 may stop the counter when the sensor 205 receives an upcoming synchronization signal. For example, referring to fig. 4, the sensor 205 may stop the counter when the sensor 205 receives the synchronization signal X from the ECU210 (e.g., the sensor 205 may stop the counter at the end of the synchronization X frame on the bus 215 communication schedule).

As further shown in fig. 5, process 500 may include determining whether the value of the counter matches the target time buffer (block 530). For example, the sensor 205 may determine whether the value of the counter matches the target time buffer.

The value of the counter represents: an amount of time between a time at which sensor data associated with the synchronization signal is ready for transmission and a time at which the synchronization signal associated with the transmitted sensor data is received. In other words, the value of the counter represents the actual time buffer between the time the determination of the sensor data is completed and the time the sensor data is to be transmitted.

The target time buffer identifies a target time buffer to be implemented by the sensor 205, for example, to ensure that sensor data associated with an upcoming synchronization signal is ready to be transmitted before the synchronization signal (e.g., to prevent timing errors, prevent late transmission of sensor data, improve utilization of the bus 215, etc.). In some implementations, the sensor 205 can store or have access to information identifying the target time buffer (e.g., the target time buffer can be configured on the sensor 205).

In some implementations, the sensor 205 can determine whether the value of the counter (i.e., the actual time buffer) matches the target time buffer based on comparing the value of the counter to the target time buffer. For example, if the sensor 205 determines that the value of the counter differs from (e.g., is less than or greater than) the target time buffer by an amount of time that exceeds a threshold amount (e.g., 0.2 μ s, 0.5 μ s, 2 μ s, etc.), the sensor 205 may determine that the value of the counter does not match the target time buffer. As another example, if the sensor 205 determines that the value of the counter differs from the target time buffer by an amount of time that is less than or equal to a threshold amount, the sensor 205 may determine that the value of the counter matches the target time buffer.

As further shown in fig. 5, process 500 may include selectively adjusting a delay time for triggering sensor operations associated with another synchronization signal based on whether a value of a counter matches a target time buffer (block 540). For example, the sensor 205 may selectively adjust a delay time for triggering sensor operations associated with another synchronization signal based on whether the value of the counter matches the target time buffer.

In some embodiments, selectively adjusting the delay time may include refraining from adjusting the delay time when the value of the counter matches the target time buffer. For example, if the sensor 205 determines that the value of the counter matches the target time buffer, no adjustment to the delay time may be needed (e.g., because the target time buffer is already implemented by the sensor 205).

In some embodiments, selectively adjusting the delay time when the value of the counter does not match the target time buffer may include: the delay time associated with triggering sensor operation for another synchronization signal (e.g., the next synchronization signal) is increased or decreased. For example, if the sensor 205 determines that the value of the counter does not match the target time buffer, and the value of the counter is less than the target time buffer (i.e., the actual time buffer is shorter than the target time buffer by more than a threshold amount), the sensor 205 may adjust the delay time by decreasing the delay time. Here, by reducing the delay time, the sensor 205 causes sensor operations associated with another synchronization signal to be triggered at a relatively earlier time, which results in a relatively longer actual time buffer when the sensor 205 transmits sensor data associated with the other synchronization signal.

As another example, if the sensor 205 determines that the value of the counter does not match the target time buffer, and the value of the counter is greater than the target time buffer (i.e., the actual time buffer is longer than the target time buffer by more than a threshold amount), the sensor 205 may adjust the delay time by increasing the delay time. Here, by increasing the delay time, the sensor 205 causes sensor operations associated with another synchronization signal to be triggered at a relatively later time, which results in a relatively shorter actual time buffer when the sensor 205 transmits sensor data associated with the other synchronization signal.

In some implementations, the sensor 205 can adjust the delay time to match an actual time buffer associated with another synchronization signal to a target time buffer. For example, the amount by which the sensor 205 adjusts the delay time may be an amount of time corresponding to a difference between the calculated actual time buffer and a target time buffer configured on the sensor 205. As another example, the sensor 205 may adjust the delay time by a particular amount (e.g., an increment configured on the sensor 205 that is less than a difference between the calculated actual time buffer and the target time buffer).

In this manner, the sensor 205 may selectively adjust the delay time in order to ensure that sensor data associated with the upcoming synchronization signal is ready for transmission prior to the synchronization signal without introducing an undesirable amount of delay between performance of the sensor operation and transmission of the corresponding sensor data.

In some implementations, the sensor 205 can send information identifying the counter value (e.g., information identifying the length of the actual time buffer). For example, in addition to transmitting sensor data associated with a given synchronization signal, the sensor 205 may transmit information identifying the counter value (e.g., in the same data output frame). In some embodiments, the information identifying the counter value may be used by the ECU210 to improve the accuracy of the sensor system by, for example, reducing delay time jitter.

Although fig. 5 shows example blocks of the process 500, in some implementations, the process 500 may include additional blocks, fewer blocks, different blocks, or blocks arranged differently than those depicted in fig. 5. Additionally or alternatively, two or more of the blocks of process 500 may be performed in parallel.

Fig. 6 is a schematic diagram of an example implementation 600 associated with the example process 500 of fig. 5. In some embodiments, the example embodiment 600 may be implemented in one or more components or devices included in the sensing device 220 described above.

As shown in fig. 6, a component 605 (e.g., a Set Reset (SR) component) can receive an indication 650 indicating that sensor data associated with an upcoming synchronization signal is ready for transmission. As further shown, the output of component 605 is provided to a component 610 (e.g., an and gate) that also receives a clock 655. Here, counter 615 starts based on the output of component 605 in response to indication 650, where counter 615 starts counting based on clock 655.

As further illustrated, component 605 may receive an indication 650 (e.g., at a later time) indicating that an upcoming synchronization signal associated with the sensor data has been received by sensor 205. Here, the output of component 605 changes the output of component 610 in response to indication 660. Here, the counter 615 stops counting based on the changed output of the component 610.

As further shown, after the counter 615 stops, the counter 615 outputs a counter value 665 that identifies the value of the counter 615 at the time the counter 615 stops counting. As shown, the counter 615 may provide a counter value 665 to a component 620 (e.g., a first comparator) and a component 625 (e.g., a second comparator). In this example, component 620 is configured to determine whether the counter value 665 is greater than the target time buffer 670 by more than a threshold amount, and component 625 is configured to determine whether the counter value 665 is less than the target time buffer 670 by more than a threshold amount. As further shown, in some implementations, the counter 615 may provide a counter value 665 for output with the sensor data, as described above.

Continuing the example, if component 620 determines that counter value 665 is greater than target time buffer 670 by more than a threshold amount, component 620 can provide an output to delay component 630 that causes the delay time implemented by delay component 630 in conjunction with sensor operations for another (e.g., next) synchronization signal to be increased (e.g., incremented tDelay + +). Conversely, if component 620 determines that counter value 665 is not greater than target time buffer 670, component 620 may not provide such an output.

Similarly, if component 625 determines that counter value 665 is less than target time buffer 670 by more than a threshold amount, component 625 may provide an output to delay component 630 that causes the delay time to be decreased (e.g., incremented tDelay- -). Conversely, if component 625 determines that counter value 665 is not less than target time buffer 670, component 625 may not provide such an output.

Here, the delay unit 630 causes the sensor 205 to trigger a sensor operation associated with another synchronization signal according to the delay time stored on the delay unit 630. In some embodiments, the above process may be repeated for multiple (e.g., consecutive) cycles as needed to continue adjusting the delay time.

As indicated above, fig. 6 is provided as an example only. Other examples are possible and may differ from what is described with respect to fig. 6.

Fig. 7 is a schematic diagram associated with an example application 700 of the sensor system described herein. As shown in fig. 7, the sensor system described herein may be implemented in a motor control application. For example, in such applications, the ECU may be separate from the motor for the reasons described above. Thus, a sensor (e.g., a shaft end rotor position sensor or a shaft outer rotor position sensor) cannot be embedded in or positioned near the ECU.

In such a case, the sensors may be synchronized with the ECU via a digital interface and, at the same time, achieve an improved sensor update rate (e.g., as compared to conventional synchronization techniques) using the techniques described herein.

As indicated above, fig. 7 is provided as an example only. Other examples are possible and may differ from what is described with respect to fig. 7.

Fig. 8 is a schematic diagram of an example implementation 800 associated with a synchronous mode of operation as described above with reference to the example process 300. As described above, for the exemplary embodiment 800, the sensors 205-1 and 205-2 have received a set of synchronization initiation signals from the ECU210 that are associated with initiating a synchronous mode of operation. Additionally, during a startup phase associated with, for example, starting up the sensor system, the sensor 205-1 has determined first and second data (e.g., identified as n-1 and n, respectively, in FIG. 8 in the sensor task schedule of the first sensor 205-1), and the sensor 205-2 has determined first and second data (e.g., identified as m-1 and m, respectively, in the sensor task schedule of the second sensor 205-2, in FIG. 8).

Also in example 800, address 0 × 000 is configured as a broadcast address and a read address on sensor 205-1, while address 0 × 000 is configured as a broadcast address on sensor 205-2, and address 0 × 001 is configured as a read address on sensor 205-2.

As shown in fig. 8, the ECU210 may first transmit the synchronization signal 1 (e.g., including the address 0 × 000). as further shown, the sensor 205-1 may provide the first sensor data of the sensor 205-1 (e.g., n-1) (e.g., because the address 0 × 000 is the read address of the sensor 205-1) after the sensor 205-1 receives the synchronization signal 1. as further shown, after the first sensor data of the sensor 205-1 is received by the ECU210 or at least transmitted over the bus 215 (e.g., as depicted in fig. 8), the ECU210 may transmit another signal (e.g., the address signal 1 including the address 0 × 001). as shown, the sensor 205-2 may provide the first sensor data of the sensor 205-2 (e.g., m-1) after the sensor 205-2 receives the other signal (e.g., because the address 0 × 001 is the read address of the sensor 205-2).

As further shown, the ECU210 may send the synch signal 2 (e.g., including the address 0 × 000) after the ECU210 receives the first sensor 205-2 data over the bus 215. As shown, the sensor 205-1 may provide the second data of the sensor 205-1 (e.g., n) after the sensor 205-1 receives the synch signal 2 (e.g., because the address 0 × 001 is the read address of the sensor 205-1). As further shown, after the second data of the sensor 205-1 data is received by the ECU210, the ECU210 may send another signal (e.g., the address signal 2 including the address 0 × 001). As shown, the sensor 205-2 may provide the second data of the sensor 205-2 (e.g., m) after the sensor 205-2 receives the other signal (e.g., because the address 0 × 001 is the read address of the sensor 205-2).

In this example, both sensor 205-1 and sensor 205-2 may determine a sampling pattern based on the first and second synchronization signals (e.g., in the manner described above), and may determine an expected time for receiving an upcoming synchronization signal (e.g., synchronization signal 3) based on the sampling pattern. Here, based on the expected time for receiving the upcoming synchronization signal, the sensors 205-1 and 205-2 may determine a delay time before triggering performance of the respective sensor operations associated with the upcoming synchronization signal (e.g., to determine third data of the sensor 205-1 and third data of the sensor 205-2 sensor, which are identified as n +1 and m +1, respectively, in FIG. 8).

In some embodiments, as shown in fig. 8, the delay time (e.g., identified as t in fig. 8)_{S1 Delay}And t_{S2 Delay}) May be determined such that sampling of respective sensor signals associated with performing respective sensor operations is performed at both sensor 205-1 and sensor 205-2 simultaneously. For example, when the amount of time required to determine sensor data by sensor 205-1 matches the amount of time required to determine sensor data by sensor 205-2 (e.g., within a threshold amount of time, such as about 1 μ β), the delay time may be determined such that sampling of the respective sensor signals is performed at approximately the same time. Thus, as further illustrated in FIG. 8, the sensor 205-1 and the sensor 205-2 may trigger performance of respective sensor operations (e.g., associated with determining the third sensor 205-1 data and the third sensor 205-2 data, respectively) based on the delay time.

As further shown, the ECU210 may transmit a synchronization signal 3 (e.g., including an address of 0 × 000) over the bus 215 as shown, the sensor 205-1 may provide third data (e.g., n +1) for the sensor 205-1 after the sensor 205-1 receives the synchronization signal 3 (e.g., because the address of 0 × 000 is the read address of the sensor 205-1). as further shown, after the third data for the sensor 205-1 is received by the ECU210, the ECU210 may transmit another signal (e.g., an address signal 3 including an address of 0 × 001). as shown, the sensor 205-2 may provide third data (e.g., m +1) for the sensor 205-2 after the sensor 205-2 receives the signal (e.g., because the address of 0 × 001 is the read address of the sensor 205-2). in this manner, sampling of the sensor signals may be synchronized between multiple sensors 205 (e.g., such that the sensor data from each sensor 205 has the same time stamp, even though the sensor data is received by the ECU × at different times, the sensor 205 may provide improved control of one or more electrical systems based on the sensor 205 and/or the electrical system.

As indicated above, fig. 8 is provided as an example only. Other examples are possible and may differ from what is described with respect to fig. 8.

Fig. 9A and 9B are schematic diagrams of example formats 900 and 950, respectively, for signals that may be provided by the ECU210 as described herein.

As shown in fig. 9A, in some embodiments, a signal (e.g., a synchronization signal, a signal carrying a particular address, etc.) may be formatted to include a start bit, a set of address bits (e.g., identified in fig. 9A as bits a0 through a7), and a stop bit. Thus, in some embodiments, the signal format may allow the signal to carry only information identifying the address (e.g., a broadcast address associated with multiple sensors 205, an address associated with a particular sensor 205, etc.). In some embodiments, the signal format shown in fig. 9A may be used for time critical transmissions (e.g., synchronization signals) when the components of the ECU210 associated with generating or providing the signals cannot be triggered by hardware signals (i.e., when USIC transmissions cannot be triggered using signals without software interaction inducing delay jitter).

It should be noted that the example format 900 supports a limited number of bit combinations. In some implementations, a pulse corresponding to example format 900 may be interpreted as having one T followed by a stop bit representation_BitHigh time of (n +1) T_BitA single pulse of low time length, wherein the total length of the pulse according to format 900 is constant.

T_BitRepresenting the length of a single bit (e.g., 1/baud rate), and n represents an address. In some embodiments, signals using the relatively simple example format 900 may be generated by a UART transmitter, PWM component, or the like.

In some implementations, the address patterns available when using the example format 900 can be used to read data from the sensors 205. In some implementations, the data download to the sensor 205 may be established by a write access followed by a parameter data type.

As shown in fig. 9B, in some embodiments, the signal may be formatted to include a start bit, a read/write bit (e.g., identified in fig. 9B as a directory (dir) bit), a set of address bits (e.g., identified in fig. 9B as bits a0 through A3), a set of CRC bits (e.g., identified in fig. 9B as bits CRC0 through CRC2), and a stop bit. In some embodiments, the signal format shown in fig. 9B may be used for time critical transmissions (e.g., synchronization signals) when the components of the ECU210 associated with generating or providing the signals can be triggered by hardware signals (i.e., when USIC transmissions are triggerable).

As indicated above, fig. 9A and 9B are provided as examples only. Other examples are possible and may differ from what is described with respect to fig. 9A and 9B.

IN some embodiments, the high-speed sensor interface described above may use a bus system having a physical layer defined by a particular bus system standard, for example, the high-speed sensor interface may use a local interconnect network (L IN) 3-wire interface designed to provide a data transfer rate of between 1 and 20 kilobits per second (kBit/s) as described by ISO standard 17987 As another example, the high-speed sensor interface may use a fault-tolerant Controller Area Network (CAN) bus designed to provide a data transfer rate of 125kBit/s as described by ISO standard 11898-3 As another example, the high-speed sensor interface may use a CAN bus designed to provide a data transfer rate of up to 1 megabits per second (MBit/s) as described by ISO standard 11898-2 as another example, the high-speed sensor interface may use a Raxit bus designed to provide a data transfer rate of up to 5MBit/s as described by ISO standard 11898-5 as another example, the high-speed sensor interface may use a Raxit bus designed to provide data transfer rate of up to 5MBit/s as described by ISO standard 744-10.

Additionally or alternatively, the high speed sensor interface described above may provide one or more other capabilities associated with a given bus system standard (e.g., L IN, CAN (ISO 11898-5), FlexRay, etc.).

In some embodiments, the wake-up signal may cause each sensor 205 and/or ECU210 to wake-up (e.g., when each sensor 205 and ECU210 are configured to wake-up based on detecting the same format of signal). In other words, in some embodiments, the wake-up capability may not be a selectable wake-up capability. Additionally or alternatively, the wake-up signal may cause a particular sensor 205 and/or ECU210 to wake up (e.g., when the sensor 205 and ECU210 are configured to wake up based on detecting a differently formatted signal). In other words, in some embodiments, the wake-up capability may be a selectable wake-up capability (e.g., as described by ISO 11898-6 for CAN buses).

In either case, when a signal having a suitable format is detected, the sensor 205 on the bus 215 and/or the second ECU210 may wake up from the sleep mode and begin operation. In some embodiments, the wake-up capability is advantageous in that a given sensor 205 and/or ECU210 may begin operation immediately (e.g., as compared to beginning operation after being powered down). Another advantage is that the number of pins used on a given ECU210 may be reduced (e.g., because the wake-capable sensor 205 need not be supplied by the ECU210, because the wake-capable ECU210 does not need a sensor supply pin). Additionally, the wake-up capability may reduce the amount of current consumed by a given sensor 205 and/or ECU210 in a sleep mode and/or may increase the lifetime of a given sensor 205 and/or ECU 210.

As another example, a high speed sensor interface may utilize a plurality of ECUs to provide listen-only capabilities IN a sensor system (e.g., according to a bus system standard such as L IN, CAN (ISO 11898-6), FlexRay, etc.) FIG. 10 is a schematic of an example environment 1000 including a listen-only ECU, as shown IN FIG. 10, IN some embodiments, the listen-only ECU may be connected to the bus 215 (e.g., IN addition to the ECU 210). As such, IN some embodiments, the listen-only ECU may be configured to "listen" for transmissions on the bus 215 and may be configured to refrain from sending transmissions on the bus 215. accordingly, IN some embodiments, the listen-only ECU may be able to receive sensor data (e.g., provided by the sensor 205 based on a signal provided by the ECU 210) without sending any signal on the bus 215.

In some embodiments, only listening can provide a functional safety feature in the sensor system. For example, the listen-only ECU may provide functional safety features in reducing the latency associated with receiving sensor data (as described above) at the listen-only ECU (e.g., so that time-critical information may be received in real-time or near real-time). As another example, the listen-only ECU may provide a functional safety feature by acting as a backup or fail-over in the event that the ECU210 experiences an error, is disabled, loses power, or the like. As another example, the listen-only ECU may provide a functional safety feature by monitoring the operation of the sensors 205 and/or the ECU210 in the sensor system.

Some embodiments described herein provide techniques directed to an apparatus for synchronizing a sensor (e.g., a remote sensor) with an ECU via a digital interface while achieving an improved sensor update rate (e.g., as compared to conventional synchronization techniques described above). In some embodiments, such improved synchronization may be achieved by configuring the sensors based on a triggering technique for anticipating self-adjustment of an upcoming synchronization signal, as described in further detail below.

The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the embodiments to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the embodiments.

Some embodiments are described herein in connection with a threshold. As used herein, meeting a threshold may refer to a value that is greater than the threshold, exceeds the threshold, is above the threshold, is greater than or equal to the threshold, is less than or equal to the threshold, is equal to the threshold, and so forth.

Even if specific combinations of features are recited in the claims and/or disclosed in the description, these combinations are not intended to limit the disclosure of possible embodiments. Indeed, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification. Although each dependent claim listed below may be directly dependent on only one claim, the disclosure of possible embodiments includes the combination of each dependent claim with all other claims in the claim set.

No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Further, as used herein, the words "a" and "an" are intended to include one or more items, and may be used interchangeably with "one or more. In addition, as used herein, the term "set" is intended to include one or more items (e.g., related items, unrelated items, combinations of related and unrelated items, etc.) and may be used interchangeably with "one or more". Where only one item is intended, the term "one" or similar language is used. Furthermore, as used herein, the terms "having," "containing," "including," and the like are intended to be open-ended terms. Additionally, the word "based on" is intended to mean "based, at least in part, on" unless explicitly stated otherwise.

Claims

1. A system for synchronization, comprising:

a first sensor to:

determining an expected time for receiving an upcoming synchronization signal based on two or more synchronization signals provided by a control device; and is

Performing a measurement of a first sensor signal at a point in time such that sensor data corresponding to the measurement of the first sensor signal at the point in time is available for a first selectable period of time prior to receiving the upcoming synchronization signal; and

a second sensor to:

determining the expected time for receiving the upcoming synchronization signal based on the two or more synchronization signals provided by the control device; and is

Performing a measurement of a second sensor signal at the point in time such that sensor data corresponding to the measurement of the second sensor signal at the point in time is available for a second selectable time period.

2. The system of claim 1, wherein the first sensor is further to:

performing another measurement of the first sensor signal based on a synchronization signal provided by the control device; and is

Calculating sensor data corresponding to the another measurement of the first sensor signal.

3. The system of claim 1, wherein a length of the first selectable time period is less than or equal to a length of a synchronization period defined by the two or more synchronization signals.

4. The system of claim 1, wherein a length of the first selectable time period is controlled based on a point in time at which the upcoming synchronization signal is received.

5. The system of claim 1, wherein the first sensor is further to:

receiving the upcoming synchronization signal; and is

Transmitting the sensor data corresponding to the measurement of the first sensor signal at the point in time in response to receiving the upcoming synchronization signal.

6. The system of claim 1, wherein the second sensor is further to:

performing another measurement of the second sensor signal based on a signal provided by the control device; and is

Calculating sensor data corresponding to the another measurement of the second sensor signal.

7. The system of claim 1, wherein a length of the second selectable time period is less than or equal to a length of a synchronization period defined by the two or more synchronization signals.

8. The system of claim 1, wherein a length of the second selectable time period is controlled based on a point in time at which the upcoming synchronization signal is received.

9. The system of claim 1, wherein the length of the second selectable time period matches the length of the first selectable time period.

10. The system of claim 1, wherein the read address of the first sensor matches a broadcast address associated with the first sensor and the second sensor.

11. The system of claim 1, wherein the second sensor is further to:

receiving a signal including information identifying a read address of the second sensor; and is

In response to receiving the signal including the information identifying the read address of the second sensor, sending the sensor data corresponding to the measurement of the second sensor signal at the point in time.

12. The system of claim 11, wherein the read address of the second sensor is different from broadcast addresses associated with the first sensor and the second sensor.

13. The system of claim 1, wherein the first sensor or the second sensor, in determining the projected time for receiving the upcoming synchronization, is to:

determining the expected time based on a time difference between a time of receiving the first synchronization signal and a time of receiving the second synchronization signal,

wherein the first synchronization signal and the second synchronization signal are included in the two or more synchronization signals.

14. The system of claim 1, wherein a synchronization signal of the two or more synchronization signals includes only information identifying broadcast addresses associated with the first sensor and the second sensor.

15. The system of claim 1, wherein a synchronization signal of the two or more synchronization signals comprises information identifying a broadcast address associated with the first sensor and the second sensor, read/write bits, and a set of Cyclic Redundancy Check (CRC) bits.

16. The system of claim 1, wherein the physical layer of the system comprises a local interconnect network (L IN) bus, a Controller Area Network (CAN) bus system, or a FlexRay bus.

17. The system of claim 1, further comprising a listen-only control device for receiving the sensor data.

18. A control device, comprising:

one or more components to:

providing a set of synchronization signals to a set of sensors, wherein the set of synchronization signals defines a sampling pattern for identifying an expected time associated with another synchronization signal;

providing the further synchronization signal; and is

Receiving first sensor data from a first sensor of the set of sensors after providing the other synchronization signal, wherein the first sensor data is available at the first sensor before the other synchronization signal is received by the first sensor based on the sampling pattern, wherein the one or more components are further to:

providing another signal; and is

Receiving second sensor data from a second sensor of the set of sensors after providing the signal,

wherein a sampling time associated with the second sensor data matches a sampling time associated with the first sensor data, and

wherein the first sensor data and the second sensor data are received at different times.

19. The control device of claim 18, wherein the read address of the first sensor matches a broadcast address associated with the first sensor and the second sensor.

20. The control device of claim 18, wherein a read address of the second sensor is different from a broadcast address associated with the first sensor and the second sensor.