Patent Description:
The electrical and electronic (E/E) architecture of vehicles has been evolving significantly in recent years. Document <NPL> provides an overview of such a technological trend. Similarly, document <NPL> is exemplary of the prior art in this field. Other documents exemplary of the prior art include: <NPL>; <CIT>; and <CIT>.

Substantially, the E/E architecture of vehicles has changed over the years from a flat or distributed architecture (as exemplified in the communication network scheme of <FIG>) to a domain-oriented architecture (as exemplified in the communication network scheme of <FIG>), and is now shifting towards a zone-oriented architecture (as exemplified in the communication network scheme of <FIG>). The main factors that drive the evolution of the E/E architecture are: the evolution of computation power (increasing computation power leads to consolidation; application separation by hardware hypervisor); the evolution of the car network (high bandwidth networks connect processors); the evolution of the architecture (increased computation power and high bandwidth interconnects shape the car architecture towards domain-oriented and zone-oriented architecture); and the willingness for a reduction of the Total Cost of Ownership (TCO) without degradation of overall performance.

As exemplified in <FIG>, a flat E/E network of a vehicle V includes a plurality of electronic control units (ECUs) positioned at different locations of the vehicle and coupled to each other via a communication network (bus) and, optionally, a central gateway <NUM>. Each of the ECUs includes a processing unit and/or driver units and carries out respective operations (e.g., sensing from sensors and/or actuating actuators).

As exemplified in <FIG>, a domain-oriented E/E network of a vehicle V also includes a plurality of electronic control units (ECUs) positioned at different locations of the vehicle. The various ECUs are logically (and not necessarily physically) grouped in different groups (or domains) of ECUs, where the ECUs pertaining to a same group carry out operations relating to a same domain of functions. For instance, ECUs in a first group 20a may be configured to control the drivetrain functions, ECUs in a second group 20b may be configured to control the connectivity functions, ECUs in a third group 20c may be configured to control the infotainment functions, ECUs in a fourth group 20d may be configured to control the functions related to advanced driver assistance systems (ADAS) or autonomous driving (AD) systems, and ECUs in a fifth group 20e may be configured to control the body and comfort functions. The ECUs in a same group (or domain) are coupled to each other via a dedicated network that is coupled to a respective domain controller (e.g., a drivetrain controller 22a for domain 20a, a connectivity controller 22b for domain 20b, an infotainment controller 22c for domain 20c, an ADAS/AD controller 22d for domain 20d, and a body/comfort controller 22e for domain 20e). The domain controllers are coupled to each other via a central gateway <NUM> for exchanging signals (e.g., data). Since the ECUs pertaining to a same domain may be physically distributed at different locations of the vehicle V (e.g., an ECU managing a front camera may be located at the front of the vehicle, and an ECU managing a rear camera may be located at the rear of the vehicle), the communication network of each domain may turn out to be complicated and involve a complex and/or costly harness.

As exemplified in <FIG>, a zone-oriented E/E network of a vehicle V also includes a plurality of electronic control units (ECUs) positioned at different locations of the vehicle. The various ECUs are physically grouped in different groups (or clouds) of ECUs, and the ECUs pertaining to a same group are physically located in a given region or zone of the vehicle V. For instance, ECUs in a first group 30a may be located in the front left area of vehicle V, ECUs in a second group 30b may be located in the front right area of vehicle V, ECUs in a third group 30c may be located in the rear right area of vehicle V, and ECUs in a fourth group 30d may be located in the rear left area of vehicle V. The ECUs in a same group may perform functions relating to different domains, e.g., each of groups 30a to 30d may include different ECUs that control the drivetrain functions, the connectivity functions, the infotainment functions, the ADAS/AD functions, the body/comfort functions, and so on. The ECUs in a same group are coupled to each other via a dedicated zonal network (possibly with the ECUs pertaining to different domains being arranged and coupled via dedicated sub-networks, as exemplified in <FIG>). Each zonal network is coupled to a respective zonal gateway or zonal controller (e.g., a front left gateway 32a for zone 30a, a front right gateway 32b for zone 30b, a rear right gateway 32c for zone 30c, and a rear left gateway 32d for zone 30d). The zonal controllers are coupled to each other via a central control unit <NUM> (or plural central control units).

In order to enable many of the functions available in modern vehicles (e.g., front and rear lighting effects, door zone functions, power trunk, etc.) the electronic communication relies on the provision of microcontrollers (MCU) and software for high dynamics and safety. In particular, the microcontrollers may be located close to the respective drivers (e.g., a microcontroller may be provided in each of the ECUs in each of groups 20a to 20e or groups 30a to 30d), as well as in the domain controllers 22a to 22e or the zonal controllers 32a to 32d. This may result in a complex network topology and/or a high cost.

Therefore, there is a need in the art to provide improved communication networks (e.g., improved E/E architectures) in the automotive sector, as well as improved controller devices and satellite devices suitable to operate in such improved networks. In particular, such improved communication networks, controller devices and satellite devices may rely on a CAN protocol, particularly a CAN FD protocol, more particularly a CAN FD Light protocol, as described in the Draft Specification Proposal (DSP) CiA <NUM>-<NUM> CAN FD Light specification.

An object of one or more embodiments is to contribute in providing such improved automotive communication networks, controller devices and/or satellite devices.

According to one or more embodiments, such an object can be achieved by a vehicle communication network having the features set forth in the claims that follow.

The claims are an integral part of the technical teaching provided herein in respect of the embodiments.

In one or more embodiments, a vehicle communication network includes a plurality of electronic control units (ECUs) arranged in a plurality of groups. The ECUs pertaining to a same group are coupled to each other via a respective dedicated communication bus operated according to a CAN protocol. The network includes a plurality of local controllers, each including a microcontroller unit and being coupled to a respective one of the groups of ECUs via the respective dedicated communication bus to exchange CAN frames therewith. The network includes a central controller coupled to the plurality of local controllers via a vehicle communication bus. The network includes a first set of electrical loads, each coupled to one of the electronic control units to receive an actuation signal therefrom and/or provide a feedback signal thereto. Each microcontroller unit of the local controllers is configured as communication commander device to transmit and receive CAN frames via the respective dedicated communication bus. Each of the ECUs includes a respective logic circuit configured as communication responder device. In response to a CAN frame being received from the respective local controller, the logic circuit decodes the received CAN frame to produce the actuation signal for a respective electrical load. In response to a feedback signal being received from the respective electrical load, the logic circuit transmits a CAN wake-up frame to the respective local controller and encodes the feedback signal into a CAN frame for transmission to the respective local controller.

One or more embodiments may thus provide an automotive communication network where most of the signal processing is performed by the local controllers, and where the ECUs exchange CAN frames with the local controllers according to a commander-responder scheme but are able to wake up the CAN bus to start the communication.

Reference to "an embodiment" or "one embodiment" in the framework of the present description is intended to indicate that a particular configuration, structure, or characteristic described in relation to the embodiment is included in at least one embodiment. Moreover, particular configurations, structures, or characteristics may be combined in any adequate way in one or more embodiments.

Throughout the figures annexed herein, unless the context indicates otherwise, like parts or elements are indicated with like references/numerals and a corresponding description will not be repeated for the sake of brevity.

