Patent ID: 12206521

DETAILED DESCRIPTION

ExampleFIG.1shows a CAN bus system100with a plurality of nodes or ECUs (Electronic Control Units)101-104connected to the same CAN bus wires105comprising a first CANH wire and a second CANL wire. The nodes101-104may comprise nodes that implement Classical CAN, CAN FD nodes that implement the CAN FD protocol or CAN XL nodes that implement the new CAN XL protocol.

ExampleFIG.2shows one of the nodes101-104in more detail. A node mainly comprises a CAN controller200, such as a microcontroller, that implements the CAN, CAN FD or CAN XL protocol such as by using an embedded CAN, CAN FD or CAN XL protocol controller201. The CAN controller200may be known as a host. The controller200and, more particularly, the protocol controller201is connected to the CAN bus105by a CAN transceiver202. The CAN controller200is connected to the CAN transceiver202through two interface connections called TXD (Transmit Data)203and RXD (Receive Data)204. The controller may therefore have a transmit output terminal that couples with a transmit input terminal of the CAN transceiver202. Likewise, the CAN transceiver202may have a receive output terminal that couples with a receive input terminal of the CAN controller200. The transceiver202is used to convert transmit-data, comprising a digital bit stream on TXD203, into analogue signalling on the bus wires105using a transmitter module205. The transceiver202is also used to convert analogue signalling from the bus105into receive-data comprising a digital output signal or bit stream by a receiver module206for providing to the RXD connection204. The transmitter module205is thus configured to convert the transmit-data into dominant bit and recessive bit differential signals for the bus105. The receiver module206is thus configured to receive the differential signals from the bus105and determine the presence of either a dominant bit or a recessive bit and generate the receive-data based thereon. In general, the CAN transceiver comprises an interface device to the network and the CAN controller comprises a controller that is configured to transmit data to and receive data from the network via the interface device.

In one or more examples, and for context, if node103is transmitting a CAN frame, the receiving nodes101,102and104, are, according to the CAN protocol, configured to verify the received frame and may acknowledge the frame or invalidate the frame with an error frame. The error frame can be transmitted during the frame or in an End Of Frame (EOF) field. If there is an error frame transmitted on the bus, all receiving nodes101,102,104will discard the frame they just received and the transmitting node103will optionally retry to transmit the frame for a number of times. With this property each node has a veto with which it can invalidate a frame on the bus105.

The CAN protocol includes different types of errors that may cause a CAN controller to transmit an error frame. The error frames that may be transmitted during a CAN frame, and prior to a CRC delimiter field, are a result of bit errors, form errors and/or stuff errors. A bit error is detected by transmitting nodes if they do not receive back in the receive-data what they have transmitted in the transmit-data. A form error is detected if a predefined bit of the CAN frame does have the correct value according to the CAN protocol. A stuff error is detected when the CAN stuffing rule is not obeyed and too many bits with the same value are transmitted consecutively, which is in most cases no more than five bits.

CAN transceivers may be configured to be protocol aware, meaning that they can identify one or more parts of a CAN frame and provide functions in response to one or more parts of the CAN frame received from the signalling from the bus105. The CAN transceiver may be equipped with a CAN ISO11898 compliant receiver that is capable of decoding frames on the bus. The CAN transceiver may include clock recovery functionality to synchronize with the timing of CAN frames in the receive-data and/or the transmit-data.

In one or more examples, the protocol aware part of the CAN transceiver is observing the CAN frames and bits therein on the bus105from a different location from the CAN protocol controller201in the CAN transceiver.

Accordingly, due to the point where the protocol aware transceiver is observing the bus, the protocol aware transceiver202may not sample the same value from the bus105as the CAN protocol controller201of the local host, even if the sample point configuration is identical. It may be that the CAN protocol controller201is sampling slightly earlier and, if a dominant bit is stretched more than the allowed arbitration delay, it can occur that the local host will sample a dominant bit while the protocol aware transceiver samples a recessive bit. Further, if the bit sampled dominant by the CAN protocol controller201is, for example, the sixth dominant bit in a row, the CAN protocol controller201will detect a stuff error and then generate an error frame. The protocol aware transceiver did not detect a stuff error and will determine that the stuff error frame from the CAN protocol controller as illegally generated, but from the point of view of the CAN protocol controller it was validly generated.

We disclose an example apparatus210that may, in one or more examples, be configured to evaluate the signalling on the bus105to determine signalling metadata. With this signalling metadata, the apparatus may be configured to determine whether the actions of the CAN protocol controller, such as the generation of one or more error frames or error signals, are legal or illegal wherein the metadata may be used to account for the apparatus210sampling the receive data from the CAN bus from within or near the CAN transceiver202while the CAN protocol controller201is sampling the receive data from the CAN bus from within the CAN controller200. An error frame may be of the form defined in the CAN protocol. An error frame may comprise a frame as defined by ISO11898-1. An error signal can be any signal provided to the bus that corrupts the current frame.

If a node has a CAN controller or associated host with a defect or compromised software, it can occur that the node will try to invalidate CAN frames that are received correctly and that should have been acknowledged according to the CAN protocol. A compromised CAN controller or host may abuse the error management of the CAN standard to perform a denial of service attack by invalidating all frames on the bus or mute one of the other nodes by selectively invalidating frames with certain IDs or CAN frame formats. For safety and security reasons this is unwanted behaviour. Thus, in one or more examples, providing an apparatus210that may identify illegal behaviour of the CAN controller more effectively, such as with fewer false positives, may be advantageous.

Thus, in one or more example embodiments of the disclosure, the CAN transceiver202may additionally include an apparatus210configured to receive the receive-data, the receive-data comprising a plurality of bits. The apparatus may be configured to receive the transmit-data.

The apparatus210may be configured to, for each of one or more bits of the plurality of bits of the receive-data, sample the receive-data at a respective sample time to determine a respective value of each of the one or more bits in the receive-data. The sample time may be defined at a network level such that each node101-104coupled to the CAN bus network samples the signalling from the CAN bus at a substantially equivalent time during each bit. It will be known to those skilled in the art that this sampling time may be set at, for example, 80% (or other percentage) through a bit time such that any ringing that may occur has time to settle before the value of the bit is sampled. However, the precise time that the sample time occurs depends at least on clock drift of a clock in each node or each CAN controller that is used to determine the sample time.

The apparatus210comprises an edge detector (not shown inFIG.2). The edge detector is configured to detect edges, that is transitions between values of the bits, in the receive-data. In one or more examples, the edge detector is configured to determine, during a respective edge detector window, the occurrence and/or non-occurrence of an edge in the receive-data. The edge detector, such as in combination with the apparatus, may be configured to generate metadata that is indicative of an edge having occurred and/or not-occurred during the respective edge detector window. The edge detector window comprises a period of time, in each of the one or more of the plurality of bits, that extends from a first time to a second time and that includes the sample time. The edge detector window will be described in more detail with reference toFIG.5below.

Further, in one or more examples, the apparatus210is configured to determine whether or not the transmit-data is compliant with one or more rules based on the respective values of each of the one or more bits and the metadata. Thus, because the metadata is used as part of the assessment of the transmit data, decisions made by the apparatus210on whether the transmit-data is compliant may be improved in one or more examples. If the apparatus210determines that the transmit-data is non-compliant, even when accounting for the metadata, then a control action may be taken.

In one or more examples, the apparatus205may be configured to block or allow the transmit-data received on TXD203from being received by the transmitter module205of the CAN transceiver202. In one or more examples, the apparatus may be configured to use the metadata to determine whether to take action or not take the control action in limiting access to the CAN bus105for the CAN controller200.

