Selecting the right Ethernet standard and configuring all the network devices in the embedded systems accurately is an extremely hard and rigorous job. The configuration depends on the topology, workloads of the connected devices, processing overhead at the switches, and the external interfaces. Network calculus, mathematical models and analytical techniques provide worst case execution time (WCET), but their probability of activity is extremely wide. This leads to overdesign which leads to higher costs, power consumption, weight, and size. Simulating the network is the best way to measure the throughput of the entire system. Digital system simulation provides better latency and throughput accuracy, but the accuracy is still limited because it does not consider the latency associated with the network OS, cybersecurity processing and scheduling. In many cases, these factors can reduce the throughput by 20-40%. In this paper, we will present our research on modeling the entire Ethernet network, including the workloads, network flow control, scheduling, switch hardware, and software. To substantially increase the coverage and compare topologies, we have developed a set of benchmarks that provides coverage for different combination of deterministic, rate-constrained, and best effort traffic. During the presentation, we will cover the benchmarks, the list of attributes required to accurately model the traffic, nodes, switches, and the scheduler settings. We will also look at the statistics and reports required to make the configuration decision. In addition, we will discuss how the model must be constructed to study the impact of future requirements, failures, network intrusions, and security detection schemes. Key Takeaways: 1. Learn how to efficiently use network simulation to design Ethernet systems 2. Develop a reusable benchmark and associated statistics to test different configurations 3. The role and impact of the CDT slots, guard band, send slope, idle slope, shuffle scheduling, flow control and virtual channels

1. SESSION 3: TSN
ROLE OF DIGITAL SIMULATION IN
CONFIGURING N/W PARAMETERS
Deepak Shankar
Founder
Mirabilis Design Inc.
Email: dshankar@mirabilisdesign.com

2. Industry Overview
6/8/2022 MIRABILIS DESIGN INC. 2
•Transition to Ethernet and Time-Sensitive Networks requires investments in new technologies
• Connecting existing CAN, CAN/FD networks
• Addition of Gateways
• Configuring switches for the traffic
• Adding security and wireless protocols
•Huge number of parameters interact with topology configurations, use-cases and traffic profiles
• Routing
• Traffic stream allocations
• Quality-of-Service (QoS)
•Investment in research to determine the required set of parameters to tune
Transition creates uncertainty while offer opportunities

3. Transitioning
6/8/2022 MIRABILIS DESIGN INC. 3

4. Current approach to System Design
6/8/2022 MIRABILIS DESIGN INC. 4
•Current approach to tune network parameters are based on
• Spreadsheets
• Python scripts
• Open-source simulators
• Field tests
•Network configuration is done in two stages
• Initialization – Default factory settings
• Run time – Resources are reallocated, application streams are assignment new priorities and thresholds
are adjusted
Quick mechanism to get the Worst Case Execution Time

5. Challenges in current approach
6/8/2022 MIRABILIS DESIGN INC. 5
•As the network become large, configuring initial values for the network parameters becomes
difficult as well as the run time dynamism introduces uncertainty
•Too many unpredictable behaviours are observed when assembled
•Updating combinations of parameters during run time is huge effort
•If fault are detected after assembling the system, then reconfiguring the network parameters or
rearranging the topology is time consuming and resource intensive
Concurrent operation, impact on the Real-Time software and response to Failure not considered

6. Network Configuration Requires
Expertise in Multiple Areas
6/8/2022 MIRABILIS DESIGN INC. 6

7. ADAS is creating
Complex Traffic Streams
6/8/2022 MIRABILIS DESIGN INC. 7
Testing of the configuration requires accurate traffic representation and cover every corner case

8. Network Modeling must be Integrated into the
Product Development, Test and Manufacturing
Concept to Validation for the entire system
Track 30 targets per minute
Connect 5G and V2V
Process 3 cameras, 4 Lidars & 5 Radars
SW response time of 30 ms
Gateways to ECAN, WiFi, BLE and TSN
Product
Idea
Optimized Architecture
ECU1
ADAS
Brake
AI/CCN
TSN/CAN
Select IP- Third-
party & Custom
Assemble Models
Conduct Trade-offs
Architecture Optimization
Functional Analysis
Validation
Simulation Environment
Documentation
Traffic,
Workload
Use-cases
IP Models
SW Performance Measurement
Hardware-in-the-Loop
Integrate Data Center Communication

9. Why Discrete-Event Simulation
Network parameter configuration is not just about setting values
◦ Generate tests for software, provide a configuration executable for customers and partners, and early
software development
Discrete-event simulation supports concurrent traffic pattern
◦ For application-level testing to encompasses hardware, software, RTOS and network
Discrete-event simulation transfers the packets through the model
◦ Critical for event data collection for manufacturability
Integrate with real hardware and test equipment
◦ Downstream verification
Study future challenges in failure testing and cyber-security
◦ Configure to accommodate for these impacts
6/8/2022 MIRABILIS DESIGN INC. 9

10. How does a Discrete-
Event Simulation Work?
AUTOSAR, RTOS, VIRTUAL MACHINE, HYPERVISOR
OPTIMIZE TO MEET PERFORMANCE USING EXISTING HW AND NW

11. ADAS Logical Mapping to Network
Engine function
Brake function
EPS function
Body function
ADAS function1
Other functions
Engine ECU
Brake ECU
EPS ECU ADAS ECU
ADAS function2
ADAS function3
ADAS functions
Other ECU
Gateway ECU
Other ECU
Logical arch
Physical arch
Other ECU
Move to another network layer
Map to physical ECU
CAN BUS
TSN
Trade-off at Application-Level across distributed ECU Network

12. Migration Applications Makes
Discrete-event Simulation Valuable
System-level experiment with Network Topology, Assignment of Tasks to ECU and ECUs to Network

13. Migrating to High-
Performance Servers
DISTRIBUTED ECU TO INTEGRATED PLATFORM

14. Auto HPC must be Evaluated at the
Application-Context
Need a single Discrete-Event Simulation
◦ Compare the performance improvement of centralized server ECU vs distributed ECU
◦ Compute the ECU processing requirements for safety, ADAS, control and comfort features
◦ Measure the response times to user and autonomous driving requests
◦ Design the network topology with selection of routing protocols and bandwidth sizing
◦ Failure analysis to view the impact of lost network link or ECU cores
AI metrics provided
◦ Timing deadlines, data throughput, quality of service and energy consumption
◦ Core, OS and hypervisor utilization
◦ Task response times
◦ Buffer occupancy at each level
◦ Measure the power per computation
Sizing, Evaluating Proposal and Measuring the Performance and Power Impacts

15. End-to-end System Evaluation
Sensor1
Sensor2
Sensor3
Sensor4
Sensor5
Sensor6
HPC/ECU1
Sensor10
Sensor9
Sensor7
Single ECU configuration
Redundancy on the network and at the Server
Fast multi-core processor with quicker response time
Simulate traffic, network and ECU overhead to generate statistics

16. Integrating with the Datacenter
Interface 1
Interface 2
Interface 3
Interface n
.
.
.
OS1
OS2
OS3
OSn
Task
lookup
Hypervisor
Proc
Core1
Proc
Core2
Proc
Core3
Proc
Core4
Proc
Core n
SSD1
SSD2
SSD
n
HDD
1
HDD
2
HDD
n
Request
1
Request
2
Request
n
Datacenter

17. Example using Discret-
Event for Network
Design
DISTRIBUTED ECU TO INTEGRATED PLATFORM

18. Example: Automotive Driving Network
Lower cost, weight, power to meet the target performance

19. Requirements
6/8/2022 MIRABILIS DESIGN INC. 19
•Response time for real time applications must be within constraints
•Throughput requirements for each type of frame must be satisfied
• Priority level 0 to Priority level 7
• CDT
• Class A or B
•Critical frames should not be buffered, or buffered for extended periods
So many configuration options and tight requirements make the confluence difficult to comprehend

