I've been thinking about why engineers that develop MCU based systems don't do their homework on software alternatives while analyzing hardware decisions to death. I think in part that they are just happy to find a solution that works because traditionally, only the hardware was a problem. Today, MCU based systems are 80% software. Engineers must recognize and use new approaches to maximize company benefits.
Software engineering economics is an important area when building MCU based systems. Often technical people ignore the business side because they are more comfortable with the technical side. Sometimes they ignore the technical side. When they ignore both the business and the technical side, the company pays big time.
One key area that engineers have completely ignored is total cost of ownership or TCO. This concept has been well known and used in IT systems and now is entering the realm of embedded systems. The concept of TCO is simple: when making software decisions consider the total life cycle costs for your OEM development and minimize costs thereby maximizing profit.
TCO should be like apple pie and homemade bread - so universally appealing that everyone loves it; however this is seldom done today. Why is this the case?
Lemming behavior is most common. If a solution becomes fashionable, often others pick it up and use it without analysis of their requirements. The current case of Lemming behavior in the MCU world is underway with a well known proprietary kernel. Its consistently abysmal and disappointing performance and proprietary API should preclude its use on any system except a hobby system where development time, longevity, engineering costs and TCO are all subservient to immediate out of pocket costs.
When are these engineers going to realize free is not necessarily free? Why didn't they calculate TCO before the commitment rather than after the fact?
Ostrich behavior is common too. In this case, engineers use obsolete and proprietary technologies when they should know better. The world is built on open systems and compatibility. For the MCU world and the RTOS world, two key factors which should influence all software development are discussed here.
The first fact is that the world has moved to POSIX for every major operating system and RTOS excluding those RTOS solutions in the MCU world. This should not be surprising - we have known for 20+ years that software reuse and portability of software are critical and POSIX delivers on this. In addition, it minimizes training, eases access to trained people, ensures robust and reliable systems and much more.
The MCU world is now adopting POSIX solutions quickly for all the same reasons that we use them in larger systems. Up until the announcement of Unison and DSPnano, a native POSIX solution was not available for MCUs, but today a broad set of MCUs is supported.
The second issue is the use of a single loop of control or a "scheduler", use of a kernel (not to be confused with an RTOS), use of a proprietary rtos and use of a POSIX based RTOS. For MCU developers this tradeoff has been complex because many developers failed to understand system complexity. For trivial systems, an RTOS is overkill but for anything but a trivial system, a POSIX micro-kernel architecture is the best you can get. You can use just the kernel if that is all you need, or you can add a complete I/O system - all absolutely free.
The third issue which is often ignored is time to market. Being late or being locked into a proprietary product which limits your ability to change with the market can cost significant market share. The entire profitability of the product line is often at stake. POSIX micro-kernels and commercially supported products minimize time to market and maximize your profits.
Just because it will work eventually and the download is free does not mean that the TCO will be optimal and time to market will be minimized. By thinking ahead and doing your own analysis you can save your company substantial time, money and effort.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment