JP2019176474A - Communication method, corresponding system, device, signal and vehicle - Google Patents

Abstract

To achieve cost-effective high data rate vehicle networks.SOLUTION: A method includes: coupling a first device 10 and a set of second devices 20 via a bus 30 on board of a vehicle V; configuring the first device as a master device to transmit over the bus first messages carrying operation data message portions for execution by a second device 20i and second messages addressed to the second device, the second messages conveying identifiers of the second devices requesting respective reactions toward the first device within respective expected reaction intervals; and configuring the second devices as slave devices to receive over the bus the first messages transmitted from the master device, read respective operation data message portions and execute respective operations as a function of the respective message portions, and to receive over the bus the second messages transmitted from the first device that is configured as the master device and react on the second messages within the respective expected reaction intervals by transmitting over the bus reaction messages toward the master device.SELECTED DRAWING: Figure 1

Description

  The present invention relates to bus support communication for use in, for example, automotive applications.

  For example, one or more embodiments may be provided between an electronic control unit (ECU) of a vehicle light (eg, front light, rear light, interior light) and a corresponding lighting module (eg, LED light module). It can be applied to communication.

  For example, various applications in the automotive field involve the exchange of data over one or more bus networks. High data rate, robustness, defect detection, safety, and low cost are desirable features for such applications.

  Existing high data rate (eg, 1 Mb / s) standardized vehicle communication systems may involve complex and accurate protocol controllers that use external components. These can be expensive, especially when implemented as single chip analog / bipolar application specific integrated circuits (ASICs) and / or application specific standard products (ASSPs).

  Vehicle lights (e.g. front lights, rear lights, interior lights) are becoming increasingly sophisticated and distributed (e.g. matrix LEDs, ambient LEDs). Controlling such sophisticated and distributed systems may involve high data rate control. Furthermore, automotive grade safety and robustness are desirable, especially for front and rear lighting systems.

  LED drivers may be cost effective when using single chip technology such as, for example, bipolar-CMOS-DMOS (BCD) technology. Otherwise, high data rate protocol controllers using, for example, BCD technology are expensive and depend on an accurate clock source (crystal).

  It is possible to employ differential wiring for clock and data signals to facilitate robustness, which may increase wire “harness” costs.

  Thus, the increasing complexity of communication networks in vehicles to drive distributed illumination sources such as LED matrices, for example, can increase production costs, which is mostly compatible with business models in the automotive industry. It may be non-sexual.

  One or more embodiments are applicable, for example, to a CAN (controller area network) bus. This is a known arrangement that can facilitate communication between a device mounted on a vehicle and, for example, a microcontroller without a host computer. The operation of the CAN bus can be based on a message-based protocol as handled in standards such as ISO 11898-2: 2015 and ISO 11898-2: 2016.

ISO11898-2: 2015 and ISO11898-2: 2016

  Despite extensive activities in this field, further improved solutions are desired.

  For example, it can facilitate the realization of cost effective high data rate vehicle networks for driving distributed LED light sources that meet automotive conditions in terms of robustness, defect detection, and safety New solutions are desired. Similar solutions may also facilitate the realization of high data rate networks for implementation in, for example, production automation systems.

  One purpose of one or more embodiments is to contribute to providing such an improved solution.

  According to one or more embodiments, such an object can be achieved by a method comprising the features set forth in the following claims.

  One or more embodiments may be associated with a corresponding system.

  One or more embodiments may relate to corresponding devices, such as a transmitter and a receiver (interface) that are intended to work together.

  One or more embodiments may be associated with a corresponding signal.

  One or more embodiments may relate to a corresponding vehicle, such as a powered vehicle such as an automobile.

  The claims are an integral part of the technical teaching provided herein in connection with the examples.

  One or more embodiments may provide suitable hardware solutions to implement a communication network for communication between, for example, an electronic control unit (ECU) and a lighting module such as an LED light module. Is possible.

  One or more embodiments can implement a master-slave communication bus interface that can be used in automotive applications.

  Such a communication bus interface for use in automotive applications can rely on a standardized CAN FD (Flexible Data Rate) protocol for driving light modules in vehicles ("CAN FD lights"). It is.

  One or more embodiments may rely on network technologies other than standardized CAN FD networks for use in non-automotive applications, such as automation systems.

  For example, one or more embodiments can use differential bus wiring and have a defined edge density for synchronization purposes (eg, from one recessive for each 10 bits). Edge to the dominant).

  One or more embodiments can perform cyclic redundancy check (CRC) and error checking for security reasons.

  In one or more embodiments, the data exchange may depend on a master-slave scheme, in which case the slave “satellite” (only) depends on the request from the master device. The data is transmitted via the communication bus. Such an operation scheme may not involve a collision resolution feature that treats a collision as an error if normal operation can be intended to avoid the collision.

  In one or more embodiments, normal operation of the communication bus may involve the master sending data (periodically) to the slave. Such a (periodic) data stream can be used by the slave as a kind of network “heartbeat” or watchdog. If a regular data stream is not received within a defined time slot, the slave can enter fail-safe (or limp home) mode.

  In one or more embodiments, data such as diagnostic data from the slave can be requested by the master, for example, using a dedicated command frame. An addressed slave can react to such a request within a time frame. Such a reaction can be used by the master to detect the availability of the slave.

FIG. 2 is a schematic diagram of a possible implementation of an embodiment. Schematic of possible implementations of a master device in an embodiment. FIG. 2 is a schematic diagram of a possible implementation of a slave device in an embodiment. FIG. 3 is an exemplary schematic diagram of possible operations of an embodiment. FIG. 6 is an exemplary block diagram of possible operations of an embodiment for managing “broadcast” frames. FIG. 4 is an exemplary block diagram of possible operations of an embodiment managing a “diagnosis” frame. FIG. 4 is an exemplary block diagram of possible operations of an embodiment for managing “error” frames. FIG. 4 is an exemplary block diagram of a possible implementation of a master communication cycle in an embodiment. FIG. 4 is an exemplary block diagram of a possible implementation of a slave communication cycle in an embodiment.

  In the following description, one or more specific details are set forth in order to provide a thorough understanding of the examples of the described embodiments. Embodiments may be implemented without one or more of the specific details, or with other methods, parts, materials, etc. In other instances, well-known structures, materials, or operations are not illustrated or described in detail so that certain aspects of the embodiments are not blurred.

  References to "one embodiment" or "one embodiment" in the framework of this description refer to a particular form, structure, or characteristic described in connection with that embodiment in at least one embodiment. It is intended to show that it is composed. Thus, the phrases “in one embodiment” or “in one embodiment” that may exist at one or more points in the description do not necessarily refer to one and the same embodiment. Absent. Furthermore, the particular forms, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

  The references used in this document are provided for convenience only and do not define the scope of protection or the scope of the examples.

  As noted, one or more embodiments may be intended to provide a “robust” master-slave bus interface that can be used in automotive applications.

  One or more embodiments can rely on standardized CAN FD physical interfaces and protocols and use differential bus wiring while providing some edge density for synchronization purposes It is possible.

  One or more embodiments can implement cyclic redundancy check (CRC) and error checking for safety compliance.

The drawing of FIG. 1 is an exemplary schematic diagram of a configuration in which a first device 10 and a set of second devices 20 ₁ , 20 ₂ ,. . . , 20 _n are coupled via a bus 30. For example, the bus 30 can be a differential bus. The CAN bus is an example of such a possible differential bus.

