Monitoring local interconnect network (LIN) nodes

The present disclosure relates to a method of monitoring Local Interconnect Network (LIN) nodes and a monitoring device performing the method. In an aspect a method of a monitoring device of monitoring a plurality of LIN buses is provided, wherein at least one LIN node is connected to each LIN bus, said plurality of LIN buses being interconnected via the monitoring device. The method comprises detecting, for each LIN bus, any dominant data being sent over said each LIN bus by a LIN node connected to said each LIN bus and routing said any dominant data received by the monitoring device over said each LIN bus to all remaining LIN buses without overwriting any dominant data sent over the remaining LIN buses.

CROSS REFERENCE

This application claims priority to European application no. 19158878.9 filed Feb. 22, 2019, the entire contents of which are hereby incorporated by reference.

TECHNICAL FIELD

The present disclosure relates to a method of monitoring Local Interconnect Network (LIN) nodes and a monitoring device performing the method.

BACKGROUND

The automotive industry is using message based communication protocols between electronic control units (ECUs) embedded in motor vehicles. An example of such a protocol is Local Interconnect Network (LIN). This protocol is standardized by International Standards Organization (ISO). For instance, the LIN protocol used in automotive is defined by ISO standard ISO 17987, consisting of several sub specifications addressing different parts; for example the LIN datalink layer is defined by ISO 17987-3 and LIN physical layer is defined by ISO 17987-4.

An important capability in design, verification and fault tracing of LIN communication are tools that can be used to analyse all communication protocol details. In particular tools that aid analysis of communication faults and errors. However, it is not only faults that can be of importance but rather finding the origin of a certain communication event. Analysing both expected and unexpected events can provide enhanced understanding of a LIN network. It may also be used as an early warning of any potential problem that may occur later on. Gathering the information, for instance the type of event and origin, for expected and unexpected events may be based on sampling the network communication for an amount of time or in certain operational modes. From that information a risk analysis can be made which can aid in addressing or dismissing further investigation towards certain parts of a LIN network.

Conventional state of the art LIN tools provide extensive analysis capabilities, but with ever increasing complexity of vehicle electrical systems there is an increasing risk for systems not behaving as expected, hence there is need for even more detailed analysis capabilities.

An important aspect of unexpected or even expected communication behaviours is to determine the root cause or origin. Having the capability to precisely determine the origin (e.g. a particular LIN ECU in a network of ECUs) of an unwanted behaviour can be especially valuable as this can reduce the total effort needed to find the root cause and make corrective actions. Another desired capability is to characterise an expected behaviour where some margin exist between actual behaviour and requirements or where requirements are loosely defined (e.g. accumulated count of error flags).

Reducing the total analysis effort usually mean that time and cost for detecting an unexpected behaviour, determining the origin of it, making corrective actions, and finally verifying the problem as solved, can be significantly reduced. Reducing time for resolving problems are often critical in the automotive industry.

For LIN there is at the datalink layer a possibility to detect faulty LIN frames by means of a checksum transmitted at the end of a LIN frame. A LIN node—in the form of e.g. an ECU—may determine that a received frame is corrupted if the checksum for the received frame does not match with a checksum calculated by the LIN node.

The reasons for LIN faults may be hardware or software (e.g. bugs, damaged components or even system design flaws) or environmental, such as EMI disturbance. Depending on type of fault, this can have widely different impacts on the electrical system ranging from no impact at all, slower system response, and system partly going to limp home mode, full or partial loss of system functionality or system start up- or shutdown problems. Problems can also vary over time in the same vehicle making them very hard to identify, reproduce, plan and implement corrective actions and verify those actions. It can be particularly difficult to identify and associate customer perceivable symptoms with a root cause in the electrical system. There may also be symptoms not noticeable by a customer but still being important or even making the vehicle not compliant to critical requirements.

Conventional LIN analysis tools that are connected in the conventional way directly and only to a LIN bus are unable to provide some analysis capabilities. The reason is the nature of the LIN physical layer itself. Determining several aspects about each ECU in a LIN network separately from the other ECUs may provide an improved understanding of the communication properties of that ECU. Having access to internal signalling inside LIN ECUs that would support detailed analysis may be difficult or inconvenient for several reasons. For instance, ECUs are normally not designed for external access to internal signals, so ECUs have to be opened or modified such that internal signals can be accessed. Further, ECUs may be difficult to access due to the inconspicuous positions in which they are mounted in the vehicle.

SUMMARY

One objective of the present invention is to solve, or at least mitigate, this problem in the art and thus to provided an improved method of monitoring a plurality of LIN nodes in the form of for instance ECUs of a motor vehicle.

This objective is attained by a monitoring device according to an embodiment. The monitoring device is configured to receive data over a plurality of LIN buses.

If dominant data bits are received by the monitoring device over any one or more of the plurality of LIN buses, the dominant data bits are routed over the remaining LIN buses at a voltage level interpreted by LIN nodes connected to the buses as being dominant, but which voltage level is configured such that the dominant data routed over the remaining buses by the monitoring device does not overwrite dominant data sent by one or more of the LIN nodes connected to the remaining buses.

DETAILED DESCRIPTION

The aspects of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the invention are shown.

These aspects may, however, be embodied in many different forms and should not be construed as limiting; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and to fully convey the scope of all aspects of invention to those skilled in the art. Like numbers refer to like elements throughout the description.

FIG. 1illustrates three LIN nodes11,12,13being connected to a LIN bus14. A LIN bus is a master-slave serial communication bus. All LIN nodes (embodied in the form of e.g. ECUs) in a LIN network10are connected to the LIN bus. Normally one of the LIN nodes is a LIN master and the remaining LIN nodes are LIN slaves.

Internally, each LIN node11,12,13has a bus interface circuit; a LIN transceiver15,16,17. Each LIN node also has a LIN protocol controller18,19,20which handles protocol bit stream reception and transmission on data link layer according to ISO 17897. A microcontroller21,22,23is connected to the respective LIN protocol controller (or frame processor)18,19,20. The LIN controllers may optionally be a part of the microcontrollers.

The LIN protocol uses a serial bit stream with values 0 and 1, or also known as dominant and recessive bits that make up LIN frames and other protocol symbols transmitted on the LIN bus14. All LIN nodes11,12,13are capable of transmitting frame responses to a frame header. The LIN protocol controller18,19,20is handling the reception and transmission of LIN frames. The transmitted bit values 0 and 1 from the LIN protocol controller are converted in the LIN transceiver15,16,17in each LIN node into two voltage levels on the LIN bus14, which is referred to as recessive and dominant state. That is, the recessive state is caused by recessive data being sent over the bus, while the dominant state is caused by dominant data being sent over the bus. These states relate to two voltage ranges on the LIN bus14. For reception it is the reverse; the LIN transceiver15,16,17converts the two voltage levels on the LIN bus14into suitable levels to the LIN protocol controller18,19,20.

Each LIN node11,12,13can drive the LIN bus14into a series of recessive/dominant states, enabling a communication network according to ISO 17897. The LIN protocol data link layer defines how sharing of the network is performed, according to a time-division multiple access (TDMA) operation driven by a LIN master.

A LIN database is used, among other things, for associating LIN frame identifiers to each LIN node. It can be used as a base for implementation of the frame transmission and reception in each LIN node, as well as being used for analysis of the communication or runtime operation of the LIN nodes by connecting an optional LIN analysis tool. The LIN database may be seen as a lookup table; the identifier is input and the LIN node name is obtained as a result. A LIN identifier has a unique characteristic in that it points to a certain LIN node as being the transmitter of a frame response for a certain frame. Further, the LIN database normally implies that any given identifier is only associated to one LIN node as being the transmitter of a frame response.

In this disclosure the terms event, LIN event, and protocol event should be interpreted broadly. That is; as an occurrence of a LIN protocol procedure or mechanism defined in LIN datalink layer protocol ISO 17987-3 or physical layer 17987-4. Examples are frame header transmission, frame response transmission or network start up/wakeup. Additional examples of events are procedures that are not defined in LIN data link layer protocol 17987-3, and can constitute for instance misbehaviour or misuse of the LIN protocol, as well as misbehaviour preventing shutdown of the LIN network, or wakeup the LIN network.

FIG. 2illustrates on a left-hand side stipulated voltage ranges on the LIN bus for recessive and dominant data transferred over the bus, according to standards ISO 17987-4- and 17987-7. The voltage ranges defined by ISO 17987-4 result in no margins around the 40% and 60% levels, between transmitter voltages and receiver voltages, and may in some examples not be preferred. In practice, a slightly modified voltage range as shown on a right-hand side is typically utilized.

The LIN bus interconnection of LIN nodes corresponds to a “wired-AND” mechanism. Recessive bits (logic 1) are overwritten by dominant bits (logic 0). In recessive state, a dominant bit from any one or more LIN nodes result in a dominant bus state. As long as no LIN node is sending a dominant bit, the bus is in the recessive state.

InFIG. 2details are shown for expected LIN bus voltage (called VBUS) values measured between the LIN bus14and ground, for transmitter part of a LIN transceiver (bus driver) and receiver part of a LIN transceiver (bus line receiver/comparator). The transmitter allowed voltage is in intervals251and241for recessive and dominant state while the receiver must accept intervals252and242as recessive and dominant state respectively. The voltage of VBUSis given as a percentage of the supply voltage VSUPof the LIN nodes. The supply voltage VSUPmay vary for different systems, vehicles and operational modes of a vehicle. The voltage VBUSin dominant state must be between 0 and 40% of the supply voltage VSUPof the LIN nodes on the transmitting LIN node output as well as on the receiving LIN node input. For a given LIN node, the actual dominant data voltage falls anywhere within this range but is more or less fixed, with slight variation over temperature and loading from bus termination components and impedance of the LIN cable.

For a population of ECUs (i.e. LIN nodes) in a single vehicle or a fleet of vehicles, the VBUSdominant voltage may vary from ECU to ECU within the range between 0 and 40% of the supply voltage VSUP. The variation is due to several reasons like transceiver hardware production tolerances, different transceiver brands, temperature, ageing, shifts in ground reference levels, and so on. These many reasons are partly why the allowed range from 0 to A % of voltage VSUPexists, to give a robust and tolerant system even with large differences in voltage levels on the same LIN network.

A receiving ECU being compliant with ISO 17897-4- and 17897-7 must accept a voltage VBUSfrom 0 to 40% of VSUPas dominant. For recessive state, VBUSis in the range from 60% to 100% of VSUP. For receiver voltages between 40% and 60% of VSUPthe resulting state is undefined but normally there is a recessive-to-dominant and dominant-to-recessive state transition with hysteresis implemented. As can be seen on the right-hand side, dominant transmit is in practice commonly selected to be from 0 to A % of VSUP, i.e. within the range denoted248, where the value A is appropriately selected depending on the application and may in some examples be around 5-15% of VBUS.

Again with reference toFIG. 1, the case when two or more LIN nodes transmit dominant state at the same time is an unexpected situation, as a frame header is normally transmitted by a LIN master, and a frame response is normally only transmitted by any one of the LIN master or LIN slaves. When more than one LIN node is transmitting a dominant state at the same time it cannot always be determined for each LIN node respectively, whether it is transmitting dominant data or recessive data thereby causing a dominant state and a recessive state on the bus, respectively, by analysing bus voltage VBUS, since all LIN nodes are directly connected to each other via the LIN bus. Determining this is even more difficult if the dominant state output voltage from each LIN node is very close to each other so that they can not be reliably distinguished. This is not a problem in LIN communication for the ECUs but adds difficulty to advanced network analysis.

However, if it is required to analyse whether for instance the first LIN node11or the second LIN node12or both is actually driving the LIN bus into dominant state, this cannot be determined in a reliable way by measuring the voltage on the LIN bus. It gets more difficult to achieve a method working for all LIN buses in all vehicles including all variables such as transceiver brand, age, temperature and so on, since dominant state output voltage is allowed to vary within a relatively large range (from 0 to 40% of VSUP) and most likely there will be a distribution of voltages where a few ECUs have less VBUSdominant drive capability than others ECUs on the same LIN bus.

