## 4 Main Tools of the WSN-DPCM Platform
### Overview of the Network Simulation Tool  
To set up a new simulation, the user creates a new Network Simulation Descriptor (NSD). Each NSD contains a complete specification that directs the tool to synthesize and execute simulations. NSD objects are composed and edited using a dedicated editing GUI. In particular, an NSD contains:  
* A reference to a PLAN, and all its sub-objects (as shown in Figure 2),
* A simulation model for the environment that is used to generate sensor measurements and other \"environment\" events at simulation time,
* The sequence of result analysis and visualization operations to be performed on simulation output,
* Simulation-related parameters (length of simulation period, statistics collection granularity, HiL configuration _etc._). Once created, an NSD document can be used to execute new simulations at any time, by a \"one-click\" operation via the WebTop GUI. When a new simulation is launched on a given NSD, the tool performs the following steps:1. The PLAN object is imported and information is extracted. This information comprises of WSN topology (location and type of nodes), the Connectivity Matrix, and the components and parameters defining each node type (NODEDEF and ROOTDEF objects). This information, together with other parts of the NSD, is compiled into a Platform Independent Model (PIM). 2. The PIM is validated, checking its consistency. If any inconsistencies are found, a detailed report is generated for the user and the simulation is aborted. Inconsistencies at this level are probably due to some user error (e.g., some NODEDEF has missing information). Also, the validation may create a number of warnings, which alert the user that something seems strange (e.g., routing seems misconfigured), but warnings alone do not abort the simulation. 3. The PIM is transformed to a Platform Specific Model (PSM). The PSM contains objects which describe the OMNeT++/Castalia simulation to be created. The transformation utilizes a library of Castalia-specific simulation models for the hardware and software components that define each node type (e.g., sensor types, radio chips, MAC and routing protocols, power consumption models, _etc._). 4. The PSM is validated and if it is found to be inconsistent, a detailed report is generated and the process is aborted. A failure at this point is probably because of some problem in the tool (e.g., something wrong in the library of simulation models). 5. Based on the PSM, OMNeT++/Castalia code is generated, and compiled. Then, the simulation is executed by a suitable runtime manager. 6. The data output by the simulation is post-processed (including user-defined statistical processing) and a number of plots are created. These are sent to the WebTop GUI, in order to be presented to the user and the simulation terminates. Supporting Environment Simulation with VectorL  
In order to allow the user to specify simulation models for the environment, while hiding the underlying Castalia-based implementation, we designed a simple but expressive domain-specific language, VectorL. A more extensive discussion of VectorL appears in [46]. In a nutshell, there are three salient features of VectorL:  
* Environment simulation models are typically models of physical systems. In order to code such models concisely, VectorL syntax looks very similar to vector calculus. Variables in a VectorL program are multidimensional arrays of reals, integers or booleans (scalar variables are semantically equivalent to 0-dimensional arrays). Complex values and strings are not currently supported, but may be supported in the future. In order to avoid looping constructs, which result in error-prone code, all VectorL expression operators are vectorized, similar to languages such as MatLab, R, yorick or Python/Numpy. * At a higher level, VectorL programs are formed as collections of Event-Condition-Action (ECA) rules. Actions are sequences of statements.