The determination of compliance with the one or more rules by the apparatus may include determining whether one or more CAN frames present in the transmit-data and that represent reactions of the CAN controller to the state of the bus have been generated correctly.

The apparatus210may thus be CAN protocol aware (e.g. to an extent necessary), meaning that it can identify one or more parts of a CAN frame and provide its control in response to one or more parts of the CAN frame being transmitted and/or present in the signalling on the bus105. The apparatus210may include a CAN ISO11898 compliant receiver that is capable of decoding frames from the bus105, such as in the receive-data from the receiver module206. However, it will be appreciated that the apparatus210may not require all the functionality provided in ISO11898 and may, instead, be configured to decode CAN frames according to one or more predetermined decoding rules, which may be derived from or comprise a subset of the rules defined in ISO11898 for a CAN receiver.

In one or more examples, the apparatus210may be configured to detect errors in the receive-data. The apparatus210will therefore know whether an error frame generated by the CAN controller and present in the transmit-data was generated at an appropriate time. Thus, the one or more rules used by the apparatus210to determine compliance may include the detection of an error frame in the transmit-data only at times the apparatus210detects an error is present in the receive-data.

It will be appreciated that the apparatus210may be configured to determine one or more of the potential errors according to the CAN protocol. For example, the apparatus may be configured to determine that at error is present in the receive-data if one or more of the following receive-data rules is contravened:a stuff error rule, the stuff error rule defining adherence to a stuffing rule for the CAN protocol;a CRC error rule, the CRC error rule defining that the CRC field indicates that the data in the data field is correct;a form error rule, the form error rule defining one or more expected values of predetermined bits in a CAN frame according to the CAN protocol; anda bit error rule, the bit error rule defining that bits in the transmit-data should be seen in the receive-data.

A more detailed view of the apparatus210is provided inFIG.3.FIG.3shows an example of the functional parts the apparatus210may require. The same reference numerals as used inFIG.2are also used inFIG.3for like parts.

In summary, the apparatus210is for a CAN transceiver. InFIG.3, the apparatus210is shown as part of the CAN transceiver202and as an interface between the combination of the receiver module206and the transmitter module205and the receive output terminal301and the transmit input terminal302. In other examples, the apparatus210may be external to the CAN transceiver202, and couple to the receive output terminal301and the transmit input terminal302. In such a configuration, the transmit-data from the CAN controller200may pass through the apparatus210to the transmit input terminal302and the receive-data received from the receive output terminal301may be passed to the CAN controller through the apparatus210.

In whichever configuration, the apparatus210may comprise a first input320for receiving transmit-data generated by a CAN controller200. The transmit-data, as will be familiar to those skilled in the art, causes the CAN transceiver202to transmit signalling that represents said transmit-data on the CAN bus, such as by way of the transmitter module205. Further, the apparatus210may comprise a second input321for receiving receive-data, wherein the receive-data is indicative of signalling from the CAN bus105, which may be received from the receiver module206.

The apparatus210comprises protocol-and-sampling block303configured to read the CAN frames and signalling in the transmit-data and the receive-data. To provide such functionality and subsequent control, the protocol-and-sampling block303includes a first timing recovery block304for determining the signal timing in the transmit-data. Further, the protocol-and-sampling block303includes a second timing recovery block305for determining the signal timing in the receive-data. An edge-timing-check block306is configured to receive the transmit data and check the timing of the edges, that is transitions between dominant and recessive bits, in the transmit-data for errors or compliance with the CAN protocol. A bus-state block307is configured to determine the state of the bus from the receive data. Accordingly the bus-state block may be configured to determine one or more of the type of CAN frame being received, the part of the frame being received and whether the bus105is in use or not. A violation-detector-and-TXD-gating block308is configured to provide for detection of the violation of one or more predetermined rules in the transmit data. The violation of the one or more predetermined rules may be determined based on the content of the transmit-data and the current state of the bus105, determined from the receive-data.

In general and in one or more examples, the apparatus210comprises one or more clock recovery modules to determine the bit timing in the receive-data and/or the transmit-data and is configured to follow the CAN protocol and to determine if the bit timing that is observed is in accordance with one or more bit timing rules (which may be or be based on bit timing rules of the CAN protocol). The apparatus may thereby be able to detect the presence or absence of errors in a received CAN frame from the CAN bus105and therefore determine whether or not a reaction of the CAN controller200is appropriate.

The protocol-and-sampling block303may be configured to receive one or more reference signals to provide these functions. Thus, a bit-timing-settings block312is configured to store the bit timing settings for the CAN network, as will be familiar to those skilled in the art. A clock313provides a clock signal.

The violation-detector-and-TXD-gating block308, or more generally the apparatus210, may be configured to perform one or more control actions.

In one or more examples, a first control action may be to isolate or block the transmit-data from reaching the receiver module205or the bus105. In this example, the violation-detector-and-TXD-gating block308or more generally the apparatus may be configured to manipulate the transmit data that is provided to the transmitter module205by way of one or more signals provided at a first output322. The signals from the first output322may control switch310. Switch310may interrupt the connection between the transmit input terminal302and the transmit module205. In other examples, the signal322may be configured to insert or change bits in the transmit-data. Thus, if the apparatus determines that the transmit-data is not compliant, the apparatus210may prevent transmission by said CAN transceiver of said signalling that represents said transmit-data by one or more of: modification of the transmit-data; blocking of the transmit-data from receipt by a transmitter module of the CAN transceiver, the transmitter module configured to translate the transmit-data into differential voltage levels for transmission on the CAN bus; and blocking of the output of the transmitter module of the CAN transceiver, the transmitter module configured to translate the transmit-data into differential voltage levels and output said differential voltage levels to the CAN bus.

In one or more examples, a second control action may be to provide for transmission of dominant bits on the bus to invalidate the frame. In this example and one or more other examples, the violation-detector-and-TXD-gating block308or, more generally, the apparatus, may be configured to send error frames by providing appropriate signals to the transmit module205from a second output311. This control action may be used if the apparatus is configured to detect errors in the receive-data independent of the CAN controller.

In one or more examples, a third control action may be to modify the receive-data that is passed to the CAN controller200. In this example, the violation-detector-and-TXD-gating block308or, more generally, the apparatus, may be configured to manipulate the receive-data that is provided to the CAN controller200by one or more signals provided at a third output323. The signals from third output323may control switch309. Switch309may interrupt the connection between the receive module206and the receive output terminal301. In other examples, the signals at third output323may be configured to insert or change bits in the receive data.

In one or more examples, a fourth control action may be to do nothing because the metadata is indicative of an edge having been detected. This may mean that there is a chance that any suspicious behaviour of the CAN controller can be explained by the possibility that it sampled a different value in the receive data from that sampled by the apparatus210.

It will be appreciated thatFIG.3provides one example of an implementation of the apparatus210. In other implementations, the functions of the apparatus210described herein may be provided by a general purpose processor with appropriately configured software or a FPGA or a PLC or a dedicated die. Accordingly, in the description that follows, the functionality will be described as being provided by the apparatus210in general rather than by one or more of the blocks, such as block308.

To provide further context, and with reference toFIG.4, we can consider a possible architecture for a protocol engine of the CAN protocol controller201in the CAN controller200. The protocol engine typically comprises a transmit part401and a receive part402with a common Bit Stream Processor (BSP)403and frame buffers. Thus, data generated for transmission is passed from the transmit buffer404, to the BSP403and into the transmit part401before being sent on TXD203. Further, receive-data from RXD204is received into the receive part402, is passed to the BSP403and then to the receive buffer405. The transmit part401and the receive part402can have different notions of time. If the protocol engine has nothing to transmit and is only listening on the bus, the receive part is synchronizing to the timing of the signalling on the bus105, received via the CAN transceiver202. Sampling of the receive-data will be done with that recovered timing and will define a sampling time. If the protocol engine is also transmitting or participating in arbitration, it may be configured to sample the receive-data from the CAN transceiver202with a sample pulse based on time that is synchronized with the timing used to generate the transmit-data. This sample time will likely be ahead of the sample time in the receive path, as the delay introduced by the CAN transceiver202may not be accounted for.

