Sensor Network Modeling as a Service
Anca Daniela Ionita, Florin Daniel Anton and Adriana Olteanu
Department of Automatic and Industrial Informatics, University Politehnica of Bucharest, Bucharest, Romania
Keywords: Cloud Services, Model as a Service, Sensor Network Modeling.
Abstract: Cloud Computing opens new possibilities of service provisioning for sensor networks, necessary as they
become more pervasive and distributed. This paper introduces a Model as a Service approach and a modeling
language specifically defined for representing sensor network architecture, based on a four-phased method. It
describes the metamodel and the correspondent environment for graphical modeling, with examples of sensor
network models for road traffic monitoring. The sensor modeling environment was integrated on a private
Cloud platform, within a virtual machine template, to provide sensor network modeling as a service, which is
currently available for our university students. This serves as a foundation for delivering new services based
on the interpretation of the resulted sensor network architecture models.
1 INTRODUCTION
Sensor networks are present in plenty of distributed
applications characteristic to the Internet of Things
(IoT) era (Flammini and Sisinni, 2014), and they have
a great potential to get advantage of the deployment
in Cloud Computing environments for various goals,
like data integration, advanced processing, or global
interoperability. This paper approaches a kind of
Cloud services based on the Model as a Service
(MaaS) concept, whose applicability for sensor
networks may be considerably extended. MaaS is
derived from the Model Web and Everything as a
Service concepts, as shown in (Roman et al., 2009).
Roman et al. give an example of MaaS application for
providing access to oil spill models, with the purpose
to support decisions and increase the preparedness to
this type of hazard. The work outlines important
challenges related to the explicit manifestation of the
model, separate from the rest of the software, as well
as the importance of performing model updates based
on data collected by sensors that might indicate a
change in the environmental conditions. Researchers
discovered a big potential for MaaS in domains like
geosciences (Li et al., 2014) and, generally, whenever
the models engage big volumes of data and must be
executed repeatedly. Thus, MaaS may be considered
a means to get models more accessible and widely
used in executable settings and not just as simple
documentation.
This paper presents a MaaS-enabled environment
for sensor network architecture modeling, offered as
a service in an IBM CloudBurst platform, and used
for educational applications. The graphical modeling
language was specifically conceived for sensor
networks and is accompanied by an editor and by
interpreters developed within the Generic Modeling
Environment (GME) (GME, 2017) and migrated to
MaaS. The language resulted from the definition of a
metamodel and the customization of a concrete
notation. It is useful for representing models of sensor
network architecture, which may subsequently be
interpreted for reconfiguration and visualization of ad
hoc networks, or for generation of standard
descriptions in SensorML. It was elaborated based on
the analysis of several sensor taxonomies and on the
study of multiple sensor networks presented in the
scientific literature.
The remainder of the paper is structured in the
following sections: Section 2 presents the Model as a
Service concept; Section 3 describes our sensor
network modeling environment and the way it was
integrated in a Cloud Computing environment and
offered as a service; Section 4 offers details about the
realization of the sensor network modeling language,
whose editor is delivered as a service. In Conclusion
we discuss other services that may be provided as
MaaS, starting from existing and future software,
capable to automatically interpret sensor network
models defined in this environment.
346
Ionita, A., Anton, F. and Olteanu, A.
Sensor Network Modeling as a Service.
DOI: 10.5220/0006670903460353
In Proceedings of the 8th International Conference on Cloud Computing and Services Science (CLOSER 2018), pages 346-353
ISBN: 978-989-758-295-0
Copyright
c
2019 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
2 MODEL AS A SERVICE
Model as a Service is a form of XaaS (Everything as
a Service). A more detailed classification introduces
the concept of Model and Simulation as a Service
(MSaaS) (Cayirci, 2013), with three types of services:
Modeling as a Service, Model as a Service, and
Simulation as a Service. Another idea resulted from
(Cayirci, 2013) is that it is possible to develop
composite MSaaS, located either on a single
datacenter, or on multiple ones.
A variant of MaaS called Model Web aims at
creating “webs of interacting models”, and an
initiative is proposed within the earth observation
community (Nativiti et al., 2013). For instance,
Model Web applications were introduced for climate
change models (Skøiena et al., 2013), and the solution
was also found suitable to give access to non-
homogeneous models for geo-analysis (Yuea et al.,
2016).
Model Web is considered an implementation style
derived from Systems of Systems (SoS) based on
semantic web. Guided by principles like open access
and publishing new resources in a simple way, the
idea is to support interactions between models and
between modelers. The Model Web is rather a
precursor of MaaS, but it is still confronted with
strong interoperability challenges.
The concept of MaaS is also associated with
quantitative analysis (Yung Rowe, 2014). Due to the
large-scale data resulted from the Internet of Things
and social media, it may be useful to subscribe to
MaaS, and to use the model outputs for decision
support. MaaS is considered an agile approach to
deliver data services in the context of Big Data and of
heterogeneous lakes of data that may be structured,
semi-structured or non-structured (Piscopo, 2014).
An example of geospatial MaaS is ArcGIS Online
(Esri, 2017), which offers services related to
geoinformation models, including mapping and
visualization. Generally, the use of MaaS in
geosciences exonerates users not only from general
software maintenance, but also from setting up
models, which may be a repetitive and very complex
task (Li et al., 2017). It also offers powerful resources
in terms of data storage and computational speed. Li
et at. proposed a framework where a model registry
gives access to a repository of climate, polar and
environmental models, based on a Cloud Computing
platform. They refer to executable models, whose
results can be obtained through a web interface.
3 SENSOR NETWORK
MODELING IN CLOUD
3.1 Modeling Environment
This paper introduces a modeling environment
realized within Generic Modeling Environment and
deployed in Cloud for the restricted use of our
students.
First, GME was used to represent the Sensor
Network language in an abstract way, as a metamodel
(further described in Section 4.3). Then, we
introduced a concrete notation for each modeling
element, and afterwards we used the GME
metamodel interpreter to generate an environment
configured for our language. The resulted modeling
language is graphical, i.e. graph-based, and the model
editor uses specific modeling elements, whose
semantics are defined within the specific application
domain, i.e. sensor networks.
For configuring the model visualization, it is also
possible to add one or more “aspects”, which allow
one to see just a part of the modeling elements, in
order to reduce the model complexity and to show
what is relevant for a particular point of view. For the
Sensor Network language, we defined “aspects” that
show parts of the model concerning Communication,
Power, Memory, and Sensors respectively.
Thus, the modeling environment allows one to
represent sensor network models conforming to the
metamodel created in GME (see Figure 1). The next
paragraph explains the environment, but the model
illustrated in Figure 1, representing the architecture of
a sensor network for road traffic monitoring, is
presented in detail in Section 4.4.
The central pane represents a model drawn with
the elements available on the left side (Part Browser),
corresponding to the classes defined in the
metamodel, but configured with specific notations
(i.e. icons). The environment shows the editable
attributes of a selected model element on the lower
right side (Object Inspector).
With double-click on an element, a new drawing
pane may open, and one can edit a diagram for
showing the structure inside that element. When the
mouse is placed over a modeling element, one can see
the kind of that element (from the metamodel) - in
parentheses - e.g. the kind AggregationUnit for T-
Sink Node Lane 4, in Figure 1.
Sensor Network Modeling as a Service
347
Figure 1: Modeling environment representing a sensor network for road traffic monitoring.
3.2 Modeling Service in Cloud
The previously described modeling environment for
sensor networks was deployed in Cloud, in Virtual
Machines (VM) replicated in respect with the number
of students subscribed to a Model Driven Engineering
course.
3.2.1 Implementation
The implementation used an IaaS (Infrastructure as a
Service) Cloud system based on IBM Service
Delivery Manager (ISDM), which has the same
hardware configuration as the IBM CloudBurst 2.1
medium configuration (Lemos et al., 2012):
14 Blades HS22 (72 GB RAM)
28 TB Raw Data Space.
From the point of view of software, ISDM is more
flexible and customizable, being able to integrate
different types of servers (servers with Intel or Amd
CPUs, Power systems, or even Mainframe) (Huche et
al., 2012).
In order to implement the solution, a virtual
machine was created, installed with the required
software and transformed into a template. The
template was then discovered by the TSAM
component (Tivoli Service Automation Manager)
and registered in the Cloud service catalog using the
Self Service Interface offered by the Cloud system.
From this point on, the service implemented by the
virtual machine was available and ready to be
requested and deployed into one or more projects.
The service can be offered using two methods:
As access to the modelling environment
As a virtual machine for each service request
in the form of an IaaS service
In this way, the user can benefit of the entire
virtual machine, not only of the modeling
software; after the service request has been
processed and the virtual machine is available,
one can connect using Remote Desktop
Connection, and the username and password
provided by the system
The first method, i.e. the access to the modeling
environment, can be applied in two different ways:
CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science
348
For each service request, a virtual machine can
be created, and each user will use his or her
own VM, like in the previous IaaS solution;
however, each VM is customized such that,
each time a connection is made, the explorer
process is killed, and the modeling software is
launched; thus, the user only has access to the
requested software, so one can consider that, by
using an IaaS system, the modeling service is
offered as Software as a Service (SaaS)
The other option is to deploy a VM for a
predefined number of users. When a user is
requesting a service, the VM is only
reconfigured by TSAM, and a new user is
added to the virtual machine; the VM
configuration can be identical to the first
solution, for offering access only to the
software (killing explorer and starting the
modeling software only) and can be installed
with VNC (Virtual Network Computer), which
offers the possibility to connect to the user
session using a Java-enabled web interface. In
this way, one can connect to the service only
using a web browser.
3.2.2 Service Request & Provisioning
Process
When requesting a service, the user will connect to a
web interface, which is the Cloud Self Service
Interface; the user authenticates with a registered
username and a password and then, selecting the
interface options, he or she can request a service in
the form of a project, including the number of virtual
machines to be created based on a template. The
service request is filled with the following
information: the name of the project, the description,
the period of time when the project will be available,
the name of the virtual machine template used to
deploy the virtual machines included in the project,
the additional software that will be installed, the
number of virtual machines included in the project
and their hardware configuration (number of virtual
CPU cores, the number of tenths of physical CPU
cores, RAM, swap space and HDD capacity).
After the user submits the request, the service
request is sent to the Cloud administrator to be
processed. If the Cloud administrator approves the
service request (SR), the SR is sent from the Self
Service Interface to Tivoli Service Request Manager
(TSRM) using REST API; the requester of the service
is also notified that the request has been approved.
Then, TSRM places the request into a queue and
waits for the scheduled date and time.
When the scheduled date and time arrive, the
provisioning of virtual servers begins; if the
provisioning is successful, then the user who
requested the service is notified by email and receives
information on how to access the VMs (VM hardware
configuration, IP address, username, password).
From this point forward, the VMs can be accessed
and used; if the user wishes to modify the project (for
example the RAM capacity of VMs, or the project
schedule) the request is sent to the administrator to be
approved and then the project is modified. If the
project is canceled or the project end date arrives,
then the virtual machines are powered off and then
erased, and the resources are freed; a copy of the VM
image can be done if the user requested it when the
project was created or canceled. The user is notified
at the end of the project, and also two days before the
end date arrives, so he or she can modify the project
schedule if needed.
3.2.3 Testing the Solution
From the preliminary tests, we noticed that, for a
template having a size of 10 GB and a project with 20
VMs, the process of offering the service takes about
22 minutes. Using the same template into a project
with 100 VMs, the process only requires 63 minutes.
These performances are obtained because the VM
template has a reduced size, and also because the
project provisioning was done without processing
other service requests in parallel. The small
difference between the two tests exists because, in the
first stage of project provisioning, TSAM checks the
status of Cloud resources and has an intensive
interaction with the Cloud hypervisor (VMware) and
the Cloud database (DB2), which takes about 10
minutes, before the VM template cloning starts; the
cloning process takes lesser time because the size of
the template is reduced, but also because the cloning
is done in parallel on eight threads.
4 SENSOR NETWORK
MODELING LANGUAGE
4.1 Background
The service provisioning related to sensors is support-
ed by OGC (Open Geospatial Consortium) with the
Sensor Observation Service (SOS), for registering
sensors and giving access to the data measured by
them through web services (OGC, 2017). SOS does
not support a service for modeling the architecture of
the sensor networks that acquire the data.
Sensor Network Modeling as a Service
349
For sensor modeling there is a standard called -
Sensor Model Language (SensorML) - focused on
data models, position, description of the observed
phenomena, and processes (OpenGIS, 2007). It does
not support the description of a network topology.
In the Model-Driven Engineering (MDE)
community, there have been multiple attempts to
model sensor networks. A comprehensive study on
Wireless Sensor Networks (WSN) was presented in
(Malavolta and Muccini, 2014), where several criteria
were used for comparison: capacity to generate code,
type of modeling language, aspects under considera-
tion (e.g. structure, behavior, mobility, power consum-
ption). Another survey, based on almost two thousand
papers, was presented in (Essaadi et al., 2017).
4.2 Method
Based on the general theoretical background related
to sensor networks, we applied an iterative method for
developing the graphical modeling language.
Phase 1 is the analysis of examples of sensor
networks, for which one identifies the main concepts
(terms) that describe the physical and the
computational architecture.
Phase 2 is focused on the creation of a
metamodel, seen as the abstract syntax of the future
language specific for modeling sensor networks. The
aim is that any concept or relationship related to the
real-world examples selected at Phase 1 can be
represented as an instance of a metamodel class. The
metamodel also considers existing classifications and
taxonomies regarding measurements, sensor
characteristics, or Wireless Communication
Networks (WCN) in general (see Section 4.3).
Phase 3 generates an editor of models conforming
to the metamodel, introducing customized notations,
and adding the abstractions that allow one to visualize
different views and hide the rest of the model details
– if the users need this. As explained in Section 3.1,
in GME they are called “aspects”.
Phase 4 was introduced for the metamodel
validation. It consists of using the editor to represent
models for all the examples analyzed at Phase 1.
4.3 Metamodel
Generally, sensor networks are represented
informally for visualization purposes and formally for
hypertext-based design, which requires programming
skills. The language proposed here aims at
reconciling the two approaches, i.e. obtaining an
intuitive representation that is also compatible with a
precise metamodel, which allows model execution
within a program, and automatic transformation to
other paradigms, for interconnection purposes.
Our concern was the sensor network architecture,
with a focus on structural aspects and less details
about the behavioral ones. Moreover, the purpose was
to elaborate a little language, and to raise the
abstracting level as much as possible, yet to be
capable to model a large variety of real-life sensor
networks. This fits to the existing trend of developing
little Domain-Specific Languages (DSL) (Erwig and
Walkingshaw, 2014), and then compose them
according to the needs of large-scale applications
(Estublier and Ionita, 2005).
The metamodel of the sensor network modeling
language is composed of a core (named Sensor
Network) and four other parts, defined according to
the classification of WCN devices: Communication,
Power, Memory, and Sensors (Cheekiralla and
Engels, 2005). A sensor network may be composed
of sensing, aggregation, communication, and
processing units, and of sensors connected to each
other (see Figure 2).
We define ProcessingUnit as an element that may
contain SoftwareUnit elements, dependent on one
another. A software unit in our language represents
any piece of software, be it a physical or a logical
artifact, e.g. an architectural layer, a software agent, a
service, or even an algorithm.
A SensingUnit is an AggregationUnit that
contains sensors, so it can perform acquisition of data.
An AggregationUnit is used for gathering data
originated from sensing units or from other
aggregation units, and for transmitting them forward,
but it may also perform some data processing. For this
reason, it contains objects of the following kinds:
CommunicationUnit, ProcessingUnit, and
PowerUnit, connected to each other.
A Sensor contains the attribute MeasurandType,
having one of the following values: Acoustic,
Biological, Chemical, Electric, Magnetic,
Mechanical, Optical, Radiation, and Thermal, as in
the classification from (White, 1987).
The type of SensorNetwork is specified through
an enumeration attribute: Standards-Based, Internet-
Connected, Context-Aware, Agent-Based, Service-
Oriented, Secure and Fault-Tolerant, Vehicle-Based,
Habitat-Monitoring, and Multi-Owner, following the
taxonomy proposed in (Fokum et al., 2008).
The sensors characteristics are given in
conformity with the abstract syntax from the Sensor
part of the metamodel, with classes like: Operating
Range, Power Supply, Output, Accuracy, Sensitivity -
according to (Kalantar-zadeh, 2013).
CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science
350
Figure 2: Part of the metamodel.
The metamodel was specified in the
metamodeling language supported by Generic
Modeling Environment. GME offers a metamodeling
language whose main objects are: Atom (indivisible,
yet characterized by attributes), Model (a composite
of other modeling elements) and Connection (to
represent links between model elements). The
notation adopted in GME is very similarly to the
UML (Unified Modeling Language) class diagrams,
as noticed from Figure 2. As in UML, the triangle is
used for generalization relationships, and the line
ended with a diamond for compositions
4.4 Example of Model
According to the method described in Section 4.2, we
performed multiple iterations for elaborating the
metamodel and testing the use of the modeling editor.
During one of these iterations, we studied a series of
systems where wireless sensor networks were used
for monitoring vehicle traffic. A comprehensive
survey on this topic is presented in (Nellore and
Hancke, 2016). Thus, in Phase 1 from our method,
we studied multiple sensor networks described in the
scientific literature, then in Phase 4 we modeled them
with the specific modeling environment from Section
3.1.
One of these systems is meant to detect vehicles
on a four-lanes road, using a Telematics Sensor
Network (TSN) (Yoo, 2013).
Figure 1, also illustrating the modeling
environment, contains the upper part of the TSN
model, containing the following objects of kind
AggregationUnit:
four sink nodes, one for each lane, and
one base station, named T-BS-com node, which
has a video camera and transmits the data to a
ProcessingUnit named T-Mon Host.
The names from this model are the ones given in
(Yoo, 2013). Data are collected from two telematics
sensor nodes per lane, named T-Sensor Node,
instantiated from SensingUnit.
We also added details for some of these elements,
according to the description from Yoo’s article. For
example, the elements inside a sensor node are:
MSP430 MCU, micro-controller, of kind
ProcessingUnit
CC2590 RF Amplifier, of kind ProcessingUnit
Sensor Network Modeling as a Service
351
CC2420 Transceiver, of kind
CommunicationUnit and
HMC1041Z MR, of kind Sensor, with the
MeasurandType attribute set to Magnetic.
All the objects previously mentioned have the
type Model in the GME language, therefore it is
possible to describe their inner structure. For instance,
the sensor is described with three groups of
characteristics, as specified in (Honeywell, 2017):
Bridge Elements, Set/Reset Strap, and Offset Straps.
The specific modeling environment allows one to
specify values for each characteristic, e.g. for one that
represents an OperatingRange, it is possible to set the
conditions, the minimum, typical and maximum
values, and their units. The values given in our model
are those from the technical specification of the
sensor.
5 CONCLUSIONS
The paper presents a modeling language and a
graphical modeling environment for sensor network
architecture, provided as an educational service on a
private Cloud. The approach can be compared to
WebGME, realizing Domain Specific Modeling
Languages (DSML) in the Cloud (Maróti et al.,
2014). Thus, our service is exclusively dedicated to
modeling, not to metamodeling (as WebGME) and its
users are only supposed to use the sensor network
modeling environment AS-IS, and not to upgrade it,
or configure it themselves. Any modifications at the
metamodel level need, in our process, the creation of
a new template for generating other virtual machines.
The migration of models to the new VMs is clearly
possible, but with the inherent limitations imposed by
GME; for example, if a metamodel class is eliminated
from the metamodel, a model containing an instance
of that class cannot be opened with the new version
of the sensor network editor. The modeling
environment has evolved during our study and it is
still subject to change, according as new examples are
studied and modeled. For example, the language was
applied for modeling volcano monitoring networks,
and it may be considered one of the multiple
modeling paradigms (Ionita and Mocanu, 2015)
required for dealing with the complexity of hazard
management systems in general.
According to the Cayirci’s classification
presented in Section 2, our approach currently fits in
the Modeling as a Service type (Cayirci, 2013),
because it stands in the availability of a sensor
network modeling environment, deployed on a Cloud
platform. The templates we use also have some
similarities to the solution from (Li et al., 2017),
where the models are executed on virtual machines,
based on an image. The MaaS engine presented there
generally corresponds to a model interpreter.
The template containing the modeling
environment may be used for creating virtual
machines according to the needs of various
educational programs in our university, to allow the
remote access to graphical modeling of sensor
network architecture. It also supports the definition
of models that are potentially executable, therefore
the environment is a foundation for providing more
services by adding model interpreters, in the spirit of
the Model as a Service approach.
Future work will focus on adding new services
that provide information about sensor network
complexity, transform the model to standard formats,
integrate the data acquired by sensors, or evaluate the
impact of sensor network evolution.
ACKNOWLEDGEMENTS
This work was funded by University Politehnica of
Bucharest, through the “Excellence Research Grants”
Program, UPB – GEX 2017. Identifier: UPB-
GEX2017, Ctr. No. 44 /2017 (AU 11-17-13).
REFERENCES
Cayirci, E., 2013. Modeling and Simulation as a Cloud
Service: A Survey. In Proceedings of the 2013 Winter
Simulation Conference, R. Pasupathy, S.-H. Kim, A.
Tolk, R. Hill, and M. E. Kuhl, eds, pp. 389-400.
Cheekiralla, S., Engels, D.W., 2005. A functional
taxonomy of wireless sensor network devices. In 2nd
International Conference on Broadband Networks.
BroadNets.
Erwig, M., Walkingshaw, E., 2014. Semantics-Driven DSL
Design. In Computational Linguistics: Concepts,
Methodologies, Tools, and Applications, Volume I, IGI
Global, pp. 251-275.
Essaadi F., Ben Maissa Y., Dahchour M., 2017. MDE-
Based Languages for Wireless Sensor Networks
Modeling: A Systematic Mapping Study. In El-Azouzi
R., Menasche D., Sabir E., De Pellegrini F., Benjillali
M. (eds), Advances in Ubiquitous Networking 2.
Lecture Notes in Electrical Engineering, vol 397.
Springer, Singapore.
Esri, 2017, Esri Managed Cloud Services [online],
Available from: http://www.esri.com/arcgis/services/
managed-cloud [Accessed 14 Oct. 2017].
Estublier, J., Ionita, A.D., 2005. Extending UML for Model
Composition, In Proceedings of Australian Software
Engineering Conference (ASWEC), Publisher IEEE
CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science
352
Computer Society, March 2005, Brisbane, Australia,
pp. 31-38.
Flammini, A., Sisinni, E., 2014. Wireless Sensor
Networking in the Internet of Things and Cloud
Computing Era, In Procedia Engineering, vol. 87, pp.
672-679.
Fokum, D.T., Frost, V.S., Mani, P., Minden, G.J., Evans,
J.B., Muralidharan S., 2008. A Taxonomy of Sensor
Network Architectures. In Technical Report, ITTC-
FY2009-TR-41420-08, University of Kansas.
GME, 2017. Generic Modeling Environment,
http://w3.isis.vanderbilt.edu/Projects/gme/ [Accessed
14 Oct. 2017].
Honeywell, 2017. One-Axis Magnetic Sensor HMC1041Z
[online]. Available from: https://aerocontent.honey
well.com/aero/common/documents/myaerospacecatalo
g-documents/Missiles-Munitions/HMC1041Z.pdf
[Accessed 14 Oct. 2017].
Huche, T., Koohi, B., Lam, T.V., Reynolds, P., Swehla,
S.M., Wain, J., Vetter, S., 2012. Cloud Computing
Infrastructure on IBM Power Systems: Getting started
with ISDM. IBM Redbooks.
Ionita, A.D., Mocanu, M., 2015. Multiple Modeling
Paradigms Applied for Accidental Pollution
Management. In Environmental Engineering and
Management Journal, Issue 9, Volume 14.
Kalantar-zadeh, K., Sensors, 2013. An Introductory Course,
Springer.
Lemos, A., Moleiro, R., Ottaviano, P., Rada, F., Widomski,
M., Braswell, B., 2012. IBM CloudBurst on System x.
IBM Redbooks.
Li, Z., Yang, Huang, Q., Liu, K., Sun, M., Xia, J., 2017.
Building Model as a Service to support geosciences. In
Computers, Environment and Urban Systems, Volume
61, Part B, Pages 141–152.
Malavolta, I., Muccini, H., 2014. A Study on MDE
Approaches for Engineering Wireless Sensor
Networks, In 2014 40th EUROMICRO Conference on
Software Engineering and Advanced Applications
(SEAA), Italy, pp. 149-157.
Maróti, M., Kecskés, T., Kereskényi, R., Broll, B.,
Völgyesi, P., Jurácz, L., Levendovszky, T., Lédeczi, Á.,
2014. NextGeneration (Meta) Modeling: Web-and
Cloud-Based Collaborative Tool Infrastructure. In
Proceedings of the 8th Multi-Paradigm Modeling
Workshop, Spain, pp. 41–60.
Nativiti, S., Mazzetti, P., Geller, G.N., 2013. Environmental
Model Access and Interoperability: the GEO Model
Web Initiative. In Environmental Modelling &
Software, Volume 39, pp 214–228.
Nellore, K., Hancke, G.P., 2016. A Survey on Urban Traffic
Management System Using Wireless Sensor Networks,
In Sensors, 16 (2) 157.
OGC, 2017. Sensor Observation Service [online],
Available from: http://www.opengeospatial.org/
standards/sos [Accessed 14 Oct. 2017].
OpenGIS, 2007. Open Geospatial Consortium, OpenGIS®
Sensor Model Language (SensorML) Implementation
Specification, M. Botts Ed., Version: 1.0.0.
Piscopo, N., 2014. Agile Big Data and Many-Particle
approach change Marketing and Sales effectiveness
[online], In Cloud Best Practices Network. Available
from: https://cloudbestpractices.wordpress.com/author/
nucciopiscopo/ [Accessed 14 Oct. 2017]
Roman, D., Schade, S., Berre, A. J., Bodsberg, N. R.,
Langlois, J., 2009. Model as a service (MaaS). In
AGILE workshop: Grid technologies for geospatial
applications, Germany.
Skøiena, J.O., Schulza, M., Duboisa, G., Fisherb, I.,
Balmanc, M., Mayc, I., Tuamad, É.Ó., 2013. A Model
Web approach to modelling climate change in biomes
of Important Bird Areas. In Ecological Informatics,
Volume 14, pp 38–43.
Yoo, S., 2013. A Wireless Sensor Network-Based Portable
Vehicle Detector Evaluation System. In Sensors 13(1),
pp. 1160-1182.
Yuea, S., Chena, M., Wena, Y., Lua, G., 2016. Service-
oriented model-encapsulation strategy for sharing and
integrating heterogeneous geo-analysis models in an
open web environment. In ISPRS Journal of
Photogrammetry and Remote Sensing, Volume 114, pp
258–273.
Yung Rowe, B. L., 2014. The Models as a Service era has
arrived [online], Available from: https://cartesianfaith.
com/2014/06/05/the-models-as-a-service-era-has-arriv
ed/ [Accessed 14 Oct. 2017]
White, RM., 1987. A sensor classification scheme. In IEEE
Trans Ultrason Ferroelectr Freq Control. 34(2),
pp124-126.
Sensor Network Modeling as a Service
353