Some time ago, eWeek published in interesting article by Scott McNealy named "Technology's Barriers to Exit" (http://www.eweek.com/article2/0,1895,1907211,00.asp).  In this article, Scott makes an interesting point about considering the cost of technology.  There are three costs to consider:

• cost of acquisition
• ongoing cost
• cost to exit
  

Scott states that most people analyze the first two costs fairly well.  What is not thought about as much is the the cost to exit -- how do I move on to the next thing.  I think these basic questions apply very much to embedded technology decisions.

Most of the time we carefully consider our requirements, think about ongoing manufacturing costs, etc.  There may be some thought given to upgrading (the exit), but we encounter several difficulties when planning for the future with complex embedded systems:

• we often can't predict what technologies will be available in the future
• if may be difficult to predict our product requirements in the future 

As an example, we may have a product with an ethernet networking interface, and two years after product launch we have an opportunity that requires a wireless network interface.  How much is it going to cost to add wireless support to our product?  If the product is based on technologies that do not fundamentally support wireless networking, we are looking at very costly exit strategy.  Another example is application-specific, off-the-shelf solutions.  While these are great for many problems and provide a quick way to get something working, what happens when we want to upgrade?  Do we have to re-implement the entire system?

How does one hedge against the unknowns in the future?  One way is to try to anticipate every possible requirement and design it in.  I think this is bad strategy because you usually end up spending a lot of time working on things you don't really need and the quality of the product suffers.  A better approach is make sure your product does what it needs to do well and is based on a flexible platform where significant parts of your design and software can be re-used in future versions.  This approach has many parallels to recent trends in software development and manufacturing such as Agile Software Development, and Lean Manufacturing.

Follow Scott's advice and make technology selection decisions with the following questions in mind:

• Is the technology based on open standards?
• Are programming interfaces and protocols open, published, and been adopted by industry?
• Is there a community process behind the technology (not just one company)?
• Can the same technology be sourced from multiple companies?

The use of Linux in embedded systems is an excellent example of a technology that meets the above criteria.  You can develop your prototype on a x86 PC.  Move it to an embedded ARM single board computer (SBC) for the first production run.  Switch to a different SBC or design your own board when you run into new product requirements.  Sure, it will cost you more to develop the product initially due to the complexity of a system like Linux, but you now have options to expand and change your product while directly re-using the work you have already done.

But wait, as long as I write my application in C, it is portable -- right?  Most embedded systems support development in C so I will just port my application to a new platform when needed.  C is a great language and the language is more or less portable between systems.  But as systems get more and more complex, embedded engineers find themselves spending less time writing original code and spending more time putting together pieces that already exist.  A modern embedded application is often little more than some glue between various libraries and system functions.  The fact that you can develop in C for a particular system does not really mean a lot.  What about the threading model, driver model, library APIs, etc.  I just spent a significant amount of time recently porting a large C application from a proprietary platform to new hardware platform as the original system was going obsolete.  It was a huge amount of work.  The driver model was completely different, APIs were different.  Changing platforms can be very expensive.

It rarely pays to be short sighted when choosing technologies for complex embedded systems.  The best strategy is to stay flexible and choose a platform with a future.