GRATIS II Technical Overview

The GRATIS II Graphical Development Environment for TinyOS) has been built using the GME ( Generic Modeling Environment ). We used the GME to create the metamodel defining the graphical modeling language of GRATIS II along with a set of model integrity constraints in OCL to keep the models valid. The graphical representation provides a clear overview of the TinyOS Components, Interfaces and applications. We have also utilized the GME component plug-in capabilities to add an effective parser and a code generator to the environment. The parser allows converting existing TinyOS code to graphical representation. In fact, the package includes the entire TinyOS source tree already converted to graphical models. The code generator generates all necessary glue code to create an application from the models, and assemblies a Make file for the application.

 The figure below shows the main view of the GRATIS II metamodel.

• Why II?
  
  The first version of GRATIS was created for the  TinyOS v0.6, but with nesC (TinyOS 1.x), the structuring concept and execution model has changed. Therefore, we had to create a new metamodel, parser and interpreter for the GRATIS, and this new environment is the GRATIS II. There is not much connection between these systems except GME.
   

• Overview of the graphical concept
  
  The purpose of the GRATIS II is to help understand and overview the TinyOS's parts and applications structure and hierarchy with the advantages of a graphical environment. This tool can parse existing nesC (*.nc) files and directories and build-up the corresponding  representation in GME (these parsed files can be used as libraries in subsequent application development) and it also can generate the corresponding files of a valid GRATIS II model.
  
  Here is an example where the frequently used /tos/system/GenericComm.nc configuration's model can be seen. The elements of the nesC language can be easily recognized  (boxes; gray: interface, green module, yellow: configuration, etc) and the nesc wirings appear as connections between components. More detailed description of GratisII can be found here  Note that  GME's treebrowser on the right side, shows the same directory structure as TinyOS has on the disk.

• Additional non nesC language elements in GratisII

  To be able to build up, work with and support multi platform nesC applications, the following concepts are introduced.

   

  • Platforms: this group of language elements help to describe the dependency of the various platforms. The dependency tree (see picture below) used during the code generation of a system.

  

   

  • System: is a compostion of a top-level nesC configuration (application), to which a device and a tinyos_root can be assigned. Where device is combination a platform and a sensor_board*, and tinyos_root is a relative path to the root of the tinyOS within the model.

  

   

  • ConfigurationAlternative / ModelAlternative: is a collection of Configurations / Modules which are alternative of each other. For example a ModulAlternative can contain several Modules so that those implement same functionality on different platforms and so on.  ConfigurationAlternative and ModelAlternative are distinguished by its darker color from Configuration and Modules, as it can be seen on the GenericComm model above (RadioPacket is a ConfigurationAlternative). The selection among alternatives is based on constraint evaluation and executed by DESERT during the code generation.

   

  • ConstraintSet: assemblies a set of constraint. These sets used at two levels; first at Modules (which are leaves in the appication tree) to assign module-specific values to constraints (e.g.: BufferSize = 1000); second at the top level application (alias system; see above) where the values regard to the entire application (e.g.: BufferSize < 1500) and evaluated during the code generation process (see later). Here is an example for the top level assignment (note the constraints are in different aspect as nesC language elements, see GME documentation for further information)

  

   

• Parsing
  The core is an ANTLR generated parser what  also performs some additional work on the GME project to make the generated library more usable: cleanup and auto placement. During the parsing phases we might encounter problems, inconsistencies in the text files. In these cases the parser tries to handle these errors as gracefully as possible. The auto placement feature separates and organizes the used, provided interfaces, configuration and other nesC elements in the GME models. The process can be executed on a selected directory or file. It automates the model building phase though human interaction cannot be avoided completely.
   

• Code and Makefile generation
  The generation starts from a selected system. The process itself has two phases; the first phase analyzes the design space, evaluates the constraints (with contribution DESERT) and selects the adeqaute alternatives in the model; the second phase generates the relevant source files (configuration and interface files) and a Makefile .
   

• Case study: Blink

Back to GratisII main page

Contact:
For more technical information or to report bugs and request improvements contact Sebestyen Dora