## 4 Main Tools of the WSN-DPCM Platform
### Tool for WSN Application Development and Simulation  
The main functions of the Development Tool within the WSN-DPCM platform are:  
* To support the design of top-level application-specific behavior and properties at node level;
* To synthesize node hardware and software using the top-level application specifications and library components;
* To generate simulation code and perform network simulations;
* To generate and compile node programming code;
* To generate application-specific configuration for nodes and for the Commissioning and Maintenance Tool. Figure 10 shows the typical Development Tool flow. It starts with the input of the application-specific behavior, which can range from manual input of source code to automated code generation from model-based design (MBD) abstractions, such as state charts [42], metaprogramming approaches [43], UML-based or _ad-hoc_ high-level modeling flows [24; 44; 45]. Behavioral input is captured in a specific view of the top-level component, which also includes all metadata needed by the subsequent phase of the flow, the automated hardware-software system synthesis. The same component format is used for all library components and can include more than one view, e.g., behavioral source code or binary, simulation models for various abstraction levels and simulation environments. Regardless of their format and abstraction level, these views are always handled as black boxes by the synthesis engine, which relies only on the metadata for its operation. For the WSN-DPCM flow we developed a project generator that uses the network defined by the WSN planner using the Planning Tool to extract the distinct node types. For each type, the generator creates a synthesis project skeleton, which includes all node specifications already present in network planning and allows the developer to add behavioral code (e.g., using a high-level state chart interface) and other constraints. Figure 10: Main stages of semi-automated Development Tool flow. These are saved in the format of top-level components that drive the second phase of the flow shown in Figure 10, which is fully automated. In this phase, the synthesis engine of the tool receives as input the top-level component(s) and processes their metadata (such as requires, provides, conflicts). These properties are the starting point for the synthesis process, which iteratively attempts to find all subsets of its library of components that do not have unsatisfied requirements and, at the same time, satisfy all constraints of the top-level and all other components included in the solution. Library components (Figure 11) are central for system synthesis engine operation in order to:  
* Store the behavior and requirements of the node-level WSN application modeled as a top-level component by the developer;
* Define the library blocks that can be instantiated by the system synthesis tool;
* Interface with OS or middleware services when necessary;
* Provide simulation models, at different levels of abstraction;
* Provide the target code that implements their behavior to program the nodes;
* Provide code generators that can be run during system synthesis to check if the component can be configured for the specific requirements of the current solution, or to build specialized code stubs based on the actual parameters of the current solution (e.g., for API translation and component code configuration). Figure 12 shows a simplified representation of just a few metadata properties for both library components (bottom) and the top-level specification component (top-left). Metadata specifications of the top-level component drive the beginning of the system synthesis process. As other library components are instantiated in the partial solution, their metadata requirements will drive future searches of the tool together with the still unsatisfied specifications of the top-level component.