Mirrors/VILLASnode
1
0
Fork 0
mirror of https://git.rwth-aachen.de/acs/public/villas/node/ synced 2025-03-09 00:00:00 +01:00
Code Issues Releases Wiki Activity

improving documentation

Browse source
This commit is contained in:
Steffen Vogel 2016-02-10 19:22:06 +01:00
parent c112d2e426
commit cbd1982f6e
3 changed files with 29 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
doc/nodes/NGSI.md
View file

@ -1,4 +1,4 @@
# OMA Next Generation Services Interface 10 {#ngsi}
# OMA Next Generation Services Interface {#ngsi}
The `ngsi` node type implements an interface to FIWARE context brokers following the NGSI 10 RESTful HTTP API.
@ -24,7 +24,7 @@ Every `ngsi` node supports the following special settings:
#### `mapping` *(array of strings)*
Format `AttributeName(AttributeType)`
Example: `AttributeName(AttributeType) MetadataName1(MetadataType1)=MetadataValue1 MetadataName2(MetadataType2)=MetadataValue2 ...`
### Example
@ -42,9 +42,10 @@ Format `AttributeName(AttributeType)`
timeout = 5, # Timeout of HTTP request in seconds (default is 1)
verify_ssl = false, # Verification of SSL server certificates (default is true)
mapping = [ # Format: "AttributeName(AttributeType)"
PTotalLosses(MW)",
"QTotalLosses(Mvar)"
mapping = [
"PTotalLosses(MW)",
"QTotalLosses(Mvar)",
"Phase(rad) min(rad)=0 max(rad)=3.141"
]
}
}

10
doc/nodes/OPAL.md
View file

@ -1,9 +1,15 @@
# OPAL-RT Asynchronous Process {#opal}
The communication between OPAL-RT models and the S2SS is established by using ansychronous programs.
The communication between OPAL-RT models and the S2SS is established by using asynchronous programs.
Asynchronous programs are are a feature of RT-LAB. They are used to exchange data between Simulink models and custom C programs.
There are two ways to exchange sample values with an OPAL-RT simulator:
For this purpose the C program handels IP/UDP communication via BSD sockets.
1. Use our adapted version of OPAL-RT's AsyncIP example for asynchronous processes (see `clients/opal`)
In this mode, OPAL will send sample data via UDP to S2SS. S2SS has to use the `socket` node-type.
2. Run S2SS as an asynchronous process itself. This is a highly experimental feature and implemented in the node-type `opal`.
It requires a 32-bit version of the `s2ss-server`. Data exchange is then handled using OPAL-RT's libAsyncApi.
The following description applies only to the `opal` node-type:
## Configuration

17
doc/nodes/Socket.md
View file

@ -1,4 +1,4 @@
# Socket {#socket}
# Berkely BSD Sockets {#socket}
The socket node-type is the most comprehensive and complex one.
It allows to send and receive simulation data over the network.
@ -23,6 +23,19 @@ Every `socket` node supports the following special settings:
#### `netem` *(dictionary)*
Enables and configures the network emulation qeueing discipline.
See below for a more detailed description of this feature.
netem = { # Network emulation settings
# Those settings can be specified for each node invidually!
delay = 100000, # Additional latency in microseconds
jitter = 30000, # Jitter in uS
distribution = "normal", # Distribution of delay: uniform, normal, pareto, paretonormal
loss = 10 # Packet loss in percent
duplicate = 10, # Duplication in percent
corrupt = 10 # Corruption in percent
}
#### `layer` *("udp" | "ip" | "eth")*
### Example
@ -87,7 +100,7 @@ This allows us to reduce the amount of conversions during one transfer.
S2SS supports the emulation of wide-area network characterisics.
This emulation can be configured on a per-node basis for **outgoing** / **egress** data only.
This emulation can be configured on a per-node basis for **outgoing** (egress) data only.
Incoming data is not processed by the network emulation!
This network emulation is handled by Linux' [netem queuing discipline](http://www.linuxfoundation.org/collaborate/workgroups/networking/netem) which is part of the traffic control subsystem.