Development Considerations

Development Considerations

Jaco Prinsloo

Software Engineering

Software development has proven to be a difficult and

error-prone undertaking

Difficult to think holistically and still keep the specifics in


Software engineering intends to ease this burden through

software design

Accomplishes this by rationalizing about the problems

before development starts

Software Engineering

An important concept in software engineering is that of a


A methodology is a set of methods and principles used to

regulate the software development process

Determines how the problem will be approached in order

to solve it

Software Engineering

The architecture of a system determines how components

interact and provides a holistic view of the system

The architecture influences all other design decisions and

can be considered to be the backbone of the design

Design of the architecture is thus an important part of

software engineering

Software Engineering

Most software domains have a few common problems,

which are repeatedly experienced by developers working

on those domains

Design often includes the use of “best practices” for these

problems, called patterns

A pattern is a tried and tested solution to a common


Development Patterns


Ensure correctness of system before deployment

Updating deployed motes is often difficult (somewhat easier

with OTA programming)

Statistical purposes (what is the reliability/longevity of the


Development Patterns

Automated Testing

Often in conjunction with simulation

Ensures correctness of system

User testing can’t cope with a large number of motes

System tests on the motes themselves

Development Patterns

Component Reuse

Certain components change only slightly from system to

system (e.g. gateway communication, rules engines)

Reuse allows for more rapid development

Composing of new applications from old services

Development Patterns

Separation of mote and business logic

Create a business layer which makes use of a mote layer

Changes to the business logic does not affect mote logic and

vice versa

Underlying sensor network can be replaced with a different

sensor network without (major) alterations to the business


Development Patterns

Applications should be adaptable

No assumptions should be made regarding reliability,

message ordering, routing paths taken, etc.

Application should be adaptable and should make provision

for mote-related errors

Adaptability allows for the extension of the system through

the introduction of new sensor and actor types

Design Problems

WSAN presents unique design problems

Some have been solved to a certain degree, others are still

open problems

Important to think about these problems before developing

a WSAN system

Design Problems

Power consumption

Sleep/Wake cycle

Mission critical systems

Solar power/other types of power?

Design Problems

Mote failure

Ad hoc routing

Notify end-user

Mote redundancy

Design Problems




Encryption requires additional cpu power, which translates

to additional electrical power

Design Problems

Mote tampering

Can we trust the data?

Response to outliers?

Make tamper-proof

Design Problems

Huge volumes of data

Information retrieval

Quick response to critical events

Making sense of the data

Design Problems

System granularity

Tens to thousands of motes

Individual attention to motes (battery life, health, sensed


Overall view of system

Design Problems

Mobile motes

Related to mote failure, but not quite the same

Mote leaves and enters network space

Store sensed readings on the mote while disconnected?

Design Problems

Sensor network architecture

Two paradigms

Centralized (motes only sense and route data, server

performs all processing)

Decentralized/Distributed (smart motes which process data

before routing it)

Sensor Network Architecture

Centralized network

Conserves mote processing and electrical power

All recorded data is available should the network go down

Separates mote and business logic

Limits the usefulness of the motes

Sensor Network Architecture

Decentralized network

Allows for more advanced applications

Motes can work in clusters to decide what was sensed and

whether it warrants communication

Motes with actors can immediately respond to triggers, no

communication reliability worries

Closer to the idea of autonomous actors inside a network

Increased power and cpu usage

More magazines by this user
Similar magazines