As previously discussed with reference to <FIG> and <FIG>, in certain domain-oriented or zone-oriented automotive E/E architectures, programmable "intelligence" (e.g., programmable processing circuitry) is redundantly available in the vehicle's domain or zonal controllers as well as in the satellite ECUs. <FIG> is a block diagram exemplary of such a configuration: a domain or zonal controller <NUM> includes a microcontroller <NUM> (MCU or µC) that runs a program or application <NUM> (e.g., a firmware or embedded software), and each satellite ECU <NUM> includes a microcontroller <NUM> that runs a program or application <NUM> (e.g., a firmware or embedded software). With reference to <FIG>, each of the ECUs in groups 20a-20e could be assimilated to an ECU <NUM> as illustrated in <FIG>, and any of the domain controllers 22a-22e could be assimilated to a controller <NUM> as illustrated in <FIG>. With reference to <FIG>, each of the ECUs in groups 30a-30d could be assimilated to an ECU <NUM> as illustrated in <FIG>, and any of the zonal controllers 32a-32d could be assimilated to a controller <NUM> as illustrated in <FIG>. Each ECU <NUM> is coupled to the respective controller <NUM> via a communication network <NUM> (e.g., a communication bus operating according to a CAN protocol, particularly a CAN FD protocol). Therefore, each satellite ECU <NUM> (e.g., a door control unit, also referred to as a door zone device in the present description) includes a microcontroller <NUM> that is configured to "manage the intelligence" in the satellite application (e.g., receive, process and transmit signals). For instance, an ECU <NUM> may be configured to receive (CAN) frames from a controller <NUM> via the network <NUM>, decode the received frames, determine the resulting operation to be carried out, and operate accordingly the driver circuits in the ECU <NUM> to drive the loads coupled to the ECU <NUM>. Additionally, the ECU <NUM> may be configured to sense operating parameters from the loads coupled thereto, determine that a frame (e.g., a diagnosis frame) has to be sent to the controller <NUM>, encode the frame, and send the frame to the controller <NUM> via the network <NUM>. Therefore, signal processing capabilities (or "intelligence") are provided in the ECUs <NUM> to control and/or monitor a plurality of loads by which the application is characterized. For instance, as exemplified in <FIG>, the loads coupled to the ECU <NUM> may include at least one of a window lift motor <NUM>, an LED lighting device <NUM>, an incandescent lighting device <NUM>, a switch panel (or key pad) <NUM>, and a heater device <NUM>.

In one or more embodiments, the E/E architecture (be it domain-oriented or zone-oriented) can be improved by reducing such overhead of computational resources (e.g., the provision of microcontrollers <NUM> and <NUM> both in the domain/zonal controller <NUM> and in the satellite ECUs <NUM>) as much as possible. For instance, as exemplified in <FIG>, a domain-oriented or zone-oriented E/E architecture can be improved by consolidating (e.g., gathering, grouping) the computational resources needed by the application in a powerful, centralized domain or zonal controller <NUM>' (e.g., a calculation cluster) and exchanging data with (e.g., addressing) the satellite ECUs <NUM>' via an "intelligent" bus system <NUM>, while the satellite ECUs <NUM>' may include less computational resources compared to the current solutions. In other words, the "intelligence" of the E/E system is moved from the satellite ECUs to the domain or zonal controllers <NUM>', while a smart connection bus is provided therebetween in order for the ECUs <NUM>' to be able to operate even without an internal microcontroller, or with a low-end microcontroller (depending on the network topology and on the application). By doing so, redundant processing resources can be simplified or even removed, resulting in an improved Total Cost of Scale.

In one or more embodiments where the ECUs <NUM>' are not provided with an internal microcontroller (or with a low-end one), the topology of the electrical connections to the electrical loads may also be revised and modified with respect to the topology exemplified in <FIG>. In particular, the electrical loads may be partitioned in a first subset of loads (e.g., load <NUM>) and a second subset of loads (e.g., loads <NUM> to <NUM>) according to safety and timing requirements. For instance, the first subset may include one or more electrical loads that are to be driven according to safety-critical and/or time-critical requirements, such as a window lift motor <NUM> that is provided with a position estimation function and an anti-pinch function. The second subset may include one or more electrical loads that are not safety-critical or time-critical, such as a door lock, a switch panel or key pad, an electrochromic (EC) glass control device, a mirror glass control device, a heating device, and/or lighting devices, both LED and incandescent (see exemplary loads <NUM>-<NUM>). As exemplified in <FIG>, the safety-critical and/or time-critical loads <NUM> may be directly driven by the domain or zonal controller <NUM>' insofar as processing circuitry (e.g., programmable or non-programmable, the latter being possibly implemented by hardware such as a finite state machine, FSM) may be required for the control thereof, while the loads <NUM>-<NUM> that are not safety-critical or time-critical may be driven by the ECU <NUM>' that only includes the corresponding driver devices but does not include a processor, insofar as the required signal processing is carried out by the controller <NUM>' and the corresponding commands are issued towards the ECU <NUM>' via the intelligent bus system <NUM>.

Substantially, in one or more embodiments the time-sensitive and/or calculation-sensitive tasks are carried out in the controller <NUM>' and the corresponding loads <NUM> are driven by direct wiring to the controller <NUM>', whereas other loads <NUM>-<NUM> are controlled via the intelligent bus <NUM> and the ECUs <NUM>'. The actuation and monitoring functions of loads <NUM>-<NUM> may be carried out by the satellite ECU <NUM>' that is provided with some limited processing capability (e.g., a limited program or application <NUM>', such as a light firmware or embedded software). In other words, the satellite ECUs may be "intelligent" to some extent but may not include a microcontroller, insofar as they are coupled to the controller <NUM>' via the smart bus <NUM> and are provided with some limited processing means <NUM>'.

By way of example, the control of a power window motor <NUM> (or the control of any other motor requiring safety- and time-critical features like position detection and anti-pinch feature, such as power trunk lids or door closing applications) may rely on a flexible and programmable software to provide the proper support for certain safety features. Such a programmable signal processing capability may be too complex to be implemented in a satellite ECU <NUM>' which is controlled by an intelligent bus <NUM> and is not provided with an internal microcontroller, so the control of the load <NUM> is transferred in the powerful controller <NUM>' and is easily supported, insofar as only two wires are needed for direct drive of load <NUM> by controller <NUM>'. Other loads <NUM>-<NUM> that also need programmability but are less safety- or time-critical can instead be controlled by the satellite ECU <NUM>'. Processing of the control signals addressed to such loads <NUM>-<NUM> and/or processing of the sensed feedback signals from such loads <NUM>-<NUM> is carried out in the controller <NUM>' and supported by the intelligent bus <NUM>. In this way, all loads <NUM>-<NUM> can be addressed by one bus and no direct signals (e.g., direct cables) are needed. The satellite ECUs <NUM>' may be provided with limited processing capabilities in the form of some hardwired logic <NUM>', but no complex programable devices like a microcontroller are needed in the satellite ECUs <NUM>'. Additional loads inside the satellite ECUs <NUM>' not covered by the driver device can be addressed by a bus-to-SPI (or I2C, LIN, etc.) concept, in order to meet flexible application requirements and provide a scalable architecture.

Therefore, in one or more embodiments as exemplified in <FIG>, a domain or zonal controller <NUM>' may include a microcontroller <NUM> that runs a (relatively complex and/or heavy) program or application <NUM> (e.g., a firmware or embedded software) configured to control and/or monitor one or more electrical loads. The microcontroller <NUM> may issue command frames towards one or more ECUs <NUM>' via a (smart) communication bus <NUM>. The ECUs <NUM>' may receive the command frames from the controller <NUM>' via the bus <NUM> and may drive the loads <NUM>-<NUM> accordingly. The frames received by the ECUs <NUM>' are not processed by an internal microcontroller, insofar as the received frames may be encoded in such a way that a simple logic circuit <NUM>' in the ECUs <NUM>' is able to produce the corresponding driving signals for the loads <NUM>-<NUM> without substantial computations having to be carried out in the ECUs <NUM>'. Additionally, the ECUs <NUM>' may receive feedback signals from the loads <NUM>-<NUM>, and may encode (again in the simple logic circuit <NUM>') corresponding frames to be sent to the controller <NUM>' via the communication bus <NUM>. Also in this case, encoding frames in the ECUs <NUM>' may not involve processing by an internal microcontroller, and substantial computations in the ECUs <NUM>' may be avoided.

Additionally, as exemplified in <FIG>, the domain or zonal controller <NUM>' may include further control and sensing circuitry <NUM> (which, in one or more embodiments, may be incorporated in the microcontroller <NUM>) configured to directly control and monitor one or more loads <NUM> that are safety-critical and/or time-critical.

<FIG> is a circuit block diagram exemplary of some components of an E/E domain-oriented or zone-oriented network of a vehicle V that rely on the solution disclosed herein. The network includes a central gateway <NUM> or central control unit <NUM> (see <FIG> and <FIG>), four domain controllers, zonal controllers or zonal gateways <NUM>' (e.g., a front left controller, a front right controller, a rear right controller, and a rear left controller in the case of a zone-oriented architecture), and - by way of example - four satellite ECUs <NUM>' (e.g., door zone devices <NUM>' or door smart nodes <NUM>' that are configured to control all the electronics of the respective door of vehicle V, again in the case of a zone-oriented architecture). Of course, in real applications the number of satellite ECUs or nodes <NUM>' may be higher, as exemplified in <FIG> and <FIG>. Each door of the vehicle V includes a respective window lift motor <NUM>, which is an example of a safety-critical and time-critical load.