In such a configuration as illustrated in FIG. 1, the first device 10 transmits a “first” message carrying a set of operational data message portions on the bus 30 and the set of second devices. 20 ₁ , 20 ₂ ,. . . The second device respectively in the 20 _n reacts to them by performing an identification to each of the operation the operation data message portion of each of them being addressed in the first in the message.

  As illustrated in FIG. 1, one or more embodiments can be applied to a local communication bus network, for example, to drive LED clusters (eg, multiple lights on a vehicle). If such bus networks are compatible with standard CAN FD networks, they are referred to herein as “CAN FD Lite” networks.

  Otherwise, references to such possible applications are for illustrative purposes only and should not be construed as limiting the embodiments (even indirectly). ) Is understood.

  For example, a communication system such as that illustrated in FIG. 1 may be suitable for use with drivers for vehicle front lights and / or interior lights.

  Similar communication systems may be suitable for use with any other type of ECU and driver (not necessarily in a vehicle) as long as they can rely on a master-slave architecture. is there.

  FIG. 1 is an example of a system based on an embodiment having a master device 10, for example an electronic control unit (ECU) for LED clusters in a rear light in a vehicle.

  Again, reference to such possible applications is for illustrative purposes only and should not be construed as limiting the embodiments (even indirectly). .

One or more embodiments include a plurality of “satellite” or slave devices 20 ₁ , 20 ₂ ,. . . , 20 _n , for example, a (linear) LED drive circuit that communicates with the master device via the communication bus 30.

In one or more embodiments, the master device 10 and the slave devices 20 ₁ , 20 ₂ ,. . . , 20 _n can be supplied with power from a power source 40, for example, a battery provided in the vehicle.

In one or more embodiments, the master device 10 and slave devices 20 ₁ , 20 ₂ ,. . . , 20 _n can be referenced to a different ground or ground.

The master device 10 as illustrated in FIG. 1 has the following parts:
A main (eg “back”) converter 101,
An optional (eg, “back” again) converter 102,
A low dropout (LDO) linear voltage regulator, standby, reset and window, and watchdog circuit block 103;
Voltage supervisor, good power, oscillator and enable circuit block 104,
A microcontroller 106,
A transceiver circuit 105 (eg, a LIN2.2 / HS-CAN transceiver) for communicating with other ECUs that may be mounted in the vehicle; and
An access point for an external communication bus 107 connected to the transceiver 105 for communicating with other ECUs provided in the vehicle;
It is possible to have one or more of the following:

  In one or more embodiments, the microcontroller 106 can be fed from the main converter 101 and / or from the optional converter 102. The microcontroller 106 can be coupled to the circuit block 103 and the transceiver 105 and can be adapted for communication and / or collaboration with the communication bus 30.

  Except for the aspects described below, such an architecture for the master device 10 is prior art, and therefore need not provide a more detailed description in this document.

  In one or more embodiments, the “master” functionality of the device 10 is implemented using a microcontroller 106 and a protocol controller embedded within the CAN FD transceiver (not shown in FIG. 1). It is possible to make it.

  For example, in one or more embodiments as illustrated herein, master 10 is a microcontroller (μC) that handles bus communications. Such a microcontroller can use an embedded CAN FD protocol controller that can handle the CAN FD protocol without software intervention. This may be a desirable choice compared to running a different controller through the SW, which will take up the resources of the microcontroller core and may be undesirably slow. Thus, one or more embodiments facilitate the reuse of existing hardware protocol controllers by sending CAN FD messages and controlling their content in software.

  In one or more embodiments, the slave device 20 can be implemented as an LED driver using BCD technology.

In one or more embodiments, the data exchange on the communication bus 30 can depend on a master-slave scheme, in which case the slaves 20 ₁ , 20 ₂ ,. . . , 20 _n can transmit data via the communication bus 30 (only) upon request from the master device 10.

As noted, in one or more embodiments,
-Such an operation scheme may not involve the collision resolution feature by treating the collision as an error, as long as the normal operation can be intended to avoid the collision,
The normal operation of the communication bus 30 is that the master 10 has slaves 20 ₁ , 20 ₂ ,. . . , 20 _n on a regular basis (ie, at defined time intervals), such data is transmitted to (all) slaves 20 ₁ , 20 ₂ ,. . . , 20 _n may be involved. Such a regular data stream can be used by the slave as a network “heartbeat” or watchdog. As a result of this periodic data stream not being received within a defined time slot, the slave can enter fail-safe (or limp home) mode.

In one or more embodiments, the slaves 20 ₁ , 20 ₂ ,. . . , 20 _n may be requested by the master 10 by using a dedicated command frame such as a “second” message transmitted by the master 10 on the bus 30, for example. A certain (one) addressed slave 20 _i can react, for example, respond to a request issued by the master within a certain time frame. The response sent by the slave 20 _i via such a bus network 30 can be used by the master 10 to detect the availability and / or correct operation of the slave 20 _i .

The following is understood:
-The first message discussed here basically corresponds to a broadcast message conventionally transmitted in a protocol based on a message, such as a CAN bus protocol, for example. Messages transmitted on the bus by the device are received (simultaneously) by (all) other devices, and the devices receiving these messages are each as a function of the operational data portion conveyed by such broadcast messages. It is possible to perform
While the so-called “physical” broadcast on the bus by one (master) device, the second message is actually basically a request message to the individual of the other (slave) device. Addressed “logically” so that the slave device can react by sending respective responses, eg diagnostic messages, etc. —in a certain time interval (period) —to the master device. As long as the master device allocates a respective non-collision response interval (period) to the respective slave devices as required, such possible response collisions will be avoided.

  It should be further noted that in the framework of this description, the terms “frame” and “message” may be used to represent messages that are exchanged between participants on the communication bus 30.

  In one or more embodiments, the communication protocol can use CAN FD format frames (only) without bit rate switching and with a standard ID.

  Extensions such as supporting extended IDs, classic CAN frames or bit rate switching can optionally be included. Frames that are not supported by the implementation can be ignored and the bits intended to change these modes of operation are kept at their fixed values.

  FIG. 2 is an exemplary block diagram of a possible implementation of the master device 10 according to some embodiments.

  Throughout the figures attached to this document, like parts or elements are designated with like reference / numbers and corresponding descriptions are not repeated for the sake of brevity.

Thus, FIG. 2 shows the master device 10, which
An access point to the communication bus 30, for example a CAN bus,
-An access point to the second communication bus 107,
A transceiver circuit 105 for cooperation with the communication bus 107,
A transceiver circuit 108, for example a CAN FD transceiver, for use with the communication bus 30;
A (HW and / or SW) communication protocol controller 1062 such as a CAN FD protocol controller, a communication protocol extension (eg SW) 1061 such as a “CAN FD Lite” protocol extension, and possibly other circuit blocks A microcontroller 106 including 1063,
It is possible to comprise.

  In one or more embodiments, as illustrated herein, an additional CAN FD protocol extension 1061 may control the CAN FD protocol controller 1062 to implement the master side of the CAN FD write protocol. Is possible.

  In one or more embodiments, access to the physical interface of the bus 30 may otherwise be provided by using a conventional CAN FD transceiver 108.

FIG. 3 is an exemplary block diagram of a possible implementation of a slave device 20 _{i according} to some embodiments.

As illustrated in FIG. 3, the slave device 20 _i
-For example "CAN FD Lite" communication and communication such as protocol controller and protocol controller circuit 201;
A memory area 202,
A transceiver 203, such as a CAN FD transceiver, for example, for cooperation with the communication bus 30, and possibly other ECU circuit blocks 204,
It is possible to comprise.

Except for the aspects described below, such an architecture for slave device 20 _i is prior art and therefore it is not necessary to provide a more detailed description herein.

  For example, in one or more embodiments, the implementation of the communication and protocol controller circuit 201 may be by application specific hardware to reduce the need for an embedded processor to run the software. Is possible.

  In one or more embodiments, the communication and protocol controller circuit 201 may have an accurate oscillator (not shown in FIG. 3) for use in generating and sampling data bits.

  FIG. 4 is a schematic diagram illustrating possible operations of communication and protocol controller circuit 201, such as CAN FD write communication and protocol controller circuit.

The communication and protocol controller 201 as illustrated in FIG.
A communication controller 2010,
A protocol controller 2011 having a transmitter circuit 2012, a transmission error counter (TEC) circuit 2013, a receiver circuit 2014, and a reception error counter (REC) circuit 2015; and optionally a voltage, process and temperature compensation type And / or correspondingly trim-type oscillator 2016,
have.

  In one or more embodiments, the transmitter circuit 2012 and / or the receiver circuit 2014 can be configured to cooperate with a transceiver 203, such as a CAN FD transceiver, for communication over the bus 30. It is.

  In one or more embodiments, the transmitter circuit 2012 includes frame preparation (2012a), bit stuffing (2012b), CRC insertion (2012c), frame error check (2012d), error counting (2012e), and acknowledgment (2012e). 2012f) may be implemented.

  In one or more embodiments, the receiver circuit 2014 includes bit decoding (sampling-2014a), error detection (2014b), bit destuffing (2014c), CRC verification (2014d), and acknowledgment generation (2014e). It is possible to adopt a configuration that implements.

  In one or more embodiments, the communication controller 2010 can send data to the protocol controller 2011 and receive data from the protocol controller 2011, respectively, to control communication. .

  In one or more embodiments, applying a master-slave architecture to a CAN FD based communication bus 30 may benefit from the CAN FD protocol (eg, high data rate, robust differential signal processing). The possibility of enjoying a CRC for safety purposes) and its disadvantages, for example accurate clock timing for multilateral communication (eg arbitration, error signal processing, frame check by all ECUs) ), High complexity, and absence of guaranteed communication slots due to the absence of a central communication master.

  In one or more embodiments as illustrated herein, high bandwidth (eg, 500 kb / s, preferably 1 Mb / s) can be used, and communication is ASIL B (automotive safety). Integrity level B) It is possible to involve checks on safety conditions. For example, satisfying such a safety condition can be facilitated by a CRC value transmitted with each data frame.

In one or more embodiments as illustrated herein, for example as a result of receiving a data frame, such as "first" message sent to the bus 30 on the master 10, the recipient (slave 20 ₁ , 20 ₂ ,..., 20 _n ) transmit “acknowledge” bits, so that at least one acknowledge bit is received by the sender (master 10) if the system is operating correctly. The Rukoto.

Therefore, the slaves 20 ₁ , 20 ₂ ,. . . , 20 _n as a result of receiving at least one acknowledge bit from the master 10, the master 10 can detect that it is still coupled to the bus network 30. Since the participants in the bus network 30 are connected to the same wire, the transmitter can detect if it is not operating correctly and, as a result, will not interfere with bus communication. It is possible to enter a “passive” state.

  In one or more embodiments, a participant in the bus network 30 in a passive (eg, recessive) state can sense the value of the bus differential voltage, but drive the bus. May not be possible, i.e., certain values of the bus differential voltage may not be enforced.

  In one or more embodiments, it is possible to generate data sampling clocks individually in multiple receiver circuits. Thus, a minimum edge density of the data stream is beneficial, for example when there is at least a recessive to dominant edge, eg every 10th bit, thus facilitating synchronization of the receiver circuit to the data stream. It becomes.

In one or more embodiments, the differential bus network facilitates “robust” data transfer at low cost. In one or more embodiments, a wake-up on the network can also be realized and the slaves 20 ₁ , 20 ₂ ,. . . , 20 _n can be woken up using a wake-up pattern (WUP) according to the ISO11898-2: 2015 standard, for example using a filter time T _filter (short).

  Thus, one or more embodiments can utilize the conventional CAN FD protocol, for example, at 1 Mb / s, without bit rate switching for compatibility reasons. Therefore, exploring suitability by performing a feature (only) of a subset of a conventional CAN FD protocol (without performing a bit rate switching feature) (otherwise in a conventional CAN FD protocol controller) Is possible.

  A communication network as described herein is conceptually suitable for use with any CAN and / or CAN FD protocol “flavors”.

For example, in one or more embodiments as illustrated herein,
Use CAN FD base frame format (FBFF) (only), for example to increase the data payload of each frame (eg up to 64 bytes per frame) without the need to appeal to extended IDs Is possible,
-Without the need to fix bits in the control field and support extended ID (EID, IDE bits are always dominant), bit rate switch (BRS, always dominant) and error status indication (ESI, always dominant); One frame format (FBFF) (only) can be supported, for example, an FD frame (FDF) can be set to recessive (constantly).

  In one or more embodiments, supporting one (only) frame format, eg, CAN FD base frame format, may be a simpler implementation and facilitates cost reduction. There is.

  The data field in the CAN FD base frame format can be up to 64 bytes long. Depending on the number of data bytes, either CRC 17 or CRC 21 can be calculated. In one or more embodiments, one (only) CRC delimiter bit can be transmitted and accepted.

  In one or more embodiments, the network participant 20 may have a reception error counter (REC) 2015 and a transmission error counter (TEC) 2013.

In one or more embodiments, network participants 20 ₁ , 20 ₂ ,. . . , 20 _n can be assumed that the reception error counter 2015 at network participant 20 _i has reached a certain threshold as a result of loss of coupling of network participant 20 _i to communication bus 30. It is.

In one or more embodiments, network participants 20 ₁ , 20 ₂ ,. . . , 20 _n as a result of the transmission error counter at network participant 20 _i reaching a certain threshold, node 20 _i stops transmitting data and passively avoids disrupting the bus. It is possible to enter a target state (recessive state).

In one or more embodiments, network participants 20 ₁ , 20 ₂ ,. . . , 20 _n is a master that can transmit to a participant 20 _i as a result of no data being received from node 20 _i for a certain period of time. It can be reset by a command from 10. Receiving a reset command at a slave 20 _i can unlock that slave, which may have entered a passive state, for example due to some exceptional condition (eg, distortion).

  One or more embodiments may employ REC / TEC as long as they are provided in the “virtual” standard of the CAN bus.

  The safety concept of one or more embodiments can be built with respect to the master-slave protocol structure and operations involving sending messages within a given time frame and receiving these messages correctly. Is possible.

  One or more embodiments may envision a situation as described below.

a. TEC threshold exceeded i. TEC at the master: the master knows that it is no longer associated with the slave-> a warning message is issued (eg to the driver: lamp, dashboard message, etc.)
ii. TEC at slave: recognizes that some slave is unable to send diagnostic message to master-> enters failsafe state ("Limp Home"), eg turns on LED backlight.

b. REC threshold exceeded i. REC at Master: “Distortion” on the network (eg, shorted cable or other reason) —> Master sends failsafe command to slave and issues warning message (eg, to driver).

  ii. REC at Slave: “Distortion” in network—> Slave stops communication (thus avoiding the potential risk of the bus blocking other slaves' communication) and enters a fail-safe state.

c. Master sends “first” message i. Master does not receive an acknowledgment-> TEC increases at the master and reacts the same as described above.

  ii. The slave does not receive the “first” message in a given time frame-> distortion occurs in the network (same response as above, same as REC failure in slave).

d. Master sends “second” message i. Master does not receive an acknowledgment (ACK)-> Same response as above.

  ii. The master does not receive a response from the addressed slave-> distortion occurs in the network (at least in the associated slave, the same reaction as described above).

  iii. Slave does not receive "second" message-> no action; communication is verified by "first" message, in that respect the same reaction as described above.

e. The slave responds to the “second” message by sending a diagnostic frame i. The master does not receive a diagnostic frame within a certain time frame or receives a distorted response-> distorted in the network (at least in the associated slave, the same response as described above for a REC failure in the master).

  ii. Slave does not receive acknowledgment: Network distortion-> Same response as above for TEC failure in slave; no response provided in possible absence of TEC in slave (see also below) The communication is verified by receiving the “first” message from the master.

  As described above, one or more embodiments may “drop” the REC / TEC concept for the slave and keep it (only) at the master, eg, as part of the original CAN (FD) protocol. It is possible that the master (only) evaluates its TEC / REC.

  In one or more embodiments, in a fail-safe / limp home situation, a slave (eg, a backlight LED driver in a car) enters a safe state, eg, turns the backlight on (at least partially), Thus, the vehicle can be seen by other drivers in the dark, and other incidental functions that may increase power consumption, for example, to avoid excessive temperatures or other obstacles are blocked.

  Of course, the type and nature of the failsafe / limp home situation may vary as a function of the type of slave involved, for example, simply turning off the interior lights to avoid driver confusion during night driving There is.

  In one or more embodiments, if the network connection to the main controller (chassis / body controller, higher level controller) via bus 107 fails, the master enters a fail-safe state. In some cases. As a result of the master entering the fail safe state, the master can send a command to the slave associated with it to enter the fail safe state respectively. The master can also react to the occurrence of network distortion via a warning message, for example, notifying the driver via a warning lamp and / or dashboard message.

  In one or more embodiments, any transmitter can receive an acknowledgment (“ACK”) bit from at least one receiver as a result of the receiver receiving the data frame correctly. is there. Thus, the transmitter can identify whether it is still coupled to at least a portion of the network. For example, a transmitter transmission error counter is incremented as a result of no ACK bit being received by the transmitter.

For example, in one or more embodiments, as illustrated herein, the master 10 can send messages at regular time periods that can be used as a “watchdog trigger” and / or a network “heartbeat”. Send it out. Therefore, the receiving slaves 20 ₁ , 20 ₂ ,. . . , 20 _n can recognize whether or not the master 10 is communicating. The master 10 may periodically request status information from each connected slave 20. The slaves 20 ₁ , 20 ₂ ,. . . , If the 20 _n slave 20 _i in does not respond to the issued status information requested by the master 10, "absence" of the slave 20 _i (e.g., failure) can be detected.

  For example, in one or more embodiments as illustrated herein, any transmitter may be configured to compare the bits it transmits over communication bus 30 with the bits received on bus 30. Is possible. As a result of determining that the transmitted bits and received bits are not equal, it is possible to assume the presence of an error, and therefore it is possible to increase the transmission error counter of the transmitter. The transmitter node can stop transmitting data as a result of the corresponding TEC reaching a certain threshold and allow the transmitter to enter a passive state.

  For example, in one or more embodiments as illustrated herein, received frames may be verified for accuracy, for example, by checking one or more of the following features: Is possible.

That is, the feature is
-The accuracy of the received CRC,
-Reception of one recessive bit as a CRC delimiter following the CRC field;
The accuracy of bit stuffing in received frames,
It is.

  In one or more embodiments, the received frame can be discarded and the receiver's REC can be increased as a result of the received CRC not matching the received frame.

  In one or more embodiments, as a result of incorrect bit stuffing of the received frame, it is possible to discard the received frame and increase the REC of the receiver.

In one or more embodiments, the transmitted frame can be verified for accuracy, for example, by checking one or more of the following features. The feature is
-The transmitted bits are received by the transceiver, so the equality between the transmitted and received bits,
-Acknowledgment of a transmission frame by at least one receiver circuit by issuing an ACK bit from at least one receiver.

  In one or more embodiments, the transmitted frame can be considered invalid as a result of finding that the transmitted bit and the received bit are not the same, the transmission is aborted and The TEC of the transmitter is increased.

  In one or more embodiments, as a result of the transmitter circuit not receiving an ACK bit from the receiver, the transmitted frame may be considered as not being received by any of the receivers. Yes, the TEC of the transmitter may be increased and the transmitted frame may not be retransmitted.

In one or more embodiments, the slave devices 20 ₁ , 20 ₂ ,. . . , 20 _n oscillators 2016 can have a maximum allowable deviation of their vibration frequency, for example ± 2% of the expected value. Thus, the maximum frequency offset between two slaves in one or more embodiments can reach a maximum value, for example up to ± 4% of the vibration frequency.

  In one or more embodiments, a frame transmitted by one slave may not be intended to be decoded by another slave on the same communication bus 30. As a result of one slave receiving a frame transmitted by another slave, the reception error counter of the first slave may increase. Error frames are not transmitted by these slaves, and therefore no distortion occurs in the communication.

  Thus, in one or more embodiments, the REC of the receiver is the result of receiving an error-free frame according to the length of the frame thus received, as illustrated in Table 1 below. May be reduced.

  In one or more embodiments, the receiver's REC may have a data length code of up to 8 (e.g., according to CAN partial networking (CAN PN) operating with the classic CAN extended frame format (CEFF) ( (DLC) may be reduced by one unit. For longer frames, such behavior can be taken into account in the communication controller 2010. This is because many frames generated from the slave may not be recognized by other slaves on the communication bus 30. In the worst case, (all) of the frames originating from the slave may not be recognized by other slaves in the communication bus 30. Furthermore, the REC of the receiver may be increased beyond 1 unit per received frame. This is because a stuffing error, a CRC error, and a CRC delimiter error may be added.

  In one or more embodiments, the master sends more 8-byte data packets for each slave response than the slave. Indeed, in one or more embodiments, the slave response may be shorter than the frame transmitted by the master (eg, carrying a lower number of data bytes).

  In order to “compensate” that slave responses sent by one slave on bus 30 to other slaves coupled to bus 30 will increase their RECs, they will be sent by the master correctly received by the slaves. A long frame can reduce the REC of the slave by a length according to the length of the frame transmitted by the master, as illustrated in Table 1.

  FIG. 5 is a block diagram illustrating a possible logical flow describing a “broadcast” frame protocol performed in one or more embodiments, for example, where a master sends a “first” message and a slave Is when such a message is received.

In FIG. 5, the logical block existing on the left side of the thick vertical line represents the operation executed by the master device 10, and the logical block existing on the right side of the thick vertical line is the slave device 20 ₁ , 20 ₂ , . . . , 20 _n represents an operation executed in one of the slave devices 20 _i .

  The meaning of the logical block in FIG. 5 is as follows.

-300: send "first" message with broadcast ID,
-301: reception of "first" message,
−302: An error is detected in the received “first” message (Y = error detected, N = error not detected),
-303: Increase the REC of the slave when the positive (Y) output of block 302;
-304: End of transmission,
-305: send ACK bit if negative (N) output of block 302,
−306: Decrease the REC of the slave
-307: End with "Reception successful" status,
−308: Receive ACK bit,
-309: Error detected in the received ACK bit (Y = error detected, N = error not detected),
−310: End in “successful transmission” state in case of negative (N) output of block 309,
-311: In case of positive (Y) output of block 309, optionally increase the TEC of the master and send an error frame;
−312: End of transmission,
-313: Receive error frame,
-314: Increase the REC of the slave,
-315: End of transmission.

  The operation described in the block diagram of FIG. 5 will be described below in order to facilitate understanding.

As illustrated in FIG. 5, in one or more embodiments, to set an operating value, eg, to set an actuator value, from master 10 to slaves 20 ₁ , 20 ₂ ,. . . , 20 _n can send a “first” message.

In one embodiment, the “first” message is sent to the slaves 20 ₁ , 20 ₂ ,. . . , 20 _n may be included.

In another embodiment, the “first” message is sent to the slaves 20 ₁ , 20 ₂ ,. . . , 20 _n of a subset of all of the slaves, eg slaves 20 ₁ , 20 ₂ ,. . . , 20 _n may be a single slave, but may contain set values.

In one or more embodiments, the master 10 sends the “first” message after the slaves 20 ₁ , 20 ₂ ,. . . , 20 _n may be unexpected, but at least one acknowledge bit, eg, a CAN acknowledge slot, may be expected from at least one slave.

  In one or more embodiments as illustrated herein, master 10 does not receive any acknowledge bits from at least one slave, eg, in a CAN acknowledge slot, as a result, Increase the transmission error counter. In one or more embodiments, the master 10 may send an error frame on the communication bus 30.

In one or more embodiments as illustrated herein, slaves 20 ₁ , 20 ₂ ,. . . , 20 _n can check the integrity of the received “first” message and send an acknowledge bit if the received “first” message is error-free, in such a case The “first” message is considered valid. In one or more embodiments, receiving an additional error frame will increase the reception error counter without any additional response.

In one or more embodiments, the slaves 20 ₁ , 20 ₂ ,. . . , 20 _n may pick data from “first” messages that are valid for them. In one or more embodiments, the “first” message may carry a broadcast ID, eg, in the standard ID field of a CAN message.

  FIG. 6 is a block diagram illustrating a possible logic flow describing a diagnostic frame protocol performed in one or more embodiments, for example, where a master sends a “second” message and one This is the case when two slaves receive and react to such a message.

As shown in FIG. 5, the logical block present on the left side of the thick vertical line in FIG. 6 represents the operation executed in the master device 10, and the logical block present on the right side of the thick vertical line is the slave 20 ₁ , 20 ₂ ,. . . , 20 _n represents an operation executed in any one of the slave devices 20 _i .

  The meaning of the logical block in FIG. 6 is as follows.

-400: (target) send "second" message with slave ID,
-401: Receive "second" message,
-402: Error detection in the received "second" message (Y = error detected, N = error not detected),
-403: Increase the REC of the slave when the positive (Y) output of block 402,
-404: End of transmission,
-405: Send ACK bit in case of negative (N) output of block 402,
−406: Decrease the REC of the slave,
-407: 10-bit bus idle standby,
-408: Error detection (Y = error detection, N = error not detected),
-409: Send reaction message with slave ID,
-410: ACK bit received,
-411: Error detection in the received ACK bit (Y = error detection, N = error not detected),
-412: Increase the TEC of the master and transmit an error frame in the case of the positive (Y) output of block 411,
-413: An error frame is received,
-414: Increase the REC of the slave,
-415: End of transmission,
-416: Waiting for TREC,
-417: Check whether or not the TREC timeout has been reached (Y = TREC timeout reached, N = TREC timeout not reached)
-418: Trigger watchdog failure when block 417 is positive (Y) output,
-419: A response message is received in the case of a negative (N) output of block 417,
-420: Error detection in the received reaction message (Y = error detection, N = error not detected),
-421: Increase the REC of the master and send an error frame in case of positive (Y) output of block 420,
-422: received an error frame,
-423: increase TEC and REC of the slave,
-424: End of transmission,
-425: Send ACK bit in case of negative (N) output of block 420,
-426: Decrease the REC of the master,
-427: end in "successful reception" state,
-428: Receive ACK bit,
-429: Error detection in the received ACK bit (Y = error detection, N = error not detected),
-430: Increase the TEC of the slave when the positive (Y) output of block 429,
-431: end of transmission,
-432: Decrease the TEC of the slave when the negative (N) output of block 429,
-433: Finished in the “transmission successful” state.

  The operation described by the block diagram of FIG. 6 is also briefly described below for easy understanding.

As illustrated in FIG. 6, in one or more embodiments, the master 10 includes the communication bus 30 by including in the message ID, for example, the standard ID field of the CAN message, the identification slave ID of the slave 20 _i. , Slaves 20 ₁ , 20 ₂ ,. . . , 20 _n can transmit a “second” message requesting diagnostic data from a slave 20 _i . The master 10 may wait for a response from its addressed slave, eg a response message, within a specific time window TREC. It is possible to trigger a watchdog error as a result of the master 10 not receiving a response within that time window TREC.

In one or more embodiments, as a result of correctly receiving the “second” message sent by the master 10 on the bus 30, the slave 20 _i responds with an ACK bit in the ACK slot and a certain time interval ( Period), for example, at least 10 bits of bus idle, and the response message is transmitted after waiting.

In one or more embodiments, the slaves 20 ₁ , 20 ₂ ,. . . , 20 _n may receive the response message incorrectly (eg, due to the frequency offset of the respective oscillator relative to the frequency of the master 10). As a result of receiving such a response message incorrectly, the receiving slaves 20 ₁ , 20 ₂ ,. . . , 20 _n may be increased.

  In one or more embodiments, as illustrated herein, slaves that are not addressed by a “second” message issued by master 10 do not respond and ignore response messages sent by the addressed slave.

In one or more embodiments, as illustrated herein, a frame is transmitted by slaves 20 ₁ , 20 ₂ ,. . . , 20 _n (only). Therefore, if an error occurs, the slaves 20 ₁ , 20 ₂ ,. . . , 20 _n are not retransmit whatsoever frame.

  In one or more embodiments, as illustrated herein, the “second” message may be labeled with the ID of the addressed slave. Optionally, the “second” message can be labeled as a broadcast frame with an unused ID bit in the standard ID field (eg, indicating the slave to which the lower 10 bits of the standard ID field are addressed) While the eleventh bit can mark the frame as a broadcast frame).

  FIG. 7 is a block diagram illustrating a possible logic flow describing the error and overload frame protocol performed in one or more embodiments.