Thus, if we consider possible differences between the timing used by the protocol engine of the CAN protocol controller201and the timing used by a protocol aware CAN transceiver, the CAN transceiver will be synchronizing on the data received from the bus, but may be slightly ahead of the receive part in the CAN protocol controller201, as it does not have the input-output delay between CAN transceiver202and the CAN controller200included. Further, the CAN protocol controller201and the protocol aware CAN transceiver may use independent clock sources, which have their own accuracy tolerances, which could also cause differences in timing between the protocol aware transceiver and the CAN controller200.

The apparatus210, in one or more examples, may be configured to mitigate against the sampling of different values in the receive-data. The apparatus210, in one or more examples, may then be able to reliably determine suspicious or erroneous behaviour of the CAN controller200rather than reach a false positive conclusion caused by the described timing discrepancies.

ExampleFIG.5shows a representation of the receive-data501comprising a plurality of bits. A first bit502is shown inFIG.5followed by a second bit503. Each bit is provided over a nominal bit time504defined by the protocol. However, due to delays on the bus, such caused by an arbitration delay, the first bit502may or may not be stretched over a longer bit time505.

A first timing diagram510shows the sampling of the bits of the receive-data501by the apparatus210.

A second timing diagram520shows the sampling of the bits of the receive-data501by the CAN controller200when using a clock reference that is configured to be synchronized with the receive-data.

A third timing diagram530shows the sampling of the bits of the receive-data501by the CAN controller200when using a clock reference that is configured to be synchronized with the transmit-data generated by the CAN controller200.

With reference to the second timing diagram520, the CAN controller200is shown to sample the receive-data at a sample time521. The sample time521may however occur at any time within a sampling window522due to clock drift.

With reference to the third timing diagram530, the CAN controller200is shown to sample the receive-data at a sample time531earlier than the sample time521. The sample time531may however occur at any time within a sampling window532due to clock drift.

With reference to the first timing diagram510, the apparatus210is configured to receive each of the one or more bits502,503of the plurality of bits of the receive-data, and sample the receive-data501at a respective sample time511(and subsequently sample time513). The sample time511may however occur at any time within a sampling window512due to clock drift of the clock of the apparatus210. Sampling at sample point511will determine a respective value of the first bit502of dominant or logic 0.

However, a change in the value of the bits502,503may occur at the end of the nominal bit time504at time point506or at some point after considering the possible arbitration delay. Thus, with the sampling window522very close to the time point506, the CAN controller may sample a different value at the nominal bit time504because the receive-data may transition from the first bit502to the second bit503at any time between506and the end of the period505. Similarly, when sampling the next bit503, the first bit502may have been stretched, by the arbitration delay, over the time505and therefore the sample time513,523,533may occur close to the change in bit value at time508.

FIG.5shows the edge detector window514in which the edge detector (such as embodied as edge-timing-check block306) is configured to determine the occurrence or non-occurrence of an edge507in the receive-data501. The edge detector window514comprises a period of time for each sample time511that extends from a first time515, prior to the sample time, to a second time516, after the sample time, and therefore the window includes the sample time511.

The size of the period of time of the edge detector window514may be configured to encompass a maximum clock drift that may occur in one or more clocks used by the CAN controller200to determine the sample time521and/or sample time531. Thus, in this example, the edge detector window514is configured to extend from a time of a lower bound of the sample window532to a time of an upper bound of the sample window522.

In one or more examples, the edge detector window514is configured to end before an earliest possible edge of a subsequent bit, i.e. before time506in this example.

