the following description is presented to enable any person skilled in the art to make and use the invention , and is provided in the context of a particular application and its requirements . various modifications to the disclosed embodiments will be readily apparent to those skilled in the art , and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention . thus , the present invention is not limited to the embodiments shown , but is to be accorded , the widest scope consistent with the claims . the data structures and code described in this detailed description are typically stored on a computer - readable storage medium , which may be any device or medium that can store code and / or data for use by a computer system . this includes , but is not limited to , magnetic and optical storage devices such as disk drives , magnetic tape , cds ( compact discs ), dvds ( digital versatile discs or digital video discs ), or any device capable of storing data usable by a computer system . wireless sensor networks ( wsns ) are emerging as an important technology that allows tight integration of the physical world with a computing system infrastructure . ad hoc , self - organizing , distributed wireless sensor systems composed of a vast number of sensor nodes can be deeply embedded in physical environments . while nodes can vary in their basic architecture , most have severe resource limitations that call for extremely efficient computation models and communication patterns . the design and maintenance of software infrastructure needs to be attentive to these constraints , while addressing the complexities inherent to any distributed system . wsns are diverse at all levels , from their hardware configurations to the applications they run . multiple modes of sensing , computing , and communication enable a wide spectrum of applications that include , but are not limited to , disaster recovery , homeland security , civilian infrastructure monitoring , condition - based maintenance in factories , education , habitat monitoring , precision agriculture , military use , education , and pervasive computing environments . applications in these areas can be characterized not only by their diversity , but also by the specific and unique requirements they impose on underlying software and network infrastructure . often , they require long - term uninterrupted and unattended operations . key characteristics include : small nodes with cost limitations and highly limited resources ( e . g . small amounts of memory and low - power / low - bandwidth communication mechanisms ), heterogeneity in nodes , applications and systems software that evolve during application lifetime , and physical node deployment . in order to enable the successful development , deployment , and management of sensor network applications , the applied software technology should ideally not limit long - term reliability and secure deployment , and should ideally ensure that each of the above characteristics are addressed suitably . fig1 illustrates an exemplary wireless sensor network application , in which a set of heterogeneous sensor nodes 102 observe and gather information from two physical environments . gateways 104 in each environment collect and aggregate these results and then send them through a transit network 106 to a base station 108 . the base station 108 in turn processes the data and then forwards the results through the internet 110 to a set of interested clients 114 . the base station can also send the data to a data service 116 for long - term storage or backup . note that even a single wsn deployment may require a wide range of devices and architectures . for instance , for the wsn of fig1 , there are three types of nodes ( sensor nodes , gateways , and base stations ), whose roles are filled by specialized devices with different capabilities . wsn applications are typically built using software infrastructure . ( e . g . operating systems , middleware , virtual machines , etc .) that interface the applications with the low - level devices , provide communication mechanisms for cooperation among devices , and manage device and network - wide resources . fig2 a illustrates a traditional software stack . a layer of system software 204 is implemented directly upon the device hardware 202 , and a set of middleware services 206 are built on top of the system software 204 . applications 208 can interact with the middleware 206 or directly with the system software 204 . wsn software infrastructure needs to run on a wide variety of devices , have a minimal resource footprint , and be easily adapted to run on a new set of devices . one option is to build for the lowest common denominator , but this fails to take advantage of the unique features of each platform . maintaining a separate version of an application for each platform takes advantage of unique platform features , but requires developers to understand the peculiarities of each platform . in addition , in such an environment it is difficult for developers who need to be able to work with software that they did not write and account for performance and resource usage implications . the present invention provides a set of component - based development techniques that automate the process of customizing applications and system software for a range of widely different platforms , thereby making wsn applications easier to write , deploy , and maintain . this approach breaks software artifacts into fine - grained components and composes these components according to a set of non - functional constraints , application requirements , and device properties . the key challenge in building a software stack for heterogeneous and resource - constrained devices lies in developing techniques that : ( 1 ) expose a common set of abstractions that are independent of specific platforms ; and ( 2 ) permit mapping of these abstractions to a wide range of platforms with diverse resources and capabilities . an important insight takes advantage of two possible views of a software stack : a logical view and a reified view . an application developer sees the logical and platform - independent view when developing software components , so that the development task is unhindered by peculiarities and limitations of target sensor devices . the reified view is an application - specific projection of the logical view for a specific device . the logical view thus denotes a product family , whereas the generated reified view denotes a specific product in the family . the development challenge lies in designing software techniques and tools that facilitate and automate the process of constructing reified views from logical views . two principal aspects of reification are software synthesis and software scaling . software synthesis of a wsn application involves identifying semantic properties of an application and discovering the software components needed to build a complete execution environment for the application . synthesis involves analyzing the semantic properties of an application , identifying the programming language abstractions used and components required , and then configuring an execution environment that contains these abstractions and components . software synthesis is useful because the logical abstract view may be too general , which results in an unnecessarily rich service model with a very narrow application layer . on resource - constrained devices , loading an entire suite of services may be impossible . synthesis allows the system to discard abstractions not needed by a specific application , thereby resulting in a minimal , resource - efficient infrastructure . while software synthesis yields a compact semantic view , the system may not be able to implement this view in a general form on many platforms due to resource constraints or fundamental architectural limitations . in these cases , the system may need to use “ software scaling ” to scale the synthesized software stack up or down so that services implemented by the components can be provided at enhanced or diminished capacity . the system expands this notion of scaling , traditionally used to characterize the ability to adapt in demand or resources at run time , by allowing the developer to adjust software to known differences in the runtime environment at build time . the result is a scalable software design methodology aimed at building software artifacts that can run on a wide variety of devices with different levels of quality and fidelity depending on the resources and capabilities of the underlying platforms . one example of software scaling is a garbage collection component . some garbage collectors have significant memory overhead , while others require much less space but may be slow . a system that uses scaling can automatically select a garbage collection component that meets the resource limitations of a specific platform . software scaling highlights the design trade - offs that can be made with respect to resources that are available , and codifies these trade - offs so that the software stack for wsn applications can be automatically generated . software scaling requires identifying design trade - offs for three aspects of software artifacts : state , computations , and information representation . states capture the specific knowledge used in a computation , and can be stored at different levels of detail or extent . for instance , in fig1 , the gateway nodes 104 may have more memory , and thus store additional network routing information , while the sensor nodes 102 store only application - specific and nearest - neighbor data . computations transform knowledge in the network . the choice of computation techniques will depend on the speed of the cpu or other hardware capabilities ( e . g . the lack of a dedicated floating - point unit may result in software estimation of floating point values ). finally , the system can represent information about program abstraction at different levels of detail . an example in this instance is the amount of type information available for runtime reflection , serialization , and debugging purposes ; typed object or byte code may consume a significant amount of space , and sometimes cannot be stored on smaller nodes . software scaling enables the system to identify and represent the design trade - offs in states , computations , and information representation , and thereby automate the synthesis of highly - scalable software systems . in one embodiment of the present invention , the system achieves scaling by providing language mechanisms and tools . these mechanisms identify the design parameters ( e . g . memory , energy efficiency , performance , etc . ), associate the design parameters with application and software infrastructure components , and use a design trade - off technique to select the set of components that will satisfy implicit application requirements and meet overall resource constraints . fig2 b illustrates the synthesis and scaling of a traditional software stack 210 into a customized software stack 212 . the initial traditional stack 210 is unnecessarily rich , with a set of operating system components 214 and middleware / virtual machine ( vm ) components 216 that provide a wide range of services to applications 218 . the system uses software synthesis 220 to identify a smaller set of components 222 required for the applications 218 , and then software scaling 224 chooses the specific components suited to the composition of a minimal , resource - efficient infrastructure suited to the capabilities of the device hardware 202 . one embodiment of the present invention uses a high - level virtual machine ( vm ) as the core software for sensor nodes . this vm includes a common execution framework ( such as data types and an instruction set ), a computation model ( e . g . concurrency and event handling ), a set of runtime services for managing devices , application , and system resources , and a set of libraries for accessing device - specific capabilities . in a variation on this embodiment , the system uses the java ™ virtual machine ( jvm ) instruction set to specify the common execution framework for sensor nodes . there are several benefits to using a vm as the core software . first , the vm masks the differences among sensor nodes through the common execution framework . application distribution , management , and interoperability take place through the common intermediate representation . secondly , the system can customize vm implementations to exploit specific capabilities of devices . these implementations can be scaled up or down , can be optimized for specific architectures , and / or can be made more resource aware without affecting applications . finally , applications can access device - specific features ( for instance , specific sensing or actuating capabilities ) through a native library . thus , applications can evolve as devices evolve , and interoperate with older devices at the same time . while vms sometimes introduce overhead , the system can reduce such overhead through streamlined interpreter implementation and jit compilation , as well as small - device - specific techniques such as partial compilation , result caching , and hardware - assisted instruction execution . the system uses software synthesis and scaling to generate a device - specific and application - specific vm . fig3 illustrates the generation of a runtime environment for applications , while fig4 presents a flow chart illustrating application generation . in the first step ( step 402 ), the system receives an application specification . in one embodiment of the present invention , applications 302 are written in gaggle , a macro - programming language designed for programming wsns . since sensor applications typically use such a large set of nodes that assigning individual tasks to nodes is difficult , gaggle supports high - level abstractions for organizing and controlling sensor nodes in terms of groups , implementing and managing synchronous and asynchronous node and group - level interactions , and group - level information sharing . a gaggle compiler 304 analyzes the application and transforms it into java ™ class files 308 , thereby generating a product specification that characterizes the middleware components required to implement the application . alternatively , the application 306 may be written in java ™ or other languages that can output java ™ class files or byte code . note that the application specification is not language - dependent , and the techniques described in the present invention can be applied generally to any programming language . next , the system uses a java ™ compiler 310 to generate java ™ bytecode 312 ( step 404 ). the bytecode program provides a high - level product requirement specification for the runtime environment that will run on each sensor device . this specification contains information about vm instructions , language abstractions ( such as type , inheritance , static / instance variables , exception handling , concurrency , synchronization , etc . ), references to other classes or native libraries , runtime , and operating system modules . the system performs byte code analysis 314 to generate a platform - independent product specification 316 that characterizes the vm and operating system ( os ) components needed to run the application on a sensor node ( step 406 ). the high - level language - semantics - driven derivation of the application - specific product specification 316 allows the system to use a software synthesis tool to inspect a set of implementation components 320 and discard the components ( e . g . instructions , runtime services , libraries , etc ) not needed to run the application ( step 408 ). the synthesis tool outputs an application - specific software stack 322 that describes a minimal set of application needs . for instance , if an application only requires 20 vm instructions to run , the produced stack will only contain support for those 20 instructions . the system passes the application - specific software stack 322 on to a product scaling tool 324 , which analyzes a set of target device descriptions 326 , the application needs , and the candidate components to select a set of component implementations that meet the constraints imposed by the platform ( step 410 ). the output of the product scaling 324 is an application - and platform - specific software stack 328 . the system uses this stack for software generation 330 , during which it generates customized device stacks 332 for each device description type ( step 412 ). this involves creating a binary for each vm , and patching the application class for any references to native methods . after this , the system proceeds to use a distributed program loader to load the application and system software binary on the target device ( s ). the high - level languages ( e . g . gaggle and java ™), the virtual machine that runs on each device , and the low - level operating system that interfaces with the low - level hardware form an abstract software stack . the fine - grained composition process described above allows the construction of application - specific virtual machines and operating systems that can be run on highly resource - constrained devices , while maintaining an illusion of a high - level programming language abstraction for wsn application writers . one challenge in software synthesis and scaling lies in the ability to discover semantic properties of applications and the demands they place on the runtime environment . to scale a software infrastructure , the system needs to be able to identify the design parameters ( e . g . memory , energy efficiency , performance , etc . ), associate the design parameters with application and software infrastructure components , and use a design trade - off technique to select the set of components that will satisfy application requirements and node constraints . the system should be able to provide scaling services for a wide variety of object types , such as different thread types , software techniques ( e . g . sorting or search methods , inheritance ), code ( e . g . code size scaling , type info , data structure types ), data storage sizes and methods , and caching techniques / extent . in one embodiment of the present invention , the system uses a component language that addresses these challenges by allowing software developers to annotate components with design - choice descriptions and associate complex dependency relationships among components . this language represents the software system at a very fine - grained level so that decisions about the composition of the system can be made at all levels , including specific data structures and functions . given that a software stack on a sensor node will include components potentially written in several programming languages , this language also supports the ability to represent components described and implemented in different languages by separating the structure , composition , and scalability aspects of a system from its actual implementation . finally , the language also facilitates future updates of applications and system software as wsn applications and infrastructure change , thereby allowing the system to implement changes in application requirements , to fix bugs , and to enhance capabilities of the system software . another challenge in the wsn space involves long - term management of applications after deployment . given that many sensing devices are embedded in physical settings that will be difficult to reach , the ability to dynamically update deployed applications and system software is important . however , there are a number of challenges in providing updates to sensor network nodes . first , re - flashing sensor node binaries can be error - prone , and errors in updates can render a large number of devices unusable . another concern is security , since anyone with access to the control channels can upgrade the firmware . finally , for widely - deployed sensor networks , the update process may need to patch thousands or even millions of heterogeneous devices . in the present invention , the system structures the vm to evolve dynamically to meet changing requirements , and modifies components selectively and securely . the system supports secure updates by implementing a protocol that admits update requests only from authenticated end - points . the system implements an extensible vm using a remote dynamic linking service that adds new vm and service components to a sensor node vm . when an application is changed , the system generates new bytecode and determines any corresponding component changes . in one embodiment of the present invention , the system uses a monitoring system to track the devices and application versions installed , and to facilitate pushing out incremental semantic changes . the system uses higher - capability devices ( e . g . the gateway node 104 or base station 108 in fig1 ) for tracking and to assist in the update process for lower - capability nodes . these higher - capability devices can speed up the update by providing features such as higher compute power , memory space , and remote incremental linking functionality . for instance , the base station can maintain for every sensor node installed the layout of program and data memory , the vm and application code , version information , etc . these flexible update options allow the efficient upgrade of the software infrastructure installed in the sensor network in the face of evolving applications . in summary , the present invention provides a set of component - based development techniques that automate the process of customizing applications and system software for a range of widely different platforms , thereby generating application - specific software infrastructure that meets the resource constraints of sensor network applications . the foregoing descriptions of embodiments of the present invention have been presented only for purposes of illustration and description . they are not intended to be exhaustive or to limit the present invention to the forms disclosed . accordingly , many modifications and variations will be apparent to practitioners skilled in the art . additionally , the above disclosure is not intended to limit the present invention . the scope of the present invention is defined by the appended claims .