METHOD FOR THE DYNAMIC CONFIGURATION OF SENSORS AND CONTROL UNITS IN AN ETHERNET NETWORK

Abstract

A method for dynamically configuring devices in an Ethernet network, including: a head node a) determining the number of active nodes, b) classifying the identified nodes into two or more classifications of nodes to prioritize the Ethernet network communication, and c) receiving reservation requests from at least some of the multiplicity of nodes, and d) allocating time slots, in response to reservation requests, to one or more nodes in the upcoming communication window, the allocations based on a node priority and the priority being allocated to the nodes in accordance with their classification. After the active nodes have been determined, the nodes are dynamically configured, and a timer of the respective node is selected and started, with each active node respectively assigning the smallest possible ID to itself. This leads to a bus access of the respective node and, if there is bus activity, the other network nodes behave passively.

Claims

1. A method for dynamically configuring sensors and control devices in an Ethernet network, the method comprising: a) determining, by a head node, a number of active nodes, b) classifying, by the head node, the nodes into two or more classifications of nodes in order to prioritize Ethernet network communication, c) receiving, by the head node, reservation requests from at least some of the nodes, and d) allocating time slots, in response to reservation requests, to one or more of the nodes in an upcoming communication window, the time slot allocations being based on a priority of the nodes and the priority being allocated to the nodes in accordance with their classification, wherein after the number of active nodes has been determined, the nodes are dynamically configured, and a timer of a respective node is selected and started, with each active node respectively assigning a smallest possible ID to itself, thereby leading to a bus access attempt by the respective node and, if there is bus activity, other nodes in the Ethernet network behave passively.

2. The method as claimed in claim 1, wherein when there is a bus access attempt that is successful, the timer is incremented.

3. The method as claimed in claim 1, wherein when there is a bus access attempt that is unsuccessful, the timer is decremented.

4. A control unit for an Ethernet network, which, as a first node, is configured, as a control unit: to transmit a signal to a second control unit of the Ethernet network and to receive the signal from the second control unit; to determine a propagation time of the signal on a connection path to the second control unit; to determine a maximum speed of the connection path based on the propagation time; and to determine a type of a transmission medium of the connection path based on the maximum speed; wherein the control unit comprises a microprocessor, a volatile memory and non-volatile memory, at least two communication interfaces, a synchronizable timer containing non-volatile memory program instructions which, when executed by the microprocessor, performs a method as claimed in claim 1.

5. An Ethernet network for a motor vehicle, having a first control unit and a second control unit, wherein the control units are connected to one another via at least one connection path, and the first control unit is configured as claimed in claim 4.

6. The Ethernet network as claimed in claim 5, wherein the Ethernet network further comprises a third control unit, which is connected to the first control unit only indirectly and is connected to the second control unit directly by way of a third connection path, wherein the third control unit is configured to determine a propagation time of a third signal on the third connection path, wherein the first control unit is configured to trigger the determination of the propagation time of the third signal by way of a service message to the third control unit.

7. A computer program product comprising instructions that, when the instructions are executed by a computer, the instructions cause the computer to carry out the method as claimed in claim 1.

8. A non-transitory computer-readable medium on which the computer program product as claimed in claim 7 is stored.

9. A vehicle having an Ethernet network comprising multiple control units, at least one of the multiple control units comprising the control unit as claimed in claim 4.

Description

DRAWINGS

[0057] An exemplary embodiment of the present disclosure is depicted in the drawings and will be described in greater detail below. In the drawings:

[0058] FIG. 1 shows the simplified illustration of the differences between an Ethernet bus (10 Mbit/s) and a switched network;

[0059] FIG. 2 shows the basic flow of communication on the Ethernet bus;

[0060] FIG. 3 shows the physical representation of the Ethernet bus with stubs;

[0061] FIG. 4 shows the course of the method according to the present disclosure by way of ID allocation following successful bus access;

[0062] FIG. 5 shows extension of the standard to include automatic configuration of the node IDs (the boxes represent the course of the standard; the white boxes indicate how the method can be integrated into a standard);

[0063] FIG. 6 shows the automated bus access through local ID assignment;

[0064] FIG. 7 shows the setting of the timer range depending on the type of bus access;

[0065] FIG. 8 shows the variability of the range (timer) depending on different situations;

[0066] FIG. 9 shows the initialization of the bus (ID assignment) from the point of view of the master node;

[0067] FIG. 10 shows the special version of the initialization of the bus according to FIG. 9 (ID assignment) from the point of view of the master node in a plug and play network if control devices do not start up at the same time, but rather are only later delayed; and

[0068] FIG. 11 shows the plug and play manifestation stage of the automated bus access if control devices are only later delayed.

DETAILED DESCRIPTION

[0069] FIG. 1 shows the simplified illustration of the differences between an Ethernet bus (10 Mbit/s) and a switched network.

[0070] The present disclosure proposes a new method to optimize the efficiency of data transmission on the automotive 10 Mbit/s bus and to reduce the bus access time for the nodes.

[0071] FIG. 2 shows the basic flow of communication on the Ethernet bus. After the beacon has been transmitted, node 0 is next and, when it has finished its transmission, the next node is allowed to transmit (typically only a single Ethernet frame in each case may be transmitted in the slot).

[0072] The basic idea of the method according to the present disclosure describes a dynamic adaptation of the bus cycle. Unlike FlexRay, this has no negative or ill-considered effects. The nodes do not have a fixedly defined time window, but only follow an order. The head node also does not know which data are sent by the nodes beforehand.

[0073] FIG. 3 shows the physical representation of the Ethernet bus with stubs.

[0074] The method first determines all participants on the bus. This is typically statically preconfigured, since the head node needs to know this number of participants to schedule the flow.

[0075] FIG. 4 shows the course of the method according to the present disclosure by way of ID assignment following successful bus access.

[0076] FIG. 5 shows the extension of the standard to include automatic configuration of the node IDs, with the boxes representing the course of the standard. The white boxes show how the method according to the present disclosure can be integrated into the standard. This should make it clear where the method according to the present disclosure takes effect and how the standard can be modified without changing the general course. In this case, the nodes that have not yet been able to allocate an ID change to the Initialize ID state, with a check being performed in order to determine whether there is preconfiguration, and keep the default ID 255 or allocate this ID to themselves. The nodes remain in this state until they have had a successful bus access. In the Initialize Network state, the master node steps in when no slaves have been preconfigured for it, i.e., when it does not know its network. Only when it has initialized all slave control devices does it leave the state.

[0077] The head node then determines all sleeping or defective or inactive nodes on the bus. A distinction may be made here as to whether they are currently sleeping or whether a time in the future is known when the nodes are inactivesleeping or inactive in this context means that they are not participating in the bus communication (either activelytransmitting payload dataor passivelyreceiving payload data). The head node receives this knowledge either via a higher software layer or application communicated by a message from one or the participant on the bus, for example response to a sleep/wake-up signal due to an error state of a node, for example through a request from the network management, checking of protocols, reading of registers on the node.

[0078] FIG. 6 shows the automated bus access through local ID assignment. The uninitialized participants on the bus wait for the beacon from the head node (master node). As soon as they recognize this beacon, they start the NodeIDSelectionTimer. The timers will have expired at different times for each node, since a random function is used here to select from a range of valuesthe control devices therefore do not have to work synchronously either.

[0079] The initialization starts with setting the local node ID (ID). This value is set from 255 to the lowest possible value that has not yet been used (important: there should be no gaps in the sequence).

[0080] LastSuccessfullNodeID is initialized with 0. The method therefore starts with ID=1 for all nodes. This is a local allocation in each case. Since all nodes or control devices can read activity on the bus, they always have the same ID and it is ensured that none is left out.

