## 4 Main Tools of the WSN-DPCM Platform
### Overview of the Network Simulation Tool
#### 4.2.3 Middleware  
The WSN-DPCM Middleware is responsible for the definition of the common abstractions and the realization of their interfaces for components of functionality typically existing in WSN-based systems. The main objective is to enable high level compositions over heterogeneous embedded programming platforms, promoting portability and reconfigurability, as well as interoperability based on mappings to international standards and industry driven specifications. It defines a core component execution framework which includes design-time configurable inter-component communications, execution scheduling and resource monitoring mechanisms. Based on this and on common interfaces, it provides implementations of components for HAL, Network and Platform layers, hiding the lower-level details (hardware and OS drivers), implementing the available networking and distribution mechanisms, and offering interoperable services to local or network applications. Middleware component abstractions are provided as UML/SysML block descriptions of leaf Function Blocks (executable code) and Assemblies (connectable compositions of other blocks/assemblies with input and output ports, as shown in Figure 17). A component developer, who typically is an expert programmer, has to implement the interfaces of the component to the configuration and runtime sub-systems, and provide SysML block descriptions with all attributes required by the defined WSN-DPCM UML Profile [47].  
Every assembly (its.uml model) can be fed in the developed Xmi2x WSN-DPCM parser, which generates the instantiations, links and configuration files ready to be inspected or manually added to a previously generated device source code tree, or ready to be compiled alone as a relocatable generic binary that can be dynamically loaded into a running device.  
The middleware run-time environment provides C and NesC bindings of the various block interfaces and implementations, as they also appear in the toolset repository, based on the corresponding Block, Parameter and Variant argument models of IEEE 2145-1, but with identification tags mapped restricted in size and semantics, in order to comply with the OMA LWM2M addressing  
Figure 17: Middleware sensor assembly example.  
scheme (type ID/object ID/parameter ID). It defines its own build environment, which combines and abstracts the underlying operating environments (Contiki [48], TinyOS [49], ChibiOS [50] and RIOT [51]). This combined environment along with the captured booting process also allows one to selectively combine the interleaved execution of two run-to-completion schedulers, either over bare hardware or inside a RIOT or ChibiOS thread, thus allowing the coexistence of blocks with internal implementations in either OS.  
In order to simplify the remote access to various block parameters (ports), the middleware provides also high level implementations of Java APIs in order to be used by Java-enabled gateways and configuration and monitoring clients such as the CMT Hand-held, abstracting all the MW functions as set/get accesses to a selected block instance or port, following the OMA addressing scheme, as shown in Figure 18. The Java APIs offer direct network access either to the WSN, through an additional C/NesC programmable embedded interface, or to the web side of a gateway.