Further, by analysing the current that each LIN node drive into the LIN bus while at the same bit time transmitting dominant data is also a challenge since in principal it is only the LIN node with the highest VBUSdominant drive capability that force current. Alternatively it is only the LIN nodes with highest VBUSdominant drive capability that actually force a reliably measureable current to flow out of the transceiver.

If it is required to analyse whether for instance the first LIN node11or the second LIN node12or both is actually driving the LIN bus into dominant state, this cannot be determined in a reliable way by measuring the current flow to/from the transceiver15,16and the LIN bus.

FIG. 3illustrates a monitoring device200according to an embodiment being configured to monitor LIN nodes100,110,120being connected to LIN buses105,115,125connected between the monitoring device200and the respective LIN node100,110,120.

At least two LIN buses are connected to the monitoring device200, where at least one LIN node is connected to each LIN bus. However, a greater number of LIN nodes may be connected to each LIN bus. Further, the monitoring device200is configured to transfer signals carried over any one of the LIN buses to the remaining LIN buses. Thus, signals transferred over the first LIN bus105is carried over the second LIN bus115and the third LIN bus125, signals transferred over the second LIN bus115is carried over the first LIN bus105and the third LIN bus125, and so on.

It is noted that a number of LIN nodes may be connected to a bus. If a certain LIN node is to be monitored, then that LIN node should be the only node connected to a bus. However, it may be envisaged that a group of LIN nodes is to be monitored in a scenario where it is not necessary to distinguish between individual LIN nodes in the group. For instance, it may be desirable to analyse a group of LIN nodes originating from the same manufacturer. If so, the group of LIN nodes can all be connected to the same LIN bus.

As inFIG. 1, the LIN nodes100,110,120comprise a LIN transceiver101,111,121, a LIN protocol controller102,112,122and a microcontroller (not shown inFIG. 3). As is understood, a LIN transceiver and a LIN protocol controller is required for any device configured to be connected to a LIN bus. In this example, as inFIG. 1, a LIN controller is part of a micro-controller. In another example, the LIN controller is not part of a micro-controller but is a separate part in a LIN node.

The monitoring device200according to an embodiment comprises a LIN transceiver201,211,221connecting to the respective LIN bus105,115,125.

Further, the monitoring device200comprises a signal router202configured to route the LIN signals transmitted over any LIN bus to the remaining LIN buses. For instance, any LIN signal transmitted by first LIN node100is received by the first LIN transceiver201and then routed via the signal router202to the second LIN transceiver211and the second LIN node110as well as to the third LIN transceiver221and the third LIN node120. While the monitoring device200is illustrated as a hardware device inFIG. 3, it may also be envisaged that the device can be implemented as a simulation model for simulating behaviour of LIN nodes in the form of e.g. ECUs.

The routing of signals by the signal router202is performed since the LIN nodes100,110,120under test should display the same behaviour as if they were connected to a single LIN bus as shown inFIG. 1. In other words, all of the LIN buses105,115,125should be exposed to the same data.

Hence, assuming that a “real-world” scenario is to be tested using the setup ofFIG. 3. One or more of the LIN nodes100,110,120may be triggered to perform a selected action resulting in signals occurring on the LIN buses, i.e. LIN data being sent from one of the LIN nodes100via the bus105to the monitoring device200is routed to the remaining LIN nodes110,120over the respective bus115,125.

Reference will further be made toFIG. 4showing a flowchart illustrating a method of the monitoring device200of monitoring the plurality of LIN buses105,115,125according to an embodiment.

Hence, the monitoring device200monitors, for each of the LIN nodes100,110,120, any event occurring on the LIN buses105,115,125. That is, any data sent via the LIN bus of each LIN node is monitored by the monitoring device200. In this particular example, it is assumed that the first LIN node100sends data over the first LIN bus105to the first LIN transceiver201of the monitoring device200.

In order to re-create the situation where all the LIN nodes100,110,120are connected the LIN bus as previously has been illustrated with reference toFIG. 1, the monitoring device200receives the LIN data via the first LIN transceiver201, performs a detection process in step S101(to be described in detail below) and routes in step S102the LIN data via signal RXD′ over path204to the signal router202and further on via a) signal TXD′ over path213to the second LIN transceiver211over the second LIN bus115to the second LIN node110, and b) signal TXD′ over path223to the third LIN transceiver221over the third LIN bus125to the third LIN node120.

Advantageously, the LIN nodes100,110,120are analysed in a non-intrusive manner. The LIN nodes100,110,120are no longer electrically directly connected to each other on a physical layer, but remains connected on a datalink layer. It is to be noted that for any new vehicle, the monitoring device200may be implemented from scratch in the manner illustrated inFIG. 3, while for an existing vehicle implementing the prior art LIN bus ofFIG. 1, the bus would have to be “broken up” such that the monitoring device200can be connected as shown inFIG. 3.

Thus, datalink timing between the LIN nodes remains unaffected and the LIN nodes share all transmitted recessive and dominant bits exactly as if the LIN nodes were still directly connected to each other via a single LIN bus. This is applicable for all possible events, including events that are outside the defined events in the LIN protocol.

Hence, with the routing of data over the remaining LIN buses115,125to the remaining LIN nodes110,120, the monitoring device200does not affect the LIN network in a manner such that the behaviour of the LIN nodes changes; the LIN nodes100,110,120will act as if they are connected to a single LIN bus.

However, while the monitoring device200receives data over the RXD′ wire204from the first LIN node100, the event detection device200may simultaneously send data, for instance originating from the second LIN node110, to the first LIN node100via TXD′ wire203.

This implies that each LIN bus105,115,125may be driven dominant by both the LIN nodes (in this example the first LIN node100) and also by the monitoring device200at the same time, since the monitoring device200routes data received over any one of the LIN buses to the remaining LIN buses. Driving a LIN bus dominant from the LIN node side and from the monitoring device side suggests a potential problem, in that the monitoring device200cannot determine why the LIN bus105is dominant. That is, whether it is because the first LIN data100is transmitting dominant data bits or because the monitoring device200itself is transmitting dominant data bits.