20. Common Statistics to Design Parameters
6/8/2022 MIRABILIS DESIGN INC. 20
•End to End latency for traffic streams
•Throughput between switch ports
•Buffering in network switches and gateways
• Overflow across switches
•Credit usage per traffic class
Evaluate statistics at the stream or port level while maintaining visibility of the overall system

21. Top-View of the Vehicle Architecture
CAN/
Eth
Bus
CAN/
Eth
Bus
CAN/
Eth
Bus
Wheel
1
Wheel
2
Wheel
3
Wheel
4
Break
Pedal
Proximit
y Sensor
Gyro
Sensor
Brake
ECU
Road
sensor
Engine
CAN
ECU
CAN
ECU
CAN
ECU
N N
N N N
N
N
N
N
N
N
N
Gateway
N
Leverage Libraries to build up the full starting model; Replace with IP blocks later

22. VisualSim Model of a Braking System

23. Power, Heat, Functional and Timing

24. Statistics for Latency, Resources and
Buffer
Compare metrics along the same time line to understand the source of the problem

25. Focusing on Gate Control List
o Gate Control List (GCL) is configured as:
o During Time Slot T1 only CDT frames can be sent. T1 period = 2.0e-3
o During Time Slot T2 AVB and BE can be sent. T2 period = 8.0e-3
o Guard Band period sent to be 5 usec
o So roundtrip time = T1+T2+Guardband Period = 10.005 msec
Deterministic traffic can be delayed if large packets are accommodated in the Best effort or AVB slots

26. Statistics - Latency
Notice spike in latency every roundtrip
period (10.005 msec).
This is because during T1 slot, only CDT
can be sent out.
So Latency for the AVB or BE frames
coming in at that time will increase as it
has to wait for T2 slot
Quickly identify source of latency

27. Statistics – Sendslope/Idleslope
• IdleSlope is the line going up and
sendSlope is the line going down
• Y-axis shows the amount of credit
available for AVB frames (class A
and class B)
• So IdleSlope represents the building
up of credits
• SendSlope shows the usage of
credits
• We can send a frame if and only if
the credit available (y-axis) is >= 0
• If credit available is < 0, then we
have to wait until the credit builds
up
Configure parameters by running parameter sweeps

28. Statistics – Sendslope/Idleslope
❖ Notice that the credit builds up to the
max credit on every roundtrip time
(10.005msec)
❖ This is because during T1, only CDT
frames are allowed and so the AVB
frames will be waiting. So during this
wait period , the credit for AVB frames
will build up
Worst case scenarios such as every device generating traffic at the same time is unrealistic and causes overdesign

29. Statistics – Buffer Occupancy
Notice spike in the buffer usage at every
roundtrip time (10.005 msec).
This is because, at those times, T1 slot will
be active and CDT frames will be
processed. So the AVB and BE frames have
to wait in buffer till their slots (Gate)
become active
Detect the dependencies between parameters

30. Identify Unpredictable Behavior at
Early Design Stage
Latency for CDT spiked
• CDT frame misses the time
slot
Simulation Time ( Sec )
Latency
(
Sec
)
Ensure in all cases deterministic traffic is not delayed

31. Decision
•With the help of digital simulation, we were able to identify scenarios which can cause
unpredictability to the critical data flow at an early stage and reconfigure the parameters
accordingly.
•Simulating the Bandwidth(BW), Maximum Interval Frame (MIF), Time Aware Shaper (TAS) and
Credit Based Shaper (CBS) parameters gives an idea on what could happen with a worst-case
scenario and determine optimal configuration
6/8/2022 MIRABILIS DESIGN INC. 31
Analytical and network calculus assist. But evaluating the network parameters require both concurrent
behavior and real-time software behavior on ECU. Combine Communication, Computing and Scheduling

32. ROLE OF DIGITAL SIMULATION IN
CONFIGURING N/W PARAMETERS
Deepak Shankar
Founder
Mirabilis Design Inc.
Email: dshankar@mirabilisdesign.com