Products

TCN TimeAnalysis™ solution overview

TCN Time Analysis™ is a software tool developed to allow designers of networks and automotive electrical architectures to easily construct architecture and network digital twins and perform e.g. architecture exploration and what-if analysis via simulation.

The software behind TCN TimeAnalysis™ is continuously being evolved to support simulation of an ever wider range of bus- and network technologies, protocols, hardware traffic-shaping mechanisms etc. Currently, the focus is on standards and hardware mechanisms within Ethernet Time-Sensitive Networking (TSN), the new set of standards being developed by IEEE for transporting audio and video as well as other time-sensitive data with increased robustness and determinism as compared to traditional switched Ethernet.

The current version of TCN Time Analysis™ includes basic support for the following technologies:

Benefits of using TCN Time Analysis™ include:

  • Study how the network behaves under different load conditions, e.g. to find a suitable trade-off between network performance and hardware and software cost.
  • Evaluate different network topologies and network parameter configurations, e.g. port or flow priorities.
  • Identify possible hot-spots where contention will occur, e.g. due to high link utilization.
  • Estimate worst-case case delay and jitter for individual data frames, or even the occurrence of packet drop due to limited memory buffers sizes. Thereby the validity of any timing constraints applied to a time-sensitive data frame can be verified.
  • Minimize learning curves and debugging times of new protocols, traffic shaping mechanisms, etc.

The screenshots below also illustrate a selected set of functionalities and benefits gained from using TCN Time Analysis™:


Model based performance simulation of networks and automotive electrical architectures

Defining the automotive electrical architecture or network digital twin

TCN Time Analysis™ allows the user to construct a network topology from clean slate by instantiating a number of virtual Hosts representing automotive ECUs and Gateways. Next, the Hosts can be connected together by CAN- or LIN-busses or by defining Ethernet networks consisting of one or several Ethernet Switches. Finally, the Protocol Data Units (PDUs) originating within Hosts and carrying different signal and data messages are defined and how they map to different CAN- and Ethernet frames etc. All virtual devices expose model parameters like link speeds, priorities etc. These parameters can be configured to explore the large design space available to system engineers. If an ARXML file is available, TCN Time Analysis™ unofficially also supports importing the architecture topology as well as signal and data frame information from such a file.

Figure 1: The Topology View visualizing a non-trivial, automotive architecture consisting of Host ECUs and Gateways (cyan) connected by Ethernet switches (orange) as well as CAN and LIN buses (green and yellow, respectively).


Figure 2: After different traffic flows have been defined, the path taken by, for example, individual Ethernet frames as delivered using uni-, multi- or broadcast can be visualized for easy verification.


Figure 3: IPDUs represent data carried as payload in CAN-frames, Ethernet-frames etc. and can be routed via Gateways across several different network technologies to the final destination Hosts. The above figure visualizes how IPDU1 originates in Host1 and is broadcasted across a CAN-bus, gatewayed in Host3 and further broadcasted via the Ethernet switch to reach several different destination Hosts.


Figure 4: In Ethernet networks, several Virtual LANs (VLANs) can be defined. TCN Time Analysis™ allows visualizing the extent of each individual VLAN.


Figure 5: This example illustrates a straightforward way to make a digital twin of a physical sensor, in this case a camera, using playback of Ethernet frames stored in a capture file. We had access to a physical automotive-grade camera generating a video stream transmitted as a continuous string of Ethernet frames. For a period of time, the stream of Ethernet frames was recorded using Wireshark and stored in a PCAP file. In TCN Time Analysis™, the Sensor node can be associated with a PCAP file and, during a simulation, this node will read Ethernet frames from the PCAP file and transmit them in accordance with the time stamps stored with every captured Ethernet frame. Unlike a physical camera, its virtual digital twin counterpart can be easily replicated and instantiated as many times as required, as is evident from the picture above. The four camera streams are all received by Host2 in the figure. Also, a small control packet is sent from Host1 to Host2 and has to compete for bandwidth with the camera streams on the egress port Switch1.Port2. This can be seen in the Gantt chart in figure 8. Furthermore, figure 10 shows the measured latency frequency plot for the end-to-end delay of the small control packet.


Figure 6: Certain applications require that all devices in an electrical architecture have a common time reference. The Generalized Precision Time Protocol (gPTP) can then be used to synchronize the device clocks among each other. As can be seen in this figure, TCN Time Analysis™ can visualize the different time domains and the clocking hierarchy. In this example, Host1 contains the Grand Master clock, which is distributed by sync messages to the other devices, allowing time synchronization to be achieved.


Analyzing and evaluating simulation results

During a simulation, statistical data is gathered and written to a database file. After the simulation terminates, the collected data and statistics can be analyzed. As the following figures illustrate, valuable insights can be gained:

Figure 7: During a simulation, different hardware resources perform different tasks. A simple example is a Transmitter (Tx) of a Switch port that repeatedly will transmit Ethernet frames being queued up while awaiting transmission. Every task commences and terminates at specific points in time. All the different tasks performed during a simulation can be written to the results database and be inspected in the form of a Gantt-chart. For example, in this figure we can see that the Ethernet frame at the head of the queue buffering the lowest priority frames (Q0) of the Switch port SMSC4.Port2 was being transmitted during the interval 49.749025 ms to 49.863105 ms. Detailed inspection of the tasks presented in the Gantt chart can help understanding the exact behaviour of, for example, traffic shaping mechanisms like TSN's Credit Based Shaper (CBS) and Time Aware Shaper (TAS).


Figure 8: This image shows a small part of the Gantt chart resulting when simulating the network shown in Figure 5. In this network, a small control packet and four video streams are all transmitted to one and the same destination, Host2. On the final link, L2, connecting Switch1.Port2 to Host2.Port1, we can see that all the Ethernet frames being forward via the Switch result in contention and the frames are being transmitted back-bo-back requiring 100% of the available bandwidth. In figure 10, the latency frequency plot for the end-to-end delay of the small control packet is shown.


Figure 9: Timers can be applied that trigger every time a specific Ethernet frame or IPDU is transmitted or received, each time collecting a time stamp. After a simulation terminates, forwarding latencies can be calculated from the collected timestamps and plotted as a frequency histogram.


Figure 10: This frequency plot specifically shows the end-to-end packet delay measured for the small control packet transmitted from Host1 to Host2 in Figure 5. It is also visible in the Gantt chart shown in Figure 8; the control packet is being received periodically on Switch1.Port1, but it then has to compete for bandwidth with Ethernet frames carrying fragmented video frames on the egress port, Switch1.Port2. Therefore, a newly arrived control packet is often delayed by an ongoing transmission of a larger Ethernet frame containing a fragment of a video frame, which is evident from the latency frequency plot above.


Figure 11: A combination of limited memory in Ethernet switches, an abundance of Ethernet packets and contention in switch egress ports can potentially cause memory overflow and packet drop. Ethernet switches contain a configurable memory model, which allows predicting which ports, if any, risk reaching 100% utilization.


Figure 12: If 100% utilization of a switch port memory still occurs during a simulation, hoovering the mouse pointer over the critical histogram bar triggers a pie chart to appear showing how the dropped Ethernet packets are distributed over different traffic flows. As higher priority frames are stored in a separate memory buffer, dropping lower priority frames may still be acceptable.


TCN TimeAnalysis™ offering

The TCN Time Analysis™ offering has its base in a model based simulation software and includes:

  • Software, developed by TCN : Software subscription, run within your site or as a service by TCN (or partner)
  • Consultancy service (optional): TCN, or partner, creates models to perform the analysis. TCN can develop software to the customer's specific needs, for instance reading customer specific files for import or to import data collected from a physical network measurement tool of your preference.