If not resolving this critical problem, the monitoring device200may latch up and never release the dominant state to which it has driven the LIN bus105. The latch up problem would occur as soon as at least two LIN nodes out of LIN nodes100,110,120transmit dominant data bits, thereby causing a dominant state, at the same time.

Thus, in step S101, the monitoring device200detects if any dominant data bits are being sent by any LIN node,100,110,120over the respective LIN bus105,115,125. In this particular example, the monitoring device200detects that dominant data is being sent over the first LIN bus105by the first LIN node100.

Further, if the first LIN node100is the one sending the dominant data bits, these dominant bits are routed in step S102to the second LIN node110and the third LIN node120, in a manner such that the routed dominant bits do not overwrite any dominant bits transferred by the second LIN node110and the third LIN node120over the LIN buses115,125.

Advantageously, any dominant data received by the monitoring device200over any LIN bus105,115,125is routed to the LIN nodes100,110,120connected to the remaining LIN buses105,115,125.

As an example, dominant data received from the first LIN node100over the first LIN bus105is routed to the second LIN node110over the second LIN bus115and to the third LIN node120over the third LIN bus125.

Further, any dominant data simultaneously received by the monitoring device200for instance from the second LIN node110over the second LIN bus115is routed to the first LIN node100over the first LIN bus105and to the third LIN node120over the third LIN bus125, in a manner such that the dominant data received from the first LIN node100to not overwrite the dominant data received from the second LIN node110, and vice versa.

Hence, the above described latch up problem is advantageously overcome.

With reference toFIG. 5, in an embodiment, the dominant data bit detection is performed as will be described in the following. InFIG. 5, the voltage diagram on the left-hand side is identical to that previously illustrated on the right-hand side inFIG. 2. Hence, the LIN nodes100,110,120are all configured to output data where a voltage VBUSbetween the LIN bus14and ground potential is in a range from 0 to A % of VSUP, where A is a value lower than 40% of VSUP.

However, the voltage diagram on the right-hand side illustrates voltage levels which the monitoring device200is configured to comply with according to an embodiment. In the voltage diagram on the right-hand side, it is illustrated that the monitoring device200is configured to output dominant data bits to the LIN nodes at a voltage level not exceeding a maximum receive voltage level stipulated by the LIN standard for dominant data bits, i.e. not exceeding 40% of VSUP, but not overlapping with the voltage level with which the LIN nodes are configured to output dominant data bits, i.e. at least B % of VSUP. That is, the dominant data bits are outputted by the monitoring device200at a voltage level falling into range244, where the range244does not overlap with the range248. However, the range244is configured to overlap with range242, such that the LIN nodes will perceive a voltage in range244as dominant data being sent by the monitoring device200.

Further, the monitoring device200is configured to receive dominant data at a voltage level at least being in the range248with which the LIN nodes100,110,120are configured to output dominant data, i.e. in the range from 0 to A % of VSUP, even though dominant receive range of the monitoring device200may be configured to be in range245, i.e. from 0 to just below B % of VSUP. For the monitoring device200, the dominant transmit range244should not overlap with the dominant receive range245, since that would cause a latch-up on the LIN bus.

To comply with recessive receive stipulated in ISO 17879-4 and 17897-7, range246should at least overlap with range251, but preferably also with range252(but not with range248), even though the range246could extend over the voltage span illustrated inFIG. 5. Further, the monitoring device200should interpret its own dominant transmit data voltage range244as recessive receive, implying that range246overlaps with range244. The boundary range between ranges245and246is denoted247.

As a result, the monitoring device200will advantageously detect a dominate state driven by any of the LIN nodes100,110,120in case the voltage on the buses105,115,125is from 0 to A % of VSUP, since range248overlaps with range245, while the monitoring device200uses a voltage in the range244(which does not overlap with the range248) to transmit dominant bits, i.e. to cause a dominant state on the LIN bus14. That is, the LIN nodes100,110,120output dominant data at a voltage level between 0 and A % of VSUPwhile the monitoring device200outputs dominant data at a voltage level between B and 40% of VSUP, where B should exceed A.

In one embodiment there is an advantage of having the voltage A % and B % clearly separated. Such separation accomplishes a margin between transmitted dominant voltage248and received dominant voltage245, which adds robustness to the system.

The receiver dominant detection voltage range of the monitoring device200(defined by voltage interval245) is configured not to overlap its transmitter dominant voltage interval244. Further, the VBUSvoltage where transition recessive-to-dominant and transition dominant-to-recessive occur and is provided by transceiver201,211,221output signals RXD, lies between voltage intervals245and246(i.e. the boundary range247).

Reference will further be made toFIG. 6showing a flowchart illustrating a method of the monitoring device200of monitoring the plurality of LIN buses105,115,125according to the embodiment discussed with reference toFIG. 5.

As can be seen, if the monitoring device200detects that the voltage of the data sent over the first LIN bus105from the first LIN node100is in the range from 0 to A % of VSUPin step S101, the correspondingly dominant data received from the first LIN node100is routed to the second LIN node110and the third LIN node120over the second and third LIN bus115,125at a voltage level between B % and 40% of VSUP, where B>A in step S102a. Advantageously, this avoids overwriting any dominant data simultaneously being written to the second LIN bus115by the second LIN node110and/or to the third LIN bus125by the third LIN node120, since the outputted LIN node dominant data always is at a lower voltage level than the outputted monitoring device dominant data, i.e. there is no overlap between ranges244and248.

According to ISO 17987-4, the LIN transceiver for a LIN master and LIN slave is internally arranged with a pull-up resistor which will passively pull-up the bus voltage VSUPto be well above 60%, when all LIN nodes are driving at a recessive state. A LIN node driving dominant state will actively by means of e.g. a transistor actively drive the voltage to a lower voltage level. The LIN node that have the capability to actively drive, or pull down, the bus voltage to the lowest voltage VSUPwill be the LIN node determining the resulting bus voltage VSUP.

