Bus communication methods and bus master devices

Abstract

This application relates to a bus communication method and a bus master device that allows for rapid reinitialization of sensor devices, minimizing interruption time associated with unexpected device resets. An exemplary bus communication method includes: providing a dynamically determined bus address for each of one or more slave devices; querying each of the dynamically determined bus addresses to obtain a unique device identifier associated with that dynamically determined bus address; receiving a sequence of data frames from the one or more slave devices, each data frame having time-division multiplexed data; and checking between the data frames in the sequence to determine whether any of the one or more slave devices has been reset.

Description

Technical Field

[0001] This disclosure relates to digital communication bus management, and more specifically to techniques and controllers that can provide rapid reinitialization of devices that have been accidentally reset on a shared bus. Background Technology

[0002] Current and future vehicles are increasingly incorporating more and more onboard sensors and systems to enable or assist critical vehicle functions, including adaptive cruise control (AAC), parking assist, forward collision warning (FCW), forward collision and automatic emergency braking, blind spot warning (BSW), lane keeping assist (LKS), and more. These technologies provide direct drive assistance in normal driving and critical situations, and some technologies can even enhance drive control or provide autonomous control to prevent or mitigate collisions or adverse consequences.

[0003] To accommodate the numerous sensors, actuators, and control systems used for such features, manufacturers are implementing increasingly sophisticated data communication networks in every vehicle. The Generation 3 Distributed System Interface (DSI3) standard, released by the DSI Consortium (dsiconsortium.org), provides an example of such a communication network. The entire contents of DSI3 bus standard revision 1.0, released on February 16, 2011, are incorporated herein by reference.

[0004] DSI3 and other communication standards must address a unique set of situations that challenge their performance. These networks are portable, battery-powered (i.e., low-voltage), with wires long enough to cause (and be susceptible to) electromagnetic interference (EMI). These networks should be resistant to vibration, yet remain inexpensive and easy to maintain. The DSI3 standard was developed to offer several desired features, including single-conductor communication with optional integrated power delivery. However, safety standards being developed to certify systems operating in automotive environments challenge the ability of existing sensors and systems to rely on DSI3 and similar communication standards. Summary of the Invention

[0005] Therefore, this paper discloses a host device and bus communication method that allows for rapid reinitialization of sensor devices, minimizing the interruption time associated with unexpected device resets.

[0006] According to one aspect of this application, a bus communication method is provided, characterized in that the bus communication method includes: providing a dynamically determined bus address for each of one or more slave devices; querying each dynamically determined bus address to obtain a unique device identifier associated with the dynamically determined bus address; receiving a sequence of data frames from the one or more slave devices, each data frame having time-division multiplexed data; and checking between the data frames in the sequence to determine whether any of the one or more slave devices has been reset.

[0007] In one implementation, the bus communication method is characterized in that the check includes attempting to retrieve a unique device identifier from the default bus address.

[0008] In one embodiment, the bus communication method is characterized in that it further includes: receiving a unique device identifier of the reset slave device in response to the attempt; determining a dynamically determined bus address previously associated with the unique device identifier of the reset slave device; and configuring the reset slave device with the dynamically determined bus address previously associated with it.

[0009] In one implementation, the bus communication method is characterized in that the configuration includes writing register data to a default bus address.

[0010] In one implementation, the bus communication method is characterized in that when the check causes a timeout, the next data frame in the sequence is initiated.

[0011] According to another aspect of this application, a bus master device is provided, characterized in that the bus master device comprises: a driver configured to drive a downlink signal on a bus signal line; a receive buffer configured to sense an uplink signal on the bus signal line; and a controller coupled to the driver and the receive buffer, the controller being configured to implement a communication method via the bus signal line. The method includes: providing a dynamically determined bus address for each of one or more slave devices; querying each dynamically determined bus address to obtain a unique device identifier associated with the dynamically determined bus address; receiving a sequence of data frames from the one or more slave devices, each data frame having time-division multiplexed data; and checking between the data frames in the sequence to determine whether any of the one or more slave devices has been reset.

[0012] In one implementation, the bus master device is characterized in that the check includes attempting to retrieve a unique device identifier from the default bus address.

