Recently in embedded systems Category

The idea for the story started back in early 2001 on a bitterly cold January night in Woonsocket, Rhode Island. I'd just flown in from Arizona to spend a week emptying out and closing up the house of my recently deceased father, who'd finally succumbed to cancer at age 87.

When I say it was bitterly cold, I ain't just kiddin'. The high for the day was about zero Fahrenheit, which is cold even for New England in January. For a desert rat living in Arizona, it was unbelievable!

Then, the sun set, and it got colder.

I curled up in a lotus position with the thickest quilt I could find wrapped around me, hoping the furnace would soon drive away the chill that had seeped into the walls during two weeks of the house being empty. Since the house had been empty, there was no TV. I'd been cooped up on an airplane for hours with nothing to do but read, so I was read out. My body was still on Mountain Standard Time, and I'm a night owl, anyway, so sleep was many hours away.

I just sat, and thought.

What I thought was the beginning of this story. It was going to be the adventures of two young people who made a transcontinental journey by motorcycle, visiting all the places I liked to go by motorcycle, doing the things I like to do when touring by motorcycle, and meeting the kinds of people I meet when wandering around by motorcycle.

To make it interesting, I'd have the lady be a newbie biker, who'd never been on a motorcycle tour before. Everything would be new to her, and a surprise.

What would she look like? Well, I like tall redheads who are really, really smart. My mother was tall, had auburn hair, and was one of the smartest people I've ever met. My wife is tall, has red hair, and is no slouch between the ears, either. In fact, I'm a sucker for tall redheads with lots of brains. So, my heroine would be tall, have red hair, and be really, really smart.

Since everything in an exciting fiction story must be bigger than life, she'd have to be extremely tall - like six-foot, three-inches tall - have lots of flaming red hair, and be a genius with a full scholarship in an Ivy League college studying something that gives most people phobias: mathematics.

The guy would be a veteran biker, who knew all the right places to go, and could introduce her to the most interesting people. To be able to match her, he'd have to be really tall - like six-foot, six-inches tall - more athletic, and even smarter.

They'd visit motorcycle races, camp out at biker rallies, spend hours shopping at motorcycle flea markets, and spend evenings getting plastered at biker bars. Being really, really smart would give them the wherewithal to thumb their noses at convention whenever they wanted to. They could get into stuff the rest of us only fantasize about.

It'd be a lot of fun for them, and, maybe, for readers.

In that form, however, it'd be lucky to make fifty pages long. That's a longish short story, not a novel. A novel needs a lot more. It needs character development. It needs suspense. It needs mystery.

It needed a lot of work.

Over the next nine years, the story grew. The young lady got a name, Judith McKenna (nicknamed "Red" for obvious reasons), as well as a troubled past. Her troubles, however, were not her fault, and not the fault of any character flaw. The troubles stemmed from a singular event that made building relationships difficult at best, especially building relationships with guys. That event was the untimely and mysterious disappearance of her father just at the time an adolescent girl needs a father figure most.

So, the father figure would be supplied by the mysterious biker, who takes her on a journey, which is no longer a touristy vacation, but a journey of self-discovery. Who was she, inside? How could she relate to other people? What was she going to do with her life?

One of the ambiguities she'd have to resolve could be a bit of sexual confusion. That could be fun!

The mystery, of course, is what happened to her father. Why'd he leave? Why'd he not come back?

Now, my favorite fiction genres over the past lots-and-lots-of-decades have been mystery and science fiction. And, my favorite stories have always combined both. And, my favorite author has been Rober Heinlein, who generally combined those two genres and used them to weave epic tales that explored basic human values. That's what I'd try to do.

Judith's story had a mystery, and had some serious character-development potential. It also had two young people off on their own, providing plenty of opportunities for fooling around between sheets, which will seriously spice up any story. In fact, giving her a chance to peel back layers to slowly discover who this biker was would add a second mystery, which might be fun to develop as well.

What she would find is a scientific genius who could provide technology that would make solving her other mystery - what happened to her father - possible, where it hadn't been before. He'd have built his own company in very short time, capitalizing on his inventions in aerospace technology. I know about aerospace technology. I can do that.

With all that additional content packed in, the space needed to tell the story expanded tenfold. When I finally sat down to type it out, it took a year instead of the three-to-six months I envisioned. From a simple little story about a motorcycle trip, it grew to an epic adventure.

By the way, it's still growing, with new titles coming soon. My wife says she likes the sequel even better.

I think you'll like it, too.

Many thanks to the loyal readers of this blog, who have put up with a low posting frequency over the past few months. My excuse is that I've been trying to get my next book into production. It's nearly there, so I should be able to provide more frequent posts to this blog.

Readers who enjoy my commentaries on how technological advances affect current events will have a lot to interest them in the book, which should be in bookstores around mid-summer. Entitled Red, it is a novel whose main characters work in a private applied-physics research company. The title comes from the nickname for the central character, Judith McKenna, who is a tall, athletic, young mathematician, who tosses everything away to search for her missing father after the authorities have exhausted all conventional means of finding him. Her faltering quest is saved by Doc, her mentor and sometime lover, who shows her how to organize the scientific and technical resources she didn't even realize were available to solve the mystery.

To reach her goal, she needs to learn techniques of organization, resource allocation, team building, and decision making under uncertain conditions. If you thought such issues were dry and academic, it's because you haven't seen them played out in the emotionally charged, risk-filled environments where real-life technology developers live and work, where millions of dollars, careers, and even lives are often at stake, and any mistake can lead to disaster.

If you think that's hyperbole, take a look at what's happening right now in the Gulf of Mexico.

We're now doing the final polish edit on Red. The schedule calls for that to be done before the end of June, at which time the book will go directly into production.

Most of the work is now in the hands of others, so I will have more time to devote to looking at how technology interacts with society, which is the focus of this blog. I plan to start by sorting through the issues surrounding the Gulf oil disaster. What actually happened? Who should really be pointing fingers at whom? Are the actions contemplated by the Obama Administration likely to help the situation, or make it worse?

Hopefully, I can help make sense of it all.

I've had occasion to write articles about factory automation several times, and one question that often comes up is: "Why automate a manual process?" In the short run, automation is expensive. It's a lot cheaper to keep running the same old manual system (especially if it's working well) than to take on the capital expense of replacing it with automation.

Any automated system replacing a manual one will be, by definition, novel. There is large technical risk in any novel system. Experienced engineers know that nobody is smart enough get it right the first time (at least not with any consistency). There are always things you don't know, forgot, or did just a little bit wrong - not to mention the dreaded unintended consequences that plague any complex system.

These days, it's possible to automate virtually any task. The challenge in the industrial engineering field is to interlink islands of automation into what my friends at Siemens like to call "Totally Integrated Automation" (TIA).

There are, however, still a few tasks that are manual in nature. Folding them in under the TIA umbrella, whether using technology from Siemens or another factory automation equipment vendor, as manual systems is problematic. There is a tendency to automate any task as a knee-jerk reaction to manualism.

That can be a mistake. Not everything should be automated, even in a TIA environment. Some things people are better at doing than machines. There aren't many, and the number grows fewer as automated systems become ever more capable. But, they are still there, and represent big land mines for system integrators.

The issue will also start to impact consumers in the general public as embedded control systems spread throughout society. In fact, it's already becoming significant in the automotive space, as systems become commercialized to monitor (and correct) driver actions that the computers deem suspect. Poor shifting habits were the first to succumb to the engineers' heavy hands with automatic transmissions. Then, decades later, overbraking by panicked drivers was theoretically eliminated by anti-lock brake systems (ABS). Now, we're poised for a host of computer intrusions into the driving process, from falling asleep at the wheel to clumsy parking techniques.

There are a number of criteria that can be used to decide when to automate a task, but the earliest, and still the most universally applicable, is the Three Ds. The Three Ds hail from the early days of robotics, when doing anything automatically was a major challenge. It's a razor that can be used to divide sharply between what is essentially for humans to do, and what is fair game for automation.

(A razor is a logical device used to guide difficult this versus that decisions. The famous Occam's Razor, which tells you to always favor the simplest hypothesis that explains the facts, is a well known example. Razors should be short, easy to understand and apply, and unambiguous. It also helps if the actually work!)

The Three Ds are "dirty, dull, and dangerous." The razor says that any task that exhibits even one of these characteristics should be considered for automation. If it exhibits any two, its a strong candidate for automation with all deliberate speed. If it exhibits all three, get the humans out of there as fast as their little legs can carry them.

Recently, NASA deployed some robotic sensing devices atop Mt. St. Helens that demonstrate how to apply the Three Ds. The task is to carefully monitor a number of significant variables at hot spots on the volcano.

Dirty does not just mean a tendency to get coated with unspecified unpleasant guck. I once had a summer job cleaning the hard-water scale from the insides of boiler tubes. It came out as nano-scale red powder particles suspended in the air. That was a traditionally dirty job. It was also dirty in a wider Three Ds sense: ambient conditions were such as to physically stress human organisms. Basically, the insides of boilers were uncomfortably hot. Not quite hyperthermia-inducing hot, but hot enough that you didn't want to be in there any longer than you had to be. While being outdoors on the top of a high mountain might seem an ideal environment to a city dweller locked in an office, to those of us who've been left out in the elements long enough to feel the effects of exposure, it qualifies as mildly dirty. Add in noxious vapors and other things that tend to leak out of volcanic hot spots, and it gets dirty, indeed.

Dull really means tedious. Anything repetitive, especially if the situation requires constant attention, is dull. Again, data logging is something that sounds like a walk in the park to those who haven't done it manually. I remember one day as an undergraduate student, when I was studying the stability of an oscillator I'd just finished building. I set the thing up with a frequency counter displaying measurements to six digit accuracy on a nixie-tube display. This was before the days of LED readouts, and long before PC-based data acquisition. Only the last two digits were changing. I sat in a (happily reasonably comfortable) chair writing down the last three digits every 30 seconds for six hours straight. No bathroom breaks. No talking with the guy at the next bench. No reading a book. That taught me the real meaning of dull. The poor robots on Mt. St. Helens are tasked with doing that job 24/7 with the only reprieve coming when the mountain next blows its top and ends their miserable existences.

Dangerous means who or what is undertaking the task is in imminent danger of annihilation, or at least grievous bodily harm. NASA's robots weren't put in nice, safe locations. They were put in places the volcanologists deemed most likely to vaporize catastrophically, taking the robots' spindly little bodies with them.

Folks - and you're going to see a lot of them in the next year or so as the economic recovery seems endlessly "jobless" - who complain that automation is taking away their jobs should heed the Three Ds. The only people that automation (properly done) will put out of work are those who are so stupid they embrace tedium, so expendable they get sent into the lion's maw, or so desperate that they're willing to work under inhuman conditions. The rest of us will make do with the good jobs.

Chevrolet leads off the content at its website for the Volt electric car with a cryptic explanation of the test conditions that allow them to claim 230 mpg fuel economy for an electric car. That's good, because nobody in their right mind would accept such an outlandish figure without at least a stab at knowing the test conditions. It's bad because fuel economy figures for an electric vehicle are meaningless, since an electric vehicle does not run on fuel.

Hybrid automotive propulsion systems run primarily on fuel (gasoline, diesel, liquified natural gas, etc.) with a means of capturing energy generated when the car's propulsion demand is lower than the engine's available output, then delivering it back when propulsion demand is high. That allows the vehicle to have an undersized engine and still deliver bursts of performance equivalent to a car with a much more powerful engine.

As an example of how this works in practice, some Formula One race cars use a similar technology called the kinetic energy recovery system (KERS). While braking for a corner, the KERS system captures some of the energy that would be burned off as heat in the brakes and stores it in a battery. The driver has a push button that pours that energy back through the drive train, delivering some 80 HP in excess of the engine's maximum output.

Two anecdotes are available from this experiment. First, it is said that KERS equipped cars are nearly impossible for non-KERS cars to pass under acceleration. Does that surprise anyone? The second bit of information is that the leader in this year's F1 constructors championship does not use KERS. What that really means, and what the standings will be at the end of the season are valid topics for beer hall debates.

Electric vehicles - the Volt included - are primarily driven by electric motors. From an engineering standpoint, there's a lot to be said for this architecture. It's well understood. It vastly simplifies the mechanical drive train. Leaving out the battery pack, it reduces the powerplant weight by a lot. Consequently, it will likely reduce the energy cost of getting the payload from A to B. It probably will reduce maintenance requirements as well, since the components are few, quite robust, and don't suffer much wear.

I said that the technology is well understood. It is and has been for a very long time. Some of the earliest experiments in automotive technology were electric vehicles. I drove an electric forklift during the 1960s. My grandson has owned and operated a series of electric go karts for most of his life. Electric golf carts dot the fairways of America. Electric vehicle technology has been under development for at least as long as the internal combustion engine. What we know about it is a lot!

The problem, which I sidestepped above, is that battery technology is such that storing the energy needed to get that payload from A to B is enormously bulky and heavy. If A and B are significantly far apart, the size and weight of the battery becomes impractical.

The problem is storing enough energy in electric form to run the thing a reasonable distance. The Volt gets around this problem by installing an auxiliary power unit (APU) to provide power when the driver has been foolish enough to drive past the vehicle's point of no return on battery power, and wants to get back by, say, 3:45 PM for a meeting. The APU kicks in, providing enough juice to get you home.

Altogether, I have no problem with the Volt itself. It looks great - or at least as good as allowed by the inaesthetic drech that passes for automobile styling today. Not having driven one myself, yet, I can't answer for its performance, but electric vehicles generally can be made to go as fast as you want (for a while). From my comments above, you can tell that I like the concept from an engineering standpoint - especially for short trips with long recharge spells in between.

My problem is with the idea of assigning a miles per gallon performance figure. It makes sense for hybrid vehicles because the whole driving experience is energized by fuel from a tank. For an electric vehicle, with the bulk of the energy theoretically supplied by an electric outlet, it is rediculous.

So what if the current test protocol returns a result of 230 mpg? I can double that just by jiggering the test protocol for shorter trips so the horse gets back to the barn for more oats before having to limp the last few furlongs. If the car is good for 40 mi on battery power, I can jack the fuel economy rating to infinity just by allowing test trips of 39.5 mi.

It's just soooo bogus!

Some media analysts have admitted to being confused by the fact that companies engaged in the personal computer business, such as Dell and Microsoft, have recently published less-than-stellar financial results and gloomy guidance for the future, while other companies, such as Intel and Apple, are fairly jumping with glee over future prospects. This seeming paradox evaporates, however, as soon as one realizes that the vast majority of computers aren't PCs, anymore.

I talked about one aspect of this phenomenon in this blog's last entry ("The PC as Dodo"). In today's entry, I'll talk about a second trend: embedded systems technology. I've mentioned embedded systems before in this blog, but today I want to get a little deeper into the guts of the things to show how this trend affects so many technology companies so differently.

Embedded systems, as Figure 1 shows, generally embody a control loop where a microcontroller reads signals from sensors attached to some equipment out in the real world (IRL). Based on those sensor readings, the microcontroller calculates some changes it wants to make IRL to control the equipment. The equipment responds to these changing signals, which changes the sensor readings.

What makes the system a control loop, rather than the proverbial snake swallowing its tail, is the fact that there is a control input, called a set point to which the controller compares the sensor inputs. The controller bases its output signals on how the actual readings from the sensors compare to the set point. In actual fact, there may be several sensors and several set points, and the controller likely will take into account how the sensor inputs are changing with time as well as their instantaneous values. People can select how they want the system to behave by changing the set points.

The classic embedded system that everyone uses as an example is a digital thermostat. This system has one sensor (a temperature sensor sampling the room air), one IRL equipment unit (a heater or air conditioner), and one controller (the digital thermostat). You control the temperature you want to have in the room by changing the temperature set point. Almost any digital thermostat worth its price will also include a time sensor (a clock) that allows you to program different temperature set points depending on the time of day.

What makes this technology important is the fact that embedded systems are now used to control just about every device we have. In the past, I've commented that microcontrollers now run just about every device more complicated than a lead pencil. That may be an exaggeration, but not much of one. To paraphrase the announcer from the old "Chickenman" radio show: "They're everywhere! They're everywhere!"

(If you don't know about Chickenman, you missed one of the great campy entertainment experiences of the mid-1960s. Episodes from the original series and two resurrections are still available for purchase on the Internet.)

The heart of an embedded system is that little microcontroller. Figure 2 shows what's inside a typical microcontroller. It's a monolithic integrated circuit (IC) that has a microprocessor, multiple types of memory, including read-only memory (ROM), random-access memory (RAM) similar to what you see in a PC, along with a programmable read-only memory that holds the software that the microprocessor needs to run, along with several types of input/output circuits to take care of reading sensors, driving actuators, and communicating with the outside world. Many microcontrollers even have microscopic radio sets to communicate wirelessly with other systems.

What sets these things apart is that, unlike the components of a personal computer, all of this circuitry is crammed into one tiny chip. As anyone who's seen a PC with the covers off knows, the PC architecture has its circuitry spread around on a number of ICs. That takes up a lot of space, adds weight, and makes the whole thing bulky. One characteristic that embedded systems, from experimental nanobots to cellphones to television set-top boxes, share is the need to have their controllers as tiny and as light as possible.

Now, the semiconductor companies that make chips for PCs also make chips for embedded systems. The companies that use these chips in their products are more-or-less traditional industrial companies that make dishwashers, microwave ovens, cars, cellphones, etc.

The software these microcontrollers run is not the same as the software PCs run, either. Instead of operating systems like Windows Vista, or Apple Mac OS, they run things like LynxOS, QNX, and VxWorks that most people have never heard of.

In the world of computer technology, embedded systems are where the action is. PCs, for all their historical significance and public share of mind, are a small part of the market with lackluster (at best) growth prospects.

So, companies involved in the embedded system business, such as Intel and Apple, report spectacular profits and predict stellar growth prospects. Companies whose businesses depend on the PC industry complain of shrinking markets and poor future prospects.

I've just spent some time debating with my book publisher at Whitehorse Press about what we should put into a new chapter to be included in the third edition of my book How to Set Up Your Motorcycle Workshop. The reason there's any debate is because we're in the middle of a change in computer architecture that's bigger than the introduction of the PC. (See my July 8 blog entry "Why a Thin Layer of Chrome Will be the New Thick.")

First of all, I need to specify what I mean by "PC." Some folks want to reserve the term for stand-alone desktop machines running a Windows operating system (OS). I, on the other hand, am old school. To me "PC" is just shorthand for "personal computer," and that means a computer made for personal use by, well, a person. It includes all the offerings of such machines from Acer to Zenith . Main PC OSs include Mac OS, certain distributions of Linux, and, of course, the various versions of Windows. It also includes laptops, tablets, etc. that are just modified packages for computers meant to be used in exactly the same way that the desktop systems are used.

Closely allied are workstations, which are intended for use in an intensive work environment. They are generally connected to an enterprise intranet, rather than directly to the Internet. They usually have enhanced processors and memories, and data-storage capabilities. They generally run larger and more involved programs appropriate to meeting enterprise-level needs.

Also similar to PCs are netbooks, which are essentially stripped-down models intended for thin-client applications, such as surfing the net. They have far less memory storage space, and may even lack hard drives. What distinguishes netbooks from what I call PCs is their intended use as thin-client terminals at the expense of making them practically useless for anything else.

Just as PCs' performance is sandwiched between that of workstations and netbooks, their price range is as well. Workstations are generally more expensive (often several times more expensive) than PCs, while netbooks typically cost far less.

In the past, any introduction to computer use would have to start with choosing an operating system. That's no longer the case, however. The choice of operating system has become pretty much moot, as there's application software available for every popular OS to do pretty much anything, and non-PC architectures are becoming increasingly important.

Advanced networking technologies, such as virtualization and cloud computing, are driving this shift by making it possible to serve up most applications, from email to computational fluid dynamics (CFD) as Web applications. With this technology, the user's computer becomes a thin client - little more than a terminal to display the system's user interface. Since Web applications are OS agnostic, choice of OS to run on your personal computing station (PC, netbook, mobile platform, or whatever) is immaterial.

These are not future technologies. As a technology journalist, I get to see these things develop years before mainstream media. I've been watching these technologies - and using them - for about five years. They are quite ready for prime time, and in regular use by mainstream computer users today.

All major ISPs use virtualization and cloud computing technology to run their operations. Most e-commerce sites are built on MySQL databases. This generation of PCs are capable of virtualization using software downloadable from Xen. Every bank website is a thin-client Web app.

Dell's already seeing PC sales crash. Microsoft's scrambling to react. Apple's already made the transition, as have Google and leading chip makers like Intel.

In the end, PCs as such will be squeezed practically out of existence. Very soon PCs will be dinosaurs. Ordinary folks won't have or want to have them. It'll all be netbooks and mobile computing. Even Kindle may be obsolete before it really gets started! It'll just be an application on next years' iPods and Blackberrys.

What will count will be the application you run, and not the OS.

The trend is moving much faster than I thought it would. I figured we'd still have another 2-3 years for it to roll out. Now it looks more like a matter of months.

The PC, as such, is already dead, the general public just doesn't know it, yet. PC sales will not recover significantly from the present slump. "Computer" sales growth has already moved to other platforms, such as products from Apple, RIM, and Palm.

The media is painting it as a wrestling match between giants: Google vs. Microsoft. Operating system king Microsoft recently introduced a new Bing! browser, followed last night by search engine titan Google's announcement that it's working on an operating system for netbooks.

As usual, the mass media have somewhat missed the mark. What's actually happening is the whole landscape of computing is changing, and a race is on to see who's going to plant their flag on the new territory first.

The change in computing is the steady migration of computer technology from a thick client model to a thin client model for most routine computing needs. If you haven't yet heard about this, yet, let me explain:

Thick Clients are powerful stand-alone computers with network access. To do something useful, you download the file you want to do it to from a server; do it; then upload the file to the server again, keeping (or not) a copy of the updated file on your local computer.

Thin Clients are computers with powerful communications and display capabilities, but which are otherwise pretty anemic by conventional computer-performance standards. To do something useful, you visit an extremely powerful server, which is actually a supercomputer based on cloud-computing architecture (see "Computing With Your Head in the Clouds"). This server creates a virtual computer (See "Virtualization flies under the mass-media radar") with enough resources to run an application program (which it preloads onto the virtual computer) to do whatever it is you want to do with the file (which is stored somewhere in the computing cloud). When you're done doing your thing, the server updates the file and dissolves the virtual computer into - nothing.

Thin clients have been around for a long time. The old time-shared computer terminals we used in the 1970s to access minicomputers were very much like today's thin clients, which you know as netbooks.

The term was coined in the early 1990s by Tim Negris, VP of Server Marketing at Oracle Corp. The technology has been growing in popularity and usefulness ever since. Expect in the future (probably less than 5 years) that this style of computing will be almost universal, with everything from mobile devices to home entertainment centers architected as thin clients allowing users to interface over the Internet with service providers, such as banks, online stores, news providers, and entertainment content providers. I'm already writing this blog entry using exactly this technology!

Don't invest in companies that make personal computers.

So, how does the Google vs. Microsoft struggle fit into this landscape? They both see it coming and want to provide you with the means to partake of its bounties. The problem is that they have competition. All the makers of mobile devices, household appliances, TV set-top-boxes, telecommunications suppliers, and virtually anyone who makes anything with even the potential for Internet connectivity sees it coming, too. Especially, all the Internet service providers building all the computer clouds see it coming. Google and Microsoft are really just struggling to avoid being left behind!

Google does have one advantage, at least relative to Microsoft. Google is wisely basing its Chrome OS on Linux, which is the Open Source leader. To develop application software in a Linux-based thin-client environment, a company can hire a few pimply-faced ex-hackers who learned to roll their own Linux distribution before they reached puberty. Software engineers with expertise in the latest of the never-ending stream of Windows versions are harder to come by.

Basically, the days when anybody cares what operating system or browser your Internet-connected device uses are gone. In the thin-client/cloud-computing world of the future, like in the post-Civil-War land of Gone With the Wind, frankly, my dear, nobody is going to give a damn.

Nearly every technophile on Earth has seen Star Wars medical droids subbing for human physicians, surgeons, and other medical professionals. Unlike most technological marvels portrayed by Hollywood as existing sometime in the far future, such robots aren't that far from reality. A case in point is GeckoSystems Intl. Corp.'s CareBot robotic elder-care system, which graduated to nurses' aid status with the addition of a miniaturized, solid state onboard blood pressure and pulse rate monitor.

"We believe that the incorporation of an onboard blood pressure/pulse rate monitoring system for our CareBots will further enhance their cost effective, utilitarian capabilities. Our CareBot's ability to automatically follow and verbally remind a designated care receiver at predetermined dates and times that their blood pressure/pulse rate needs to be checked by this onboard, integrated monitoring system will enable a higher level of safety, security and cost savings for those at home and in nursing homes, assisted care facilities, hospitals, etc.," observed Martin Spencer, President/CEO of GeckoSystems.

The company says CareBot is a multitasking personal robot incorporating advanced, proprietary AI engines. Given the CareBot's network connectivity and Internet accessibility, alerts of vital signs and other various healthcare events outside of normal range can be quickly sent by telephone, instant or text messaging, and/or email.

GeckoSystems uses sensor fusion extensively for actionable situation awareness in their complete multitasking personal robot, the CareBot. Their mobile robot's hardware and software architecture is designed to be expandable and upgradeable such that many years of cost effective usage can be readily achieved.

The primary market for this product is the family for use in eldercare, care for the chronically ill, and childcare. The primary distribution channel for this new home appliance is the thousands of independent personal computer retailers in the U.S.

Spencer suggests thinking of it as a new type of labor saving, time management automatic home appliance. The unit decreases the difficulty and stress for the caregiver who needs to watch over family members most, if not much, of the time day in and day out due to concerns about their well being, safety, and security. Not infrequently, the primary caregiver has a 24 hour, 7 days a week responsibility. There is concern that medication will be missed or the care receiver have an accident requiring immediate assistance. And the care receiver may be very resistant to a "stranger" coming in to her home and "running things" in the care giver's absence.

Spencer points out that the CareBot is a new kind of companion that always stays close to the care receiver, enabling family and friends to care for them from afar. It tells them jokes, retells family anecdotes, reminds them to take medication, reminds them that family is coming over soon (or not at all), recites Bible verses, plays favorite songs and/or other music. It alerts them when unexpected visitors, or intruders are present. It notifies designated caregivers when a potentially harmful event has occurred, such as a fall, fire in the home, or simply been not found by the CareBot for too long. It responds to calls for help and notifies those that the caregiver determined should be immediately notified when any predetermined adverse event occurs.

The family can customize the personality of the CareBot, modulating the voice's cadence to be fast or slow. The intonation can be breathy, or abrupt. The voice's volume can range from very loud to very soft. The response phrases from the CareBot for recognized words and phrases can be colloquial and/or unique to the family's own heritage. The personality can range from brassy to timid depending on how the caregiver, and others appropriate, chooses it to be.

Addition of medical-condition monitoring technology is a landmark for the robotic care system, upgrading its functionality from strictly social interaction as a companion (no mean feat itself!) to managed-care activity that may be beyond the capabilities of an untrained human caregiver.

As with so many terms bandied about in mass media, "Smart Grid" is a cutesy umbrella term that allows politicians, analysts, and newscasters to vaguely refer to a collection of technologies that neither they nor their audiences fully comprehend, with advantages that are easily stated, and of uncertain measurability.

While that sounds pretty negative, let me point out that nothing in the above paragraph says anything against the technologies themselves, or their value, but merely pans vague marketspeak terms in general, and the folks who rely on them for ... anything.

Smart grids are part of a general technology trend toward incorporating embedded microcontrollers and data-communication capabilities into all sorts of previously existing devices. For those unfamiliar with them, a "microcontroller" is an integrated circuit that includes a microprocessor and peripheral circuits that allow the microprocessor to sense conditions and events in the external world (data acquisition) and put out signals to drive actuators in the external world (control).

Perhaps the first "smart" devices were automobile engines, which came under microprocessor control during the late 1970s, long before the term "smart xxx" became current. Such engine control modules (ECMs) sensed such variables as outside air temperature and throttle position, and used that information to control such parameters as fuel/air ratio and spark timing. Later, ECMs gained the ability to communicate with additional embedded microcontrollers managing such functions as anti-lock braking systems (ABS) and alarm systems. Modern automobiles now contain dozens of networked microcontrollers operating nearly all functions.

Today, most significant appliances operate under guidance of microcontrollers. Microwave ovens, dishwashers, clothes dryers, televisions, and home thermostats are familiar examples. The extent to which manufacturing operations rely on "smart" technology is even more profound.

Electricity generation and distribution networks, however, are far behind other industries in incorporating smart technology. That is the impetus behind all of the noise and fury about "Smart Grids" in the media.

To be fair, there are significant barriers to incorporating smart technology into electric-power infrastructure. Most significantly, it is imperative to keep the system operating reliably while applying new technology to it. Second, the cost of upgrading existing equipment that was never intended to be part of a computer-integrated system is, shall we say, large. There are many additional issues to be considered when making the move to smart utility grids.

The motivation to incorporate computer control and networking technology into the electric power system is not just to make it more "modern." The concept avoids Scheiber's Rule (Just because you can doesn't mean you should.) by solving a number of present and future problems arising from electric-utility development trends.

The first issue is the fact that the present distribution grid developed from early systems where a single generating plant distributed power to an isolated netword of loads. That placed the responsibility for maintaining voltage, frequency, and phase of the provided electricity squarely on one generating facility. Such installations are amenable to simple closed-loop control.

Later, but still quite some time ago, outputs from multiple generating plants were combined to supply power to the user network. That created the issue of coordinating the output levels and phases of the sources. At least, the sources on a given network were controlled by a common authority capable of centrally guiding the generators via more complex closed-loop control.

Problems became serious when power-distribution networks were interconnected to allow power sharing between sources operated by separate authorities. This makes simple reactive closed-loop control problematic. When you have multiple agents independently providing control inputs in response to observed conditions, the system becomes chaotic. This is not a slam on the engineers who designed and operated the system. It's a fact of life dictated by mathematics. Voltage variations, unpredictable frequency and phase shifts, and seemingly random catastrophic failures ensue.

Happily, all the folks on the supply side of the system were highly intelligent professionals who realized that the only solution was to co-operate their power-generation controls. We'll call it meta-control, where individual operators don't blindly react to every movement of the controlled system, which is what drives the system into chaotic behavior. Instead, when they observe a departure from nominal status, they first communicate among themselves, and devise a coordinated response that brings the entire system back toward nominal.

You can do that when there are relatively few operators. As the number of operators grows, the time needed to communicate and devise a coordinated strategy becomes longer, while the frequency and severity of divergences become more severe.

In the past, the economics of power-generation have favored large generating stations because they can be made more efficient. Costs for fossil fuels and nuclear power scale more slowly than generating plants' output. Emerging energy sources, such as photoelectric and wind power, have been billed as "free energy sources," although they are nothing of the kind, so power-plant efficiency figures less in the installation decision. Thus, we expect to see many more smaller plants. With more small plants, the number of sources that need to be coordinated will rise dramatically, and system-control cost and difficulty will increase.

The assumption is that increased deployment of smart-grid technology will make it possible to maintain system control in the face of increased chaos. High-speed data sharing is to improve coordination while expanded computer automation improves the speed and quality of meta-control decision making.

According to Wikipedia, support for smart grids became federal policy with passage of the Energy Independence and Security Act of 2007. The law, Title13, set out $100 million per fiscal year in funding for fiscal years 2008-2012, established a matching program for states, utilities and consumers to build smart grid capabilities, and created a Grid Modernization Commission to assess the benefits of demand response, and recommend protocol standards.

The Act directs the National Institute of Standards and Technology (NIST) to coordinate the development of smart grid standards, which the Federal Energy Regulatory Commission (FERC) would then promulgate through official rulemakings. Smart grids received further support with the passage of the American Recovery and Reinvestment Act of 2009, which set aside $11 billion for the creation of a smart grid.

Progress has been swift, as it needs to be. Federal Energy Regulatory Commission (FERC) issued a proposed policy statement and action plan on 19 March 2009 for standards governing the development of a smart grid. However, FERC noted that the electric industry started moving ahead with smart grid technologies prior to these government initiatives. The Commission is proposing to establish some general principles that the smart grid standards should follow.

We have known for some years that the trend was toward more numerous smaller power plants. The handwriting has been on the wall since the introduction of a feed-in tariff (FIT) system in 1978. A feed-in tariff is an incentive structure to encourage the adoption of renewable energy through government legislation. The regional or national electricity utilities are obligated to buy renewable electricity (electricity generated from renewable sources, such as solar photovoltaics, wind power, biomass, hydropower and geothermal power) at above-market rates set by the government. The higher price helps overcome the cost disadvantages of renewable energy sources. The rate may differ among various forms of power generation.

FIT means that any Tom, Dick, and Harriett with access to enough cash can set up a generating station, then sell the power to utilities, which are obliged to buy it. This model works well for facilities, such as hospitals and certain manufacturing operations, that need to maintain back-up power generation plants in the event of power failure. Most of the time these generators stand idle. FIT allows their owners to defray some of their cost by running them during peak periods, when demand may exceed fixed-power plant capacity and electricity costs (and FIT repayments) are largest.

The unintended consequence, of course, was a more chaotic electricity environment. Specifically, since a hallmark of chaotic systems is scale invariance, departures from nominal expanded to higher spectral frequencies with smaller amplitude signals (amplitude varies inversely with frequency. While these departures are smaller, their higher frequency translates into the need for faster response. Utilities began experimenting with smart-grid technology in hope of reigning in chaos over a much larger bandwidth.

ADDITIONAL RESOURCES:

U.S. Department of Energy Smart Grid

IBM Smart Grid

American Superconductor Smart Grid: It's More than you Think

Our friends at virtual infrastructure developer Virtual Instruments, and IT technology research firm Taneja Group plan to host an interactive and educational webinar on April 29 titled "Virtual Infrastructure Optimization: What You Can't See Can Hurt You." This live session will feature Dave Bartoletti and Jeff Byrne, both senior analysts and consultants at the Taneja Group, and Mark Urdahl, CEO of Virtual Instruments.

Our March 18 blog entry "Cisco, HP, and the forgotten factor of virtualization" introduced the concept of software virtualization in the context of data servers. These systems should be on the minds of everyone interested in infrastructure expansion and modification while the U.S. economy shifts from contraction to expansion later in 2009. While most folks who think of "infrastructure" as bridges, highways, and buildings, the real infrastructure of the technology-driven U.S. economy, as well as the economies of the fastest growing nations globally, is information technology (IT).

While brick-and-mortar infrastructure is certainly important, and woefully in need of attention, most of the effect of the Federal government's stimulus efforts will be to boost IT infrastructure. That is, it will drive expansion of public and private sector organizations' abilities to store and communicate mountains of data. We will be modernizing, building, and expanding data servers and the networks that interconnect them.

Virtualization will surely be an important core technology built into most, if not all, of this expanded IT infrastructure. As pointed out in the 3/18 blog entry, virtualization provides critical capabilities to data server operators, whether they are in government, financial, healthcare, or other sectors. Anyone involved in any of these sectors needs to understand what virtualization is, what benefits it provides, and how it provides them.

Attending the 4/29 seminar on optimizing virtualized data servers is a good way to bone up on the critical information everyone involved in activities enabled by data-server technology needs to know. To attend, visit the webinar's free registration website. the webinar will be held live on April 29, 2009 at 8:30 a.m. PT (4:30 p.m. GMT)

According to Virtual Instruments, the webinar will introduce new research on the topic of virtual Infrastructure optimization (VIO) - the market category of solutions designed to significantly improve the performance of virtualized applications and to help optimize the utilization of both storage and server resources. The hosts will highlight how IT managers and administrators can:

* Tackle challenges associated with deploying virtualization for performance sensitive, business-critical applications, including visibility into and managing the internal cloud.

* Proactively avoid over-provisioning and under-provisioning of server and storage assets

* Track system interdependencies to accelerate identification of performance choke points

* Select monitoring and analysis tools with the instrumentation needed to address today's scale and complexity

* Gain clear visibility into real-time virtual SAN performance

* Confidently deploy virtualization in business-critical environments

Speakers and audience participants - who will be able to ask questions during the event - will discuss how new solutions enable administrators to peer into multiple dimensions of the infrastructure in real-time and obtain the integrated monitoring and analytics required to optimize and troubleshoot virtual infrastructure performance holistically across every element of the system - from the application to the spindle.