Interview: Jessen Page

You are a model of predictability. You come to your office every day of the week at 8 am sharp, never one minute late. You take no breaks until noon, when you instantly disappear from your building. At 2 pm you rematerialize in your office, where you work until 6 pm. You take weekends off, and perhaps some other holidays. While in the office, you sit perfectly still and have your computer switched on. The heat generated from your body and your computer are flat constants, and the only difference between you and a radiator is the odor that slowly builds up in the office while you are there. This is your life, day after day, kWh after kWh, pol after pol (the unit of air pollution).

Hardly flattering, but this is the assumption most building simulation software packages make about you. Your presence, your activities in your home or your office contribute to the heat load and affect the air quality in the building, so no serious simulation software could afford to ignore your presence. Building simulationists therefore represent you as the dummy described above.

Anyone alive would find it hard to recognize themselves in this computer model, and that’s where Jessen Page steps in. A PhD candidate at the Swiss Federal Institute of Technology, Jessen develops more accurate mathematical models of our behaviour in buildings that will one day replace deterministic ones.

Jessen was hired by the Solar Energy and Building Physics Laboratory (LESO-PB) in 2002, the same year he graduated from the University of Fribourg, Switzerland. Although his graduate work was in theoretical physics, he wanted to work on problems of sustainable development, and on solar energy—his lifelong interest since childhood—in particular. The LESO-PB was at that time involved in the SUNtool project, a new software package that would simulate the energy and materials flows of whole urban neighbourhoods.

The SUNtool developers did not want to use deterministic or profile-based behavioural models, and asked LESO-PB to develop behavioural models that would reproduce the most important characteristics with respect to the occupant’s impact on the building. Jessen’s doctoral thesis is about the use of so-called stochastic behavioural models, i.e. models whose state at time t is randomly determined.

Jessen’s work will introduce more realism in building simulation programs and help them make better predictions of urban energy demands and flows of materials. Surprisingly, Jessen says that the impetus behind his work came not from practitioners or architects but more from academics.

I am therefore particularly pleased to be the first to announce on the Web that Jessen Page has succesfully defended his PhD thesis last August in front of a private jury, and will give his public defense shortly.

Running Apache Felix on the UNC90 platform

We have made Apache Felix run successfully on the UNC90 embedded platform and here I’d like to share our experience.

Our UNC90 runs on an ARM9 chip with 16 Mb flash and 32 Mb RAM. It runs the uClinux operating system. The flash is divided in four partitions according to the linux/drivers/mtd/maps/modarm9.c file in uClinux’s source distribution:

/dev/mtdblock/1: 256 kB for the U-Boot loader
/dev/mtdblock/2: 2.75 MB for the uClinux kernel
/dev/mtdblock/3: ~3 MB for the root partition
/dev/mtdblock/4: ~6.4 MB for user applications, mounted on /mnt

We have chosen the Mika Java Virtual Machine, made by /k/ Embedded Java Solutions. We install it under /usr/bin and /usr/lib respectively, and its total footprint is about 1.67 MB. It claims to be compatible with at least Java 1.3, but already includes many features from Java 1.4.

We have installed Felix on the user applications partition under /mnt/felix. The framework is then started by a script similar to this:

  mika \
      -Dfelix.config.properties=file:felix.config.properties \
      -Djava.protocol.handler.pkgs=com.acunia.wonka.net \
      -jar bin/felix.jar

We had to slightly modify the default configuration file. We force the framework to export system packages as if we were running Java 1.4:

org.osgi.framework.system.packages=org.osgi.framework; version=1.3.0, \
 org.osgi.service.packageadmin; version=1.2.0, \
 org.osgi.service.startlevel; version=1.0.0, \
 org.osgi.service.url; version=1.0.0, \
 ${jre-1.4}
# ${jre-${java.specification.version}}

The -Djava.protocol.handler.pkgs=com.acunia.wonka.net option is necessary if you want to do anything URL-related. See here for a full discussion. Basically, we must specify the name of a package containing protocol handlers, which defaults to sun.net.www.protocol. But with Mika this must be set to com.acunia.wonka.net.

We have found this setup to be more than satisfactory in terms of stability, performance and memory usage. We have uncovered several bugs in Mika’s class library, but the folks at /k/ have always patched them in a timely manner.

I’d be happy to answer any further questions you may have about running Felix on the UNC90 platform.