As exemplified in <FIG>, the central gateway or control unit <NUM>/<NUM> may include processing circuitry <NUM> configured to directly manage (e.g., control and/or monitor) the safety-critical and time-critical loads <NUM>. For instance, the processing circuitry <NUM> may carry out ripple counting and run an anti-pinch algorithm. The central gateway or control unit <NUM>/<NUM> may be directly coupled to the loads <NUM> to directly manage them. Such direct coupling may be implemented via a communication bus (e.g., a mechatronic window is commanded via a LIN bus) or via power signals (e.g., a "normal" window lift motor powered by a H-bridge driver included in the central gateway or control unit <NUM>/<NUM>). Additionally, the central gateway or control unit <NUM>/<NUM> is coupled to the domain or zonal controllers <NUM>'. Each controller <NUM>' includes a respective microcontroller <NUM>, which may also be configured to directly manage the safety-critical and time-critical loads <NUM> by carrying out ripple counting and running an anti-pinch algorithm. Therefore, also the controller <NUM>' may be directly coupled to the loads <NUM> to directly manage them, again via a communication bus or via power signals. Additionally, each controller <NUM>' includes at least one physical transceiver <NUM> configured for coupling to a satellite ECU <NUM>' via a smart communication bus <NUM>, e.g., a CAN FD Light bus. Each satellite ECU <NUM>' includes a transceiver <NUM> for coupling to the smart bus <NUM>, a power management circuit <NUM>, and drivers <NUM> for driving the loads coupled thereto (not visible in <FIG>). Therefore, the microcontroller <NUM> of the controller <NUM>' may be configured to manage the non-safety-critical or non-time-critical loads coupled to the satellite ECU <NUM>' by exchanging signals via the bus <NUM>. Additionally, as exemplified in <FIG>, the satellite ECUs <NUM>' may also be coupled to the loads <NUM> to manage them.

According to an example, the satellite ECU <NUM>' (or smart node) is a door zone device that controls the electronics of a door of vehicle V. However, it will be understood that one or more embodiments may be applied to other body electronic application domains with similar requirements, like a trunk module, a sunroof control device, a sliding door control device, etc. Generally, as exemplified in <FIG>, one or more embodiments rely on the fact of moving the processing circuitry from the satellite ECUs to the domain or zonal controllers <NUM>'. This is facilitated by a networked architecture where the satellite ECUs are smart nodes that communicate with the controller <NUM>' with a "command and response" scheme (e.g., resorting to the CAN FD Light protocol). For certain non-safety relevant functionalities, the satellite ECU <NUM>' embeds an internal logic <NUM>' able to interpret the commands received from the controller <NUM>', reacting (e.g., responding) within a given timing (non-safety relevant control loop). In case of safety-relevant functionalities, the safety-relevant and high computation power control loops (e.g., for power window lift management) are instead located in the controller <NUM>' (or even in the central gateway or control unit <NUM>/<NUM>).

By way of example of a non-safety-relevant control loop, the use case of a door lock initiated by a local key pad is discussed herein.

In a conventional E/E architecture, where the door zone satellite device is provided with a local microcontroller, a door lock procedure could include the following steps:.

Conversely, in an E/E architecture (be it domain-oriented or zone-oriented) according to one or more embodiments, where the door zone satellite device is not provided with a local microcontroller and the loads are managed by the controller <NUM>', a door lock procedure may include the following steps:.

Therefore, in one or more embodiments the communication between the satellite ECUs <NUM>' and the controller <NUM>' regarding non-safety-relevant control loops may rely on the use of a commander/responder network protocol (e.g., CAN FD Light), as such network protocols can provide maximum delay times (due to scheduling, which is not possible with the standard CAN protocol where arbitration takes place) that facilitate accurate and timely diagnosis, as well as a "wake-up by responder" feature. In particular, in one or more embodiments the communication between the satellite ECUs <NUM>' and the controller <NUM>' may rely on an improvement of the conventional CAN FD Light protocol, the improvement allowing for the responder devices to wake up the bus. In fact, this feature is not available in a conventional CAN FD Light bus where the responder nodes only act on CAN FD data frames received from commander nodes and do not arbitrate, so that one commander node controls the communication of the connected responder node(s).

