Active Badges—The Next Generation
An increased interest in location-aware computer systems has occurred recently. This class of computer systems is able to react to location changes of people, equipment or resources. These systems could create a base for applications such as a “follow me” computer environment that supports user mobility around a building. The main part of such a system forms a location system.
This article describes our experiences during the implementation of a selected component of a new ABng (Active Badges Next Generation) software component for the location system called Active Badge. The ABng software has been implemented as a CORBA application using the distributed object paradigm.
The component of the ABng software that we implemented is called the poller: it acts as a communication engine between Active Badge Systems' sensors and the rest of the location system. Its efficiency and reliability have a substantial influence on system performance. Despite this strategic role, the poller is a self-contained, plug-and-play hardware component, easy to install and inexpensive.
The main purpose of this paper is to show that the usual trade-off problems between robustness, efficiency and low price can be solved by implementation of the poller as a Linux-embedded application. All consequences of this design decision have been analyzed in detail to evaluate its advantages and disadvantages.
The Active Badges system was originally invented and developed at the Olivetti Research Laboratory in Cambridge, UK, in 1990-92. It uses hardware infrastructure with the key components of infrared (IR) sensors installed in fixed positions within a building, and infrared emitters (active badges) worn by people or attached to equipment. The sensors are connected by a wired network that provides a communication path to the controlling device, called a poller. A poller can be implemented on a PC or a workstation using a software communication protocol to talk to the active sensors.
An active badge periodically transmits an infrared message containing a globally unique code (a badge identifier) using a data-link layer protocol running over an RS-232/422 network. The messages sent by the badges are received and queued by sensors. A poller periodically polls sensors and retrieves badge messages from the sensor queues. Each message and the identifier of the sensor that received the message is forwarded to the software part of the Active Badges system. The software layer maintains a database that maps sensors to places where sensors are installed, and badges to the users wearing them or the pieces of equipment to which they are attached.
The relation defined between a set of sensors and badge identifiers is called sighting. Using collected data, the system can infer where users or pieces of equipment are currently located. Information about the current locations of users and equipment is provided to various applications, such as presentation tools that display location data or applications that use location data to control the users' environment. The software part of the original Active Badge system developed at ORL uses the ANSAWare distributed environment.
The ABng project goal is the development of a new software layer of the Active Badge system that will be flexible and reconfigurable. To satisfy this requirement, ABng uses modern components and object-oriented technology. The system was developed in CORBA-compliant environments: Orbix, omniORB and OrbixWeb. It is based on the object model in which all logical and physical elements of the Active Badge system (users, locations, sensors, badges, etc.) are represented as CORBA objects.
In the context of the ABng project requirements, ABng poller must be implemented as a CORBA object. The poller provides two-way communication between sensors and the rest of the system. It is, in fact, a gateway between the ABS data-link layer protocol running over an RS-232/422 network and the IIOP implemented over a TCP/IP protocol stack.
The poller acts as a CORBA client when it forwards information from the sensors, and as a CORBA server during information flow in the opposite direction. Acting as a client, the poller provides information (mainly the badge identifiers seen by a given sensor) to all Main Sighting Processors (MSP) registered with the poller, so that the MSP can update the sighting relation. The observed/observer design pattern is exploited to organize this communication. As an example, let's see what happens when a person wearing a badge (see Figure 2) enters a room containing an IR sensor. The message containing the identifier, generated by the badge, is observed by the IR sensor and cached in its local buffer. When the poller sends the next periodic polling request to the sensor, the information cached by the sensor is sent back to the poller. The poller in turn sends this message, with the sensor and serial network numbers, to all its observers; the MSPs interested in receiving the information needed for the sighting relation modification.
Taking the role of a server, the poller provides operations that forward commands to sensors and badges. In the ABng system, these commands are issued by a dedicated server called Scheduler. The badge can play sounds, and turn one of its two LEDs on or off. This simple feature can be used to notify a person wearing an Active Badge about events—for instance, a phone call or an e-mail arrival. This notification could also include an action based on information about the person's location, e.g., a call could be redirected to the nearest telephone.
The poller server's software interface consists of two parts, each with its own functionality. The first part of the interface provides system operations that register MSPs interested in receiving information for the sighting relation update from the poller. It will also de-register them when they are no longer interested. The second part represents the operations corresponding to the set of commands performed by sensors and badges.
The ABng system is integrated using two services: a standard name server implemented according to COS OMG specification and a server manager. The server manager is a dedicated server providing a notification mechanism for all servers in the system interested in server activity. When a new ABng poller is started, it registers with the name server via the server manager; the server manager notifies all registered MSPs that a new poller has begun activity. The server manager also monitors the poller process using a simple keep-alive protocol. The poller's IOR (Inter-Orb Reference) is de-registered from the name server when the poller is removed from the system or when its process dies. This integration mechanism provides plug-and-play functionality for the ABng poller CORBA server, supporting self-configuration and automatic binding, which is crucial in systems with many dependencies between the objects.
ABng poller is a multi-threaded Linux application, with the main purpose of collecting sightings from the serial lines and distributing the received data to registered observers. This application can be configured to interface with sensors designed by the ORL as well as with the modified sensors commercially available from Olivetti. The six serial lines available in the prototype ABng poller can serve up to about 80 sensors with reasonable response time. When more sensors are needed, additional pollers must be deployed. The design of the ABng system places no limitation on the number of pollers; thus, system scalability is ensured.
ABng poller is able to cooperate with other parts of the system via the standard socket services or through the CORBA interface. This feature enables a smooth transition from the old ANSAWare-based location system to the CORBA-based ABng. Object Request Broker functionality is ensured by the omniORB which, although free, has performance levels hard to beat by the commercially available CORBA-compliant products including the industry leader—Orbix. An important feature of omniORB is its portability; it runs on most modern operating systems, including Linux.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide