Tech­no­logy always advances, and in most areas the rate of change is also increas­ing all the time. But there are some areas where tech­no­lo­gical changes either hap­pen only slowly, or even go into reverse. Not some­thing we’re used to in com­puter sci­ence, but it’s a fea­ture of sensor net­work pro­gram­ming: what are the chal­lenges that tech­no­logy won’t solve for us?

Moore’s law has been a defin­ing fea­ture of com­puters for the past dec­ades. By and large com­put­ing power has doubled every 18 months at con­stant price; altern­at­ively, the cost of a unit of com­put­ing power has halved in the same period. The effects of this on user exper­i­ence have been plain to see.

Within com­puter sci­ence, Moore’s law has had an effect on research dir­ec­tions too. In start­ing on a PhD a stu­dent can work on a prob­lem that’d at the edge of the per­form­ance envel­ope of whatever class of machine she is tar­get­ing — cell­phone, laptop, desktop or server — secure in the know­ledge that, but the time she’s com­ing to an end, the power avail­able to that machine class will have quad­rupled. This doesn’t open-up every prob­lem, of course — a four-times speed-up on an NP-hard search prob­lem might still leave it largely intract­able — but in fields such as mid­dle­ware, soft­ware tools, lan­guage design and the like, it’s enough to over­come many issues.

It’s there­fore some­thing of a shock to come to sensor net­works and sim­ilar sys­tems, because I sus­pect these sys­tems aren’t sub­ject to Moore’s law in the usual way.

In some ways, the situ­ation on such small sys­tems is actu­ally bet­ter than in desktops and enter­prise com­put­ing. At the higher end, we’re already hit­ting at least the sus­pi­cion that the per­form­ance increases in indi­vidual cores will soon start to flat­ten out. Mul­ticore pro­cessors allow us to keep increas­ing per­form­ance, but at the cost of vastly com­plic­at­ing the sorts of pro­gram­ming needed in order to keep all those cores occu­pied. Sensor motes are still single-core and typ­ic­ally aren’t using state-of-the-art pro­cesses at that, so there’s still plenty of room for manœuvre.

But it’s easy to for­get that while the cash cost of a unit of pro­cessing power has decreased, the power cost of that unit hasn’t decreased by nearly as much (and may actu­ally have increased). Those twice-as-powerful chips eight­een months on typ­ic­ally burn sig­ni­fic­antly more power than their pre­de­cessors. You only have to look at the size of heat­sinks on chips to real­ise that there’s a lot of heat being dissipated.

So for a sensor net­work, which is using a bat­tery or scav­en­ging for power,  increas­ing the pro­cessor power will almost cer­tainly decrease life­time, and that’s not a trade-off design­ers will accept. Bat­tery, scav­en­ging and renew­able power sources like solar cells aren’t sub­ject to Moore’s law: their growth curves are those of phys­ics and tra­di­tional engin­eer­ing, not those of IT sys­tems. Ten years ago my cell­phone went for three days without a charge; my new HTC Hero lasts no more than two days, even if I turn off the data ser­vices and wifi. The extra com­pute cost has a severe power cost.

In many sensor applic­a­tions, the trade-off will actu­ally be in reverse. Given the choice, a designer might opt for two older, less cap­able but less power-hungry pro­cessors over one more power­ful but more hungry. Two motes can provide more cov­er­age, or more robust­ness, or both.

But this exposes a real pro­gram­ming chal­lenge, since it implies that we’re going to have to get used to build­ing mod­ern, open, adapt­ive soft­ware on machines whose cap­ab­il­it­ies are sim­ilar to those of a mid-1980’s vin­tage home com­puter — and which might in fact even decrease over time, since the driv­ing forces are push­ing for cov­er­age, life­time and redund­ant rep­lic­a­tion. The per­form­ance of a net­work in aggreg­ate might still increase, of course, but that still means that we have to extract extra per­form­ance from co-ordinating dis­trib­uted pro­cessors rather than from improv­ing indi­vidual nodes. The his­tory of dis­trib­uted par­al­lel pro­cessing should warn us not to be san­guine about that prospect.

Actu­ally, though, the chal­lenge will do us good. Mod­ern machines encour­age sloppy over-engineering and over-generalisation — build­ing frame­works for situ­ations that we anti­cip­ate but which might never occur. Tar­get­ing small machines will change this, and instead encour­age us to build soft­ware that’s fit for imme­di­ate pur­pose, and that’s build to be evolved and exten­ded over time along­side chan­ging require­ments and con­straints. This build­ing evol­u­tion into the core of the sys­tem will make for bet­ter engin­eer­ing in the long run.