In another scenario, if the data over the first LIN bus105is not in the range from 0 to A % of VSUPin step S101—and the monitoring device200is not sending dominant data over the first LIN bus105, thereby indicating that dominant data is not being sent by the second LIN node110and/or by the third LIN node120—recessive data is received from the first LIN node100, which is routed in step S102bfrom the first LIN node to the second LIN node and the third LIN node at a voltage level between 60% and 100% of VSUP. It should be noted that if any one of the other LIN nodes110,120, for instance the second LIN node110, would transmit dominant data, that particular dominant data would be routed to the first LIN node100and the third LIN node120, and any recessive data from the first LIN node100would thus be overwritten.

FIG. 7illustrates a further embodiment, where the signal router202of the monitoring device200encodes data received from the respective LIN node.

Hence, data received from the first LIN node100via the first LIN transceiver201with signal RXD′ over path204is combined in a first encoder216with data received from the third LIN node via the third LIN transceiver221with signal RXD′ over path224. As can be seen in the upper table, if any combined bits of the received data is 0, then the output of the first encoder is 0. As a consequence, the signal router202will output dominant data, i.e. a 0, indicating a dominant state with the signal TXD′ over path213, which 0 the second LIN transceiver211converts to a voltage in the range from B % to 40% of VSUPand outputs to the second LIN node110as soon as any one or both of the first LIN node100and the third LIN node120outputs dominant bits (i.e. a 0 represented by a voltage in the range B % to 40% of VSUP).

Correspondingly, a second encoder206receives data from the second LIN node110and the third LIN node120and outputs a 0 to the first LIN node100if any one or both of the second LIN node110and the third LIN node120transmits a 0, i.e. a dominant bit, while a third encoder226receives data from the first LIN node100and the second LIN node110and outputs a 0 to the third LIN node120if any one or both of the first LIN node100and the second LIN node110transmits a 0.

As can be concluded, if data received from any one of the LIN nodes over the LIN buses indicates a dominant state in the form of a 0 represented by a voltage in the range from 0 to A % of VSUP, the encoders will output a dominant bit in the form of a 0, which the associated LIN transceivers transmits to the remaining LIN nodes in the form of a voltage in the range from B % to 40% of VSUP.

As further can be seen inFIG. 7(and also inFIG. 3), the monitoring device200monitors any data transmitted by the LIN nodes100,110,120via the respective signal RXD′ over paths204,214,224.

In a further embodiment, also described with reference toFIG. 7, the signal router202comprises a fourth encoder205, where data received from the first LIN node100via the first LIN transceiver201with the signal RXD′ over path204is combined with data received from the second LIN node110via the second LIN transceiver211with the signal RXD′ over path214and with data received from the third LIN node120via the third LIN transceiver221with the signal RXD′ over path224. Again, as can be seen in the lower table, if data received from any one of the LIN nodes indicates a dominant state in the form of a 0 represented by a voltage in the range from 0 to A % of VSUP, the fourth encoder will output a dominant bit in the form of a 0 over wire210a. The signal RXD″ sent over path210ais routed to a LIN protocol handling device230, as will be discussed in the following.

FIG. 8aillustrates the LIN protocol handling device230according to an embodiment, which functionally comprises a LIN protocol controller231, or frame processor, which LIN protocol handling device230utilizes the signal RXD″ carried over path210a.

FIG. 8bshows the LIN protocol handling device230utilizing an alternative signal RXD′″ carried over path210baccording to an embodiment.

Path210bserves the same purpose as the signal path210a; to provide a combined signal where data being carried over the LIN buses105,115,125is routed to the LIN protocol handling device230. Since the monitoring device200routes data from the second LIN bus115and the third LIN bus125to the first LIN bus105, the data on the first LIN bus105(or that on any bus) represent combined data from the first, second and third LIN nodes100,110,120. A transceiver215is connected to LIN bus105and the RXD wire210b. The transceiver215has the same voltage ranges for reception as the LIN Nodes100,110,120, which are according to ISO 17987.

In one example the transceiver215only uses its receiver part while the transmitter part is not used and therefore the transmitter input TXD signal is permanently tied to a recessive state. In another example the transceiver215is instead a bus line receiver and there is no transmitter or TXD signal provided.

With reference toFIGS. 8aand 8b, the signal210bor alternatively the signal210aoutput from the fourth encoder205(discussed with reference toFIG. 7) which combines signals from all the LIN nodes100,110,120is supplied to the LIN protocol controller231. The LIN protocol controller231monitors all events from each LIN node as one composite signal210a(or210b), which signal210a(or210b) represents what each LIN node100,110,120actually is seeing on the respective LIN bus105,115,125(corresponding to the data being transferred over the LIN bus14ofFIG. 1), in this particular example the data sent by the first LIN node100as previously discussed. Further, the LIN protocol controller231is capable of interpreting the data received with signal210aor210bin the context of a LIN frame. Thus, the LIN protocol controller231maps the data received with signal210aor210binto a LIN frame (or a plurality of LIN frames). The LIN protocol controller231has no TXD path back to any of the transceivers201,211,221or215, or encoder205. This is intentional since it must not affect the data that it shall monitor.

In one embodiment the transceivers201,211,221does not support being set to standby mode and continuously pass all symbols like frames headers, frame response and wakeup signals and any dominant state not recognized as a valid LIN protocol symbol to LIN protocol controller231. The LIN protocol controller231is configured to recognize wakeup signals according to ISO 17987-3.

Further, any one of LIN nodes100,110,120, can be a LIN master, and the remaining LIN nodes can be LIN slaves. The monitoring device200advantageously handles the LIN master being connected to any of the LIN buses105,115,125. If more than one LIN master would be connected, e.g. the first LIN node100being a LIN master and the second LIN node110also being a LIN master, this unusual system configuration could be identified by the LIN monitoring device200.

The LIN protocol controller231is in an embodiment capable of encoding the data received over paths210aor210binto LIN frame headers and LIN frame responses as specified in the LIN standard. Examples of such LIN frames will be given hereinbelow. These LIN frames may be provided for display to an operator of the monitoring device200via path231a.

Further, the LIN protocol controller231is in an embodiment capable of mapping events indicated by the LIN protocol controller to specific LIN nodes, and providing this information via paths232a,232b,232csuch as for instance “LIN frame header received from the first LIN node” via path232a, “LIN frame response received from the second LIN node” via path232b, etc. Any LIN frame format may be used.

Included are also the TXD signals103,113,123from the LIN nodes100,110,120. Those TXD signals are not available to the monitoring device200. However, their waveforms are recreated by the transceivers201,211,221in the monitoring device200as signals204,214,224and are shown for illustrational purposes.

FIG. 9illustrates LIN frame header transmission performed by the first LIN node100and LIN frame response transmitted by the second LIN node110, and no transmission by the third LIN node120.

As can be seen inFIG. 9, a LIN frame301consists of a so called frame header and a frame response. A BREAK field is used to activate all LIN slaves (i.e. the second LIN node110and the third LIN node120) to listen to the following parts of the header transmitted by a LIN master (i.e. the first LIN node100in this case). Hence, the BREAK field acts as a start-of-frame indicator. The header further includes a SYNC field used by the slave nodes for clock synchronization. The IDENTIFER defines a specific message address. Thereafter, the frame response part of the LIN frame commences, which is sent by any one of the slave nodes or the master node, the message response consisting of N bytes of DATA and a CHECKSUM field.

It is noted that inFIGS. 9-11, for illustrative purposes, a part of the DATA field of the respective LIN frame301,311,321(and the corresponding sections of the remaining signals) has been compressed in time as this field may contain up to 64 bits.

If at the time of detection of the BREAK field any of the RXD′ signals over paths204,214,224is 0 (i.e. dominant), then the corresponding LIN node is identified as being the LIN node transmitting the LIN frame header302,304,306comprising the data transported with signals210aor210b. While both the RXD′ signal carried over path214for the second LIN node110and the RXD′ signal carried over path224for the third LIN node120is 1 (i.e. recessive), the RXD′ signal carried over path204for the first LIN node100is indeed 0. Thus, the first node100must be the source of the data received over paths210a,210b, in this case a LIN master.

With reference to the voltage VBUSof the signals carried over the LIN buses105,115,125, in this example the first LIN node100drives the bus into a dominant state resulting in a VBUSin the range248(cf.FIG. 5). The monitoring device200will thus conclude that it is the first LIN node100that sends the dominant data bit over the first LIN bus105, and as a result route that dominant bit to the second and the third LIN node110,120via paths213,223, respectively, over the second and third LIN bus115,125at a VBUSin the range244.

The LIN protocol controller231will then encode the data sent by the first LIN node100and received over path210aor210binto a LIN frame headers until all headers fields BREAK, SYNC and IDENTIFIER are encountered.

As can be seen, at the time of the DATA1through DATA-N and CHECKSUM fields being encountered in the frame response, LIN bus combination signal210aor210bindicates dominant data being transmitted over the LIN buses, and the LIN protocol controller231detects from paths214,224only the second node110transmitting dominant data thereby successfully completing the LIN frame transmission, indicated with305.

Again, with reference to the voltage VBUSof the signals carried over the LIN buses105,115,125; at the time of frame response, in this example the second LIN node110drive the bus into a dominant state resulting in a VBUSin the range248. As a result, the monitoring device200will route a dominant bit to the first LIN node100via path203over the first LIN bus105at a VBUSin the range244.

FIG. 10illustrates frame transmission similar toFIG. 9, but in this case it is the first LIN node100that transmits both LIN frame header and LIN frame response. The first LIN node100is a LIN master, as the frame header is transmitted by the first LIN node100. The identification as regards which LIN node is transmitting the frame header is the same is that ofFIG. 9.

With reference to the voltage VBUSof the signals carried over the LIN buses105,115,125, in this example the first LIN node100drives the bus into a dominant state resulting in a VBUSin the range248(cf.FIG. 5). The monitoring device200will thus conclude that it is the first LIN node100that sends the dominant data bit over the first LIN bus105, and as a result route that dominant bit to the second and the third LIN node110,120via paths213,223, respectively, over the second and third LIN bus115,125at a VBUSin the range244.

The LIN protocol controller231will then encode the data sent by the first LIN node100and received over path210aor210binto a LIN frame header until all headers fields BREAK, SYNC and IDENTIFIER are encountered.

As can be seen, at the time of the DATA1through DATA-N and CHECKSUM fields being encountered in the frame response, LIN bus combination signal210aor210bindicates dominant data being transmitted over the LIN buses, and the LIN protocol controller231detects from paths214,224only the second node110transmitting dominant data thereby successfully completing the LIN frame transmission, indicated with313.

Again, with reference to the voltage VBUSof the signals carried over the LIN buses105,115,125; at the time of frame response, in this example the first LIN node100drive the bus into a dominant state resulting in a VBUSin the range248. As a result, the monitoring device200will route a dominant bit to the second LIN node110via path213over the second LIN bus115at a VBUSin the range244.

FIG. 11illustrates a slightly more complex scenario in the form of a LIN frame header transmission performed by the first LIN node100and frame response transmitted by the first LIN100and the second LIN node110, resulting in an invalid frame response. A frame response is expected to be transmitted by only one LIN node. Again, up until the frame header of the LIN frame is encountered, the behaviour is the same as that described with reference toFIGS. 9 and 10. Hence the first LIN node100is identified as being the LIN node transmission the LIN frame header.

However, after the frame header both the first LIN node100and the second LIN node110start to transmit a frame response. For simplicity, the byte fields of the frame responses are exactly aligned in time so they are transmitted synchronously. In another example, the byte fields of the first LIN node100and second LIN node110could be transmitted with slightly different delays relative to each other which would result in invalid byte fields DATA1trough CHECKSUM.