<FIG> is a circuit block diagram exemplary of a satellite device <NUM>' according to one or more embodiments, which is configured to operate as discussed above, i.e., to implement a "wake-up by responder" feature when communicating with the corresponding controller <NUM>' via an implementation of the CAN protocol, particularly of the CAN FD Light protocol.

As exemplified in <FIG>, the satellite device <NUM>' may include a digital core <NUM>. The digital core carries out the logic processing functions <NUM>' previously discussed to control the pre-drivers embedded in the satellite device (e.g., heater driver and electrochromic driver), and an analog-to-digital converter (ADC) <NUM> that receives external signals ES. The ADC is configured to convert external and internal analog signals used by the digital core to implement specific functionalities (e.g., potentiometer for mirror positioning, read back from an electrochromic device, supply voltage for LED PWM adjustment, etc.).

As exemplified in <FIG>, the satellite device <NUM>' may include internal analog signal generation circuitry <NUM>, whose signals are received by the ADC <NUM>.

As exemplified in <FIG>, the satellite device <NUM>' may include an analog core <NUM> that provides the central biasing, e.g., the voltage and current references for the drivers embedded in the satellite device and for the digital core <NUM>.

As exemplified in <FIG>, the satellite device <NUM>' may include a plurality of load driver devices <NUM> (e.g., half-bridges 73a, high-side drivers 73b, drivers 73c for heating devices, drivers 73d for electrochromic devices) coupled to respective loads <NUM> (e.g., actuators coupled to the half-bridges 73a for actuating mirrors and/or locks; actuators coupled to the high-side drivers 73b for actuating lighting devices and/or window lift motors; a mirror heater coupled to the drivers 73c; an electrochromic mirror coupled to drivers 73d).

As exemplified in <FIG>, the satellite device <NUM>' may include a protocol handler <NUM> (e.g., a CAN FD Light protocol handler, configured to implement a "wake-up by responder" feature) coupled to the bus <NUM> to exchange signals ZC with the controller <NUM>', a protocol translator <NUM> coupled to the protocol handler <NUM>, and a serial protocol interface <NUM> coupled to the protocol translator <NUM>. The protocol handler <NUM> is configured to extract the payload transmitted over the CAN bus <NUM> by the controller <NUM>'. The extracted information is then passed to the protocol translator <NUM> (e.g., a CAN-to-SPI translator), which is configured to translate (e.g., decode) the bits of data coming from the protocol handler <NUM> into an already known SPI command (e.g., writing the control registers) and vice versa. When communicating in the other direction, when an information has to be sent to the controller <NUM>', the protocol handler <NUM> is configured to build up and transmit the frame on the CAN bus <NUM>. The serial protocol interface <NUM> (e.g., an SPI interface) is configured to communicate with a local SPI LS and to implement a commander/responder mechanism by which the drivers <NUM> can be configured; when communicating in the other direction, diagnostic data from the drivers <NUM> can be read by the serial protocol interface <NUM> and transmitted to the protocol handler <NUM>.

As exemplified in <FIG>, the satellite device <NUM>' may include one or more voltage regulators <NUM> that provide supply voltage(s) SV to external sensors.

As discussed previously, in one or more embodiments the communication between the satellite ECUs <NUM>' and the controller <NUM>' via bus <NUM> may rely on the use of a CAN FD Light protocol that, additionally with respect to a conventional CAN FD Light protocol, implements a "wake-up by responder" feature.

A CAN FD Light protocol uses a commander-responder communication scheme. A CAN FD Light frame is based on the FD Base Frame Format Light (FBFF Light) and includes a Start-Of-Frame (SOF) bit, an arbitration field including a standard ID field (<NUM> bits), a control field, a data field, a CRC field, an acknowledgment (ACK) field, and an End-Of-Frame (EOF) field.

In the CAN FD Light protocol, the commander may send all responders to sleep using a broadcast message in a single frame. A dedicated address indicates a broadcast message. Optional E2E protection bytes can be included for safety, at the beginning of the data field (after the control field). One command byte containing the "Go-to sleep" command (e.g., encoded as value "<NUM>H") is included in the data field (e.g., after the E2E protection bytes).