[0081] When the timer expires, they try to gain access to the bus. If the bus is already being used even before its own timer expires and no collision is detected, this means that the current ID is assigned and the next node ID is incremented by one. A further attempt is made to gain access to the bus.

[0082] If the bus has not yet been used and a collision occurs during access, a variable that counts the number of collisions is incremented. This is intended to prevent a deadlock from occurring. At a defined value (or time value) the process is then aborted.

[0083] If there is no collision, this ECU keeps the ID and the Initialize ID state is exited.

[0084] FIG. 7 shows the setting of the timer range depending on the type of bus access. The choice of the timer or its range, from which a selection is made using a random function, is decisive for the time until the bus is fully initialized.

[0085] The range (a range of numbers from x-y) varies over the phase of the initialization process. The range of numbers should be specified in such a way that on the one hand fast initialization and on the other hand few collisions occur. It is specified in bit times and starts at 20 bit times as the lower end.

[0086] The upper end (MaxValue) can either always be the same for all nodes or can also be lower or higher than the others in a priority-based manner, i.e. depending on the importance of the ECU. For example, if a large MaxValue is selected, then the probability of a bus access is higher for other ECUs than for this one, etc. Range [20 bits-MaxValue]

[0087] FIG. 8 shows variability of the range (timer) depending on different situations. For the fastest possible initialization, the notification of invention proposes a FastMode variable. This indicates the extent to which the range is reduced when a node has successfully accessed the bus and thus been allocated an ID. In the automotive sector, the number of nodes is currently very limited (typically 8), which is why the method can quickly lead to a final configuration. If collisions occur, the rank may be too small, for example. The method therefore proposes increasing this value. This is then also implemented on every node and not just on those that did not successfully access the bus. A larger range means that the probability of an ECU gaining access to the bus increases.

[0088] FIG. 9 shows the initialization of the bus (ID assignment) from the point of view of the master node. The master node also has to learn which and how many nodes there are in its network, because it adapts its bus cycle thereto. To do this, it transmits completely normal beacons in accordance with the standard. All bus participants can detect collisions, and so can the master node. It allows a counter to run in order to log how much troubleshooting there has already been and to be able to optionally intervene.

[0089] If a message is received successfully (no collision), it transmits a beacon and thus interrupts this cycle and thus confirms the assignment of this ID that has just been received. It also saves the ID/MAC address pair and optionally checks whether errors have occurred.

[0090] When its timer expires, it is set to be greater than the timer range of the slaves, and it has received neither a collision nor a frame. The bus is then initialized and changes into the normal mode. In doing so, it stipulates the number of participants and calculates the bus cycle, which it specifies. The bus can now be operated in normal operation.

[0091] FIG. 10 shows a special version of the initialization of the bus according to FIG. 9 (ID assignment) from the point of view of the master node in a plug and play network, i.e., when control devices do not start up at the same time, but rather are only later delayed. The following figures show an example embodiment which is executed when the control devices are started with a delay. This method takes effect as long as the network is still in the initialization phase. To this end, the method proposes that, during the initialization method, data are sent from the control devices which have already allocated an ID. The content of the data is irrelevant.

[0092] By also reading the bus communication, the control devices can determine the current status of the initialization phase, even if they were only woken up/started later. The participants (who have not yet been allocated an ID) thereby recognize the highest ID that has already been assigned and then adjust their own ID. Furthermore, the timer (range) is adjusted.

[0093] FIG. 11 shows the plug and play manifestation stage of the automated bus access if control devices are only later delayed.

[0094] The beacon cycle (or when the next beacon is transmitted or how many nodes are active on the bus) may be calculated by determining the number of sleeping or defective or inactive participants. Per se, with the remaining number of active nodes, regardless of what ID they have, it may first be calculated how much time it is possible to save on the bus or by how much the bus cycle is able to be shortened.

[0095] With a cycle length in the normal mode of Z=participants*(transmission window+frame size), this is generally reduced to Z=(participants-non-active participants)*(transmission window+frame size).