As mentioned above, the edge detector is configured to generate metadata that is indicative of an edge having occurred or not-occurred during the respective edge detector window514. Thus, the metadata and, in particular, the metadata when it indicates that an edge occurred near (defined by the window514) a respective sample time511may be indicative of a risk that the CAN controller200has sampled the receive-data and determined a different bit value to that of the apparatus210.

In one or more examples, the apparatus210may be configured to perform a control action to ensure that the sampling of the bit by the CAN controller200is consistent with the sampling of the bit by the apparatus. Thus, in one or more examples, the apparatus210may be configured to modify the receive-data that is to be sent to the CAN controller, wherein the apparatus is configured to latch the value of a respective bit during the respective edge detector window, such that the value of the bit is held constant during the respective edge detector window. This ensures that the CAN controller200samples the same value of the bit as that sampled by the apparatus210. This latching during the edge detector window time may be performed only in certain predetermined bit fields of the CAN frame. For example, for one or more selected bits outside the arbitration field. The one or more selected bits may exclude stuff bits.

According to the protocol and in a clean environment (e.g. with no delays or timing errors), no edges should occur in this edge detector window514. However, due to disturbances and noise, it can occur that there is an edge on the bus. The metadata from the edge detector therefore informs the apparatus210on the possibility of the CAN controller generating an error frame that, from the point of view of the CAN controller200has of the receive-data was validly generated, but from the point of view of the apparatus210was not.

In this example, the period of time that defines the edge detector window may be predetermined. In some examples, a measure of the clock drift of the CAN controller may be taken (i.e. a so called clock drift parameter defining the accuracy of a clock or susceptibility to drift) during a calibration phase and used to determine the duration of the edge detector window. In other examples the period of time that defines the edge detector window may be fixed, such as up to 50%, 40%, 30%, 20% or 10% of the duration of the bits in the receive-data. The edge detector window may be substantially symmetrical about the sample time511. The size of the edge detector window may be application specific and set during a configuration phase. For example, it may be set at any value up to 30% (or other limit) of the bit time. The period of time of the edge detector window may vary through a CAN frame. For example, it may comprise a first, longer length during arbitration and a shorter length at other times. In other examples, where CAN FD and CAN XL is used, the edge detector window is shorter to correspond to the shorter bit time. In general, the edge detector window may be less than the shortest bit time of the bits currently present in the receive-data.

Thus, the apparatus210may be configured to, based on:i) detection of an error frame, in the transmit-data, sent by the CAN controller;ii) determination that an error has occurred in the receive-data based on the sampled respective values of each of the one or more bits in the receive-data and predetermined protocol rules; andiii) the metadata does not indicate the occurrence of an edge associated with said one or more bits;
determine that the error frame was validly generated.

Further, the apparatus210may be configured to, based on:i) detection of an error frame, in the transmit-data, sent by the CAN controller;ii) determination that an error has not occurred in the receive-data based on the sampled respective values of each of the one or more bits in the receive-data and predetermined protocol rules; andiii) the metadata does indicate the occurrence of one or more edges associated with the one or more bits;
determine that the error frame was validly generated and/or that there was a possibility that the error frame was validly generated. It will be appreciated that it may be determined that it was validly generated from the point of view of the CAN controller.

Thus, without the metadata, the apparatus210may have determined that the error frame was invalidly generated in this second case and may have taken a control action against the CAN controller200to restrict its transmissions or to silence it. However, by use of the metadata, such action may not be taken or different action may be taken.

In summary, the apparatus210may determine whether or not the transmit-data is compliant with one or more rules based on the respective values of each of the one or more bits and the metadata using any desired algorithm.