In the CAN FD Light protocol, the commander may also wake up the responders. Responder devices may detect the wake-up pattern according to specification ISO <NUM>-<NUM>:<NUM>, which specifies the time requirements (time constant) for a wake-up (WUP) filter Tfilter: <NUM> at <NUM> Mb/s, <NUM> at lower data rates (see ISO <NUM>-<NUM>:<NUM>, Table <NUM>). In particular, specification ISO <NUM>-<NUM>:<NUM> allows two wake-up indicators: a first one (defined in Chapter <NUM>. <NUM>) is a basic wake-up, and defines that upon receiving once a dominant state for duration of at least Tfilter, a wake-up event shall happen; a second one (defined in Chapter <NUM>. <NUM>) is a Pattern-Wake-Up ("Wake-Up-Pattern" - WUP), and defines that upon receiving two consecutive dominant states each for duration of at least Tfilter, separated by a recessive state with a duration of at least Tfilter, a wake-up event shall happen.

Selective wake-up may be optionally implemented. The commander sends a reserved frame containing the wake-up command (either basic or pattern), and additional data bytes fulfilling the wake-up requirements are optional (they may increase the detection probability in a very noisy environment). For instance, a possible wake-up pattern in a CAN FD Light frame may be the following:.

A following wake-up frame may be used to wake-up devices implementing selective wake-up according to ISO <NUM>-<NUM>:<NUM>. The wake-up frame is a CAN FD Light frame. Devices use a dedicated WUF-ID, several devices may be combined to one WUF-ID. For instance, a possible selective wake-up frame in a CAN FD Light frame may be the following:.

In the CAN FD Light protocol, responder devices are controlled by the commander device. Normally, the commander device controls sleep and wake-up of all responder devices. Responder devices answer only to commander request, and they never initiate a communication, so that no arbitration is needed. In one or more embodiments according to a modified CAN FD Light protocol, the responder devices may instead wake-up the commander device. In that case, the responder device sends a wake-up frame (again, either basic or pattern) to the commander device. This is a case in which a responder device can initiate the communication on bus <NUM>. As defined in the CAN protocol, a wake-up frame may include a single dominant pulse (logic zero - basic wake-up) or a sequence of dominant-recessive-dominant pulses (logic zero, logic one, logic zero - wake-up pattern). For instance, a possible wake-up pattern (from responder to commander) in a CAN FD Light frame may be the following, where the dominant-recessive-dominant pattern is included in the Standard ID:.

Since the CAN FD Light protocol does not provide for arbitration of the bus, giving to responders the possibility of initiating the communication on the bus may give rise to possible collisions, if more than one responder tries to wake-up the commander at the same time (using the same wake-up frame). Therefore, one or more embodiments may be specifically adapted to avoid or resolve collisions generated by the "wake-up by responder" additional feature implemented by CAN FD Light protocol. In particular, the responder devices may use mechanisms defined in the CAN FD Light Specification (CiA <NUM>-<NUM>), even if not intended for wake-up collision avoidance.

In one or more embodiments, in order to avoid collisions generated by the "wake-up by responder" feature, the responders may take advantage of the "suspend transmission" state. In particular, the responder devices enter the "suspend transmission" state before sending the wake-up frame. In the "suspend transmission" state, the responder device monitors the bus for six bit-times; if a dominant bit (e.g., a start-of-frame) is detected, the responder device does not send a wake-up frame, because the bus is already active (woken up), insofar as another responder device, or the commander device, was faster in waking up the bus. If instead, during the "suspend transmission" state no dominant bit is detected, the responder device may determine that the bus is reasonably inactive, and may send the wake-up frame if necessary to wake up the bus.

Even if using the "suspend transmission" state, two or more responder devices may still send their (equal) wake-up frames at the same bit time, thus possibly generating a collision.

However, the maximum phase shift on the CAN bus is equal to one bit time. Therefore, the wake-up frame used by the responder devices may include pulses (e.g., a single dominant pulse if the basic wake-up is used, or a sequence of dominant-recessive-dominant pulses if the wake-up pattern is used) where the duration of each pulse is higher than the WUP filter time (Tfilter) plus one bit time. In this way, even in case of a collision with a possible overwriting of one bit per each pulse, the duration of the "remaining" portion of the pulses would be sufficient to be correctly detected.