[0013] In one embodiment, the bus master device is characterized in that the communication method further includes: in response to the attempt, receiving a unique device identifier of the reset slave device; determining a dynamically determined bus address previously associated with the unique device identifier of the reset slave device; and configuring the reset slave device with the dynamically determined bus address previously associated with it.

[0014] In one embodiment, the bus master device is characterized in that the communication method further includes writing additional configuration data to a previously associated, dynamically determined bus address after the configuration and before receiving subsequent data frames in the sequence.

[0015] In one implementation, the bus master is characterized in that when the check causes a timeout, the controller initiates the next data frame in the sequence. Attached Figure Description

[0016] Figure 1A Here is a block diagram illustrating a data communication network.

[0017] Figure 1B A schematic model of an exemplary daisy-chain arrangement of sensors on the DSI3 bus.

[0018] Figure 2A A block diagram of an exemplary slave device used in the DSI3 bus.

[0019] Figure 2B This is a block diagram of an exemplary master device used in the DSI3 bus.

[0020] Figure 3 A flowchart illustrating an exemplary sensing method for quickly reinitializing from a device.

[0021] Figure 4 An exemplary lookup table that associates each sensor ID with a device-level traceability code. Detailed Implementation

[0022] The accompanying drawings and the following description illustrate specific embodiments and details for illustrative purposes, but it should be understood that the drawings and corresponding specific embodiments do not limit this disclosure. Rather, they provide the basic content that, together with the understanding of those skilled in the art, discloses and implements all modifications, equivalents, and alternatives falling within the scope of the appended claims.

[0023] Figure 1AAn electronic control unit (ECU) 102 is shown, which is coupled via a sensor bus controller 106 to various ultrasonic sensors 104, a radar array controller 108, a lidar sensor 110, and a set of actuators (such as a throttle actuator 112, a brake actuator 114, a steering actuator 116, and a steering signal actuator 118). The ECU 102 may be further coupled to a user interactive interface 120 to accept user input and provide displays of various measurement results and system status.

[0024] Various sensors emit ultrasonic pulses, electromagnetic waves, and coherent beams; receive corresponding reflections to measure reflector distances; and collect measurement results to determine the spatial relationship between the vehicle and its surrounding environment. ECU 102 can use these measurement results, along with internal measurements of vehicle orientation and motion, to provide automatic parking, assisted parking, lane change assist, obstacle and blind spot detection, autonomous driving, and other desired features.

[0025] Various standards exist to support communication between ECU 102 and various sensors and actuators. Of particular interest with respect to this disclosure is the Generation 3 Distributed System Interface (DSI3) bus standard, which provides half-duplex, single-ended signal communication between a bus master device (typically an ECU) and one or more slave devices (e.g., sensors and actuators). Because the DSI3 bus requires only one signal conductor, it is sometimes referred to as a “single-wire” bus.

[0026] Figure 1B This is a schematic model of a daisy-chain arrangement. As described in section 6.3.3 of the DSI3 standard, the bus enters discovery mode shortly after power-on to perform an iterative address allocation process. This process assigns a unique address to each device corresponding to its position in the daisy chain, allowing slave devices to avoid bus conflicts when responding to the bus master. When discovery mode is complete, slave devices use these addresses to determine the time slots they will use to transmit responses (such as measurement results) within a time-division multiplexed frame.

[0027] Figure 2A This is a block diagram of an exemplary slave device 200 applicable to the standard DSI3 bus. While maintaining physical compatibility with the DSI3 standard, the exemplary device 200 may include certain features for enhancing system performance, at least some of which extend the standard in a manner that may require firmware adjustments on the bus master device, as further described below.

[0028] Slave device 200 includes a controller 202 that collects measurement results and buffers relevant messages in memory 204 for transmitting measurement data to the bus master device. While message lengths can vary, in at least one envisioned embodiment, each message is 16 bytes long and may begin with or be preceded by a preamble of one or two 0.5 bytes. An optional scrambler 206 uses a bitwise XOR operation to mask each message with a pseudo-random binary sequence to randomize or “whiten” any repeating data patterns. If a preamble is present, it is not masked to preserve the preamble pattern in the scrambler's output bitstream. The seed of the pseudo-random sequence can be changed for each message and for each slave device.

