CPS Summer School 2017 - Hands-on session DynAA
=

The example: two nodes exchanging (compressed) data
-

The DynAA model example represents a small system with two nodes. The first node is a sensor node. It models a sensor device that produces samples of the environment, and send the sampled data to the receiver. The second node is a receiver node, that in this example only works as a sink of information. Meaning, no further processing is done in this node.

Each sample is represented by several hundred bytes (e.g. an image) to be sent. Sending so much information each time is an expensive operation in terms of power. This is a problem as the sensor node is powered by batteries. Because of that, the sensor node is provided with several compressing algorithms that can be chosen by the user/designer. It is also possible to determine the compression rate desired from the compression algorithm. Of course, compressing the data can be computationally intensive and as such spends power.

This model is done to study how the system performs:

- When changing among the different compression algorithms
- When changing the compression rate at each compression algorithm

The criteria to be used is a trade-off between on the one hand messages passed to the receiver per unit of time (possible throughput) allowed by a given system and on the other hand the average energy consumption of the node along the time, which influences its operational lifetime.

In this hands-on session, we will create parts of DynAA code that implement this example. This is done in Java, using Eclipse.

Preparation
-
- Start the virtual machine with Windows 10
- Open Eclipse


- When opening, create a new workspace in Eclipse
- Create a new directory on the virtual machine
- In Eclipse, select: *File > Switch Workspace > Other...*
- Browse to the newly created directory and click *Launch*
- Eclipse will restart
- Import the Java source code
- Change perspective, by selecting: *Window > Perspective > Open Perspective > Other...*
- From the list of perspectives, click *Git* and Eclipse will open the perspective
- Select: *Clone a git repository* in the *Git Repositories* tab
- Paste the following URI: https://github.com/DynAASim/dynaa-tutorial-compressandsend.git and click *Next* (it is not needed to provide credentials)
- Click *Next*.
- Select *Import all existing Eclipse projects after clone finishes* and click *Finish*
- A clone of the repository appears in the *Git Repositories* tab
- Change perspective, by selecting: *Window > Perspective > Open Perspective > Other...* and click *Java (Default)*

File description
-
There are 2 projects visible in the *Package Explorer*. The first is the *tutorial.compressandsend*, which contains the complete source code. The second is called *tutorial.compressandsend.gapcode*, which is a copy of the first but with gaps in the code. In this hands-on session, we will fill these gaps to create a working Compress and Send DynAA model that can be simulated.


If you expand the *tutorial.compressandsend.gapcode* project, you will find the source code files in the package *nl.tno.dynaa.tutorial.compressandsend* under *src*. The following five java files are present:

- *CompressAndSend.java*, which combines the model elements and executes the simulation.
- *SampleAndCompressNode.java*, which constructs a Node that will execute the *Sample and Compress Task*.
- *SampleAndCompressTask.java*, which constructs a Task that samples data, compresses it and sends it
- *SinkNode.java*, which constructs a Node that runs the *Sink Task*.
- *SinkTask.java*, which constructs a Task that will receive the information that is send by the *Sample and Compress Task*.

The *CompressAndSend.java* and *SampleAndCompressTask.java* contain several gaps that need to be filled with the proper code to obtain a working example.

Step 1: Create the functional model
-
In this step, we will update *SampleAndCompressTask.java*.

The first part of a DynAA model is called the functional model or functional view. A functional model defines the tasks that are executed in the system. Tasks are models of the computational behaviour in the system. Each task is modelled in a separate class. During the initialization, it is possible to set the behaviour and parameters of these tasks.

We will specify the generic DynAA computational task by describing the computational behaviour of the *Sample and Compress Task*. This behaviour consists of sensing or sampling data, possibly compressing the data and sending it. Compression can be done by using a 'ZIP' algorithm or a 'RAR' algorithm (fictive), each one of them requiring a different computational effort dependent on the compression rate.

- We start by creating an empty behaviour and a task object.

- Tasks can communicate using ports and connections. Since this task is only sending information, we only create an output port.

- We create properties that describe the size of sampled data and that select the compression algorithm and compression percentage.

- The behaviour of the task is done described by segments and a control flow that defines the order in which these segments are processed. The results of segments could have an effect on this order, but in this example the segments are executed in a fixed order. There are is a library of segments available (for example, sending or receiving data, and performing a calculation). Custom segments can be included as well. The following segments are included:
- A delay segment
- A (custom) sample segment
- A calculate segment
- A copy segment
- A (custom) compress segment
- A calculate segment
- A copy segment
- A send segment

- The first custom segment is the sample segment. Its responsability is to generate a data package of a certain size and setting the number of operations that are needed for this sense segment. The package size and computational effort is set in the task context, which is accessible to all segments of a task.
- The second custom segment is the compress segment. Based on the selected (fictious) compression algorithm and compression percentage, the number of operations for this compression is computed and set in the task context for the calculation segment. Also the resulting packet size is used to generate the message that will be send by the send segment.

Step 2: Create the physical model
-
The second part of a DynAA model is called the physical model or physical view. A physical model defines which nodes (devices) are used, the peripherals of these nodes - processors, memory modules, communication devices, batteries, etc. - and how the nodes are connected to each other. The physical model also defines other aspects of the physical reality, such as how the communication channel behaves or physical dynamics of the environment e.g. temperature, humidity, and node locations.

Though DynAA is not limited to one way of modeling the power consumption, it usually applies a power consumption tracing technique based on "modes" of operation. This technique determines a set of possible modes of operation for the peripherals, which relate to the node power consumption. During the execution, tasks can set the peripherals to different modes of operation and keep them there for some time. For instance, the processor has an *IDLE* and *BUSY* mode, a communication device has an *IDLE*, *RX* (receiving) and *TX* (transmitting) mode.

- First, we create a processor, and we set the energy consumption for each of its modes. Also, the flops (floating point operations per second) and iops (integer operations per second) are set. A calculation segment of a task that is executed on this node will provide information on the numbers of calculations that are needed (as discussed in the above). This will result in a time in which the processor is *BUSY* and consumes energy according to that mode.
- Second, the memory module os created. We use the default constructor (without providing the size of the memory) in this example.
- Next, we create a node power source with a certain electric potential and charge.
- A communication device is created similar to the processor.
- Finally, a node is created and all instantiated peripherals are associated with this node.

Step 3: Bring functional and physical models together
-
In this step, we will update *CompressAndSend.java*.

Similar to the task and node involving Sample and Compress, a task and node is created for the sink node. The construction is similar to the description in the above. The task and node models come together in the main file.

- In the functional part the tasks are constructed. We update some of the properties of the Compress and Send Task.
- In the physical part, the nodes are created. In addition, we create a simple channel that is used by the communication devices of the two nodes. This is why we need to associate this channel to each of the communication devices.
- Now, the association of tasks with nodes takes place, which is done by executing the proper task at the right node. For allow for communication between tasks, we need to separately bind the right task port to a communication device of the node that executes that task.

Step 4: Set logging and simulation settings, and simulate
-

Before we start simulating, we create loggers that we associate with certain elements in the model. These loggers collect information during a simulation. Loggers are special elements similar to probe points. They listen to a certain variable of the system and log changes in their values along the time. The data stored in a logger can be profiled later (processed) to extract more complex information about the system and calculate key performance indicators (KPIs).

In this example, we will activate a logger to count messages received in the SinkNode and a logger to monitor the power consumed by the Compress and Send Node.

Finally, we set the simulation time and activate the simulation of the complete DynAA model, by invoking the method *run* of the simulation engine.