As shown in FIGS. 5 and 6, the logical block existing on the left side of the thick vertical line in FIG. 7 represents the operation executed by the master device 10, and the logical block existing on the right side of the thick vertical line is the slave device. 20 ₁ , 20 ₂ ,. . . , 20 _n represents an operation executed in any one of the slave devices 20 _i .

  The meanings of the logical blocks in FIG. 7 are as follows.

-500: Error detection (Y = error detection, N = error not detected),
-501: If the negative (N) output of the block 500, the process ends with a "transmission successful" state.
-502: In case of positive (Y) output of block 500, increase the TEC of the master and send an error frame;
-503: End of transmission,
-504: Receive error frame,
-505: Increase the REC of the slave,
-506: End of transmission.

  The operations described by the block diagram of FIG. 7 are also briefly described below for ease of understanding.

In one or more embodiments, the error frame is a slave 20 ₁ , 20 ₂ ,. . . , 20 _n and (only) transmitted by the master 10. Receiving an error frame may increase the slave's REC by one. The present invention can also be applied to an overload frame in which the same behavior is handled as an error frame.

In one or more embodiments, the bus participants (slaves 20 ₁ , 20 ₂ ,..., 20 _n ) are not capable of arbitrating communications on the bus 30. This is because communication can be initiated and / or controlled by the master 10 (only).

In one or more embodiments as illustrated herein, any collision on the bus 30 will increase the associated error counter. The master 10 can detect an error as a collision and increment its transmission error counter without necessarily retransmitting the frame. The slaves 20 ₁ , 20 ₂ ,. . . , 20 _n may detect an erroneous bit (eg, a dominant bit instead of the expected recessive) on the bus 30 and increment its transmit error counter.

  As will be appreciated, the error messages are the errors themselves, i.e. they may not meet the CAN protocol requirements. They may simply be a set of, for example, 6 consecutive dominant bits. Therefore, they can be regarded as errors and discarded on the slave side without any reaction to them.

  One concept underlying one or more embodiments is that as long as the “first” message and the “second” message are (unique) messages sent by the master, the “first” message and / or Or (only) resetting the watchdog timer when the "second" message is correctly received.

  FIG. 8 is a block diagram illustrating a possible execution example of the communication cycle of the master unit 10 in one or more embodiments.

  The meaning of the logical block in FIG. 8 is as follows.

-600: Start communication,
-601: determine whether it should request for the diagnostic data to the slave 20 _i is issued (Y = issues a diagnostic data request to the slave 20 _i, diagnosis for N = slave 20 _i data Do not issue a request),
-602: transmitting a "second" message in the case of positive (Y) output of the block 601 to the slave 20 _i,
-603: Reset the watchdog timer of slave 20 _i
-604: Check whether or not a response message with diagnostic data is received from slave 20 _i (Y = diagnostic data received, N = no diagnostic data received),
-605: Slave 20 _i watchdog timer expired whether the check (Y = watchdog expires, N = no watchdog expires),
-606: detecting a watchdog timeout for the slave 20 _i for positive (Y) output of block 605,
-607: send "first" message if block 601 negative (N) output,
-608: As an _{option, T WAIT} wait.

In one or more embodiments, the master 10 sends a “first” message to the slaves 20 ₁ , 20 ₂ ,. . . , 20 _n and these slaves can use such a cycle as a watchdog trigger. As a result of the “first” message not being received by slave 20 _i within the watchdog time, it is possible to detect a watchdog timeout. As a result of detecting a watchdog timeout, slave 20 _i can enter a fail-safe state.

In one or more embodiments, the master 10 may request diagnostic data from an addressed slave 20 _i . As a result of the addressed slave 20 _i not responding within a certain amount of time, it is possible to trigger a watchdog timer so that the master operates on loss of communication with that slave 20 _i Is possible.