[0029] The channel encoder 208 encodes the bitstream from the scrambler 206 by mapping each nibble to a corresponding triplet of a channel symbol. Each triplet comprises three ternary channel symbols. Channel symbols, also referred to herein as “chips,” are transmitted as one of three unipolar non-return-to-zero levels 0, 1, or 2, each symbol having a fixed symbol duration of approximately 3 or 4 microseconds. As specified in the standard, “0” corresponds to the quiescent channel signal current I. Q "1" can correspond to the response channel signal current I. Q +I RESP And "2" can correspond to the response channel signal current I. Q +2I RESP In at least some implementations, I Q Limited to no more than 2mA, and I RESP The current is approximately 12mA. Some envisioned implementations could switch from three-level signaling to two-level signaling to improve noise immunity. In such implementations, the channel encoder 208 maps 8-bit bytes to 8-bit codewords, using only I in this case. Q Current level and I Q +2I RESP Current level.

[0030] An optional pulse shaping filter 210 operates on the channel symbol stream from encoder 208 to provide a transfer function that converts rectangular pulses (e.g., NRZ chips) into a smoother pulse shape, which provides more desirable spectral characteristics for the channel signal. A digital-to-analog converter 212 operates on the filtered channel signal to convert it from digital to analog form, which may be referred to herein as the uplink channel signal. An optional transmit correction filter 214 operates on the uplink channel signal to limit signal energy to one or more frequency ranges where EMI emissions are restricted.

[0031] Channel driver 216 converts the uplink channel signal into current on the input / output pins of device 200. A low-pass RC filter (capacitor C3, resistor R3) couples the input / output pins to the signal conductors of the DSI3 bus.

[0032] The current bias of the input / output pins can be provided by the current sink 218 and the receive buffer 220. During the forward (downlink) and reverse (uplink) communication phases of the half-duplex DSI3 communication protocol, the controller 202 adjusts the current sink 218 for biasing as needed. During the downlink communication phase, the input / output pins receive the downlink channel signal in the form of a voltage signal. The receive buffer 220 provides a high input impedance to the input / output pins, thereby buffering the downlink channel signal used by the analog-to-digital converter 224.

[0033] Downlink receive filter 225 limits the bandwidth of the digital received signal and / or enhances the signal-to-noise ratio of the downlink signal. In at least some embodiments, filter 225 is used to suppress noise above 300 kHz. In system embodiments where the master device employs a transmit correction filter (similar to filter 214 described above), downlink receive filter 225 may include a compensation function to boost the downlink signal frequency up to 150 kHz and then roll it off to suppress noise at signal frequencies above approximately 250 or 300 kHz. Symbol detector and decoder 226 operates on the filtered received signal to determine the command type and associated payload, thereby placing the information in a receive buffer for use by controller 202 in formulating a response.

[0034] Figure 2B This is a block diagram of an exemplary bus master device 240 applicable to the standard DSI3 bus. Like the slave device 200, the master device 240 maintains physical compatibility with the DSI3 standard, but may include certain features to enhance system performance when used in conjunction with compatible slave devices.

[0035] Master device 240 includes controller 242, which stores downlink messages in memory 244 for transmission to one or more slave devices. Channel encoder 246 encodes the binary downlink messages by mapping bits 0 and 1 to up and down channel voltage transitions provided by, for example, Manchester-1 encoding. Digital-to-analog converter 248 converts the encoded signal into an analog downlink signal. Driver 249 supplies the analog downlink signal as a voltage signal to the input / output pins of master device 240. Although the DSI3 standard provides a 2-volt swing between the "high" and "low" symbol voltages, some envisioned implementations employ a 4-volt swing to enhance noise immunity. Low-pass RC filters (capacitor C1, resistor R1) couple the input / output pins to the signal conductors of the DSI3 bus.

[0036] A high-impedance receive buffer 250 couples the uplink signal from the input / output pin to an optional receive correction filter 251. The optional receive correction filter 251 can, for example, boost the high-frequency content of the uplink signal to compensate for the operation of the transmit correction filter 214. An analog-to-digital converter 252 digitizes the uplink signal, and an uplink receive filter 253 operates on the digital signal to limit the signal bandwidth and / or enhance the signal-to-noise ratio. Filter 253 can be a matched filter having a filter response at least in part based on the pulse shape provided by the optional pulse shaping filter 210. Filters 251 and 253 can be reordered, combined into a single filter, and each implemented in digital or analog form.

[0037] Chip detector 254 operates on the filtered uplink signal to detect channel symbol levels. Threshold capture unit 255 can capture and / or adapt the comparator threshold level of chip detector 254 based at least in part on the message preamble. Decoder 256 operates on the channel symbol sequence from chip detector 254 to reverse the operation of encoder 208 to map chip triples to binary nibbles. Optional descrambler 257 operates on the bitstream from decoder 256 to reverse the operation of scrambler 206 to extract message data sent by slave device. Message data can be stored in memory 244 for analysis and use by controller 242.

[0038] Safety standards being developed for Advanced Driver Assistance Systems (ADAS) include challenging requirements for tolerance of electrostatic discharge (ESD) events within sensors or other components of the system. As an example of such an event, a passenger touching a side mirror could trigger an ESD event affecting the blind spot detection sensor located within that mirror. At the specified ESD event voltage used for testing, it has been determined that the sensor can be reset by voltage transients. Such a reset causes the sensor to forget any measurement configuration information and the unique address it was assigned during the detection process.

[0039] In the event of this information loss, the sensors cease responding to measurement requests from the ECU or bus master, potentially creating blind spots within the ECU's spatial awareness. Once multiple measurement cycles have occurred without a response from a given sensor, the ECU can immediately initiate a sensor bus reset, or even a complete system reset, in an attempt to correct the problem. A bus reset or system reset results in a substantial interruption of measurement acquisition, which is highly undesirable.

[0040] This disclosure attempts to prevent such substantial interruptions in measurement acquisition by using a process of detecting the occurrence of a sensor reset and recovering information that has been lost from the reset sensor device, doing so for a duration less than a measurement cycle (e.g., about 50 milliseconds) to prevent more than two measurement cycles from passing without a response from the reset sensor.

[0041] Figure 3 The flowchart illustrates an exemplary sensing method. Upon power-up (box 301), registers are reset in each sensor device operating on the DSI3 bus as a slave device, causing its sensor ID (“SID”, also known as the bus address) to default to 0x0. (The “0x” prefix indicates the use of hexadecimal notation.) Boxes 302 and 303 represent an exemplary discovery process, in which the ECU and / or bus master periodically send discovery commands, causing the sensor to iteratively determine its corresponding position in the daisy chain (and correspondingly, its bus address) through a sequence of current ramp changes and sensing operations conforming to the DSI3 bus standard or its variants. In box 303, the ECU and / or bus master terminate the discovery process only after the number of cycles exceeds the expected number of sensors on the bus.

[0042] Variants of the DSI3 standard can employ an alternative discovery process to provide a dynamically determined bus address for each slave device. For example, a single discovery command can initiate a multi-stage discovery process with current ramping corresponding to the number of connected sensors. Unaddressed sensors remain initiating subsequent current ramping stages until each sensor has met the requirement to obtain an address. In all cases, the discovery process ensures that each sensor device has a unique bus address in the range 0x1 to 0xE (typically supporting approximately six sensors, 0x1-0x6). Address 0xF is used for broadcast messages, and address 0x0 is the default address upon reset.

[0043] In box 304, the ECU and / or bus master query each dynamically determined bus address from the dynamically determined bus addresses to obtain a unique identifier associated with that bus address. The appropriate unique identifier will be the Device Level Traceability (DLT) code for each sensor. The ECU and / or bus master populate a lookup table such as... Figure 4 The lookup table shown associates each dynamically assigned bus address or sensor ID with a unique identifier obtained from that bus address. In block 306, the ECU and / or bus master sends commands to configure the sensor device for the desired measurement (e.g., configuring a selected sensor for both transmitting and receiving while configuring other sensors for receiving only, assigning different channels to different sensors, setting measurement ranges). The sensor device can be reconfigured before each measurement cycle, or optionally, multiple measurements can be acquired for a given configuration.

[0044] In block 308, the ECU and / or bus master triggers sensor measurements, and in block 310, the measurement results from the sensors are collected, for example, by using a broadcast read command to operate the DSI3 bus in a periodic data collection mode (a mode in which each slave device sends its data during an allocated time slot within a time-division multiplexed data frame). In block 312, the measurement results are transmitted to the ECU for use by ADAS (or for any features being provided).

[0045] Before executing a subsequent measurement cycle (box 314) that generates its own time-division multiplexed data frame, the ECU and / or bus master check whether any of the slave devices has been reset. In at least some implementations, this is done by querying the default sensor ID (0x0) for its unique identifier, for example, by operating the DSI3 bus in command and response mode to request a DLT code from the default bus address 0x0. If no sensor reset has occurred, there should be no response to this read command, resulting in a rapid timeout of the request (e.g., less than 2 ms). On the other hand, if a sensor reset has occurred, the reset sensor should respond to the read command, providing its unique identifier. (In case multiple sensors have been reset, their responses will conflict, resulting in a CRC error in the response, which can be interpreted as an indication that a full bus reset is required.)

[0046] In block 316, the ECU and / or bus master determines whether a response has been received. If not, the next measurement cycle begins in block 306 or 308. Otherwise, in block 318, the ECU and / or bus master searches a lookup table for a unique identifier to determine the dynamically determined bus address previously associated with that unique identifier. Once the correct sensor ID is determined, the ECU and / or bus master sends a block write command to the default sensor ID 0x0 to reconfigure the reset sensor with the lost configuration information and the lost bus address. Alternatively, a first write command can be used to provide the reset sensor with its previously assigned sensor ID, and subsequent write commands to that sensor ID can be used to properly reconfigure the sensor. The next measurement cycle can then be initiated in block 306 or 308.

[0047] Boxes 314 through 318 are expected to complete less than one measurement cycle (e.g., less than 50 ms) to make the sensor fully operable for the next measurement cycle. Even if more time is required, the process can still prevent a system-level reset based on the number of lost measurements required to trigger such a reset.

[0048] In the alternative sensing method, box 314 is omitted. In box 316, a reset is detected if the broadcast read command in box 310 does not elicit a response from one of the sensors. In this case, box 318 is executed to send appropriate configuration information (including the correct bus address) to the sensor with the default bus address.

[0049] In summary, various methods and devices have been disclosed. One exemplary bus communication method includes: providing a dynamically determined bus address for each of one or more slave devices; querying each dynamically determined bus address to obtain a unique device identifier associated with that dynamically determined bus address; receiving a sequence of data frames from the one or more slave devices, each data frame having time-division multiplexed data; and checking between the data frames in the sequence to determine whether any of the one or more slave devices has been reset.

[0050] An exemplary bus master device includes: a driver that drives a downlink signal on a bus signal line; a receive buffer that senses an uplink signal on the bus signal line; and a controller coupled to the driver and the receive buffer to implement the aforementioned communication method via the bus signal line.

[0051] Another exemplary communication method includes: creating a lookup table that associates each dynamically assigned sensor ID with a device-level traceability (DLT) code; querying the DLT code from the default sensor ID before initiating a measurement cycle; and continuing the measurement cycle if the query times out before receiving a response.

[0052] Each of the foregoing devices and methods may be employed individually or in combination, and they may also employ one or more of the following optional features in any suitable combination: 1. The check includes attempting to retrieve a unique device identifier from a default bus address. 2. In response to the attempt, receiving a unique device identifier for the reset slave device. 3. Determining a dynamically determined bus address previously associated with the unique device identifier of the reset slave device, and configuring the reset slave device with its previously associated dynamically determined bus address. 4. The configuration includes writing register data to the default bus address. 5. The register data includes additional configuration data for resetting the slave device. 6. After the configuration and before receiving subsequent data frames in the sequence, writing the additional configuration data to the previously associated dynamically determined bus address. 7. When the check causes a timeout, initiating the next data frame in the sequence. 8. If a response to a query is received, using a lookup table to look up the reset sensor ID associated with the DLT code received in the response to the query, and sending reconfiguration information associated with the reset sensor ID to the default sensor ID, the reconfiguration information including at least the reset sensor ID. 9. After sending the reconfiguration information and before continuing the measurement cycle, send one or more measurement configuration parameters to the reset sensor ID.

