Patent Description:
Electronics systems and devices in a vehicle are typically required to comply with functional safety requirements. Functional safety requirements are specified, for example, in the ISO <NUM>-<NUM>:<NUM> standard entitled "Road vehicles - Functional safety," December, <NUM>.

NPL document ""<NPL>, discloses the online monitoring of a CAN bus in an automotive network and validation of functional safety requirements by sniffing the messages and verification of message content vs. safety requirements.

<CIT> discloses using PTP to check whether an automotive network is operating correctly. Specifically, the system calculates the time difference between the local time and the timestamp of a received frame. If the time difference exceeds a predefined threshold, a synchronization error is detected.

The description above is presented as a general overview of related art in this field and should not be construed as an admission that any of the information it contains constitutes prior art against the present patent application.

An embodiment that is described herein provides a network element (switch) for use in an automotive network in a vehicle. The switch includes one or more ports, packet processing circuitry and a validation data collector. The one or more ports are configured for communicating over the automotive network in the vehicle. The packet processing circuitry is configured to perform the steps set out in claim <NUM>.

In some embodiments, the validation data collector is configured to derive and export validation records comprising one or more of: time-stamps extracted from one or more of time-protocol packets; one or more parameters of the one or more ports used for communicating one or more of the time-protocol packets; and error events relating to one or more of the time-protocol packets. According to the invention, the time-protocol packets include Precision Time Protocol (PTP) packets.

In a disclosed embodiment, the validation data collector is configured to store the validation data in a memory, and to provide at least part of the validation data in response to a request from outside the network element. In another embodiment, the validation data collector is configured to transmit at least part of the validation data from the network element, irrespective of any request from outside the network element.

There is additionally provided, in accordance with an embodiment that is described herein, a safety validation apparatus for use in a vehicle. The apparatus includes an interface and a validation processor. The interface is configured for communicating at least with a network element of an automotive network in the vehicle. The validation processor is configured to obtain from the network element validation data indicative of processing of time-protocol packets by the network element, and to verify, based on the validation data, that the network element complies with a vehicle-safety requirement.

In an embodiment, the validation processor is configured to verify that the network element complies with the vehicle-safety requirement by verifying an accuracy of one or more time-stamps in the time-protocol packets. In another embodiment, the validation processor is configured to verify that the network element complies with the vehicle-safety requirement by verifying that a temporal pattern of the time-protocol packets matches an expected pattern. In yet another embodiment, the validation processor is configured to verify that the network element complies with the vehicle-safety requirement by verifying a topology of the automotive network.

There is also provided, in accordance with an embodiment that is described herein, a method for use in a network element of an automotive network in a vehicle as set out in claim <NUM>.

There is further provided, in accordance with an embodiment that is described herein, a safety validation method for use in a vehicle. The method includes obtaining, from a network element of an automotive network in the vehicle, validation data indicative of processing of time-protocol packets by the network element. A verification is made, based on the validation data, that the network element complies with a vehicle-safety requirement.

The present disclosure will be more fully understood from the following detailed description of the embodiments thereof, taken together with the drawings in which:.

Safety-critical components of a vehicle are typically required to comply with functional safety requirements, such as requirements specified in the ISO <NUM>-<NUM>:<NUM> standard, cited above. Network elements deployed in the vehicle, e.g., Ethernet switches, are examples of safety-critical components. In practice, however, commercial network elements do not always comply with functional safety requirements. Redesigning a network element for selfcontained full compliance is complex and expensive.

Embodiments described herein provide methods and systems for verifying that network elements of an automotive network are functionally safe, even though the network elements are not themselves compliant to be used in a functional safety environment.

The disclosed techniques make use of time-protocol packets that are communicated among the network elements as part of the normal operation of the automotive network. For example, many automotive networks use the Precision Time Protocol (PTP) for internal synchronization among network elements and/or for synchronization with external events. The use of PTP in Local-Area Networks (LANs) is specified, for example, in the IEEE <NUM>. 1AS-<NUM> standard, entitled "IEEE Standard for Local and Metropolitan Area Networks - Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks," June <NUM>, <NUM>, whose disclosure is incorporated herein by reference. The use of PTP involves on-going transmission of PTP packets carrying time-stamps across the automotive network. The disclosed techniques monitor such time-protocol packets and use the monitoring results for functional safety validation.

In some embodiments, an automotive network in a vehicle comprises multiple network elements, e.g., Ethernet switches. Each network element comprises one or more ports for receiving and transmitting packets over the network, and packet processing circuitry that processes received packets and forwards them back to the network. Some of the packets processed by the packet-processing circuitry are time-protocol packets, e.g., PTP packets.

In some embodiments, each network element further comprises a validation data collector that derives validation data from the time-protocol packets that are processed by the packet-processing circuitry. Validation data is also referred to herein as validation records, and the two terms are used interchangeably herein. The validation data may comprise any suitable information that relates to the time-protocol packets and is indicative of compliance of the network element with functional safety requirements. Non-limiting examples of validation data include time-stamps extracted from time-protocol packets, parameters of ports used for communicating time-protocol packets, and error events relating to time-protocol packets. The validation data collector makes the validation data accessible for readout from outside the network element via a suitable interface. The interface may be an Ethernet interface, for example, or any other suitable interface.

In some embodiments the network further comprises an additional node, referred to herein as "functional safety validator," or simply "validator" for brevity. The validator obtains validation data from the various network elements and verifies, based on the validation data, whether the network elements comply with the relevant functional safety requirements.

In various embodiments, the validator may analyze the validation data in any suitable way to verify the functional safety of the network elements, and of the network as a whole. Several examples are suggested herein. In some embodiments, the network elements present an interface that enables the validator to retrieve validation data as needed. With an interface of this sort, the definition of validation tests can be made vendor-specific, e.g., left to the discretion of the vehicle manufacturer.

In summary, the techniques disclosed herein enable an automotive network to comply with applicable functional safety requirements, without mandating that every individual network element be compliant. This solution minimizes the additional hardware or software that needs to be added to network elements for the sake of functional safety validation. By making use of existing time-protocol packets, the disclosed solution also minimizes the additional network traffic needed for functional safety validation.

The embodiments described herein mainly focus on automotive networks, and on vehicle-safety as a special case of functional safety. Generally, however, the disclosed techniques are not limited to automotive environments. The disclosed techniques may be used in any suitable system or application in which communication devices are required to comply with functional safety requirements. Such applications may include, for example, industrial communication networks, aviation communication networks, aerospace communication systems, and many others.

<FIG> is a block diagram that schematically illustrates an automotive data-processing system <NUM>, in accordance with an embodiment that is described herein. System <NUM> is disposed in a vehicle, and comprises various sensors <NUM>, multiple Electronics Control Units (ECUs) <NUM>, an Advanced Driver-Assistance System (ADAS) <NUM>, an infotainment system <NUM> and a central computer <NUM>. By way of non-limiting example only, embodiments herein are described in the context of automobiles.

In various embodiments, sensors <NUM> may comprise, for example, video cameras, velocity sensors, accelerometers, audio sensors, infra-red sensors, radar sensors, lidar sensors, ultrasonic sensors, rangefinders or other proximity sensors, or any other suitable sensor type. In the present example, each ECU <NUM> (sometimes referred to as a "zone ECU") is connected to the sensors installed in a respective zone of the vehicle. Each ECU <NUM> typically controls its respective sensors <NUM> and collects data from the sensors.

The various sensors <NUM> and the various electronic systems (e.g., ECUs <NUM>, ADAS <NUM>, infotainment system <NUM> and central computer <NUM>) are referred to collectively as "electronic subsystems" or "subsystems". In some embodiments, the various electronic subsystems of system <NUM> communicate over a packet network installed in the vehicle. In the present example the network comprises an Ethernet network, but other suitable protocols can also be used. The network comprises multiple Ethernet links <NUM>, and one or more Ethernet switches <NUM>. In various embodiments, the bit rate used in the network may be <NUM> bits per second (10Gbps) in accordance with IEEE <NUM>. 3ch, 100Mbps in accordance with IEEE <NUM>. 3bw, 10Mbps in accordance with IEEE <NUM>. 3cg(10Base-T1s), or any other suitable bit rate. Links <NUM> may comprise, for example, twisted-pair copper links or any other type of link suitable for Ethernet communication.

