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
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
The figure below shows the main view
of the GRATIS II metamodel.
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
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
- Additional non nesC language elements in
To be able to build up, work with and
support multi platform nesC applications, the following
concepts are introduced.
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
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
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)
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
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 .
Back to GratisII main
For more technical information or to report bugs and request improvements