Due to the wired-AND nature of the LIN transceivers101,111,121in the LIN nodes and the LIN transceivers201,211,221in the monitoring device200, the same bits transmitted by different LIN nodes but with different bit values will result in a logical 0 on buses105,115,125for that bit. Hence, a transmitted bit with logical 1 will be overwritten by a bit with logical value 0, with the resulting value 0 on all LIN buses. That will also occur on the CHECKSUM byte fields transmitted by the first LIN node100and by the second LIN node110. For simplicity, inFIG. 11the exact bit values in each byte fields DATA1trough CHECKSUM are not shown, but the overwriting as such of logical 1 into logical 0 is highlighted on bus-signals105,115,125. Overwriting of data bits in byte fields is not a normal expected part of LIN frame header or LIN frame response transmission or and is advantageously detected by the LIN monitoring device200as an error event.

As a result, any LIN node and also the LIN protocol controller231receiving this LIN frame will interpret the CHECKSUM as being incorrect for the DATA1trough DATA N fields. The LIN protocol handling device will receive the DATA1trough CHECKSUM fields from the combined RXD signal201aor210b. However the frame response byte fields DATA1trough CHECKSUM will appear as valid byte fields if judged only by the VBUSbus voltages, and not considering the validity of the CHECKSUM, on all buses105,115,125.

As is understood, numerous use cases may be envisaged. In the following, a brief list of use cases is discussed.a. A LIN master transmits a LIN frame header and it needs to be determined which LIN node is the LIN master.b. A LIN slave transmits a LIN frame response and it needs to be determined which LIN node is transmitting the LIN frame response.c. More than one LIN slave transmit a LIN frame response and it needs to be determined which LIN slave is transmitting the frame responses. If more than one LIN slave transmit frame response this will likely result in that the response becomes invalid, for several reasons, e.g. simply by checksum error.d. A LIN slave transmits a wakeup signal and it needs to be determined which LIN slave is transmitting the wakeup signal.e. More than one LIN master is connected in the LIN network, which is normally unexpected. LIN network communication thus behaves erratic, and it needs to be determined why there is erratic communication.f. A LIN node is disturbing the bus which causes frame reception failure and it needs to be determined which LIN node is disturbing the bus.g. A LIN network is woken up. This can be due to a LIN master transmitting LIN frame header or a LIN slave transmitting a wakeup signal and it needs to be determined why the LIN network is woken up.

FIG. 12shows a monitoring device200according to an embodiment comprising the signal router202and the LIN protocol controller231previously discussed. However, in this embodiment, the monitoring device200further comprises a memory240where all or a selected part of measurements being performed can be stored and analysed. For instance, statistics may be provided to an operator. Further, individual signals e.g. carried over paths204,214,224,210a, Or210b, may be stored for analysis by an operator or a computer.

Further, the monitoring device200may be provided with a display300where any signal or detected events in the monitoring device200may be displayed. In this example, the LIN frames over path231aand events over path(s)232are provided for display to an operator of the monitoring device200.

Further, the monitoring device200comprises one or more processing units250in which the functionality of the monitoring device200may be implemented. Typically, all functionality of the monitoring device200(except for the display300) may be carried out by such processing unit(s)250, such as that of the transceivers201,211,221, the signal router202, the LIN protocol controller231, etc.

The steps of the method of the monitoring device200for monitoring a plurality of LIN buses according to embodiments may thus in practice be performed by the processing unit250embodied in the form of one or more microprocessors arranged to execute a computer program260downloaded to a suitable storage medium270associated with the microprocessor, such as a Random Access Memory (RAM), a Flash memory or a hard disk drive. The processing unit250is arranged to cause the monitoring device200to carry out the method according to embodiments when the appropriate computer program260comprising computer-executable instructions is downloaded to the storage medium270, being e.g. a non-transitory storage medium, and executed by the processing unit250. The storage medium252may also be a computer program product comprising the computer program260. Alternatively, the computer program260may be transferred to the storage medium270by means of a suitable computer program product, such as a Digital Versatile Disc (DVD) or a memory stick. As a further alternative, the computer program260may be downloaded to the storage medium270over a network. The processing unit250may alternatively be embodied in the form of a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), etc.

In one embodiment, the LIN transceivers of201,211,221, are Integrated Circuit (IC) packaged devices with a transmitter (bus driver) and a receiver (bus line receiver) in the same IC package. In another embodiment the transceivers may be constructed by a plurality of passive components and by linear or digital semiconductor components.

In an embodiment, the LIN transceivers of201,211,221can have at least two configurations of the bus driver output voltage and bus comparator input thresholds, where one selected configurations of a plurality of configuration is in operation. For example, one configuration can be according toFIG. 2, and another configuration can be according to right side ofFIG. 5. There is provided a configuration selection input, in one example in the form of digital selection input pin, in another example there is a serial peripheral interface (SPI) bus.

In one embodiment at least two LIN buses of105,115,125, and at least two transceivers of201,211,221, and the signal router202is part of a LIN bus repeater or LIN bus extender.

In a further embodiment two of LIN buses105,115,125and two of transceivers201,211,221are used with a simplified signal router202. The signal router does not need to have encoder206,216,226. Encoder205is an encoder with two inputs, one being RXD′ output204of a first transceiver and one being RXD′ output214of a second transceiver. The signal routing is simplified compared toFIG. 7; RXD′ output204of a first transceiver is directly connected to a TXD′ input213of a second transceiver, and connected directly to a LIN protocol handling device230. RXD′ output214of a second transceiver is directly connected to a TXD′203of a first transceiver, and connected directly to a LIN protocol handling device230.

In a further embodiment at least LIN buses105,115,125, and at least transceivers of201,211,221, and the signal router202are part of a LIN active star coupler.

In a further embodiment some or all parts of monitoring device200is part of a digital storage oscilloscope with serial bus protocol decoding.

An approach in LIN analysis is to passively and non-intrusively monitor the LIN nodes. This may require extended monitoring time in order to gather sufficient data about the LIN nodes. However, time available for monitoring may be limited and not enough in some scenarios. In a system of LIN nodes, there may be additional conditions caused by other nodes of the system, which affect node operation. Those conditions may not necessarily occur if performing a standalone LIN node test during e.g. LIN conformance verification. Therefore, in an embodiment, an approach is to actively generate and transmit signals over the LIN bus causing a desired result, and to monitor any LIN nodes in operation, e.g. error conditions of the LIN nodes.