In some embodiments, system <NUM> further comprises a functional safety validator <NUM>, referred to herein as "validator" for brevity. Validator <NUM> is configured to validate the compliance to functional safety requirements of Ethernet switches <NUM> using methods that are described in detail below. In various embodiments, validator <NUM> may be a stand-alone or dedicated system component, or a device that is integrated into other system components such as an onboard computer or other computer processing device disposed in the vehicle.

An inset at the bottom-left of <FIG> illustrates the internal configuration of an example Ethernet switch <NUM>, in an embodiment. Other switches <NUM> in system <NUM> typically have similar configurations. In the present example, switch <NUM> comprises multiple ports <NUM>, packet processing circuitry <NUM>, a validation data collector <NUM>, a validation data interface <NUM> and a memory <NUM>. Ports <NUM> are configured to be connected to links <NUM> for communicating packets over the automotive network. Packet processing circuitry <NUM> is configured to receive packets from the automotive network via ports <NUM>, including PTP packets, to process the received packets, and to forward the processed packets to the automotive network via ports <NUM>. Validation data collector <NUM> (also referred to below as "collector" for brevity) is configured to derive validation records <NUM> from at least some of the PTP packets that are processed by packet-processing circuitry <NUM>, and to store validation records <NUM> in memory <NUM>.

Collector <NUM> is configured to make validation records <NUM> accessible to validator <NUM> via validation data interface <NUM>. In the present context, the term "making the validation records accessible" refers to various schemes including "pull" schemes and "push" schemes. In a typical "pull" scheme, memory <NUM> (or at least the region of memory <NUM> that stores validation records <NUM>) is accessible for readout by validator <NUM>. In such a scheme, validator <NUM> may access validation records <NUM> as needed and obtain any desired validation data therefrom. In a typical "push" scheme, validation data collector <NUM> proactively transmits validation records <NUM> from switch <NUM> to validator <NUM>. In either implementation, switches <NUM> and validator <NUM> may communicate over links <NUM> of the automotive network, or over separate links.

An inset at the bottom-right of <FIG> illustrates the internal configuration of validator <NUM>, in an embodiment. As seen, in this embodiment validator <NUM> comprises an interface <NUM> and a validation processor <NUM>. Interface <NUM> is configured for communicating with switches <NUM>, e.g., for obtaining validation records <NUM>. Validation processor <NUM> is configured to validate the data in validation records <NUM>, obtained from switches <NUM>, against functional safety requirements. Several non-limiting examples of validation tests are given below.

The configuration of automotive data-processing system <NUM> depicted in <FIG>, and the configurations of its components such as switches <NUM> and validator <NUM>, are example configurations that are depicted solely for the sake of clarity. In alternative embodiments, any other suitable configurations can be used.

For example, although the embodiments described herein refer mainly to network switches, the disclosed techniques can be used for validating the functional safety of other types of network elements that may be used in the automotive network, such as routers and network interface controllers (NICs). Generally, a network element may comprise multiple ports (e.g., in the case of a switch or router) or a single port (e.g., in the case of some NICs).

As another example, although the invention described herein refer mainly to PTP, the disclosed techniques may be carried out using any other suitable time-protocol, e.g., the Network Time Protocol (NTP). Additionally or alternatively, the validation data may comprise any other suitable data of a network element, dynamic or static, if the data are relevant for the required functionality. Non-limiting examples of data that may be used as validation data comprise voltage values, measured delays or cable lengths, data from various network protocols, and the like. As yet another example, although the embodiments described herein refer to validator <NUM> as being separate from switches <NUM>, in some embodiments validator <NUM> may be implemented within one or more of switches <NUM>.

The various elements of system <NUM> and its components, e.g., switches <NUM> and validator <NUM>, may be implemented using dedicated hardware or firmware, such as using hardwired or programmable logic, e.g., in one or more Application-Specific Integrated Circuits (ASIC) and/or one or more Field-Programmable Gate Arrays (FPGA). Additionally or alternatively, some functions of the components of system <NUM>, e.g., of switches <NUM> and/or validator <NUM>, may be implemented in software and/or using a combination of hardware and software elements. Elements that are not mandatory for understanding of the disclosed techniques have been omitted from the figure for the sake of clarity.