In one or more embodiments as illustrated herein, the data is in at least two different ways, slaves 20 ₁ , 20 ₂ ,. . . , 20 _n can be transmitted.

In the first case, the “first” message is transmitted by the master 10 to all slaves 20 ₁ , 20 ₂ ,. . . , 20 _n can be transmitted. In such a case, the master device 10 has slaves 20 ₁ , 20 ₂ ,. . . , 20 _n may not be expected.

In the second case, it is possible for the master 10 to send a “second” message to a particular slave 20 _i . The slaves 20 ₁ , 20 ₂ ,. . . , 20 _n can treat the “second” message as a broadcast frame, eg for actuator setting. Thus, the addressed slave (only) reacts on the “second” message by sending back its diagnostic data in the response message. Such diagnostic data is ignored by other slaves on the bus 30. Due to the frequency offset between the slaves, reaction messages sent by one of the slaves may be considered as error frames by other slaves and may increase their respective RECs. .

  In one or more embodiments, the “second” message may be a dedicated frame, which may be ignored by other slaves.

  In one or more embodiments, the “first” message may use the specified broadcast ID, and the “second” message may contain the ID of the addressed slave.

  In one or more embodiments, the remaining available bits in the standard ID field are used to distinguish between diagnostic request transmission data for the plurality of slaves and specific requests for only the addressed slaves. Can be used.

FIG. 9 illustrates slave units 20 ₁ , 20 ₂ ,. . . , 20 _n is a block diagram illustrating a possible execution example of the communication cycle.

  The meanings of the logical blocks in FIG. 9 are as follows.

-700: Start communication
-701: Reset watchdog timer,
-702: detect whether a valid message has been received (Y = receive valid message, N = do not receive valid message),
-703: Determine if the valid message received if the positive (Y) output of block 702 is a "first" message or a "second" message (Y = "first" message Received, N = "second" message received),
-704: Send a response message with diagnostic data if the negative (N) output of block 703,
-705: Check whether the watchdog expires when the negative (N) output of block 702 (Y = watchdog expired, N = watchdog expired),
-706: Issue watchdog failure if block 705 is positive (Y) output.

In one or more embodiments, the master 10 is a slave 20 ₁ , 20 ₂ ,. . . , 20 _n (cyclically) to send data. Such data can be used by each slave to reset each watchdog. If the frame is not intended to be reset, each watchdog may be received by one slave before the watchdog expires, and a watchdog failure may be set. Such a watchdog failure may be used by the slave to enter a failsafe state.

In one or more embodiments, as a result of the slave 20 _i receives the addressed "second" message to it, the receiving slave 20 _i is encompasses diagnostic data requested reaction Reply by sending a message.

In one or more embodiments, the master 10 may transmit, for example, 64 bytes of data (ie, 512 bits, where 1 byte equals 8 bits) in a single data frame. Bus participants, such as slaves 20 ₁ , 20 ₂ ,. . . , 20 _n receive such data transmitted from the master 10. Thus, one slave can “pick” the information it needs from any set of 512 bits of data received from the master 10. This type of frame is referred to as a “first” message.

  The number of bits that a slave may read in a “first” message may vary depending on the particular implementation of the communication bus. The position of the data of a certain slave can be determined during the initialization sequence.

  For example, each slave may read 8-bit data in the “first” message. If the total amount of data transmitted by the master 10 in a certain “first” message is, for example, 64 bytes (ie 512 bits), the data per “first” message is a maximum of 64 slaves. Can be supplied to. When the amount of data transmitted by the master 10 in the “first” message and the amount of data read by the slave in the “first” message are defined, it corresponds to the maximum number of slaves addressable by the “first” message. Can be defined.

  In one or more embodiments, the number of possible bus participants (ie, the number of slaves) can be increased by providing “multiple chains” of slaves. In that case, the first “first” message addresses the first chain of slaves (eg, containing 64 slaves), and the second “first” message addresses the second chain of slaves. The same can be applied to the following, such as addressing. The plurality of slave chains can be addressed by a dedicated ID (eg, CAN FD ID field) in the message ID field.

  In one or more embodiments, a slave can be individually addressed by using its slave address, and the addressed slave reacts with respect to this diagnostic request frame.

In one or more embodiments, the “second” message sent by the master 10 and the slaves 20 ₁ , 20 ₂ ,. . . , 20 _n embed a protocol such as ST SPI (Serial Peripheral Interface) 4.1 protocol developed by a company belonging to the ST group in the data of the response message transmitted by 20 _n . Making it easier to read or write data.

  In one or more embodiments, an SPI command based on the ST SPI protocol embedded in the data of a “second” message from the master may include a memory address and a data byte for the request (read / write). It can consist of numbers. The slave can respond to the ST SPI protocol with a specific byte instead of the data byte of the address and the requested memory address. Such specific bytes are referred to as “Global Status Bytes” (GSBs) and contain important status bits, such as those representing errors that have occurred, resets that have occurred, etc. It is. It is therefore possible to send back the global status register with each diagnostic response.

In one or more embodiments, the “first” message is sent to (all) slaves 20 ₁ , 20 ₂ ,. . . , 20 _n by the master 10. The ID field of the “first” message may contain the identification number of one chain addressed by the “first” message. Slaves belonging to the addressed chain can extract their data from the data transferred by the frame (eg, up to 64 bytes of data). The number of data bits read by one slave is defined when the function is performed (eg, a so-called “hard coded” value). The position of data directed to a slave in the chain addressed in the overall data field of the “first” message can be determined during the chain initialization period.

  In one or more embodiments, the “first” message is, for example, a chain identification number, eg, a 7-bit number, addressed with an 11-bit frame ID starting with “1” and followed by three “1” s. May be used. For example, using a chain identification number encoded in 5 bits allows identification and assignment of up to 64 slave chains, in which case each chain has, for example, up to 63 slaves. Is included.

In one or more embodiments, a particular “first” message, referred to herein as an “initialization frame”, is referred to as a slave 20 ₁ , 20 ₂ ,. . . , 20 _n to set their “membership” in a chain and their relative position in the chain. As a result of receiving initialization frames, the slaves are conditioned to read data intended for them from broadcast frames received on the communication bus 30. For example, the number of bits read by one slave in a “first” message may be the same for all of the slaves and may be defined in the bus execution (eg, hard coded value).

  In one or more embodiments, the ID for the chain initialization frame can be, for example, “1 — 0110 — 0000 — 00”.

  In one or more embodiments, a slave may read, for example, 3 bytes of data from an initialization frame, for example, the first byte represents the chain to which it belongs and the second byte is the It may represent its position in the chain and its third byte may represent the addressed slave. Thus, a limited number of slaves are initialized depending on the size in bytes of the data field of the initialization frame and the amount of data required by one slave to be properly initialized. It is possible to use a single initialization frame to do so. For example, if the data field of the initialization frame is, for example, 64 bytes long and one slave requires 3 bytes of data in order to be properly initialized, one CAN FD frame It is possible to initialize up to 21 slaves.

In one or more embodiments, a wake-up pattern (WUP) can be implemented as a particular “first” message. The ID of the wakeup pattern can be selected to satisfy ISO _11898-2 wakeup pattern requirements, for example, with T _FILETER (short) at 1 Mb / s. If the communication bus is operated at a lower bit rate, T _FILETER (long) can be used.

  In one or more embodiments, the reserved WUP ID may be “1 — 000 — 111 — 000”. The WUP can be repeated or enhanced in optional data bytes of the wakeup frame.

