Project topics and materials
Get Complete Project Material File(s) Now! »
LIMITS AND COMPARISON AMONG THE DIFFERENT AP-PROACHES OF SENSOR NETWORKS DESIGN
In order to select the proper approaches to design then implement a SN system, we discuss a comparison between the different approaches regarding our requirements, identified pre-viously. Our comparison is based on the most relevant approaches regarding our context: SimStudio [TTH11], CA-PSCF (Context-Aware Pervasive Service Creation Framework) [AYG10], DSM (Domain-Specific Model) [VMP14], ITSML (Intelligent Transportation Systems Modeling Language) [FIFF15] and SysWeaver [RBR10]. The results of our com-parison is summarized in the Figure 1.5 and detailed in the next sections.
Approaches of Architectural Design Improvement
This section presents the five approaches regarding the improvement of the architectural design of SN. The five approaches aim at integrating in a single environment, tools for modeling and validating high level of pervasive services. These services can be related to complex contexts such as SN. These approaches proposed new specific SN concepts that are implemented in different frameworks and tools. According to each approach, these concepts are dedicated to be used while designing SN systems by the SN designer.
The SimStudio concepts are built by developing the generic DEVS (Discrete Event System Specification) concepts [TTH11]. The CA-PSCF concepts are based on the EMF-based concepts [AYG10]. The DSM concepts rely on Jersey JAX-RS [VMP14]. The ITSML concepts have been developed using the infrastructure of INGENME [PGSP11][FIFF15]. Therefore, during the design phase, the SN designer can use these new specific defined concepts. These concepts are created for specific domains and not for general purposes.
However, they did not propose constraints on these concepts or on the communi-cation between them. The implementation of such constraints in the concerned design tool can help the SN designer to improve the architectural design by preventing architec-tural design errors that maybe made by him. For example, the SN designer is not able to connect two sensors together, but he is able to connect a sensor to a fusion server by respecting the required criteria to establish this connection. Consequently, these five approaches help the designer by providing the ability to have SN concepts and not only general purposes concepts. However, the lack of the implementation of domain specific constraints applied on the domain concepts and relationships is not powerful support for the designer. With this kind of tooling, the designer hasn’t enough support to prevent the architectural design mistakes.
Approaches of Providing Multiple Viewpoints
This section presents one main approach that enables the SN designer to define a SN model that contains different viewpoints. These viewpoints are defined by the different concerned SN designers according to their different domains of experience. This approach is SysWeaver [RBR10].
SysWearver is a very effective approach, it aims at controlling the sensor networks1 by controlling its programming. It seeks to go up in abstraction, it works from top to bottom. It focuses on the application level that is based on programming, and the technology level that is based on simple network components. However, it misses advanced and complex networks components. Accordingly, a main question could be asked here which is: is SysWeaver can manipulate information systems (e.g. SN systems)? SysWeaver cannot be the proper approach to be adopted by the SN designer. This is due to the two main issues that are required to implement such information systems (e.g. NEPTUNE localization systems): (1) advanced and complex networks components (e.g. web servers, routers, database replication server) should be implemented in the technology level of SysWeaver design tool, which are required to be used when the designers describe the business process of a complex service such as localization of moving objects; (2) the descriptions of all the possible provided services are required to be defined using one or the different data fusion architectures. The second issue requires a business level design that contains specific SN components (e.g. fusion algorithm, data acquisition) to be used while designing such services. Therefore, a business level design and advanced IT components are required to be used while designing localization systems.
Consequently, as a solution, we can exploit SysWeaver by extending with a busi-ness level that meets the needs (e.g. specific SN components and relationships) to describe a complex service. And, by adding to the technology level, IT components that can be the correspondences of specific SN components in the business level. Another approach can be proposed, which is to reuse a design tool that contains business, application and technology levels. Then, each level can be extended and specialized by adding new SN concepts and relationships that can be implemented in the concerned design tool. Therefore as we present later, it seems to us that this last solution is less complex if the tooling respects the extensibility requirements.
Approaches of Offering Concepts Extensibility
This section presents the five selected approaches regarding the ability to extend new concepts while designing a SN. These approaches enable the extensibility by adding new concepts (e.g. Sensors, Servers, Relationships) to the concerned frameworks or design tool. This is similar to [CAKR11][CKR12]. Due to the created or generated editors/design tools that are used to create models according to each approach, these new concepts can be new SN specific elements, constraints and relationships in these design tools. This gives the SN designers an easy way to use the new specific added components and constraints.
Consequently, these five approaches help the SN designer by providing the ability to use built-in SN components and relationships from the SN generated design tools. However, modifying a tooling remains difficult when we want to respect the semantics of the added concepts and relationships.
Approaches of Supporting Heterogeneity
This section presents the five selected approaches regarding the support of the concepts 1 heterogeneity while designing a SN. The approaches provide the SN designer the possi-bility to use heterogeneous components (software and hardware)and relationships while designing SN systems. According to each approach, this possibility is provided by using the generated SN editors/design tool that contains different types of components, such as sensor, database server, fusion algorithm. These components perform different functions and provide different services.
Consequently, by supporting the heterogeneity of concepts and relationships that can be implemented in the SN design tools, these five approaches help the SN designer by providing the ability to define SN models that contains different types of components and relationships.
Approaches of Supporting Validation Tools
This section presents only the three approaches that provide tools to validate the defined SN models. These approaches are: SimStudio [TTH11], ITSML (Intelligent Transportation Systems Modeling Language) [FIFF15] and SysWeaver [RBR10]. These approaches enable the SN designer to validate the defined models by detect-ing the architectural design troubles prior to the implementation phase. This early validation is performed by simulating the defined SN models. Consequently, these three approaches help the SN designer by validating and veri-fying the result of the design phase (defined SN models). This can be performed by using a specific simulator that has the ability to provide results of the simulation task. Therefore, these approaches integrate the possibility to improve architectural design models after the analysis of the simulation result.
Table of contents :
Contents
Abstract
Acknowledgements
List of Figures
Introduction
General Context
Sensor Networks
Complexity and Challenges of Sensor Networks
Research Questions
Proposed Approach
Organization
I State of the Art
1 Sensor Networks Development Process
1.1 Sensor Networks
1.1.1 Sensor Networks Life Cycles
1.1.2 Design Phase of the Sensor Networks Life Cycles
1.1.3 Roles in the Sensor Networks Life Cycles
1.2 Sensor Networks Systems
1.3 Fusion Algorithms
1.4 Properties for Selecting a Data Fusion Architecture
1.5 Data Fusion Architectures
1.6 Limits and Comparison among the Different Data Fusion Architectures
1.7 Requirements for Designing Sensor Networks Systems
1.8 Limits and Comparison among the Different Approaches of Sensor Networks Design
1.8.1 Approaches of Architectural Design Improvement
1.8.2 Approaches of Providing Multiple Viewpoints
1.8.3 Approaches of Offering Concepts Extensibility
1.8.4 Approaches of Supporting Heterogeneity
1.8.5 Approaches of Supporting Validation Tools
1.9 Discussion
2 Model Driven Engineering
2.1 Model Driven Engineering Fundamentals
2.2 Model Driven Engineering Aspects
2.2.1 Modeling Languages
2.2.2 Model Heterogeneity and Quality
2.2.3 Models Transformation
2.3 Separation of Concerns in Model Driven Engineering
2.4 Model Driven Engineering Standards and Tools
2.5 Model Driven Engineering for Sensor Networks
2.6 Discussion
3 System Architecture Modeling
3.1 Modeling Context
3.2 Enterprise Architecture Types
3.3 Enterprise Architecture Frameworks
3.4 Domain Specific Concepts in Enterprise Architecture Frameworks
3.5 Enterprise Architecture Modeling Languages and MetaModels
3.5.1 ArchiMate
3.5.2 TOGAF
3.6 Requirements for Selecting the Enterprise Architecture MetaModel
3.7 Comparison Among Enterprise Architecture MetaModels
3.8 Enterprise Architecture Frameworks and Design Tools for Sensor Networks
3.9 DeVerTeS: A Design and Verification Framework for Telecommunication Services
3.10 Discussion
II Contributions
4 Sensor Networks Design Process
4.1 Context
4.2 Software Development Processes
4.3 Selected and Proposed tasks of the Sensor Networks Design Process
4.3.1 Concept and Challenges of Sensor Networks Design Phase
4.3.2 Requirements for Selecting or Proposing Tasks of the Sensor Networks Design Process
4.3.3 Analyzing the Relation between the Tasks of the Software Development Processes and the Identified Requirements
4.3.4 Proposed Tasks of the Sensor Networks Design Process
4.4 The Proposed Sensor Networks Design Process and Model Driven Engineering
4.5 Content of the Proposed Tasks of the Sensor Networks Design Process
4.5.1 Modeling
4.5.2 Ensuring Consistency
4.5.3 Validating
4.6 Discussion
5 Domain Specific Modeling Languages and Design Tools for Sensor Net- works Design
5.1 ArchiMO Definition
5.1.1 Marine Observatory Context
5.1.2 Selected ArchiMate Concepts and Relationships
5.1.3 ArchiMO MetaModel
5.1.4 ArchiMO MetaModel Layer Consistency
5.1.5 Formalization of Layers Interoperability
5.1.6 ArchiMO Design Tool
5.2 Generation of Simulation Code
5.3 ArchiMO and Iterative Approach
5.4 Discussion
6 Application of the Proposed Sensor Networks Design Process to a Case Study
6.1 Underwater Object Localization Case Study
6.2 Modeling a Marine Observatory Case Study using ArchiMO DSML and Design Tool
6.2.1 The Business Model Design
6.2.2 The Application Model Design
6.2.3 The Technology Model Design
6.3 Consistency between Model Layers
6.4 Simulation Code
6.5 Validation of Marine Observatory Model
6.6 Iteration of the Proposed Sensor Networks Design Process
6.7 Discussion
Conclusion and Perspectives
Answering the Research Questions
Perspectives
Bibliography .
