Transcript Service-Oriented Software Architecture for Sensor

Service-Oriented Software
Architecture for Sensor Networks
Jan Blumenthal
University of Rostock
IMC
Rostock, 17th June 2003
Outline
•
•
•
•
•
Introduction to sensor networks
Requirements
Software Engineering
Approach
Conclusion
2
Evolution of sensor nodes
Sensor,
Actuator
Battery
Processor
HF
PC
Picoradio
(UCB)
WINS
(UCLA)
Blue-Node
(UoR) Smart Piece of
Dust Silicon
3
(UCB)
Characteristics of Sensor Nodes
• Limited capacity of
– Battery (Lifetime: days – 10 years)
– Processing capabilities
– Transmission range (5…20
meters)
• Data rates: Bit/s … KB/s
• Transmission methods:
– Bluetooth
– ZigBee
– nanoNET
Coming up sensor
nodes
• One specific application
• Price: some cents
4
Characteristics of Sensor Networks
Properties:
•
•
•
•
Wireless sensor nodes connect together autonomously
Distributed organization
Contain one or more data sinks
Huge number of nodes to compensate transmission range (density: 0.1
- 20 nodes/m2)
• Nodes may move around
Tasks:
• Cooperative data acquisition:
– Cooperative data collection and preprocessing
– Running distributed applications regionally
– Forwarding of results to higher application levels
• Adaptive reactions on environment modifications
• Network has to behave robustly and fault-tolerant to:
– Failure on single nodes
– Transmission errors and distortion through obstacles
– Intrusion and jamming
5
Applications
Protecting flood dam with sandbags
Stress Monitoring
Sensor Node
Measurements in Fluids
Intra Corporal Measurements
6
Requirements of Sensor Networks
1. Self-Organization
– Ad hoc network formation
– Autonomous connection establishment
2. Network Maintenance
– Addressing of nodes
– Routing facilities
– Compensation of network failures
3. Cooperative Processing
– Context awareness
– Location positioning and location awareness
– Preprocessing of collected raw data
4. Security Mechanisms
5. Energy Optimizations
7
Context Awareness
Context Awareness: Adapts the behavior of the node to the
current environment
• Infrastructure context
– Refers to the infrastructure around the node
– Example: Perception of bandwidth and reliability
• Domain context
– Refers to the current environment of the node
– Example: Knowledge of next data sink in the network
Data sink node
Simple node
Transmission
range
8
Cooperative Algorithms
• Reduction of data by preprocessing and aggregation
• Minimization of data stream to data sinks
Example: Positioning

E3
N2

E1

• Transfer E3 to N 3
N1

E2
N3
• Measurement the field

