VisualSim Architect TTEthernet

admin_mirabilis

The Features of VisualSim Architect TTEthernet

VisualSim TTE Library is a part of the VisualSim Networking package.  This library can be combined with models from the hardware, software, aerospace, and networking library to conduct requirements validation, system analysis, topology assessment, system architecture exploration, system validation, and testing. VisualSim Architect models are end-to-end models with the hardware, software, network, and physical.  The model can be used to study latency, throughput, communication jitters, quality-of-service, efficiency, failure effects, power consumed and synchronization impacts.

VisualSim Architect TTEthernet library provides the user with TTEthernet Switches and End System nodes to which End Systems can be connected. All main features that exist in the real TTEthernet switch and interfaces can be seen in this Virtual prototype as well.

The following section shows how a block diagram gets built in VisualSim Architect:

The block diagram in the above image when built in VisualSim looks like the below image:

We are able to model the complete system – chassis made of multiple boards, multiple chassis, and redundant TTEthernet links- allowing the architect to get the full visibility into expected system behaviour under different traffic profiles, failures, configurations, etc.

VisualSim TTEthernet Library

Synchronization Masters – User can configure any of the End Systems in their design as a Synchronization master by enabling the “Synchronization_Master” parameter at the End System Node. Refer the below image:

Synchronization masters generate SYNC frames periodically and are sent to the Compression masters in the network. The SYNC Frame generation period can be configured by the user by updating a variable called “Grand_Master_Rate”. Refer the below image:

Compression Master – User can configure the TTEthernet Switches which need to act as a compression master by enabling the “Compression_Master” parameter at the TTEthernet Switch. Refer the below image:

Compression Masters receive the SYNC frames from Synchronization masters and thus calculate the current time by:

  1. Add  network delay to the received SYNC Frame time so that the Compression Master gets the “Current Time”
  2. Compression Master takes the average of all the “Current Times” reported by Synchronization Masters. This is because, even if one of the Synchronization Master provides an incorrect time (offset by a few cycles), upon average, it will stay close to the correct time.

The calculated “Current Time” (which is the average value) is then broadcasted to all End Systems.

End Systems – User can configure a simple End System interface by using the TTEthernet Node. User can uncheck “Synchronization_Master” parameter as it is a normal End System. Refer the below image:

Normal End Systems would receive SYNC frames forwarded by the Compression Masters and also send data frames through the network to the destination nodes.

Routing Table – User can use Routing Table to define the paths that exist in the system, link speeds, and link distances. Refer the below image:

We can define a path between a “Source” node and a “Destination” node by adding the corresponding entry to this table. Link Distance, Speed of the Link can be configured using this table. Duplex would mean whether the return path exists (i.e. from Destination back to Source). If we want the return path to be a different route, this column value can be set to false. 

Redundancy – Dual or Triple modular redundancy can be enabled at the TTEthernet Nodes by making use of the “Redundant_Nodes” parameter at the TTEthernet Node. Refer the below image:

Upon configuring the required level of redundancy, the routing table also needs to be updated. Refer the below image:

In the above Routing Table, we can see that the number of entries have increased when compared to the original content. This is because the path for the redundant links also needs to be defined. We can see the additional paths:

  1. Node_1A to Bridge_5 and Bridge_5 to Node_5
  2. Node_2A to Bridge_5 and Bridge_5 to Node_5

These are the redundant paths added to the network. The frame/packet that reaches the destination node first is kept, and others are discarded.

Traffic Profiles – The VisualSim Architect TTEthernet library also provides a traffic generator module that can be plugged into the TTEthernet Nodes to generate the required traffic profile. This traffic generator generates traffic based on the profile set by the user in a database/table. Refer the below image:

  • We can define the traffic type (TTEthernet Frame or Rate Constrained Frame or Best Effort/Ethernet Frame) using the “Identifier” column.
  • The destination node is specified using the “Task_Destination” column.
  • The rate at which these messages are generated is set by the “Mbps” column.
  • The frame/packet size is defined by the “Task_Size” column.
  • The time at which the frame can be injected into the network can be set using the “Start_Time” column. We would want to evaluate scenarios where a huge amount of traffic is injected into the network after some time into the simulation. So for those use cases, we can make use of this column.
  • The time at which the frame can stop generating any more traffic is set by “Stop_Time” column.
  • The protocol – TCP or UDP can be set in the “Protocol” column.
  • The VLAN identifier for the frames can be set in the “VLAN” column.
  • We can link the frame to a priority level (0 to 7) using the “Type” column. According to the “Type”, the user can restrict the bandwidth allocated to the frames.

Integration Techniques – VisualSim Architect TTEthernet library implements all three of the integration techniques:

  • Timely – RC and Best Effort traffic gets sent out only if there is enough time in the slot for them to communicate before the next scheduled TTE traffic arrives for access.
  • Preemption – Higher priority frames can preempt lower priority frames. Order of priority : Protocol Control Frames (PCF) – SYNC > TTEthernet Frames > Rate Constraint Frames > Best Effort/Ethernet Frames
  • Shuffle – Allocates access in First Come First Serve manner

These can be configured by the user by setting the required integration technique across the system by updating the parameter called “Integration_Technique” at the TTEthernet Node and Switches. Refer the below image:

VLAN Config – The BAG and LMax for each of the VLAN’s can be configured by updating the settings listed in the database/table. Refer the below image:

BAG is the minimum allowed length of an interval between consecutive frames on the virtual link and LMax is the maximum allowed frame size on the virtual link.

TTEthernet Frame Configuration Table – The window settings for each TTEthernet frame across each of the nodes it passes through can be set using the “TT_Config_Table” database/table. Refer the below image:

  • “Node” column is used to list the node (Source node, switches/bridges and destination node) through which the TTEthernet frame passes through.
  • “TTName” column is used to define the TTEthernet frame identifier. This identifier is the same entry we had defined in the Traffic database above (Feature 6)
  • “StartTime” column is used to define the start of the TTEthernet slot for that frame at the corresponding node. User must take into account of the network delay when setting the StartTime at various bridges as if the frame misses the start of the slot, then it will need to realign to the window.
  • “BasePeriod” column is used to define the repeat rate for the corresponding slot
  • “ProcTime”  column is used to define the processing time across the node

Bandwidth allocation – Bandwidth for each of the priority type (0 to 7) across each of the nodes can be set using “Type_to_BW” database/table Refer the below image:

  1. “Type” column is used to define all the priority levels (0 to 7)
  2. Other columns are for each of the nodes and bridges. We can specify the bandwidth allocated for a particular type at that particular node.

Fault Injection – VisualSim Architect TTEthernet library is packaged with provisions to inject failures across the system. This fault is injected to affect the “SYNC” frames so that the SYNC frames drift off the actual time and forces the end system to send TTEthernet frames on an incorrect time schedule. This can be done by updating the “Inject_Fault” parameter at the End Systems (TTEthernet Nodes). Refer the below image:

User can define a drift threshold (“Max_Sync_Drift_sec” parameter) for which, if the drift is below the threshold, then it is considered tolerable, while if it goes above threshold, then it would result in TTEthernet frames arriving at all the nodes at times that miss their slots making it overlap with other network traffic and thereby increasing network latency- for not only for TTEthernet frames but for others as well. 

Stats – Various statistics including per frame latency stats, activity diagram, throughput stats, debug logs and warnings are generated. Required stats can be exported in csv/txt formats as well. Refer the below images: