Month: July 2009

7 numbers why building automation can save the world

Automating buildings costs money. Lots, lots of money. The return on investment (ROI) is usually very low, and it takes a long, long time (on the order of 5 to 10 years) for such an investment to pay for itself.

To make matters worse, people who rent the home or apartment they live in have little incentive to make it energy-efficient. They have no guarantee they will still live in the same place 10 years in the future. And landlords? Why would they invest? Energy costs are always born by the tenants, so they too have little incentive.

If financial considerations won’t motivate people to invest in smarter buildings, here I propose another incentive. Building automation, if implemented globally, is one of the most cost-effective strategies for keeping the atmospheric CO2 concentration at safe levels until 2050.

I reviewed Thomas L. Friedman‘s Hot, Flat and Crowded in an earlier post. In that book, Mr Friedman refers to a paper published by Pacala and Socolow in Science in August 2004.

I’ve traced that paper. You can find it here: Stabilization Wedges: Solving the Climate Problem for the Next 50 Years with Current Technologies. Even if you don’t read the full paper, please do read the first couple of pages. The authors do a fantastic job at summarizing our current situation with respect with CO2 emissions and where we are headed if we do not act now. The abstract speaks for itself:

Humanity already possesses the fundamental scientific, technical, and industrial know-how to solve the carbon and climate problem for the next half-century. A portfolio of technologies now exists to meet the world’s energy needs over the next 50 years and limit atmospheric CO2 to a trajectory that avoids a doubling of the preindustrial concentration. Every element in this portfolio has passed beyond the laboratory bench and demonstration project; many are already implemented somewhere at full industrial scale. Although no element is a credible candidate for doing the entire job (or even half the job) by itself, the portfolio as a whole is large enough that not every element has to be used.

Let me summarize the key figures, and please commit them to memory:

280 ppm CO2 atmospheric concentration

For the most part of human history, the CO2 concentration in the atmosphere remained relatively stable at 280 ppm (parts per million). The industrial revolution coincided with the start of a clear increase in CO2 concentration.

375 ppm CO2 atmospheric concentration

The CO2 concentration at the time of the article (2004). But remember that CO2 concentration has always increased since careful measurements started in the late fifities:

CO2 atmospheric concentration for the past 50 years
CO2 atmospheric concentration measured on Mauna Loa (Hawaii) for the past 50 years, adapted from my thesis.

500 ppm CO2 atmospheric concentration

Even allowing for (healthy) skepticism, most scientists believe that mankind must at all costs prevent the CO2 levels from reaching double the preindustrial concentration, or about 560 ppm. To err on the side of caution, we as a species should pledge never to let CO2 level cross the 500 ppm limit.

7 billion tons of CO2 per year

When Pacala and Socolow wrote the article, mankind was dumping in the atmosphere the equivalent of 7 billion tons of CO2 per year (7 GtC/year). That’s enough CO2 to fill 1 billion hot-air balloons each year. It is also the upper limit of allowed global emissions if we are to stabilize CO2 atmospheric concentrations at their current levels for the next 50 years.

14 billion tons of CO2 per year

If we fail to act now, by 2054 we will be pumping out 14 billion tons of CO2 per year in the atmosphere, according to the so-called Business As Usual (BAU) scenarios. Such an emission rate will almost certainly result in a CO2 concentration of more than 500 ppm, i.e. beyond the safe upper limit. The consequences on global warming can only be disastrous.

Average global temperatures for the last 150 years
Average global temperatures for the last 150 years, adapted from my thesis.

50 years

Stabilizing CO2 emissions is only the first half of the battle. Our goal is to stabilize them at their current levels for the next 50 years, but after that we must devise solutions to reduce them.

7 wedges

The paper proposed 15 potential solutions (or “wedges”) for stabilizing our CO2 emissions. Each one of these is technologically feasible and has been commercially demonstrated. Any of them will prevent the increase in CO2 emissions by 1 GtC/year by 2054. Thus, to keep our CO2 emissions to current levels by 2054, we must implement at least 7 of these 15 strategies on a global scale.

Wedge 3

The third wedge proposed by the authors appears to me as the easiest to implement:

Cut carbon emissions by one-fourth in buildings and appliances projected for 2054.

Yes, that’s right. If we or our children are to make it safely through the second half of this century, we must implement at least 7 of 15 strategies, one of which is the reduction in carbon emissions by 25% in buildings and appliances.

And how, you may ask, can we achieve this? Well, there are really only two solutions. We may switch to more carbon-neutral energy sources, or we may reduce our energy demand. As I’ve argued in a previous post, we should prefer the latter option for the following reasons:

  • Our fundamental problem is our dependency on cheap sources of energy. Carbon-neutral energy sources, although much cheaper than only ten years ago, are still far from competitive.
  • We have enjoyed cheap sources of energy for so long that we have never had to consider the need to reduce our demand. In other words, we are addicted to energy, not oil.
    5 hours energy
    Credits: RogeSun Media
  • It is much, much more cost-effective to reduce the energy demand of buildings and appliances, particularly through better home and building automation, than attempting to replace our current sources of energy with carbon-neutral ones.

