VILLASframework
Modular co-simulation framework
Lab 11: Multi / Demultiplexing
villas_node_demux.svg

In scenarios with more than two simulators which are connected in a star topology, merging / splitting of values originating / targeting from different simulators becomes necessary. This is implemented in VILLASnode in the concept of (de-)multiplexing.

The following configuration settings in a path definition are relavant and described in this lab session.

Multiplexing

Multiplexing describes the process of merging signals from multiple input nodes into a single sample which then is processed futher in its entirety.

In this lab session, we multiplex signals originating from nodes rtds_gtnet_1 and rtds_gtnet_2 into a single path.

VILLASnode supports multiplexing by using mapping expressions in the in (list of strings: node-names | mapping expression) setting of a path. We can construct samples by joining joining multiple mapping expressions as seen in the configuration file below.

VILLASnode paths support two major operating mode which can be selected using the mode (string: "all" | "any") = "any" setting.

  • mode = "all" causes the path to be triggered, and subsequantially emitting samples to its outputs, once all of the masked input nodes receive new data. This mode behaves like a barrier which is opened once we received an update from all masked inputs. This mode effectivly reduces the number of samples which we sent to the destination nodes/
  • mode = "any" causes the path to be triggered anytime one of the masked inputs receive new data. In this mode each sample received from any of the inputs triggers new samples to be sent to all destinations.

The mask (list of strings: node-names) = _all input nodes_ settings allows the user to limit the effect of the mode (string: "all" | "any") = "any" setting to certain input nodes. By default the path mask includes all input nodes of a path.

Demultiplexing

Demultiplexing describes the process of selecting a set of signals from a sample to create a new sample. VILLASnode supports demultiplexing by using mapping expressions in the in (list of strings: node-names | mapping expression) setting of a path.

Configuration file

1 nodes = {
2  rtds_gtnet1 = {
3  type = "socket"
4  layer = "udp"
5  format = "gtnet"
6 
7  in = {
8  address = "*:12000"
9 
10  signals = {
11  count = 8
12  type = "float"
13  }
14  }
15  out = {
16  address = "134.130.169.89:12000"
17  }
18  },
19  rtds_gtnet2 = {
20  type = "socket"
21  layer = "udp"
22  format = "gtnet"
23 
24  in = {
25  address = "*:12001"
26 
27  signals = {
28  count = 8
29  type = "float"
30  }
31  }
32  out = {
33  address = "134.130.169.90:12001"
34  }
35  }
36  monitoring = {
37  type = "websocket"
38  }
39  monitoring_log = {
40  type = "file",
41 
42  uri = "ftp://acs:fake@134.130.169.32/var/villas/log/monitoring_%Y-%m-%d_%H_%M_%S.dat"
43 
44  out = {
45 
46  }
47  }
48 }
49 
50 paths = (
51  {
52  # Combine data from rtds_gtnet1 and rtds_gtnet2
53  in = [
54  "rtds_gtnet1.ts.origin",
55  "rtds_gtnet1.hdr.sequence",
56  "rtds_gtnet1.data[0-6]",
57 
58  "rtds_gtnet2.ts.origin",
59  "rtds_gtnet2.hdr.sequence",
60  "rtds_gtnet2.data[0-6]"
61  ],
62 
63  out = [
64  "monitoring",
65  "monitoring_log"
66  ],
67 
68  reverse = false,
69 
70  # The mode of a path determines when the path is triggered
71  # and forwarding samples to its destintation nodes.
72  mode = "any",
73 
74  # List of nodes which trigger the path
75  mask = [ "rtds_gtnet1", "rtds_gtnet2" ],
76 
77  hooks = (
78  # We dont want to overload the WebBrowsers
79  {
80  type = "decimate",
81  ratio = 10
82  }
83  )
84  }
85 )

The register modes

register.svg
The different register modes.

Go to [lab 12] =>(node-lab-12)