c@t(ID:8326/)Language for Programming Massively Distributed Embedded Systems Scheme language for embedded system for declarative network programming Related languages
References: that are composed of thousands (even millions) of interacting computing devices. Due to the improvements in fabricating technologies, it is becoming possible to build tiny single-chip devices equipped with logic circuits, sensors, actuators and communication components. A large number of these devices can be networked together to build Massively Distributed Embedded Systems (MDES). A wide variety of embedded control applications are envisioned for MDES: responsive environments, smart buildings, wildlife monitoring, precision agriculture, inventory tracking, etc. These examples are compelling, however, developing applications for MDES remains complex due to the following issues: MDES consist of large number of resource constrained devices and the number of potential interactions between them can be combinatorially explosive. Systems with the combined issues of such scale complexity, interaction complexity and resource constraints are unprecedented and cannot be programmed using conventional technologies. Accordingly, this thesis presents c@t, a language that employs the following techniques to address the issues of MDES: 1. To address the scale complexity, c@t provides tools for programming the system as a unit. 2. c@t offers a declarative style network programming interface so that network interactions can be implemented without writing any low-level networking code. 3. The applications developed using c@t are vertically integrated. That is, the compiler customizes the runtime environment to the suit the application needs. Using this integrated approach, efficient applications can be developed to fit the available resources. This thesis describes the design, features and implementation of c@t in detail. A sample application developed using c@t is also presented. Extract: Declarative Network Programming Declarative Network Programming In c@t, the interactions between devices can be implemented without writing any lowlevel networking code. c@t uses the paradigms of function calls and variable references to represent the interactions between devices. Further more, these transfers of control and data can be implemented without writing any low-level networking code. For instance, the function activate defined on fan controllers is invoked by the function monitor defined on sensors as seamlessly as invoking a local function. The machine code produced by the c@t compiler is vertically integrated. That is, the c@t compiler not only produces the application code, but also every single code component that runs on devices. This integrated approach can lead to efficient code realizations, as all the components can be tailored to the needs and characteristics of the application. For instance, the temperature control system can be realized in at least three of many possible ways: 1. A centralized solution, where a powerful device (if available) is chosen as a registry and all the other devices register themselves with that registry. When the sensors need to activate a fan controller, they can search this registry to choose an appropriate device and send an activation message. 2. A completely decentralized solution, where devices form minimum spanning trees to communicate and interact. Every time there is a temperature change, the sensors could search the neighborhood for fans and notify the best one. This solution is best suited for situations where there is no powerful device to act as a central registry and the searching for devices would not be expensive. 3. A hybrid solution, where many clusters are formed with one fan, one heater and multiple sensors. This solution assumes that fans can service multiple sensors simultaneously. A solution can be selected based upon the required performance (limit on number of messages exchanged, reliability, duration of operation etc) and the available resources (computational resources, interconnection topology etc). Such extensive 18 analysis is beyond the scope of current implementation. Currently, this work focuses on language design, development of the c@t compiler, and the implementation of a runtime environment. Extract: The c@t Language The c@t Language The goal of c@t is to help manage the scale and interaction complexities of MDES by preserving the sequential programming paradigms for distributed computations. c@t satisfies this goal by using the techniques of collective programming and declarative network programming. The design of c@t language is heavily influenced by Scheme. c@t, like Scheme, employs a fully parenthesized prefix notation for programs and data. This language is statically scoped with a block structure established by the enclosing functions. c@t is a statically typed or a strongly typed language. Types are associated with variables. Every program statement is checked for the correct type usages and promotions. Arguments to c@t procedures are always passed by value, which means that the actual argument expressions are evaluated before the procedure gains control, whether the procedure needs the result of the evaluation or not. The c@t compiler is written in Scheme (PLT Scheme [26]). As shown in Figure 1-2, the c@t compiler translates the programs to ANSI C and employs a C compiler to generate processor-specific machine code. The current implementation uses the Hi-Tech PICC Lite compiler [16] to generate code for midrange PIC processors. The advantages of the translating to C are: ? The c@t compiler can utilize many of the low-level service routines provided by the C compiler. For instance, the PICC lite compiler provides memory initialization routines, interrupt handling routines, power on reset code, floating point routines etc. ? Since c@t translates programs to ANSI C and C compilers are available for many commercially available processors, it becomes easy to support a wide range of processors immediately without writing any processor-specific code generators. This approach has one disadvantage: since the c@t compiler doesn?t have complete information about the low-level code generated by the C compiler, it could be a barrier to producing integrated applications. However, the c@t compiler can reasonably approximate the necessary information and still function adequately. |