Conclusion: an elevator pitch for building automation

We currently emit 7 GtC/year in the atmosphere. If we fail to act now, we will be emitting 14 GtC/year in 2054 and the CO2 concentration will be more than twice its preindustrial level. Building automation, if implemented on a global scale, can make buildings at least 25% more energy effective, which will prevent the emission of 1 GtC/year by 2054, out of 7 GtC/year required to keep at current levels. It is arguably the most cost-effective strategy for mitigating climate change.

Posted on by David Lindelöf

Enjoying a NO energy home

There’s a nice little article about green energy homes over at Greenprofs.com. The author makes a nice point that home owners have many options when it comes to choosing carbon-neutral energy sources: he mentions solar, wind and even hydroelectric power. I cannot help but submit, respectfully, that this article completely misses the point.

There are, conventionally, five different sources of energy, four of which are carbon-neutral and only three of which can be said to be completely renewable:

But, as Thomas L. Friedman mentioned in his excellent Hot, Flat and Crowded (see my review here), there is a sixth energy source: the energy that we do not use.

And the key challenge we face as a race for the next century or so is to shift our energy consumption patterns more and more towards that sixth source, instead of trying to draw more and more energy from the four carbon-neutral ones.

We have the technology and we have the means, particularly when it comes to the energy needs of homes and buildings; it is only a question of bringing those possibilities to the global awareness, instead of letting people believe they will eventually be able to simple replace all coal-powered plants with wind mills.

Posted on by David Lindelöf

5 Java logging frameworks for building automation software

Back in 2005, when I was writing Java software for an embedded home automation controller, we ran into a little unforeseen problem. The embedded virtual machine we were using implemented only the Java 1.3 API, and so did not offer any logging facilities (which only Java 1.4 started having).

We ended up using the logging implementation from the GNU Classpath project, but choosing a good logging framework in future projects will make a crucial difference for embedded applications that will run for months, if not years, unattended.

Here I recap the most popular Java logging frameworks of the day, and their relevance to the field of building automation.

Java Logging API
The default logging framework, a default implementation of which comes with the JRE. Expect this to be available on any platform that implements at least Java 1.4. A good, default choice for many applications, but very limited in its functionalities. Probably the best choice when memory and/or disk space is a critical issue.
Log4j
Arguably the most popular logging framework for Java, with equivalent implementations for many other languages. Extremely flexible and easy to configure. If your application runs on a “real” machine then you would be wise to choose this framework, or the more recent Logback (see below). If you run on an embedded platform, the choice will be more difficult and require careful thought. You can also use Chainsaw, a graphical tool for parsing Log4j logfiles if they are formatted in XML, which should probably never be done on an embedded system. The development of Log4j seems, however, to be stuck on version 1.2.
Logback
Intended as the successor of Log4j, and written by the same author. I don’t have much experience with it but it’s probably a smart move to get to know it.
Jakarta Commons Logging
Not a logging framework per se, but a logging framework wrapper. Certain kinds of applications, such as libraries, should avoid any tight coupling with any particular logging framework and instead use a framework wrapper such as JCL. There will, however, be a (small) memory penalty, which should be evaluated if the application runs on an embedded platform.
SLF4J
The author of Logback and Log4j wrote also the Simple Logging Facade for Java, another logging framework wrapper that solves several issues and problems with JCL. I cannot see how a building automation application could be concerned with these kinds of classloading problems, but I like the idea of statically binding the wrapper with the logging framework, something which JCL did not do. Also, it sort of lazily evaluates the log strings, so you avoid the little performance hit when debugging is turned off (an important factor for embedded systems). You should probably prefer this wrapper over JCL, especially if Logback takes off and eventually replaces Log4j.
Posted on by David Lindelöf

When I hear the word “Entity” I reach for my thesaurus

According to Eric Evans, the author of Domain-Driven Design:
Tackling Complexity in the Heart of Software, one of your first goals as domain analyst is to define what he calls an Ubiquitous Language, i.e., a common vocabulary that your technical team and your business sponsor will agree on, and will use to communicate. Having such a common vocabulary will prevent misunderstandings and will probably help you name things in your program, such as class and method names.

But what do you do when the business people seem unsure themselves of how to define certain concepts in their own domain? How do you even detect such situations?

I’ve found that certain words, when they begin to show up too often in conversations between the technical team and the business people, are good indicators that something needs to be clarified. Words such as object, element, perform, or do. But one word in particular seems to be particularly difficult to clarify once it has become accepted by business people: entity.

I was working on a business application that involved, well, entities that sold widgets in the world on behalf of a certain company. I asked the business people to help me understand what an entity was, or what exactly their responsibilities were.