[0096] The intention is to determine the time at which the beacon was sent depending on the position (here: node ID) of the active/sleeping nodes. All nodes on the bus have a unique ID. The method uses the total number of nodes and the ID to determine the position of the sleeping participants per bus cycle. The number of participants on the automotive 10 Mbit/s Ethernet bus is limited by the bus topology, and it is thus easy to get an overview of whether there is an active node behind the sleeping or possibly faulty node (IDsleepingnode<IDactivenode).

[0097] If there is no further active node up to the highest ID, then the beacon cycle is adapted such that the beacon is set before the transmission slot, the so-called transmit opportunity, of the first sleeping node, which only has active nodes in front of it and sleeping nodes behind it. This method assumes that there is no further active node, or ECU, sensor, behind the sleeping node, that is to say higher ID, as indicated in FIG. 10. This probability is relatively high since the 10 Mbit/s Ethernet bus system in the automotive environment is nowadays typically designed for eight (8) ECUs.

[0098] The intention is to shorten and optimize the cycle time by sending the next beacon frame ahead of time in the case of exclusively inactive participants at the end of the bus, i.e., the highest node IDs. However, if a node with a small ID no longer participates on the bus, then the invention proposes adapting or optimizing the IDs of the participants. There are multiple proposals according to the present disclosure for this; the selection or a combination of the method can be adapted depending on the application case:

[0099] The IDs of all active participants on the bus with a higher ID are reduced by the number of sleeping nodes before them. If, for example, ID 3 is sleeping, then ID 4 is reduced by one. This maintains the transmission order of the bus participants.

[0100] Another possibility is to fill up the sleeping IDs with participants with the highest ID. If ID 3 is sleeping, then this ID is reassigned to the highest one (for example ID 8). Although this changes the order of the bus participants, fewer bus participants need to be reconfigured.

[0101] To avoid useless optimization or adaptation of the bus cycle, the method proposes determining the current bus loading. The current loading may be determined by the time difference of the last beacons and the number of participating nodes. If the bus loading is low, it may be statistically assumed that it will not increase abruptly toward the next cycle. However, it is still possible to react to any changes, as it is proposed to monitor the bus loading continuously.

[0102] In the last step, the bus cycle is adapted in respect of the necessary data rate. Two possibilities will be proposed later for this.

[0103] In one advantageous substep, the method in which the necessary data rate is compared to the current bus capacity may be determined. First, the necessary download data rate is calculated here in relation to the 10 Mbit bus. Then the number of active nodes is determined by the head node. The slots of the inactive participants, either only passively listening, in the error state, or in the sleep mode, are determined and are to be made available by the method for the head node, which is referred to as D.sub.frei.

[0104] This already results in an optimization of the bus without in the process actively intervening in the ongoing communication or without in the process muting nodes. The real data rate can then also be reported back to the application without always having to assume the worst case. This saves memory and gives the application, possibly also the driver, a real time window back. This method is the first step toward optimizing the cycle.

[0105] Another possible optimization step is described, to prevent a subset (or also all) of the other participants on the bus (except of course the head node) from transmitting, based on the calculated, necessary data rate at the head node, and thus to reduce the cycle time for the purpose of the download (or security update), so that the head node is able to serve its necessary data rate, even if, according to normal bus operation, there would not be enough bandwidth available. For this purpose, the amount of data the head node would still have to transmit in the current cycle is constantly compared, wherein this value is taken as a limit value, which must not fall below 0 in this cycle and wherefore the cycle would be terminated before by the transmission of the next beacon. This method results in the highest possible fairness toward the other bus participants, because, only within certain tolerances, as much bandwidth as needed is used for the head node and the rest is still available for use by the following nodes. The number of nodes that may still transmit in a cycle due to this remaining bandwidth cannot be predicted exactly, since each bus participant may be between 0 (transmits no data at all), 64 (transmits a minimum Ethernet frame) and 1522 bytes (transmits a maximum Ethernet frame).

[0106] To increase fairness even further, it is proposed that, in the event that a node is no longer able to transmit and the cycle is terminated by the next beacon (because the remaining necessary data rate in that slot falls below a potential maximum Ethernet frame), the remaining bandwidth is carried over into the next cycle and released for use by the other bus participants in the next cycle. In this way, a kind of credit may be built up despite the bandwidth requirement at the head node being met.

[0107] However, to prevent the credit from increasing too much and thus potentially causing large data bursts in which many of the other bus participants are able to transmit large amounts of data unhindered, it is likewise proposed to limit the increase in the credit, either in terms of time by saturating or resetting the credit after a configurable period of time in seconds, or by a cycle counter when saturating or resetting the credit after a configurable number of bus cycles.

[0108] This type of cycle optimization is not the only conceivable one. An intermediate solution between no fairness and greatest possible fairness could be a simpler method, for example, in which only the head node is allowed to transmit over multiple cycles and a large credit builds up accordingly quickly. After a certain threshold value, this may then be reduced in one go by then inserting a cycle in which all nodes are given the opportunity to transmit before they then have to stop again for a certain number of cycles. If desired, in order to simplify the method, this variant may also be implemented without any consideration of credits, but simply according to the number of cyclesfor example only head node transmits for 99 cycles, then all nodes transmit for 1 cycle. In this case, however, a certain jitter (variance) in the data rate of the head node cannot be excluded.

[0109] The method according to the present disclosure may be performed through alternative method steps by means of which, after determining the number of active nodes, the unused transmission possibilities are determined and the absolute data rate for the head node is thereby calculated per time unit.

[0110] In the following, the method proposes determining the trustworthiness of a communication partner or its application. If this trustworthiness is determined, sensitive data can therefore be exchanged.

[0111] The head nodes on the server, for example, are typically connected on the PCB (printed circuit board) via MII (Media Independent Interface) or PCI Express and thus always manage without transceivers (PHYs).

[0112] An Ethernet transceiver (PHY) causes a delay in the 3-digit nanosecond range. This sounds small, but the delay on layer 2 (MAC) is approximately in the 1-digit nanosecond range or tends toward 0depending on how high the resolution of the measurement is.

[0113] The method first of all determines the address of the application with which data are to be exchanged (received, sent or both).

[0114] The method then starts a propagation time measurement for this component. For example, the PDelay_Request method of the gPTP protocol (or 802.1AS) may be used here. Two responses are sent back in response, and hardware timestamps can be used to determine the travel time of the message. (The use of a protocol with hardware timestamps is importantNTP, for example, is thus ruled out because the resolution is too imprecise).

[0115] With the help of this calculated value, the method calculates the physical distance to this participant. The distance is not directly expressed here by a unit of measurement such as meters or centimeters, but can be converted to the number of components (PHYs, switches) that are part of the connection, since this delay is significant in contrast to the delay on the actual cable.

[0116] As an alternative, the method measures the propagation time to a participant/address by starting propagation time measurements (for example part of the PTP protocol) and by calculating the distance to this participant therefrom.

[0117] The measured propagation time must first be evaluated in order to provide an indication of the location. The software cannot know whether or not a partner is located within the same ECU, or ideally it must not know if generalized SW and not a special version is used; in addition, IP addresses may be falsified or changed. The propagation time of an MII-based connection does not need PHYs (transceivers). However, neither the time synchronization software nor the actual application commissioning this investigation knows this. A PHY converts the data into electrical signals and encodes them, which takes much more time than when two Ethernet MACs communicate with each other over the MII-based lines.

[0118] The method presented also recognizes whether a participant is connected directly to the requesting participant. If this is not the case, the respectively appropriate protocol may be selected depending on the latency. For example, MAC-Sec or IP-Sec could be used for latencies that apply within the vehicle, and other IP/TCP-based methods could be used if the latency is so high that the participant is undoubtedly outside the vehicle.