Recently in computer hardware Category

This en

View of the Damifino docked in Seneca, Ill. prior to departure.

This entry breaks, once again, from the stated theme of this blog, which is to look at repurcussions of technological developments for society. We'll get back to that theme when we get back to that theme. In the meantime, take a trip with me down the Illinois, Mississippi, Tennessee, and Tombigbee rivers, thence around the Gulf of Mexico to the southern tip of Florida.

Some 40-plus years ago, my then bride-to-be asked: "Hey, could we live on a boat?"

She'd seen my parents spending weeks at a time aboard their 36-foot cabin cruiser during the summer, and it looked like a fun, romantic (and cheap) lifestyle. We were at the time firmly rooted in the Boston, Mass. area, however, so the full-time live-aboard lifestyle was impractical. Yet, the idea persisted, resurfacing from time to time.

Another persistent theme became the "I've never been to Florida. Could we go there?" question. Having visited my grandparents at their winter home near Orlando (long before Disney Corp. turned the place into Mickey's Corporate Office), my impression of Florida was of a gigantic sand spit with bugs, and rain every afternoon. It was never top of my list of places to go, so that idea didn't get very far, either.

More recently, when the school failed to pick up Bonnie's teaching contract for the forthcoming year, we finally decided to chuck it all, and abandon the Chicago-area winters for year-round live-aboard boating at the southern tip of Florida.

In the decades since getting married, we'd developed into gypsies, anyway; we'd picked up our own cabin cruiser; and learned the advantages of avoiding the annual butt-freezing season. It was time to live out Bonnie's particular fantasies.

The first step was, of course, a reconnaissance trip. Borrowing the temporarily empty house of a friend in Marco Island, Florida, we spent a week sampling the fleshpots (which, unlike Las Vegas, means beaches, not night clubs), and scrutinizing marinas.

Destination in hand, we returned to refit the Damifino (pronounced "Damn if I know!" We didn't name her. The previous owner did.) for indefinite occupancy, and move her through the western half of the Great Loop cruise track down through the river system and the Inland Waterway to the Gulf of Mexico, thence around to Florida's southern tip.

Lest this entry be completely without technological interest, let me note that I'm writing this on the upper deck (under that blue awning in the picture) using my laptop computer, which is wirelessly linked to a WiFi router attached to one of the bulkheads below, and running on ship's 12 VDC. Also on the wireless LAN are a printer, and Bonnie's laptop. The router ties into the Internet through a cellphone link.

The text editor I'm using does not run on my laptop. It's an example of thin-client technology in which I type into text boxes in a web page provided by the blogging section of my website, which runs in rented space on my ISP's server. Since the ISP's hardware is a server farm distributed over much of the U.S., it's also an example of cloud computing at its best.

Ain't tecknollogie wunnerfull!

We're now ready -- or as ready as we ever will be. Today, we drop the lines and blow a kiss and a wave to Illinois. In the words of the Paul Simon song: "We're on our way. We don't know where we're goin'!"

We'll know when we get there.

Author C.G. Masi's forthcoming novel looks at how technology developers go about their business in a corporate environment.

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.

Volcano monitoring is a task that the Three Ds say definitely should be automated. Source: NASA

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.

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.

Figure 1: Embedded systems include a control loop governed by a microcontroller.

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.)

Figure 2: Microcontrollers include a microprocessor, memory and I/O circuits on a single chip.

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.