.. _channels: Channels ========= As Sources can represent multiple distinct physical channels, a single Source may have multiple :py:class:`vspyx.Frames.Driver` s. The SourceHandle will wrap these with :py:class:`vspyx.Communication.Controller` s in order to interact with the network simulation in a realistic way. In the same way that a physical ECU which connects to three CAN channels will necessarily have three CAN controllers, a Source with support for three CAN channels will have three :py:class:`vspyx.Communication.CANController` s within the simulation. The core of the network simulation engine is the :py:class:`vspyx.Communication.Channel`. Multiple Controllers can connect to a Channel by way of :py:class:`vspyx.Communication.Connector` s. Once connected, the Channel's job is to take traffic submitted by any Controller and submit it to the other connected Controllers. In this way, it acts like an Ethernet hub, or a line splice in a shared medium network like CAN. It simulates the behavior of the physical network, so you can get information like bus utilization over time, total traffic counts, or the amount of time a particular NetworkEvent takes "on the wire" for this physical network. .. _clusters: Clusters ========= If a network architecture contains multiple routed segments, such as an Ethernet network with multiple VLANs routed together, each VLAN would constitute its own Channel. They would then be organized under a single :py:class:`vspyx.Communication.Cluster`. Or, perhaps the network has multiple redundant channels, such as FlexRay's A and B channels. These would be shown as two Channels under one Cluster. For shared medium physical layers such as CAN and LIN, there will only ever be a single Channel in the Cluster for a physical network.