In one or more embodiments, the master 10 may request data from a particular slave 20 _i by sending a “second” message that can be selected to be a CAN FD frame. . The CAN FD ID of the “second” message is a slave ID, eg a 9-bit slave ID, and one bit identifying such a frame as a “second” frame, and such a frame as a unicast frame It may contain a single bit to identify.

  In one or more embodiments, the most significant bit (MSB) of the CAN FD ID used on the bus 30 is a so-called “unicast” frame, ie a frame that is addressed to only one slave, May be equal to “0” and “broadcast” frames, ie frames addressed to all slaves, may be equal to “1”, where A chain initialization frame and a wakeup frame. As will be appreciated, references to the values of “1” and “0”, respectively, are merely exemplary and, in one or more embodiments, are actually complementary selections (eg, “0” and “1” values) may be employed.

  In one or more embodiments, as a result of the unicast frame not containing any data, the addressed slave may send default diagnostic data as defined in the implementation. is there. Otherwise, if the unicast frame contains data, such data is an SPI command based on the ST SPI 4.1 protocol.

  In one or more embodiments, a slave that receives a unicast frame containing an SPI command as described above may request that the data requested by the “second” message encoded by the ST SPI 4.1 protocol. Answer with.

In one or more embodiments, master 10 can address slave 20 _i by sending a frame containing the slave ID in the CAN FD ID field. The optional data byte may include an ST SPI SDI (ST Serial Peripheral Interface Serial Data Input) frame.

  In one or more embodiments, the slave 20 i can respond to the received “second” message by sending a response message, eg, a diagnostic response frame, over the communication bus 30. The response message can be selected to be a CAN FD frame. The CAN FD ID of the response message includes a slave ID, for example, a 9-bit slave ID, one bit for identifying such a frame as a response message, and one bit for identifying such a frame as a unicast frame. Can be included.

  In one or more embodiments, the data byte of the response message can include an ST SPI SDO (Serial Peripheral Interface Serial Data Output as developed by ST Group company) frame. If the “second” message received by the slave does not contain data in the frame data field, the slave may contain only the global status byte (GSB). It may respond to the received “second” message in a CAN FD frame.

  In one or more embodiments, different default responses can be used and can be specified in the device data sheet.

  Possible uses of frame IDs in some embodiments, such as CAN FD standard frame IDs, are exemplarily shown in Table 2 below.

  In one or more embodiments, the protocol controller may implement the CAN FD protocol as described above.

  In one or more embodiments, building blocks for performing CAN FD wakeup frame detection can be used and modified to facilitate the implementation of a simplified master / slave communication structure. Yes, in which case the slave responds (only) to requests by the master.

As already noted,
-The "first" message described throughout this description is basically a message sent on the bus by one device, for example (simultaneously) received by (all) other devices, these The latter device supports broadcast messages as conventionally transmitted in message-based protocols such as the CAN bus protocol, which can perform each operation as a function of the operation data part carried by the broadcast message. And
-Similarly, the second message described throughout this description is basically a request message, although it is a "physical" broadcast on the bus by one (master) device. As being addressed "logically" to individual ones of the other (slave) devices, in which case the slave device sends respective responses, eg diagnostic messages, within a certain time interval- It is required to react by sending to the master device, in which case a possible collision of such a response is avoided as long as the master device allocates a respective non-collision response interval to the slave device. Is done.

  Thus, the first message can be considered as a true “broadcast” message, or conversely, while physically broadcasting on the bus 30 by one (master) device, the second message As long as is logically addressed to individual ones of the slave devices, it is possible to basically regard the second message as a “unicast” message.

In one or more embodiments, a method is:
Coupling a first device (eg 10) and a set of second devices (eg 20 ₁ , 20 ₂ ,..., 20 _n ) via a bus (eg 30);
-Configuring the first device as a master device transmitting on the bus;
A) a first message carrying a set of operational data message parts representing operations for execution by a second device in the set of second devices; and b) a second in the set of second devices. A second message addressed to the device, wherein the second message is addressed to request each response to the first device within each expected response period The second message carrying an identifier identifying one; and-configuring the second device as a slave device;
-C) Read and read each operational data message portion of the set of operational data message portions to receive on the bus the first message transmitted from the first device configured as a master device. Performing each action as a function of the respective action data message portion provided;
-D) receiving on the bus the second message transmitted from the first device configured as a master device and transmitting a reaction message on the bus to the first device configured as a master device. React about it within the respective expected reaction period by
Is included.

  In one or more embodiments, a first device configured as a master device may include any operational data message portion in a first message transmitted over the bus from the first device configured as a master device. It is possible to send an initialization message on the bus that has initialization data indicating whether it is dedicated to each of the second devices configured as slaves, and configured as a slave device The second device being configured is capable of receiving the initialization message transmitted on the bus from the first device configured as a master device, and in the set of operational data message portions thereof It can be initialized as a function of the initialization data in order to read each operation data message part dedicated to it. .

  In one or more embodiments, a method can include placing a set of second devices configured as slave devices on a plurality of subsets of second devices, the method comprising: In some cases, a first device configured as a master device may send a first message on the bus having a subset identification index that identifies a second device of the subset to which the first operation message is dedicated. Is possible.

  In one or more embodiments, a first device configured as a master device can transmit a first message on the bus at a constant rate.

  In one or more embodiments, the second devices in the set of second devices can switch to a failsafe state as a result of the expiration of their respective watchdog timers.

  In one or more embodiments, as a result of a second device in a set of second devices receiving a message selected from a first message and a second message from a first device configured as a master device. It is possible to reset each watchdog timer.

  In one or more embodiments, the first device does not reach the first device for each reaction requested from the second device in the set of second devices within each expected reaction period. Each of which may be sensitive to and / or each response from a second device in a set of second devices not reaching the first device within each expected response period. It is possible to trigger a watchdog error signal.

  In one or more embodiments, the bus may comprise a differential wiring bus.

In one or more embodiments, a system is coupled to a first device (eg, 10) and a bus (eg, 30) through a set of second devices (eg, 20 ₁ , 20 _2). , ..., 20 _n ), and the first device and the second device can be configured as a master device and a slave device, respectively, and the master device and the slave device Can be configured to operate in the manner of one or more embodiments.

In one or more embodiments, a device coupled as a first device to a set of second devices (eg, 20 ₁ , 20 ₂ ,..., 20 _n ) via a bus (eg, 30) For example, 10)
A first message carrying a set of operational data message parts representing operations for execution by a second device in the set of second devices; and to a second device in the set of second devices. A second message to be addressed, requesting each response from the first device within each expected response period, and each of the second devices to which the second message is addressed The second message carrying an identifier identifying one;
Can be configured to transmit.

  In one or more embodiments, a device coupled as a first device to a set of second devices via a bus has a respective response requested from a second device in the set of second devices, respectively. Each of the responses from the second device in the set of second devices may each be sensitive to not reaching the first device within an expected reaction period of Each watchdog error signal can be triggered to indicate that the first device is not reached within the expected response period.

In one or more embodiments, a set of second devices (eg, 20 ₁ , 20 ₂ ,...) Coupled to a first device (eg, 10) via a bus (eg, 30). , 20 _n ) is included in the device (eg, 20 _i )
Receiving a first message on the bus carrying a set of operational data message parts representing operations for execution by a second device in the set of second devices, and the set of operational data messages; Reading at least one respective motion data message portion in the portion and performing at least one respective motion as a function of the read at least one respective motion data message portion;
Each second message carrying an identifier identifying the device as the one of the second devices to which each second message is addressed on the bus, each expected Receiving the respective second message requesting a respective response from the device to the first device within a reaction period and reacting to it within the respective expected reaction period;
The response message from the device can be sent on the bus towards the first device that is configured as a master device.

  In one or more embodiments, a device included in a set of second devices coupled to the first device via a bus is switched to a fail-safe state as a result of the expiration of the respective watchdog timer. It is possible to make it the structure to do.

  In one or more embodiments, a device for inclusion in a set of second devices coupled to a first device via a bus is used to transmit messages received from the first device via the bus. As a result, each watchdog timer can be reset.

  In one or more embodiments, a device for inclusion in a set of second devices coupled to a first device via a bus has application specific hardware implemented therein. It is possible to have a HW communication and protocol controller (eg 201).

  In one or more embodiments, the device for inclusion in a set of second devices coupled to the first device via a bus comprises a light source driver, preferably a vehicle light driver. It is possible.

  In one or more embodiments, a vehicle (eg, V) can be equipped with a system based on one or more embodiments.

