Help Wanted: Embedded Engineers

Here's an interesting article on Embedded Engineering. My first job out of college was doing programming for telecommunications devices. I didn't really think of it as embedded engineering. The device used a Unix OS. We had an emulator to test out the new features and bug fixes before applying them in the field. My programming mindset is naturally geared towards memory efficiency and tight code so maybe that's why it didn't really seem all that different to me. Mike Anderson does have a good point. Colleges, Universities and other Technology Schools need to teach embedded engineering.

Help Wanted: Embedded Engineers Why the United States is losing its edge in embedded systems…

By Mike Anderson, Chief Scientist, The PTR Group, Inc.

Embedded Systems are Everywhere

With all of the cellularphones, portable media player/MP3 devices, global positioning system (GPS)units, set-top boxes, digital video recorders, automobile telematics systems and digital televisions that were introduced over the past couple of years, I suspect that this number is probably on the low side today. We are surrounded by embedded systems comprised of custom hardware and software designs.

An embedded system can be characterized as any device in which you inherently know there must be a computer in there someplace, but you’re just not sure where. This is not to be confused with real-time systems. Systems that have real-time deadlines may or may not be embedded, and not all embedded systems have real-time deadlines. There is considerable overlap for sure, but they are not one and the same.

For instance, a GPS locator has a computer inside. I suspect that everyone knows that. But, we typically don’t attach a keyboard and mouse to it although it’s probably one of the most computer-like of the embedded systems since the user must input addresses in some way. Nor does the user typically vaporize if the device takes 30 seconds to acquire a satellite fix rather than 15 seconds.The GPS is an embedded device, but we probably wouldn’t classify it as a real-time device.

On the other hand, anti-lock brakes are computer controlled as well. Our input into the anti-lock brakes of the car is limited to the brake pedal. The rest of the operation is completely based on other sensors and the environment. It is clearly an embedded system. However, the anti-lock brake system is a real-time system as well. If it doesn’t function within the real-time deadline constraints, then people get injured.

Embedded systems development typically requires a different mindset than we find in the desktop environments. Embedded systems are frequently resource-limited. These systems have low-power processors, possible battery operation, and limited
memory and storage.

Embedded designers need to pack in lots of features, but keep the costs own so the units are affordable.

So, where does the embedded system designer gain this type of knowledge? Currently, companies are paying to have developers learn these concepts on the job.

What many in the embedded systems community would like to see is that new graduates already have some of this knowledge from their college/university education.

The ability of a new hire to “hit the ground running” could save U.S. embedded systems companies millions of dollars each year. This is money that could be reinvested in additional research and development to make them more competitive in the world market, or simply yield a higher return to their investors. Regardless of what is done with the “savings,” the incoming engineer would make U.S. companies more productive.

I only quoted some of the more interesting tidbits.

If you want the full version, here's the link.

Code Quality is determined by the WTF/Minute

Link

Idea for a programming experiment

This is something that I thought of after I wrote about PZ Myer's article in Seed.

I mentioned in that post, that sometimes virus programmers will create self-mutating programs in order to evade detection by the anti-virus software. Since us security folks tend to nip these nasty little programs in the bud, they don't get a chance to propagate. What if they were allowed to propagate in a controlled environment? Perhaps, over millions of iterations of random mutations a useful program can emerge.

Can computer programs evolve from something simple to something more complex without the presence of a designer or coders? If true, this could prove useful in cutting down on the man hours of programming. I seriously doubt we'll end up with something like SkyNet from the Terminator movies, but it could generate something interesting to study.

What I propose is to create a self-mutating program in a controlled environment. Let the program spawn mutated variations of itself then test those mutations for usefulness. The mutations should be random additions and alterations of program code. Selected pieces of functional code can be also patched together at random. A selector program will then perform automated test on the resulting programs to see if they are worthy of propagation. Those that meet the worthiness test are allowed to propagate and mutate again. This can go on for however long the controlled environment can support the process and resulting programs.

I don't have the facilities to create such a controlled environment, but I suspect some colleges or universities do. It should be something a graduate Computer Science student could do as a class project.

PZ Myers on Algorithmic Inelegance

Dr. PZ Myers of Pharyngula fame has on article in Seed Magazine talking about the algorithmic inelegance of genetic instructions. He compares genetic code to the design and development of computer programs. The basic idea here is that an intelligent designer can create a work of algorithmic excellence that couldn't have occured by random mutation such as what naturally occurs in evolution.

"The designers of software usually aspire to economy of code, clarity in its operation, and powerful algorithms that, with mathematical and logical beauty, do the work of generating a sophisticated result."

He does note that there are still the ubiquitous “Kludges” and hacks in the software we use.

"We tend to look down on the "kludge," the clumsy addition to fix a problem, or the brute force approach of working case by case to force a desired result (although, to be sure, I've seen enough code to know that the awkward hack is ubiquitous)."

Since PZ is a biologist, he has the opportunity to examine nature's code in detail. He goes on the talk about the "invisible hand of evolution: the evidence of random accidents."

However, what we more often see is the action of the invisible hand of evolution: the evidence of random accidents that have been incorporated into the code, of elaborations built of bricolage, a collage of bits and pieces assembled into a larger structure. Life is a collection of kludges taped together by chance and filtered by selection for functionality; it all works magnificently well, but if you look under the hood you are simultaneously appalled by the sheer inelegance of the molecular gemisch and impressed with the accumulation of complexity.

It would be inappropriate for me to critique PZ's essay from a Biologist standpoint. My only exposure to biology is reading PZ’s blog and high school biology class.

I am a programmer and have been working in the IT industry since 1996. I can tell you from first hand experience that once a code-base reaches a certain size and level of complexity, logical elegance in design becomes less and less of a concern. The emphasis becomes, "Just make it work."

At the start of the project the design team works out a beautiful object-oriented model of all of the components and various interactions. This is done to help manage the complexity and make the system easier to maintain down the road.

Once the main design phase is over, the grunt work of actually implementing the system may or may not follow the exact specifications laid out by the designer(s). Sometimes features are added in the middle of a project and the only way they make it in is to come of up with a kludge or quick hack.

After the software goes into production, the customer often comes back asking for additional changes to meet their specific needs. This often results in even more kludges and hacks. What starts out as logical beauty begins to show a few warts and wrinkles as time goes on. The visible hands of coders can result in an evolution of sorts of the software system.

You can also write a program that randomly mutates itself. Since the program is in essence data, that data can be over-written. In this way, a computer program can mutate into something that looks different from the original. Virus programmers sometimes write this functionality into their creations to get past the detection software. That functionally still requires a designer.

My point is that just because something looks like it was a patched together collection of hacks, doesn't mean it started out that way. Is evolution by design or by random accident? I'm not making any assertions either way. I know that a program that is the result of random self-mutation seldom does anything useful or elegant. The fact that it can change itself is a product of design