The Landscape of Pervasive & Mobile Computing Standards Sumi Helal Synthesis Lectures on Mobile and Pervasive Computing Preface
Download 0.57 Mb.
|
- Navigate this page:
- 13.6 Atlas Platform
13.5 PhidgetsSaul Greenberg and Chester Fitchett at the University of Calgary developed an innovative sensor and actuation platform called Phidgets or “physical widgets.”13.1 Their goal was to package physical sensors, actuators, and associated control software into physical widgets which would provide the same level of abstraction for physical devices that software widgets provide to an application developer. This would enable programmers to concentrate on developing end-user applications rather than getting distracted with low-level hardware and software issues. The Phidgets hardware consists of an interface board with a microcontroller and USB connectivity that allows developers to hook up sensors and actuators (see Figure 13.3). A PC application can then access these sensing and actuation devices through USB. Phidgets provide intuitive software control libraries for different sensors and actuators in programming languages such as Visual Basic where even novice programmers can simply drag and drop controls into their project and quickly create fairly sophisticated applications with a few lines of code. This is in sharp contrast to older platforms like the Berkeley Motes which required application developers to have embedded systems knowledge and write relatively low-level code which ran directly on the platform microcontroller making it extremely hard to write and modify complex applications. Phidgets are known for their ease of use and support of rapid prototyping, but they only support a USB communication interface and don’t have any wireless or wired networking capability. This tethering makes it difficult to deploy sensors and actuators throughout the space without requiring a fullfledged PC nearby. It makes it impractical to use the Phidgets hardware for large deployments since that would entail a messy arrangement of USB cables. Furthermore, Phidgets can’t communicate among themselves (something that platforms such as Berkeley Motes support) and the application developer has to design any such interaction from scratch. Despite these shortcomings, they remain one of the most popular platforms for prototyping in the smart spaces research community.
The Atlas hardware is designed around the Atmel Atmega128 RISC microcontroller. However, unlike most other sensor platforms, it supports different communication and sensor and actuator interface boards using the same processing hardware and firmware. Atlas was one of the first widely available sensor platforms that didn’t provide support for ad-hoc networking and instead relied on the IP protocol with further upgrades providing ZigBee and USB capabilities. This enabled application developers to intergrate Atlas-based sensor networks into existing IT infrastructure. Any Atlas hardware node could be configured for attaching multiple numbers of sensors and actuators by using an intuitive Web-based interface. This is in sharp contrast to sensor platforms such as the Berkeley Motes which require firmware modifications to accommodate different sensor configurations. Once an Atlas node is configured and powered on, all the sensors and actuators attached to it are abstracted into individual software services in a backend SOA framework such as OSGi. Making physical devices available as software services enables applications residing in the smart space to dynamically discover and access them. Similar to the Phidgets concept, Atlas abstracts away low-level device details and provides high-level APIs to application developers for controlling sensors and actuators deployed in the space. Unlike Phidgets however, Atlas supports a number of networking interfaces such as WiFi, ZigBee, Wired Ethernet, and USB hence nodes can be deployed all over the smart space. Since Atlas abstracts away the networking details, all nodes appear as part of the same logical network even if they are on separate physical networks. Moreover, even though the Atlas platform’s firmware is application agnostic, applications can push down basic data processing tasks onto the nodes such as aggregation, filtering and event-based triggers involving multiple nodes across the network. The utilization of SOA for abstracting physical devices into software services provided Atlas two major advantages. First, since each device is a high-level software service it enables developers to compose the same set of sensing and actuation devices into multiple applications without worrying about low-level embedded system details. Second, the SOA paradigm in conjunction with the use of IP-based networking allows Atlas to easily integrate sensors and actuators into existing business process management and IT systems. This has always been the Achilles heel of most sensor platforms which meant that for the longest time, their utility was largely confined to prototyping, test-beds and academic projects. Incorporation of these design features made Atlas extremely popular with commercial users who prefer standardized communications and interfaces for deploying sensors and actuators in their system. Download 0.57 Mb. Share with your friends:
|
Figure