# Software Architecture of the Platform
## Introduction
This section describes software components involved in the design and their relation with each other. The application requires hw platform as described in [Hardware Architecture of the Platform](./hw_arch_platform.md) for the stack explained in this section to work.
Following diagram illustrates the top-level architecture and arrangement of various software components:
![Software Architecture Overview](../media/sw_arch_intro.png)]
- Operating System: Xilinx Linux kernel + Ubuntu env
- Drivers:
- Uart-rs485
- set of tsn related drivers
- Libraries and Middleware
- ModBus
- ROS2
- DDS
- Applications
- tsn configurations utilities
- tsn raw package application example
- Linux ptp for clock sync
- Pmod test application over rs485
The details of each individual component can be obtained though the reference at the end of this section. The scope of this document is with respect to what is being demonstrated through the example application.
The following list describes the top-level application functions:
- TSN demonstration
- ROS demonstration
- Modbus and RS485 demonstration
## TSN
Time-Sensitive Networking (TSN) is a set of standards under development by the Time-Sensitive Networking task group of the IEEE 802.1 working group. This standards allows low latency transmission and time-guaranteed packet delivery.
### Driver
Set of drivers used for the TSN solution is enabled in the staging area under `linux-xlnx/drivers/staging/xilinx-tsn`. These set of drivers provides TSN capability such as vlan,scheduled traffic, best effort traffic, ptp, QBV shaper, and so on using standard ethernet framework and IP route tools.
The details of the device tree for the driver can be found in the kernel documentation at `linux-xlnx/Documentation/devicetree/bindings/net/xilinx*tsn*.txt`.
Refer to [Xilinx TSN Solution](https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/25034864/Xilinx+TSN+Solution) for details of various features supported by Xilinx TSN drivers.
## ROS2
Robot Operating System (ROS) is a set of open source algorithms, hardware driver, software, and tools for developing robot control software. Contrary to its name, ROS is not an operating system but a library.
In a full-fledged ROS environment sensors in robots, motion controllers, detection, and navigation algorithms, and so on are all components of this distributed ROS architecture. Each individual component is referred as **Node**. ROS nodes (and applications) typically communicate through interfaces of one of three types: messages, services, and actions. ROS 2 uses a simplified description language, the interface definition language (IDL), to describe these interfaces. This description makes it easy for ROS tools to automatically generate the source code for the interface type in several target languages.
Topics are the elements of ROS2 that act as bus for nodes to exchange messages. In the simplest use case, the message is published by a node on a given topic. Anyone subscribed to that topic can receive the message.
![TopicSingleNode](../media/Topic-SinglePublisherandSingleSubscriber.gif)
A node may publish data to any number of topics and simultaneously have subscriptions to any number of topics.
![TopicMultiNodes](../media/Topic-MultiplePublisherandMultipleSubscriber.gif)
These nodes can be on the same system or distributed across systems. The biggest improvement ROS2 provides over ROS1 is how the communication is handled across various systems. ROS2 adopts the decentralized (as opposed to centralized in ROS1) DDS middleware. Instead of implementing its own DDS layer, ROS2 provides a middleware abstraction layer (rmw), which can be plugged on any standard DDS implementation.
### DDS
ROS 2 is built on top of DDS/RTPS as its middleware, which provides discovery, serialization, and transportation. DDS is an end-to-end middleware that provides features that are relevant to ROS systems, such as distributed discovery (not centralized like in ROS 1) and control over different “Quality of Service” options for the transportation. There are many independent DDS implementation by various vendors. ROS2's rmw abstraction allows to easily switch or adapt different implementations.
Following are supported DDS implementation for ROS2 humble release:
- eProsima Fast DDS (Default RMW)
- Eclipse Cyclone DDS
- RTI Connext DDS
- GurumNetworks GurumDDS
For this application, two separate nodes, one running as publisher and the other as subscriber on separate KR260 communicate over the TSN network. The underlying middleware is default to FastDDS.
#### DDS configuration
For demonstration, the message is sent as a scheduled traffic. The DDS is configured allow the message only from the whitelisted interface, which is set to have [vlan qos mapping](https://tsn.readthedocs.io/vlan.html) for all the outgoing traffic to be set as Scheduled Traffic (PCP=4).
For example,
```shell
ip link add link ep name ep.40 type vlan id 40 egress-qos-map 0:4
ip addr add 111.222.0.10/24 broadcast + dev ep.40
```
Now this new interface can be added to whitelist of the DDS configuration for the required topic through the xml configuration.
```shell
Copyright© 2023 Advanced Micro Devices, Inc.