Saturday, 28 November 2015

SPPM 8




Waterfall Life Cycle Model Involves

  • Analysis
  • design 
  • Code (Implementation)
  • Support
Information Engineering Involves collection of the requirements.
Establish and define the requirements.

Design phase: - 
  • Model to my project. (Structure to the project).
Code phase: - (Implementation)
  • Using language, Fulfill the structure .According to the model
Test phase: - 
  • Test the code with worst, best and average cases. If there are problem again go to the design phase.
Not an iterative model.


Protected by Copyscape Online Plagiarism Scanner

Saturday, 21 November 2015

Wireless Sensor Network

APPLICATIONS OF SENSOR NETWORKS

  •    Many applications share some basic characteristics. There is a clear difference between sources of data - the actual nodes did sense data - and sinks - nodes where the  data Should be delivered to.
  •     The sinks are sometimes part of the Sensor Network; some times they are CLEARLY system "outside" the network.
  •   So, there are Usually, but not always, more sources than sinks and the sink is oblivious or not interested in the identity of the sources; The data itself is much more important.
  •   The interaction patterns between sources and sinks show some typical patterns. 
  • The most relevant ones are:


     EVENT DETECTION 

                           Sensor nodes Should report to the sink (s) once theyhave detected the occurrence of a specified event.

  •     The simplest events can be detected locally by a single sensor node in isolation (eg a temperature threshold is exceeded); more complicated types of events require the collaboration of nearby or even remote sensor to decide Whether a (composite) event  has occurred (eg a temperature gradient Becomes too steep). 
  •         If several different events can Occur, event classification Might Be on additional issue.



   PERIODIC MEASUREMENTS
                                                        Sensor can be tasked with Periodically reporting Measured values.
                                                      Often, synthesis reports can be triggered by a detected event; The reporting period is application dependent.

     FUNCTION APPROXIMATE AND EDGE DETECTION

  •       The way a physical value like temperature changes from one place to another can be Regarded as a function of location. 
  •        A WSN can be used to approximate this unknown function (to extract its spatial characteristics), using a limited number of samples taken at each individual sensor node. 
  •     This approximate mapping Should be made available at the sink. How and when to update this mapping depends on the application's needs, as do the approximation accuracy and the inherent trade-off against energy consumption. 
  •      Similarly, a relevant problem can be to find areas or points of the same value Given. 
  •      This can be generalized to finding "edges" in search functions or to sending messages along the boundaries of Patterns in Both Space and / or time.
  
    TRACKING

  •   The source of an event can be mobile (eg to intruder in surveillance scenarios).
  •       The WSN can be used to report updates on the event source's position to the sink (s), potentially with estimates about speed and direction as well.
  •      These interactions can be scoped Both in time and in space (reporting events only within a Given timespan, only from Certain areas, and so on).
  •      These requirements can thus change dynamically over time; Sinks have to have a Means to inform the sensor of Their requirements at runtime.
  •     More Over, thesis interactions can take place only for one specific request of a sink or They Could be long-lasting relationships between many sensors and many sinks.
  •     In addition, sensor nodes can be mobile Themselves and compensate_for_errors Shortcomings in the deployment process by moving into a post-deployment phase, to position search did Their sensing tasks can be better Fulfilled.
  •       They Could therefore be mobile Because They are attached to other objects and the network has to adapt itself to the location of nodes.
Protected by Copyscape Online Plagiarism Scanner

Monitors

Monitor: -

  • Solution to Problems of semaphore.
  • encapsulate Shared Data Structures With Their operations and hide Their representation
  • Provide competition synchronization without semaphores.
  • by Transferring responsibility for synchronization to the Run Time System.

Introduction: -
  • .According To Per Brinch and Edsger Dijkstra in 1971 all synchronization operations on shared data be gathered into a single program unit.
  • Brinch Hansen (1973) formalized Their concept in the Environment Operating System
  • Hoare (1974) named thesis monitor 
Competition Synchronization: -             
  • Important features: - Shared Data is resident in the monitor rather than in any of the client units.
  • Implementation of a monitor can be made to guarantee synchronized access at a time.
  • Calls to monitor: - Implicitly blocked and stored in a queue.  If the monitor is busy at the time of the call 
Cooperation Synchronization: -

  • Mutually exclusive access to shared data is intrinsic.
  • cooperation task of the programmer.
  • programmer must guarantee- shared buffer does not experience underflow or overflow.

description of the diagrams

  • Interface to monitor is insert and remove.
  • Monitor Exactly Like an abstract data type- a Data Structure with Limited Access.
Evaluation: -
  • Better Way to Provide Competition Synchronization 
  • Cooperation Synchronization is a silent problem.
  • Equally powerful - expressing concurrency control.
  • semaphores - used to implement monitor and vice versa.
  • Ada has two ways: - Ada tasking model 83- genal and Ada 95 protected objects
  • cleaner and more efficient way of constructing monitor.
  • They use message passing Which Allows concurrent units to be distributed       






Protected by Copyscape Online Plagiarism Scanner