So is, for instance, an entity associated with a country? Well no, because entity 33 is responsible for more than one country. Ok, so is an entity responsible for a geographic zone, including one or more countries? Well no, because see here, entity 12 handles all the sales in country Foo but only B2B sales in country Bar. The best definition they seemed to be able to come up with was that an entity was something that sold widgets to some people. Not exactly helpful.

Then I asked them a simple question. “Could you give me a dump from your database of the names of all your entities?” Sure enough, they did. And when I read the list of entities, I saw that they all were names of companies incorporated in their respective countries. “Say”, I asked, “aren’t these, like, subsidiaries?”

Subsidiaries they were indeed. It turned out that the company had segmented the market in each country in B2B and B2C products, and the company’s history explained why a given subsidiary got a given market segment in a given country, even in another country than its own.

This realization led to an immediate simplification of our class diagrams, and a lot of class renaming. But the resulting code is now much, much clearer, something even the business people admit.

It almost always pays off to work on redefining vague or incomplete terms. It will help you as a developer, and it might well help your customer too.

Posted on by David Lindelöf

Book review: “Hot, Flat and Crowded”

I’ve read Thomas Friedman’s “Hot, Flat and Crowded”, and firmly believe this book belongs on the shelf of anyone involved in making buildings more energy-effective.

Mr Friedman’s previous bestseller, “The World is Flat”, discussed the changes to our world that enabled more and more people to participate in a global economy. “Hot, Flat and Crowded” is sort of a sequel to that book, although there is no need to have read it first (I haven’t).

Mr Friedman’s thesis is that as more and more people participate in the global economy (“flat”), the standards of living are increased everywhere and world population grows (“crowded”), while more and more people aspire to a western style of life, with its damning consequences to the environment (“hot”).

According to Mr Friedman, the small habit changes that we are all asked to pick up (changing incadescent lights to more efficient lights, turning off our TVs instead of leaving it on standby, etc), while commendable, are simply insufficient. There is nothing we can do invidually to prevent atmospheric CO2 levels from reaching dangerously high levels in this century. Instead, he proposes a series of measures nations should take, such as imposing carbon taxes, cap-and-trade schemes, and several regulatory laws on energy efficiency for vehicules and buildings. Only such drastic measures, he argues, will make a significant difference.

An entire chapter, in particular, is dedicated to what he calls an “energy internet”, in which he envisions how a network of appliances and utilities could cooperate to dramatically reduce the energy demand for buildings. Buildings, incidentally, represent about 40% of any nation’s energy demand, and have this annoying property of being long lived. Once a building is built, it will consume energy and water for the next 30-40 years, which makes it all the more important to build them right from the beginning.

Contrary to many “green” books, though, Mr Friedman gives more arguments in favour of “going green” than the obvious environmental ones. There are at least two other, less obvious reasons why we should work on reducing our energy demand and developing renewable energy sources:

  • Current demand for oil finances petro-dictatorship all over the world, preventing many countries from achieving freedom and democracy.
  • Many poor countries lack ready access to cheap and clean energy, preventing their further development.

The arguments Mr Friedman develops for these aspects of the problem are worth the price of the book alone, in my opinion. But the real eye-opener is the extensive discussion on the way utilities have traditionally worked and how they should work in the future. He doesn’t say that our homes and buildings should simply become more efficient; he says that by wiring together buildings, appliances and utilities together, we can escape from local optimums in energy efficiency and aim for much more important savings.

And that, of course, is one of the aims of this blog: to bring together information on how to achieve that vision. We definitely have the technology (we have had it for the past 30 years or so), we only need the economic incentives to work on this problem. And Mr Friedman provides several suggestions that governments the world over could and should adopt, suggestions that will, if implemented, leave us no choice but to build the infrastructure he describes.

Posted on by David Lindelöf

Polyphasic sleep

Wikipedia defines polyphasic sleep as the practice of sleeping multiple times in a 24-hour period. Proponents of this practice argue that it results in a much reduced total sleep requirement, sometimes as little as two hours total sleep per day.

This concept immediately caught my interest when I heard about it, as it should interest anyone who feels like they do not get enough sleep. I have a rather long train commute to work (one and a half hour each way), which makes it difficult for me to get what I believe should be my normal sleep hours.

Curious, I’ve decided to give it a tentative try. I cannot yet go the full “Uberman” way, taking 6 x 20 minutes naps in a 24 hours period (and nothing else), but I have been trying to get at least three naps in the day: one during each commute, and one after lunch. Having such long commutes turns out to be kind of a blessing, after all.

After one week practice, I do indeed feel much less tired in the evenings. I’m writing this post at half past ten on a Saturday evening, when I should normally be dead tired. Instead of that I’m wide awake and I think I’ll be writing some C code afterwards.

If you would like more information, here are some links that I have found helpful:

Posted on by David Lindelöf