-
Notifications
You must be signed in to change notification settings - Fork 3
Home
To provide the reader necessary background, this section summarizes our IoT application development process. It separates IoT application development into different concerns and integrates a set of high-level languages to specify them. It is supported by compiler, mapper, and linker modules at various phases of IoT application development process to provide automation. Stakeholders carry out the following steps in order to develop an IoT application using our approach.
The domain expert specifies a domain vocabulary~(step~\circled{1}). The vocabulary specification includes concepts specific to a target application domain (e.g., building automation, transport, etc.). For example, the building automation domain is reasoned in terms of rooms and floors, while the transport domain is expressed in terms of highway sectors. Furthermore, the vocabulary includes specification of resources, which are responsible for interacting with entities of interest~(EoI). This includes sensors~(sense EoI), actuators~(control EoI), and storages~(store information about EoI).
Leveraging the vocabulary, the toolsuite generates~(step~\circled{2}): (1) a vocabulary framework to aid the device developer, (2) a customized architecture grammar according to the vocabulary to aid the software designer, and (3) a customized deployment grammar according to the vocabulary to aid the network manager. The key advantage of this customization is that domain-specific concepts defined in the vocabulary are made available to other stakeholders and can be reused across applications of the same application domain.
Using a customized architecture grammar, the software designer specifies an application architecture~(step~\circled{3}). He specifies computational services and interactions with other components. Computational services are fueled by sensors and storages (defined in the vocabulary). They process inputs data and take appropriate decisions by triggering actuators (defined in the vocabulary specification).
The development framework leverages an architecture specification to support the application developer~(step~\circled{4}). To describe the application logic of each computational service, the application developer is provided an architecture framework, pre-configured according to the architecture specification of an application.
To describe the application logic of each computational service, the application developer leverages a generated architecture framework~(step \circled{5}). It contains abstract classes\footnote{We assume that the application developer uses an object-oriented language.}, corresponding to each computational service, that hide interaction details with other software components and allow the application developer to focus only on application logic. The application developer implements only the abstract methods of generated abstract classes.
Using a customized deployment grammar, the network manager describes a deployment specification step~\circled{6}). The deployment specification includes the details of each device, including its regions (in terms of values of the regions defined in the vocabulary), resources hosted by devices (a subset of those defined in the vocabulary), and the type of the device. Ideally, the same IoT application could be deployed on different target deployments~(e.g., the same inventory tracking application can be deployed in different warehouses). This requirement is dictated by separating a deployment specification from other specifications.
The mapper produces a mapping from a set of computational services to a set of devices~(step~\circled{7}). It takes as input a set of placement rules of computational services from an architecture specification and a set of devices defined in a deployment specification. The mapper decides where each computational service will be deployed. The current version of this algorithm selects devices randomly and allocates computational services to the selected devices. A mapping algorithm aware of heterogeneity, associated with devices of a target deployment, is a part of our future work.
###Implementing device drivers Leveraging the vocabulary, IoTSuite generate a vocabulary framework to aid the device developer~(step~\circled{8}). The vocabulary framework contains {\em interfaces} and {\em concrete classes} corresponding to resources defined in the vocabulary. The concrete classes contain concrete methods for interacting with other software components and platform-specific device drivers. The interfaces are implemented by the device developer to write platform-specific device drivers.
###Linking The linker combines and packs code generated by various stages into packages that can be deployed on devices~(step~\circled{9}). This stage supports the application deployment phase by producing device-specific code to result in a distributed software system collaboratively hosted by individual devices, thus providing automation at the deployment phase.
Evolution is an important aspect in IoT application development where sensors, actuators, and computational services are added, removed, or extended. To deal with these changes, we separate IoT application development into different concerns and allow an iterative development for these concerns. This iterative development requires only a change in evolved specification and reusing dependent specifications/implementation in compilation process, thus reducing effort to handle evolution.