LIN nodes receiving the exact same bit-stream of LIN data frames handle errors in the data link layer in the same way.

Conversely, LIN nodes not receiving the exact same bit-stream of LIN data frames may handle errors in the data link layer in different ways. This may happen in e.g. harsh electrical environments such as e.g. motor vehicles, or because of a compromised bus topology, due to LIN bus signal integrity problems. Hence, a certain LIN ECU may or may not be the only LIN node to detect an error.

To evaluate a specific LIN node data link layer operation while detecting errors in a LIN system, two main scenarios are of interest:i. the specific LIN node is the only node to detect a data link error and perform a predetermined action in application layer. Other LIN nodes do not detect an error, andii. at least one other LIN node detects a data link error and performs a predetermined action in application layer.

LIN nodes that do not receive the exact same application signals in a data field of a LIN data frame may handle manipulated signals in different ways or at different instants of time of associated bits in the stream.

To evaluate a specific LIN node application layer operation while receiving manipulated signals in a LIN system, two main scenarios are of interest:i. the specific LIN node is the only node to receive a manipulated signal in a data field, while other LIN nodes receive non-manipulated signals, andii. all LIN nodes receive a manipulated signal in a data field.

FIG. 13illustrates a monitoring device200according to an embodiment comprising a first bit-stream manipulation module281connected in the RXD′ path204and a second bit-stream manipulation module291connected in the TXD′ path203between a transceiver201and a signal router202. The modules281,291are controlled to handle bit manipulation of LIN frame to and from one or more LIN nodes100,110,120(not shown inFIG. 13).

The first bit-stream manipulation module281may optionally be controlled to modify bits in a received LIN data frame from the LIN transceiver201and the first LIN node100before passing the frame to the signal router202. The activation or deactivation of manipulation may be based on a LIN frame identifier in an arbitration field, i.e. a certain bit position in a LIN frame. The manipulation may introduce a data link error, e.g. a checksum error. This manipulation will cause the second and third LIN nodes110,120to receive manipulated LIN frames, and the second and third LIN nodes110,120are expected to detect error. The first bit-stream manipulation module281may be equipped with a manipulation configuration memory, and/or a software executable instruction or similar.

The second bit-stream manipulation module291may optionally be controlled to modify bits in a received LIN data frame from the signal router202before passing the frame to the LIN transceiver201and the first LIN node100. The manipulation can be based on detecting a specific value of a received identifier, i.e. a certain bit position in a LIN frame. The manipulation may introduce a data link error e.g. a checksum error. This manipulation will cause the first LIN node100to receive manipulated LIN frames, and the first LIN node100is expected to detect errors.

LIN frames contain a cyclic redundancy checksum so that a receiver of the frames can validate the received frame as having no data link layer errors and therefore being correctly received or alternatively having errors (there is an eight-bit checksum field). This results in a certain degree of tolerance to some minor modification of the bit-stream (including e.g. data field) for which the checksum is calculated, where the resulting modified data field will result in an identical checksum as before the modification. However, this is in most situations unlikely. A majority of possible modifications of only a data field of a LIN frame will have as a consequence that such frame will be rendered invalid (and cause a checksum error), unless the checksum is properly modified as well.

The first bit-stream manipulation module281may optionally be controlled to modify bits in a data field and a checksum field of a received LIN frame from the LIN transceiver201and the first LIN node100before passing the manipulated LIN frame to the signal router202. If the data field is modified, then it is likely that in order for the frame to still be rendered valid and considered as having no checksum error by receiving LIN node110,120, the checksum need to be recalculated and the checksum field modified as well. No errors are induced on data link layer. The manipulation can be based on detecting a specific value of a received identifier, receiving a specific signal value in a data field, or a certain bit position in a LIN data frame. The manipulation can be based on a LIN database where position and size of a signal in a LIN data field is defined. The first module281may recalculate a new correct checksum based on the resulting manipulated content of data field, as well as other preceding frame fields that are used for checksum calculation and replace the checksum field.

It is noted that the first bit-stream manipulation module281may be implemented using a full LIN protocol controller in order to decode received frames and encode new or modified frames passed on to the signal router202.

The second bit-stream manipulation module291may optionally be controlled to modify bits in a data field and a checksum field of a received LIN frame from the signal router202before passing the manipulated LIN frame to the LIN transceiver201and the first LIN node100. If data field is modified, then it is likely that in order for the frame to still be rendered valid and considered as having no checksum error by the receiving first LIN node100, the checksum need to be recalculated and checksum field modified as well. No errors are induced on data link layer. The manipulation can be based on detecting a specific value of a received identifier in an arbitration field, receiving a specific signal value in a data field, or a certain bit position in a LIN frame. The manipulation can be based on a LIN database where position and size of a signal in a LIN data field is defined. The second module291may recalculate a new correct checksum based on the resulting manipulated content of data field, as well as other preceding frame fields that are used for checksum calculation and replace the checksum field.

It is noted that the second bit-stream manipulation module291may be implemented using a full LIN protocol controller in order to decode received frames and encode new or modified frames passed on to the LIN transceiver201.

Further, only first and second bit-stream manipulation modules281,291are shown inFIG. 13. However, the monitoring device200may also comprise corresponding bit-stream manipulation modules between transceivers211,221and the signal router202, respectively similar to281,291also between LIN transceivers211,221and signal router202. While the bit-stream manipulation modules281,291modify the bit-stream, the LIN nodes100,110,120can be monitored by the LIN protocol handling device230as described previously.

The aspects of the present disclosure have mainly been described above with reference to a few embodiments and examples thereof. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims. Example of other embodiments are other one-wire or single ended bus systems than LIN, where at least two bus states exist and using transceivers with other transmitted bus voltage levels and receiving thresholds, and other data link layer protocols and other protocol specific events.