Fairhaven, The River

Jet Engine Washing

United and Southwest recently started using Pratt and Whitney's EcoPower system for washing jet engines.  Ecowash was first operational at Schipol (Amsterdam) about a year ago.  Since it works on any kind of jet engine (not just P&W) and does save about 1% on fuel burn, I expect that within a year everyone will be using it.  The system removes dirt and grime inside the engine, and improved engine operation is about 1%.

Previous systems involved either highly toxic chemicals or had substantial waste disposal problems.  JFK and a few other airports had banned the approaches involving toxic chemicals.  This system used just water jets, and has an internal wash recycling so that final waste disposal does not involve the general airport wastewater.  The waste still needs disposal processing, but it's now just because of the engine grime itself, not solvents or detergents.

RNP (Airline Energy Efficiency)

Southwest Airlines announced their plans for using RNP to improve efficiency (this presentation has nice graphical illustrations) a while ago.  They just announced their vendor selection.  Southwest is not the first to use RNP.  Alaska Airlines has been using it very effectively in Alaska for several years.  The primary motivation there was dealing with the mountains and bad weather.  The reduction in flight cancellations and flight diversions justified the high capital investment.  RNP has also been prototyped in the US by Delta and in Australia to improve flight operations at congested airports (while also reducing fuel use).

The big deal with Southwest is that this will be system wide for them, with every airplane upgraded to RNP navigational equipment and every airport that they use having RNP approaches designed.  This is a big dollar investment.  The FAA portion of the investment in approach designs and ATC procedural changes is not called out.  Much of this is being designed by Southwest's vendor so that it is ready now for the Southwest routes and aircraft, instead of waiting for the FAA funding schedule.  The FAA needs to review, approve, and integrate the procedural changes.  Southwest is spending $175 million over six years to do this and upgrade their avionics, and expects to get a return of about $25 million/yr in fuel use savings.  They will also get a non-dollar savings from reducing flight times by 1-2 minutes per flight, and from using continual glide descents.  The FAA expects to reduce load on ATC and increase airport capacity slightly, based on preliminary experience with RNP.

Delta, American, and other airlines have been rolling out RNP support within the US and internationally to deal with difficult airports, where congestion or terrain give a special advantage to RNP.  Southwest is the first to announce that it will be system wide.

Lovins

Last month John Robb mentioned that he doesn't think that Lovins macro case works. I'm not sure what he means by the macro case. My evaluation of Lovins continues to be:

• Lovins, like anyone who sells to politicians, presents too binary a view. By this I mean that he sells his ideas as if they were the silver bullet that will solve all problems. Politicians and the naive public always look for a simple answer, and there is always some fraudulent advocate that will promise a simple answer. So Lovins sells a simple partially fraudulent answer. The short summary of Lovins is "reducing energy intensity is the solution". I can agree that reducing energy intensity as a key component of the solution, worthy of 80-90% of the investment resources.
• Specific proposals for reducing energy intensity are much less reliable. The savings from more efficient lighting was a clear winner. Some of his automotive ideas look very questionable.

I also note the McKinsey report that claimed that the US could hit the IPCC goals for carbon reduction merely by implementing energy intensity reduction technologies that are known, and that have a positive ROI on the investment. In effect, hitting the carbon goals would be "free". This does match many of my experiences with manufacturing and other investments. But the report gave no backup data that could be checked. It did not give methodology that could be checked. So after a while I gave up looking and won't even link to it. Claims like that need backup data and methodology that can be checked independently.

But the anecdotes continue to flow. The most recent that I saw was in Aviation Week (hiding behind a paywall). An Irish aviation manufacturing site found that they could get a 60+% reduction in carbon footprint with easy changes. No major investments were needed. They did not quote an exact ROI, but indicated that the investments had a very rapid payback.

The constant flow of simple improvements with ROIs in the range 25-50% continues, but they are all anecdotal and lack proper statistics on how widespread they really are. So while they are consistent with Lovins claims and the McKinsey claims, they do not provide enough information to assess how much their aggregate improvement will be. That is part of my problem with what Lovins claims.

From a decision making perspective this does not matter much. Actual available investment money, available construction resources, and allowable downtime are all limited. There is some evidence that all of the available resources can be put towards investments with good ROIs. These ROIs are based on process improvements and energy use reductions. Regardless of the percentage it makes sense to allocate the investments to those projects first. Some money does need to go into research. But there is no good case for most of the trendy fads like grid solar or grid/hybrid cars unless all of the excellent ROI projects are already funded. It makes more sense to invest in projects that maximize the energy use reduction per dollar spent.

So at this kind of macro level I agree with Lovins on the prioritization of energy intensity reduction, although I have not seen data to confirm the anecdotal belief that it will be sufficient.

WS-splat

We had to take a sad step today.  We enabled the use of hash codes and hash code checking on transactions that are sent using WS-*.  It seems that the implementations remain too unstable and do not reliably handle large data transfer.  It's just bugs, but we shouldn't be seeing bugs at this stage.

Kitchen energy consumption data

Now that my power meter is in the kitchen, I'll be accumulating measurements for various devices.  The latest list is:

• Bread Maker - 0.32 KWh per loaf (1.5 - 2.0 lb loaf, no special settings)
• Slow Cooker - 1.25 KWh per meal (this will vary between 1.0 and 2.0 depending on hours cooking)
• Quinoa in Rice Cooker - 0.25 KWh for 3 cups cooked.  (I'm assuming more food will consume more power, but I rarely make more than 4 cups at any one time.)

I can only measure things that use standard outlets, so the stove and oven remain a mystery.  These other smaller appliances seem to be fairly efficient.  I've seen very little information on the web or manufacturers sites about actual consumption in use.

Energy Consumption of Bread Makers

I got to wondering about the energy consumption of bread makers while thinking through some of the likely ramifications for rising food prices, etc.  There is already a trend back toward more home grown foods and saving money from make it yourself.  Making bread is a clear candidate for a major revival, since the resulting bread is usually superior to store bought bread.  (I will note that some of the local bakeries make superior bread, but it is much more expensive than the home made.)  It was a dreary cold rainy day, so I dusted off the bread maker, plugged it into my recording power meter, and made a loaf.

A 2 pound loaf bread machine consumes about 1/3 of a kwh making a loaf of bread.  So, it's less than 10 cents/loaf.  I'm not sure how flour prices and the like will shift, but I think most people will be finding it less expensive to make their own bread than buy it in a store.  I doubt that the cost savings will ever recover the cost of a bread making machine, but it does taste better.

One reason DICOM succeeded

DICOM is now a highly successful standard, and I occasionally think about why this is.  I was first involved in 1991, and have been involved on and off ever since.  It is different from most standards in that participants tend to be highly pragmatic, and willing to compromise for the sake of making things work.  I think that this is part of why it has succeeded.

One reason for this pragmatism is the original forcing function for DICOM.  In the late 1980's and early 1990's hospitals were "owned" by the MR vendor.  Each vendor had its own proprietary networking system for imaging systems.   The MR system was the really big ticket purchase for a hospital.  So the effect was that a hospital with a GE MR system would have GE for all the rest.  A Siemens MR owner would have Siemens for all the rest.  And this was a tremendous problem for the hospitals.  They wanted to be able to buy from a variety of vendors without suffering from network problems.

They laid down a nuclear threat.  They threatened to disqualify any product that did not interoperate with imaging equipment from other vendors.  The threat was to officially label that product as not suitable for medical use.  The NEMA standard that preceded DICOM had failed to be widely accepted (for a variety of good reasons) but there was a lot learned from attempts to use it.  It was clear that a standard was needed in order to accomplish interoperability.

But this is different from most standards processes.  The goal was not creation of a standard.  We were going to be put out of business if our products did not interoperate.  The standard was merely a step on the road toward that goal.  Most of us involved with creating the standard were engineering managers or product managers.  We would be failures if all we did was write a standard.  Success required product integration and successful interoperation with products from other vendors.   The standards consultants, standards experts, and the like were not welcome unless they contributed toward our success.

This did establish a tradition of pragmatism.  Making the system work was far more important than following any particular theory or standards practice.  Academic and theoretical purity was of value only to the extent that it helped ensure that things worked when we were done.  The "fad du jure" (e.g., SOA) was unwelcome.  We had products with long lifespans, strict regulatory requirements, and tight pricing pressures.   Technology fads had no influence on medical buyers.  They were influenced by medical fads.  So, as engineering and product managers who needed to sell products we stomped out the technology fads, unless they could show pragmatic value as enhancing our chances of success.

This is very different from many SDOs.   In many SDOs the development team reaches their goal with the successful balloting of the standard.  That is the target.  That is what they get paid for.  We knew that we were not done until we had a cost effective implementation of the standard, working in our product, selling to our customers, and acceptably interoperating with the other machines on the customers network.  Having this different goal and different staffing made a difference in our practices, attitudes, and traditions.

This is one reason that DICOM succeeded.

Plastic bags

Locally there are a variety of responses to the problem of plastic shopping bags.  One store offers a weekly drawing of $25 to those who bring their own bags.  Another has recycling bins.  Some reuse boxes from shipping instead of bags. Others ignore the issue.  I've seen the community practice in Belgium of bringing empty bags to the store and putting them in a large bin for re-use.  Ireland has a tax on bags.  Great Britain was debating a tax, but the supporting arguments have hit a pothole.

It turns out that the old Greenpeace arguments that have been copied for years were lies.  This could end the proposed tax.  The press is beginning to at least report environmentalist fraud when someone else does the work of exposing it.  It does say something that this error went unreported for so many years.  The press does do fact checking of claims by some politicians and companies.  They really should check the claims of anyone who alleges scientific support.  Too many of those claims are simply false if you check the original science.

There are cultural variations at work in the different approaches taken to reducing bag use.  There are good arguments for reducing use to lower costs, lower trash volumes, etc.  There never was a need to tell those lies.  But political activists have trouble arguing for a change lacks a strong emotional hook.  Paper shopping bags and plastic are both unnecessary expenses.  They are unnecessary trash.  Saving money and reducing trash lacks the emotional hook of millions of dying animals, but it has the advantage of truth.  The problem becomes one of the best cultural way to implement a sensible reduction approach.

Thoughts on standards preparation

I've started considering the use of "git" for the development of standards.  The fit with standards development is good. 

During standards development we have multiple groups are working on supplements and a base standard.  We presently use supplements and CPs as a high level visible organizing principle. These correspond to different bug fix and feature add paths in a config management system (CMS). There are multiple distributed development groups, each needing their own head.  These occasionally interact by spawning changes to another branch.

This is very similar to the environment inside the Linux Kernel and X window system.  Both of those are very large projects that have autonomous development teams and individuals working to generate a single common release.  There are a variety of internal projects that have low interactions with others (e.g., device drivers, 3D rendering, etc.)  These do find and spawn fixes to other projects.  They do have to maintain long-duration multi-release projects while sustaining regular small feature releases and bug fixes.  The end result has to support multiple releases, back ports to earlier releases, and reversions.

So the problem space is very similar.

The core differences between standards development and software development (and these matter a lot to the people involved) are:

• The underlying file formats used by SDOs are hostile to external change management.  Software developers use computer languages that are regular text files.  The languages are designed to maximize change locality.  It is natural to change one line in the language and have only one line of text change in the file body.  SDOs use Word and other formats that are generally hostile to this concept.  They are usually opaque binary blobs.
• The tools used to develop these files are hostile to external change management.  There is no tooling integration with CVS, or any of the commonly available CMS tools.

This is one reason that Wiki's are exploding in popularity for documents.  Although they are a pitiful CMS, they are a tool that does generate a text form underlying object.  They remain mostly hostile to external change management.  For example, the mediawiki tool that is behind Wikipedia, IHE wiki, and many others, does not support easy export and import of the underlying text files.  For example, the inability to use wget (or any similar tool) to export or capture contents is a bug that was recognized and listed several years ago.  It remains on the not planned (much less scheduled) for a fix or feature add.  The developers acknowledge that they are hostile to external CMS and do not view this as an important problem.

Consider the possibilities opened by the slow moving efforts to move DICOM into an XML format.  The actual format selected is DocBook, so the DICOM in XML should really be renamed DICOM in DocBook.  DocBook is very friendly to external CMS and also friendly to export into multiple forms (PDF, DOC, HTML, SGML, Wiki).  Unfortunately, DocBook lacks usable GUI writing tools.

The lack of usable GUI writing tools has been a profound barrier to the acceptance of DocBook.  The writers will not use it.  Only the occasional odd-ball writer will tolerate DocBook.

Green Walls

I've been tracking green roofs for a while and bringing them up as part of the town planning process when it seemed appropriate.  These green walls are an interesting variation.  Some of them seem to be really interesting works of art.
Others are fairly functional forms, with examples from Japan and from New York.  (I have no idea how long those newspaper links will survive.)

Whether these make good economic sense as well is unclear, but they might be a cost competitive alternative to the ordinary wall.