strengths of E1 and E2
• Triangulation / multilateration
• Transfer of determined
positions to data sink
• Max. 6 transmissions
• Decentralized positioning
9
Network Maintenance
• Attribute based addressing
– Assignment of data to location of data mining
– Location awareness necessary
– ID based addressing unfavorable
• Random node distribution
• Routes become obsolete quickly due to mobility
– Example: Temperature at location (x, y) ?
• Cooperative network behavior
– Data aggregation
– Address resolution / location awareness
– Adaptive routing strategy depends on mobility of nodes
• Communication reduction / avoidance
–
–
–
–
Connectionless transmission
Prevent network traffic through data aggregation
Event based communication in contrast to request / reply
Polling avoidance
10
Software Engineering
Network Maintenance
Services
Cooperative Algorithms
Context Awareness
Hardware Abstraction
Middleware
Common Middleware:
• Hides the complexity of the distributed system
• Standardized API to node application
• Provides access to services on remote nodes
Goal: Same middleware on different platforms
11
Middleware Properties
Scalable Middleware
• Customization of data types during compile time
• Removing of unused components
Generic Middleware
• Platform independent middleware leads to increased number of
complex interfaces
• Adaption of interfaces instead of programs
Non Generic Middleware
void setBaudrate(int handle, int baudrate)
{
hardware_addr=getIOAddress(handle);
hardware_addr->BTR0=baudrate;
}
Generic Middleware
void setBaudrate(int baudrate)
{
// getIOAddress(handle);
BTR0=baudrate;
}
Valid only, if one interface present
Savings: parameter delivery, function call, stack operation, return value
assignment, field operation
12
Middleware Properties II
Adaptive Middleware
• Mobility and changes in infrastructure require adaptions to the software
– Cluster head selection requires additional routing software
– Changing measurement methods leads to new programs
• Exchange and run components dynamically
– Start of new services
Reflective Middleware
•
•
•
•
•
Ability to understand and influence itself
Application layers are not affected
Inspection: Analyze behavior via logging / debugging
Adaptation: Changing behavior of internal layers.
Example:
Customizing routing strategy depending on mobility
!
To overcome all the mentioned requirements
we designed a software model
!
13
Our Approach
• Adaption of program to the application task
instead
adaption of application task to the program
• Adaption of interfaces to the program
instead
adaption of the program to the interfaces
• Application-dependent customized software
components
instead
multipurpose software on each node
14
Definitions
Sensor Application
• Measurements and
storage of data
• Hardware dependant
• Example:
– Software driver for
temperature sensor
Node Application
• Application specific parts
• Middleware (routing,
discovering nodes)
• Contains sensor
application
Sensor Network Application
• Describes main tasks of the entire network
• Contains several node applications
• Optional administration interface
15
Node Application
Host Middleware
Algorithms
Modules
Services
VM
Middleware Management
Operating System
Dynamic components
Internal interface
(generic middleware)
Sensor Driver
Sensor application
CPU
Sensor
No individual high level application, because:
• Nodes provide services only to the network
• Focus: Success of sensor network application instead of
node application
• Cooperative behavior of nodes
16
Sensor Network Application
Administration Terminal
boot, logging
Sensor Network Application
Distributed Middleware
Node A
Node B
Node C
Middleware
Middleware
Middleware
Operating System
Operating System
Operating System
Hardware
Hardware
Hardware
systemwide
interfaces
customized
node‘s software
different node
hardware
• Middleware and Operating System are compiled and optimized to each
hardware
• Sensor Network Application
– Composition of all node services
• Optional administration terminal to manage the entire network
17
Sensor Network Design
Components
Design & Edit
Compile/Link
Resource
Hardware
driven
• Create hardware-optimized software
components (driver, operating system)
• Create hardware-independent software
components (middleware, services)
• Combining of predefined components
• Source code generation
• Removing unused components
• Optimization of interfaces
• Optimization to node‘s hardware
• Distribution of nodes in different
environments
Distribute
Execute/Administrate
Monitoring
Evaluation
Optimization
• Monitoring the execution
• Creation of logfiles
• Evaluation of logfiles
Development Studio
Changes to common design methods.
18
Conclusion
• New challenges of software development in sensor
networks
• Optimization of node‘s software based on
– Interface design
– Adaptive and reflective middleware
• Design of service-oriented middleware in sensor networks
• Future work
– Realization of presented software concept
– Development studio
19
Thank you
Any questions ?
Services
Definition: Little program accessed by standardized
interfaces over the network.
• Discovering and using services
• Cascading of services without previous knowledge of each
other
Service infrastructure for remote access:
Surface profile service
Surrogate Host
Service Proxy
Sensor C
Sensor B
Sensor A
Bluetooth
Physical
Request
Surface profile ?
LAN
Client
Physical
Request
Reply
Proprietary protocol TCP/IP
Reply
21
Software Architecture
•
•
•
•
Desktop Model
Resource optimized
Application
Application
Middleware
Middleware
Operating System
Application Specific
OS Modules
Hardware
Hardware
Independent
applications
Standardized
middleware
Standardized
operating system
Example: Jini
Not optimized
•
•
•
•
Independent
applications
Standardized
middleware
Standardized
interfaces
Unused components
removed
(Partly) optimized modules
Sensor Node
Middleware
Node
Sensor
Specific
Driver
OS Modules
Hardware
•
•
•
•
Sensor
No independent
applications
Customized
middleware
Proprietary interfaces
Optimized driver
software
22
Example
Middleware
Node
Sensor
Specific
Driver
OS Modules
Hardware
Sensor
Middleware
Middleware
Middleware
Node
Sensor
Specific OS
Driver
Modules
Node
Sensor
Specific
Driver
OS Modules
Node
Specific
OS Modules
ARM
•
•
Sensor Node
Model
Temperature
Sensor
ARM Microcontroller
Temperature Sensor
68HC11
•
•
Pressure
Sensor
68HC11 Microcontroller
Pressure Sensor
68HC11
•
•
68HC11 µC
No Sensor
23