Abstract-With the advent of CMOS cameras, it is now possible to make compact, cheap and low-power image sensors capable of on-board image processing. These embedded vision sensors provide a rich new sensing modality enabling new classes of wireless sensor networking applications. In order to build these applications, system designers need to overcome challanges associated with limited bandwith, limited power, group coordination and fusing of multiple camera views with various other sensory inputs. Real-time properties must be upheld if multiple vision sensors are to process data, communicate with each other and make a group decision before the measured environmental feature changes. In this paper, we present FireFly Mosaic, a wireless sensor network image processing framework with operating system, networking and image processing primitives that assist in the development of FireFly Mosaic, we demonstrate an assisted living application capable of fusing multiple cameras with overlapping views to discover and monitor daily activities in a home. Using this application, we show how an integrated platform with support for time synchronization, a collision-free TDMA link layer, an underlying RTOS and an interface to an embedded vision sensor provides a stable framework for distributed real-time vision processing. To the best of our knowledge, this is the first wireless sensor networking system to integrate multiple coordinating cameras performing local processing.

No abstract

High-level specification of patterns of communications such as protocols can be modeled elegantly by means of session types [14]. However, a number of examples suggest that session types fall short when finer precision on protocol specification is required. In order to increase the expressiveness of session types we appeal to the theory of correspondence assertions [5,10]. The resulting type discipline augments the types of long term channels with effects and thus yields types which may depend on messages read or written earlier within the same session. We prove that evaluation preserves typability and that well-typed processes are safe. Also, we illustrate how the resulting theory allows us to address the shortcomings present in the pure theory of session types.

This paper [2] proposes a simple abstraction of the artifacts and activities of software development. Its purpose is to serve as a framework for discussion and comparison in software engineering, just as the ISO 7-Layer Reference Model has served in the networking area. The reference model is a more complete and formal treatment of some of our earlier work [3,6], presented in higher-order logic.Designations identify classes of phenomena in the system and environment, and assign formal names to them. Designated terms are partitioned into classes identifying phenomena that are based on control and visibility relative to the environment and system. The primary artifacts of software development are: domain knowledge, providing presumed facts about the environment; requirements, indicating what the customers need from the system in terms of desired effects on the environment; the specification, providing enough information for programmers to build a software system satisfying the requirements; the program, which implements the specification on the programming platform; and the programming platform, describing a programmable machine that can be used to satisfy the requirements.The reference model also includes proof obligations expressing the necessary relationships among the artifacts. They characterize software development in terms of the design goals for the artifacts and the relationships among them to be established by construction or verification. At the highest level, the proof obligation demands that: the domain knowledge is satisfiable; for any feasible behavior of the environment there is a feasible behavior of the system (program and platform); and if the environment, the program, and the platform always behave as described, then the requirements are always satisfied. These high-level obligations are refined to include the concept of a specification, which acts as a point of communication between customers and developers. Obligations involving specifications are as essentially these: for any feasible behavior of the en-vironment there is a feasible behavior of the specification; the program on the programming platform implements the specification; and if the environment and the system always behave as described by the domain knowledge and the specification, then the requirements are always satisfied.The full paper provides a detailed comparison with the Functional Documentation Model [4,5]. Although there are many similarities, the reference model proposed here covers errors that would not be detected using the Functional Documentation Model.Our experience in applying the reference model [1] suggests that it is useful even when the artifacts of software development are not formal. References[1] KA reference model for requirements and specifications. IEEE Software, 2000. [3] M. Jackson and P. Zave. Deriving specifications from requirements: An example. In

No abstract