However, the metadata provides additional information to avoid mis-categorising the transmit-data. Thus, determination of the transmit-data being non-compliant with the one or more rules is less likely when the metadata is indicative of the occurrence of an edge in the edge detector window for one or more recent bits of the one or more bits than when the metadata is indicative of the non-occurrence of an edge in the edge detector window for the one or more recent bits of the one or more bits. It will be appreciated that the metadata for several recent bits may be required before a decision of non-compliance can be determined.

The detection of edges could also be used to detect tampering on the bus or other diagnostic functions. In one or more examples, the apparatus may be configured to, using the metadata and one or more predetermined rules, identify one or more nodes that are coupled to the CAN bus that are generated edges at times where it is not expected. The apparatus may then be able to send one or more signals to take action against those one or more nodes.

FIG.6illustrates an example method for a CAN transceiver, the CAN transceiver configured to couple to a CAN bus and generate receive-data based on one or more signals received from the CAN bus and generate one or more signal on the bus in response to transmit-data received from a CAN controller, wherein the method comprises:receiving601the receive-data, the receive-data comprising a plurality of bits; andfor each of one or more bits of the plurality of bits of the receive-data, sampling602the receive-data at a respective sample time to determine a respective value of each of the one or more bits in the receive-data; anddetermining603by an edge detector, during a respective edge detector window, the occurrence or non-occurrence of an edge in the receive-data and generate metadata that is indicative of an edge having occurred or not-occurred during the respective edge detector window and wherein the edge detector window comprises a period of time, in each of the one or more of the plurality of bits, that extends from a first time to a second time and that includes the sample time;receiving604the transmit-data; anddetermining605whether or not the transmit-data is compliant with one or more rules based on the respective values of each of the one or more bits and the metadata.

FIG.7shows a non-transitory computer readable medium comprising computer program code which is configured to cause a processor and a memory to perform the method ofFIG.6.

The instructions and/or flowchart steps in the above figures can be executed in any order, unless a specific order is explicitly stated. Also, those skilled in the art will recognize that while one example set of instructions/method has been discussed, the material in this specification can be combined in a variety of ways to yield other examples as well, and are to be understood within a context provided by this detailed description.

In some example embodiments the set of instructions/method steps described above are implemented as functional and software instructions embodied as a set of executable instructions which are effected on a computer or machine which is programmed with and controlled by said executable instructions. Such instructions are loaded for execution on a processor (such as one or more CPUs). The term processor includes microprocessors, microcontrollers, processor modules or subsystems (including one or more microprocessors or microcontrollers), or other control or computing devices. A processor can refer to a single component or to plural components.

In other examples, the set of instructions/methods illustrated herein and data and instructions associated therewith are stored in respective storage devices, which are implemented as one or more non-transient machine or computer-readable or computer-usable storage media or mediums. Such computer-readable or computer usable storage medium or media is (are) considered to be part of an article (or article of manufacture). An article or article of manufacture can refer to any manufactured single component or multiple components. The non-transient machine or computer usable media or mediums as defined herein excludes signals, but such media or mediums may be capable of receiving and processing information from signals and/or other transient mediums.

Example embodiments of the material discussed in this specification can be implemented in whole or in part through network, computer, or data based devices and/or services. These may include cloud, internet, intranet, mobile, desktop, processor, look-up table, microcontroller, consumer equipment, infrastructure, or other enabling devices and services. As may be used herein and in the claims, the following non-exclusive definitions are provided.

In one example, one or more instructions or steps discussed herein are automated. The terms automated or automatically (and like variations thereof) mean controlled operation of an apparatus, system, and/or process using computers and/or mechanical/electrical devices without the necessity of human intervention, observation, effort and/or decision.

It will be appreciated that any components said to be coupled may be coupled or connected either directly or indirectly. In the case of indirect coupling, additional components may be located between the two components that are said to be coupled.

In this specification, example embodiments have been presented in terms of a selected set of details. However, a person of ordinary skill in the art would understand that many other example embodiments may be practiced which include a different selected set of these details. It is intended that the following claims cover all possible example embodiments.