In one or more embodiments, in a system based on one or more embodiments, a first device (eg, 10) to a set of second devices (eg, 20 ₁ , 20 ₂ ,..., 20 _n ) a signal that can be transmitted on a bus (eg 30) to send a message to
-A second message carrying a set of operational data message parts representing operations for execution by the second device in the set of second devices; and-to the second device in the set of second devices. Each of the second devices being addressed, each requesting a response to the first device within each expected response period, and wherein the second message is addressed. The second message carrying an identifier identifying the
It is possible to have

  In one or more embodiments, a signal for transmitting a first message carrying a set of operational data message portions dedicated to a second device configured as a slave device is constant. It can occur at a rate.

  Without detracting from the underlying principles, the details and the embodiments may differ, even if notably, with respect to what has been described by way of example only, without departing from the scope of protection.

  Although specific embodiments of the present invention have been described above in detail, it is needless to say that various modifications can be made without departing from the technical scope of the present invention.

10: first device 20 _i : second device 30: bus V: vehicle

Claims (19)

A first device (10) and a set of second devices (20 ₁ , 20 ₂ ,..., 20 _n ) are coupled via a bus (30);
The first device (10) is configured as a master device on the bus (30),
a) a first message carrying a set of operation data message parts representing operations for execution by the second device in the set of second devices (20 ₁ , 20 ₂ ,..., 20 _n ). And b) a second message addressing to a second device in the set of second devices (20 ₁ , 20 ₂ ,..., 20 _n ), wherein the second message is addressed to each expectation. An identifier for identifying each of the second devices (20 ₁ , 20 ₂ ,..., 20 _n ) that requests each reaction to the first device (10) within a given reaction period. The second message to communicate,
And configuring the second device (20 ₁ , 20 ₂ ,..., 20 _n ) as a slave device,
c) receiving the first message transmitted from the first device (10) configured as a master device on the bus (30), and each operating data message portion in the set of operating data message portions; And performing each action as a function of each read action data message portion,
d) receiving the second message transmitted from the first device (10) configured as a master device on the bus (30) and to the first device (10) configured as a master device; Reacting with respect to the second message within the respective expected reaction period by causing a response message to be sent on the bus (30)
The method that encompasses that. Which operation data in the first message sent from the first device (10) configured as a master device on the bus (30) from the first device (10) configured as a master device An initialization message having initialization data indicating whether the message part is dedicated to each of the second devices (20 ₁ , 20 ₂ ,..., 20 _n ) configured as slave devices. Send on the bus (30),
The second device (20 ₁ , 20 ₂ ,..., 20 _n ) configured as a slave device transmits on the bus (30) from the first device (10) configured as a master device. Initialization as a function of the initialization data to read each of the operation data message portions dedicated to it in the set of operation data message portions.
The method of claim 1. Including disposing the second device in the set of second devices (20 ₁ , 20 ₂ ,..., 20 _n ) configured as slave devices in a plurality of subsets of the plurality of second devices. The first device (10), which is configured as a master device in that case, has a subset identification index that identifies the subset of the second device to which the first operation message is dedicated Sending a first message on the bus (30);
The method according to claim 1 or 2. The first device (10) configured as a master device transmits the first message on the bus (30) at a constant rate;
4. A method according to any one of claims 1 to 3. The second device in the set of second devices (20 ₁ , 20 ₂ ,..., 20 _n ) switches to fail-safe mode as a result of the expiration of the respective watchdog timer;
5. A method according to any one of claims 1 to 4. The second device in the set of second devices (20 ₁ , 20 ₂ ,..., 20 _n ) receives the first message and the first message from the first device (10) configured as a master device. Causing each of the watchdog timers to be reset as a result of receiving a message selected from among the two messages;
The method of claim 5. The first device (10) is
Each reaction required from the second device in the set of second devices (20 ₁ , 20 ₂ ,..., 20 _n ) is within the respective expected reaction period. ) And / or the respective response from the second device in the set of second devices (20 ₁ , 20 ₂ ,..., 20 _n ) Triggering each watchdog error signal indicating that the first device (10) is not reached within a reaction period of time,
7. A method according to any one of claims 1-6. The bus (30) has a differential wiring bus;
The method according to claim 1. A first device (10) and a set of second devices (20 ₁ , 20 ₂ ,..., 20 _n ) coupled via a bus (30), the first device ( 10) and the second device (20 ₁ , 20 ₂ ,..., 20 _n ) are configured as a master device and a slave device, respectively, and the master device and the slave device are defined in claims 1 to 8. A system configured to operate in any one of the methods. In a device (10) coupled as a first device to a set of second devices (20 ₁ , 20 ₂ ,..., 20 _n ) via a bus (30), the first device is on the bus,
A first message carrying a set of operational data message parts representing operations for execution by the second device in the set of second devices (20 ₁ , 20 ₂ ,..., 20 _n ); A second message addressed to a second device in the set of second devices (20 ₁ , 20 ₂ ,..., 20 _n ) within each expected reaction period; An identifier identifying each of the second devices (20 ₁ , 20 ₂ ,..., 20 _n ) that requests each reaction to the first device (10) and to which the second message is addressed The second message carrying
(10) which is made the structure which transmits. The device
Each reaction required from the second device in the set of second devices (20 ₁ , 20 ₂ ,..., 20 _n ) is within the respective expected reaction period. ) And / or each reaction from the second device in the set of second devices (20 ₁ , 20 ₂ ,..., 20 _n ) Each watchdog error signal indicating that the first device (10) is not reached within a reaction period is triggered.
Device (10) according to claim 10. In a device (20 _i ) for inclusion in a set of second devices (20 ₁ , 20 ₂ ,..., 20 _n ) coupled to the first device (10) via a bus (30) The device is
A first message carrying a set of operation data message parts representing operations for execution by the second device in the set of second devices (20 ₁ , 20 ₂ ,..., 20 _n ). Is received on the bus (30), reads at least one respective operational data message portion in the set of operational data message portions, and at least one as a function of the read at least one respective operational data message portion. Perform each of the two actions,
In each second message carrying an identifier identifying the device as the one of the second devices (20 ₁ , 20 ₂ ,..., 20 _n ) to which the respective second message is addressed. And receiving each second message on the bus (30) requesting a respective response to the first device (10) from the device within each expected response period, and the respective device React on it within the expected reaction period, in which case a response message from the device is sent on the bus (30) towards the first device (10) which is configured as a master device Device (20 _i ). Device (20 _i ) according to claim 12, wherein the device (20 _i ) is arranged to switch to a fail-safe state as a result of the expiration of the respective watchdog timer. The device (20 _i ) according to claim 13, wherein the respective watchdog timer is reset as a result of a message received from the first device (10) via the bus (30). Device (20 _i ) according to any one of claims 12 to 14, comprising HW communication and protocol controller (201) comprising application specific hardware implemented therein. 16. Apparatus (20) according to any one of claims 12 to 15, comprising a light illumination source driver, preferably a vehicle light driver (20 ₁ , 20 ₂ , ..., 20 _n ). _i ).   A vehicle (V) comprising a system according to claim 9. Sendable on the bus (30) to send messages from the first device (10) to a set of second devices (20 ₁ , 20 ₂ ,..., 20 _n ) in the system according to claim 9 In the signal, the signal is
a) a first message carrying a set of operation data message parts representing operations for execution by the second device in the set of second devices (20 ₁ , 20 ₂ ,..., 20 _n ). And b) a second message addressed to a second device in the set of second devices (20 ₁ , 20 ₂ ,..., 20 _n ), each expected response Each of the second devices (20 ₁ , 20 ₂ ,..., 20 _n ) requesting each response to the first device (10) within a period of time and addressing the second message The second message carrying an identifier identifying one;
A signal that contains The first message carrying a set of operational data message parts dedicated to the second device (20 ₁ , 20 ₂ ,..., 20 _n ) configured as a slave device. The signal of claim 18 occurring at a constant rate.

Images