[0053] Once the foregoing disclosure is fully understood, many modifications, equivalents, and alternatives will become apparent to those skilled in the art. For example, exemplary methods are shown and described as occurring sequentially, but those skilled in the art will recognize that many operations can be reordered, pipelined, or otherwise performed in parallel, potentially using multiple independent or loosely coupled hardware components. It is intended that the following claims be construed as including all such modifications, equivalents, and alternatives where applicable.

Claims

1. A bus communication method comprising: providing each of one or more slave devices with a dynamically determined bus address; inquiring each of the dynamically determined bus addresses to obtain, for each of the dynamically determined bus addresses, an associated unique device identifier; receiving a sequence of data frames from the one or more slave devices, the data frames each having time division multiplexed data; and between data frames in the sequence, checking by attempting retrieval of a unique device identifier from a default bus address to determine if any of the one or more slave devices has been reset, wherein the default bus address is a bus address resulting from a reset register in each of the one or more slave devices upon power up.

2. The bus communication method of claim 1, further comprising: in response to the attempting, receiving a unique device identifier of a reset slave device.

3. The bus communication method of claim 2, further comprising: determining a dynamically determined bus address previously associated with the unique device identifier of the reset slave device; and configuring the reset slave device with the previously associated dynamically determined bus address of the reset slave device. the configuring includes writing register data to the default bus address. the register data includes additional configuration data for the reset slave device.

4. The bus communication method according to claim 3, wherein, writing the additional configuration data to the previously associated dynamically determined bus address after the configuring and prior to receiving a subsequent data frame in the sequence.

5. The bus communication method according to claim 4, wherein, initiating a next data frame in the sequence when the checking causes a timeout.

6. The bus communication method according to claim 4, wherein, the unique device identifier is a device level traceability DLT code.

7. The bus communication method according to claim 1, wherein, 9. A bus master device comprising:

8. The bus communication method according to claim 1, wherein, a driver configured to drive a downlink signal on a bus signal line; a receive buffer configured to sense an uplink signal on the bus signal line; a controller coupled to the driver and the receive buffer, the controller configured to implement a communication method via the bus signal line, the method comprising: providing each of one or more slave devices with a dynamically determined bus address; inquiring each of the dynamically determined bus addresses to obtain, for each of the dynamically determined bus addresses, an associated unique device identifier; receiving a sequence of data frames from the one or more slave devices, the data frames each having time division multiplexed data; and between data frames in the sequence, checking by attempting retrieval of a unique device identifier from a default bus address to determine if any of the one or more slave devices has been reset, wherein the default bus address is a bus address resulting from a reset register in each of the one or more slave devices upon power up. the communication method further comprising: in response to the attempting, receiving a unique device identifier of a reset slave device.

10. The bus master of claim 9, wherein, the communication method further comprising: determining a dynamically determined bus address previously associated with the unique device identifier of the reset slave device; and 11. The bus master of claim 10, wherein, ​ ​ configuring the reset slave device with the dynamically determined bus address of the previous association of the reset slave device with the default bus address.

12. The bus master of claim 11, wherein, The configuring includes writing register data to the default bus address.

13. The bus master of claim 12, wherein, The register data includes additional configuration data for the reset slave device.

14. The bus master of claim 12, wherein, The communication method further includes, after the configuring and before receiving a subsequent data frame in the sequence, writing additional configuration data to the previously associated dynamically determined bus address.

15. The bus master of claim 9, wherein, When the checking results in a timeout, initiating a next data frame in the sequence.

16. The bus master of claim 9, wherein, The unique device identifier is a device-level traceability DLT code.

Images