For instance, if the CAN FD Light bus is operating at a data rate of <NUM> Mb/s, the bit time BT is equal to <NUM>. Since the time constant Tfilter for the wake-up (WUP) filter is equal to (or lower than) <NUM> when operating at <NUM> Mb/s, the duration of each pulse should be higher than Tfilter + BT = <NUM>. Therefore, each pulse in the wake-up frame may include at least three consecutive bits (i.e., may have a duration of at least <NUM> when operating at <NUM> Mb/s). The graph below exemplifies a case of collision between the wake-up frames (in particular, using the wake-up pattern) transmitted by different responder devices, where the dominant bit value overwrites the recessive bit value, but the wake-up pattern is still detectable:.

According to another example, if the CAN FD Light bus is operating at a data rate of <NUM> kb/s, the bit time BT is equal to <NUM>. Since the time constant Tfilter for the wake-up (WUP) filter is equal to (or lower than) <NUM> when operating at a data rate lower than <NUM> Mb/s, the duration of each pulse should be higher than Tfilter + BT = <NUM>. Therefore, each pulse in the wake-up pattern may include at least four consecutive bits (i.e., may have a duration of at least <NUM> when operating at <NUM> kb/s). The graph below exemplifies a case of collision between the wake-up frames (in particular, using the wake-up pattern) transmitted by different responder devices, where the dominant bit value overwrites the recessive bit value, but the wake-up pattern is still detectable:.

Optionally, in one or more embodiments each pulse in the wake-up pattern may include at least four consecutive bits.

In one or more embodiments, a filter time Tfilter of <NUM> may be used at data rates higher than <NUM> kb/s, while a filter time Tfilter of <NUM> may be used at data rates lower than <NUM> kb/s.

Additionally or alternatively, possible collision issues related to the responder devices sending their wake-up frames at the same bit time may be solved by configuring different responder devices in the same network so as to use different lengths of the wake-up frame. In this way, if a collision initially occurs, the longer wake-up frame stays still on the bus and the remaining part, which may contain the wake-up pulse(s), may be detected by the other devices to wake up.

One or more embodiments may thus provide one or more of the following advantages:.

Without prejudice to the underlying principles, the details and embodiments may vary, even significantly, with respect to what has been described by way of example only, without departing from the extent of protection.

Claim 1:
A vehicle communication network, comprising:
a plurality of electronic control units (<NUM>') arranged in a plurality of groups (20a-20e; 30a-30d), wherein the electronic control units (<NUM>') pertaining to a same group are coupled to each other via a respective dedicated communication bus (<NUM>) operated according to a CAN FD Light protocol;
a plurality of local controllers (22a-22e; 32a-32d; <NUM>'), each local controller (<NUM>') comprising a microcontroller unit (<NUM>) and being coupled to a respective one of said groups (20a-20e; 30a-30d) of electronic control units (<NUM>') via said respective dedicated communication bus (<NUM>) to exchange CAN FD Light frames therewith;
a central controller (<NUM>; <NUM>) coupled to said plurality of local controllers (22a-22e; 32a-32d; <NUM>') via a vehicle communication bus;
a first set of electrical loads (<NUM>-<NUM>), wherein each electrical load of said first set (<NUM>-<NUM>) is coupled to one of said electronic control units (<NUM>') to receive an actuation signal therefrom and/or provide a feedback signal thereto;
wherein each microcontroller unit (<NUM>) of said local controllers (22a-22e; 32a-32d; <NUM>') is configured as communication commander device to transmit and receive CAN FD Light frames via said respective dedicated communication bus (<NUM>);
and wherein each of said electronic control units (<NUM>') includes a respective logic circuit (<NUM>') configured as communication responder device to:
i) in response to a CAN FD Light frame being received from the respective local controller (22a-22e; 32a-32d; <NUM>'), decode the received CAN FD Light frame to produce said actuation signal for a respective electrical load (<NUM>-<NUM>); and
ii) in response to said feedback signal being received from the respective electrical load (<NUM>-<NUM>), transmit a CAN FD Light wake-up frame to said respective local controller (22a-22e; 32a-32d; <NUM>') and encode said feedback signal into a CAN FD Light frame for transmission to said respective local controller (22a-22e; 32a-32d; <NUM>').