We almost missed the chance to highlight that the cover story of the July, 2014 issue of the Communications of the ACM (CACM) is a paper by a Caltech group on the Community Seismic Network (CSN). This note is about CSN as an example of system in a growing, important nexus: citizen science, inexpensive sensors, and cloud computing.
CSN uses inexpensive MEMS accelerometers or accelerometers in phones to detect shaking from earthquakes. The CSN project builds accelerometer “boxes” that contain an accelerometer, a Sheevaplug, and cables. A citizen scientist merely affixes the small box to the floor with double-sided sticky tape, and connects cables from the box to power and to a router. Installation takes minutes.
Analytics in the Sheevaplug or some other computer connected to the accelerometer analyzes the raw data streaming in from the sensor. This analytics engine detects local anomalous acceleration. Local anomalies could be due to somebody banging on a door, or a big dog jumping off the couch (frequent occurrence in my house), or due to an earthquake. The plug computer or phone sends messages to the cloud when it detects a local anomaly. An accelerometer may measure at 200 samples per second, but messages get sent to the cloud at rates that range from one per minute, to one every 20 minutes. The local anomaly message includes the sensor id, location (because phones move), and magnitude.
There are four critical differences between community networks and traditional seismic networks:
- Community sensor fidelity is much poorer than that of expensive instruments.
- The quality of deployment of community sensors by ordinary citizens is much more varied than that of sensors deployed by professional organizations.
- Community sensors can be deployed more densely than expensive sensors. Think about the relative density of phones versus seismometers in earthquake-prone regions of the world such as Peru, India, China, Pakistan, Iran and Indonesia.
- Community sensors are deployed where communities are located, and these locations may not be the most valuable for scientists.
Research questions investigated by the Caltech CSN team include: Are community sensor networks useful? Does the lower-fidelity, varied installation practices, and relatively random deployment result in networks that don’t provide value to the community and don’t provide value to science? Can community networks add value to other networks operated by government agencies and companies? Can inexpensive cloud computing services be used to fuse data from hundreds of sensors to detect earthquakes within seconds?
I’ve been busy traveling for most of the last month, so missed my chance for timely postings about a couple of exciting happenings that highlight how theory can impact practice. But, here are two that I can’t resist a quick post about, even if it is a bit late.
First, this year’s ACM SIGCOMM award recipient is George Varghese, for “sustained and diverse contributions to network algorithmics, with far reaching impact in both research and industry.” I think that’s a pretty nice summary. George’s work has been an inspiration for me since grad school when I worked through his book on Network Algorithmics. He is one of the masters at finding places where theoretical/algorithmic foundations can have practical impact. He’s also a master at communicating theoretical work to systems folks. As a result, he’s one of the few folks that can consistently get theory-driven work into Sigcomm, which makes him the envy of many in the community. It’s really great to see someone with such strong theory chops being recognized by the networking systems community.
The second piece of news is another highlight about the impact of Leslie Lamport‘s work. Mani wrote a great post about him when he received the Turing award earlier this year, in case you missed it. I finally got to see him give a technical talk at the Microsoft Faculty summit this year, and was excited to hear about how some of his work on model checking was finally getting adopted by industry. He mentioned in his talk that Amazon was beginning to adopt it for some large internal projects, and was even budgeting time for development for TLA+, a formal specification language that Leslie invented. After hearing this, I started to dig around, and it turns out that James Hamilton has recently blogged about incorporating TLA+ into the development of DynamoDB.
In Part I of this post, I have explained the idea of reverse and forward engineering, applied to TCP congestion control. Here, I will describe how forward engineering can help the design of ubiquitous, continuously-acting, and distributed algorithms for load-side participation in frequency control in power networks. One of the key differences is that, whereas on the Internet, both the TCP dynamics and the router dynamics can be designed to obtain a feedback system that is stable and efficient, a power network has its own physical dynamics with which our active control must interact.
This blog post will contrast another interesting aspect of communication and power networks: designing distributed control through optimization. This point of view has been successfully applied to understanding and designing TCP (Transmission Control Protocol) congestion control algorithms in the last 1.5 decades, and I believe that it can be equally useful for thinking about some of the feedback control problems in power networks, e.g., frequency regulation.
Even though this simple and elegant theory does not account for many important details that an algorithm must deal with in a real network, it has been successfully put to practice. Any theory-based design method can only provide the core of an algorithm, around which many important enhancements must be developed to create a deployable product. The most important value of a theory is to provide a framework to understand issues, clarify ideas, and suggest directions, often leading to a new opportunity or a simpler, more robust and higher performing design.
In Part I of this post, I will briefly review the high-level idea using TCP congestion control as a concrete example. I will call this design approach “forward engineering,” for reasons that will become clear later. In Part II, I will focus on power: how frequency regulation is done today, the new opportunities that are in the future, and how forward engineering can help capture these new opportunities.
June is a month that is dominated by conference travel for me, with three of my favorite conferences all typically happening back-to-back. The third (and final) of these this year was Stochastic Networks. The little one at home prevented me from being able to join for the whole conference, but I was happy to be able to come for the first two days.
Stochastic Networks is an applied probability conference that is the type of event that doesn’t happen often enough in computer science. Basically, it consists of 20-25 invited hour-long talks over a week. The talks are mostly senior folks with a few junior folks thrown in, and are of an extremely high quality. And, if you do the math, that makes an average of 4-5 talks per day, which means that the days leave a lot of time for conversation and interaction. Because of the quality of the speakers, there are still lots of folks that attend even if they aren’t presenting (which makes for somewhere around a 100+ person audience, I’d guess), so it becomes a very productive event, both in terms of working with current collaborators and in terms of starting up new projects.