In some embodiments, validation data collectors <NUM> (in switches <NUM>) and/or validation processor <NUM> (in validator <NUM>) comprise one or more programmable processors, which are programmed in software to carry out the functions described herein. The software may be downloaded to any of the processors in electronic form, over a network, for example, or it may, alternatively or additionally, be provided and/or stored on non-transitory tangible media, such as magnetic, optical, or electronic memory.

<FIG> is a diagram that schematically illustrates a process of validating the functional safety of network switches in system <NUM> of <FIG>, in accordance with an embodiment that is described herein. This figure illustrates, inter alia, the use of PTP packets for functional safety validation.

In the example of <FIG>, a certain ECU <NUM> in system <NUM> serves as a PTP grandmaster. ECU <NUM> sends PTP packets that carry timestamps (TS) to the automotive network, and the various network elements propagate the PTP packets across the network topology to the various endpoints (e.g., sensors, other ECUs, etc.). In the example topology depicted in <FIG>, PTP packets are propagated via switches <NUM> to a sensor <NUM>, a camera <NUM> and two audio speakers <NUM>. In a given network element, a port over which a PTP packet is received is referred to as a "PTP slave port", and a port over which a PTP packet is transmitted is referred to as a "PTP master port".

Upon receiving a PTP packet from a link partner, each network element (in the present example switch <NUM>) estimates (i) the time delay over the link connecting to the link partner and (ii) the time delay incurred by the network element itself. The network element adds these two time delays to the value of the timestamp in the PTP packet, and forwards the PTP packet to all output ports. In this manner, the various network elements and endpoints are synchronized to a common time-base. Further details regarding time-synchronization using PTP can be found in the IEEE <NUM>. 1AS-<NUM> standard, cited above.

In some embodiments, in parallel with the conventional use of the PTP packets for time synchronization, switches <NUM> and validator <NUM> use the PTP packets for functional safety validation. In each switch <NUM>, validation data interface <NUM> derives a list of validation records (e.g., validation records <NUM> depicted in <FIG>) from at least some of the PTP packets traversing the switch, and makes the validation records accessible to validator <NUM>.

Validator <NUM> verifies, based on validation records <NUM> obtained from switches <NUM> (using "pull" or "push" as appropriate), whether switches <NUM> comply with the applicable functional safety requirements. In response to detecting that a certain switch <NUM> fails to comply with the functional safety requirements, validator <NUM> may issue an alert or initiate any other suitable responsive action.

In various embodiments, validation records <NUM> may comprise various types of information that (i) can be derived from the PTP packets and (ii) is indicative of compliance (or lack of compliance) with functional safety requirements. Non-limiting examples of validation data that safety validation circuitry <NUM> may include in validation records <NUM> comprise, for a given switch:.

In various embodiments, validator <NUM> may assess the functional safety of switches <NUM> based on validation records <NUM> in various ways. For example, validator <NUM> may estimate the accuracy of sent and/or received timestamps. A timestamp accuracy that falls below some expected accuracy level may be indicative of a functional safety problem.

As another example, validator <NUM> may examine the temporal pattern of the PTP packets being received and/or sent by a switch <NUM>. A deviation from an expected pattern may be indicative of a functional safety violation. For example, consider an implementation in which the PTP grandmaster generates PTP packets periodically at known time intervals, i.e., at a known frequency. For a fully functional system, corresponding PTP packets should be received at every slave port, and transmitted on every master port, at substantially the same frequency. A deviation from this frequency may be indicative of a functional failure. The port or ports in which the deviation is detected can provide information regarding the type and location of the failure.

As yet another example, validator <NUM> may use validation records <NUM> to monitor the network topology and detect changes from the expected topology. In a typical automotive network the topology is fixed and known in advance, and deviations from the known topology are highly indicative of a failure. For example, validator <NUM> may detect, based on the validation records, that a certain switch stops receiving PTP packets from a second switch. This change in topology is indicative of a failure. By examining the validation records of both switches, validator <NUM> may be able to detect whether the failure is in the transmitting switch, in the receiving switch, or in the link connecting the two switches.

In some embodiments, validator <NUM> may apply suitable Artificial Intelligence (AI) or Machine Learning (ML) techniques for analyzing the validation data, e.g., for identifying deviations from some expected pattern or topology. Application of AI techniques in the context of a vehicle network is addressed, for example, in <CIT>, which is assigned to the assignee of the present patent application.

The functional safety tests described above are given solely by way of example, in order to demonstrate the disclosed techniques. In alternative embodiments, validator <NUM> may perform any other suitable test. As noted above, in some embodiments, the interfaces between validator <NUM> and switches <NUM>, and the structure of the validation records, provide validator <NUM> with considerable flexibility in defining safety validation tests.

<FIG> is a flow chart that schematically illustrates a method for functional safety validation in system <NUM> of <FIG>, in accordance with an embodiment that is described herein. The method comprises two sub-processes that are typically performed in parallel. A first sub-process, shown on the left-hand side of <FIG>, is carried out by each switch <NUM>. A second sub-process, seen on the right-hand side of the figure, is carried out by validator <NUM>.

The first sub-process begins at a packet processing operation <NUM>, with packet processing circuitry <NUM> of switch <NUM> receiving packets via ports <NUM>, processing the packets and forwarding them via ports <NUM> back to the network. Some of the packets comprise PTP packets. At a validation data generation operation <NUM>, safety validation circuitry <NUM> in switch <NUM> derives validation records <NUM> from at least some of the PTP packets processed by circuitry <NUM>.

At a record storage operation <NUM>, safety validation circuitry <NUM> stores validation records <NUM> in memory <NUM>, making the validation records accessible for readout by validator <NUM>. This example implementation is a "pull" scheme, in which validator <NUM> retrieves validation data from switch <NUM> as needed. In alternative embodiments, safety validation circuitry <NUM> may output the validation records in a "push" scheme, i.e., proactively transmit the validation records to validator <NUM>.

The second sub-process begins at a validation data retrieval operation <NUM>, with validator <NUM> retrieving validation records <NUM> from memories <NUM> of switches <NUM>. At a validation analysis operation <NUM>, validation processor <NUM> of validator <NUM> analyzes the validation records in order to verify whether switches <NUM> comply with the functional safety requirements. Upon detecting, at a checking operation <NUM>, that a switch <NUM> is found to violate the functional safety requirements, validation processor <NUM> issues an alert, at an alerting operation <NUM>.

The two sub-processes of <FIG> typically continue on an on-going basis throughout operation of switches <NUM> in the vehicle. Thus, deviation from the specified functional safety requirements can be detected and handled on-the-fly, if and as they occur.

Although the embodiments described herein mainly address functional safety validation in automotive communication networks, the methods and systems described herein can also be used in other applications, such as in aerospace and maritime devices, as well as in autonomous vehicles.

Claim 1:
A network switch (<NUM>) for use in an automotive network in a vehicle, the network switch comprising:
one or more ports (<NUM>) for communicating over the automotive network in the vehicle;
a packet processing circuitry (<NUM>), configured to:
receive packets from electronic subsystems of the vehicle via the one or more ports (<NUM>), the packets including time-protocol packets carrying time-stamps in accordance with the Precision Time Protocol, PTP, used for synchronizing the electronic subsystems to a common time-base,
process the received packets, including adding (i) time delays estimated to be incurred over links over which the time-protocol packets were received and (ii) time-delays estimated to be incurred by the network switch to values of the timestamps in the received packets, and
forward the processed packets to the electronic subsystems of the vehicle via the one or more ports (<NUM>); and
a validation data collector (<NUM>), configured to derive, from at least some of the time-stamps of at least some of the time-protocol packets that are processed by the packet-processing circuitry (<NUM>) of the network switch (<NUM>) and used for synchronizing the electronic subsystems, validation data indicative of compliance of the network switch (<NUM>) with a vehicle-safety requirement, and to make the validation data accessible from outside the network switch (<NUM>).