Introduction

Although slanted at commercial kernels for embedded systems, this article is equally applicable to other system software for embedded systems such as GUI libraries, file managers, TCP/IP stacks, etc.

Many people think that commercial kernels should sell for prices comparable to compilers. After all, they reason, there is probably as much or more code in a compiler as in a kernel. What these people do not realize is that compilers sell in the 100,000's whereas embedded kernels and RTOS's sell in the 100's. That is three orders of magnitude difference. This makes a huge difference in the economics of the kernel business versus that of the compiler business.

For example, magazines do not charge kernel vendors 1/1000 as much as compiler vendors to advertise. Nor does the post office, the landlord, or the electric company give kernel vendors a break. So how can someone expect to get a quality kernel and quality support for it at compiler prices? The short answer is: he can't. The longer answer follows.


A kernel is more than a tool

It becomes an important part of your final product. For an average project, you can expect:

                   kernel    15 KB
                   platform   5      
                             20 KB

of code to be incorporated into your product. (The platform is initialization and startup code which comes with the kernel.) 20KB is a big chunk of code and it is foundation code -- not bell-and-whistle code. For a large application, incorporated kernel and platform code can add up to 40KB, or more.


Treat the kernel like a member of your team

How much is he worth to you? The 20KB of code, calculated above, is equivalent to about 2000 lines of code (LOC). You wouldn't hire a junior programmer to write such important code. So you would probably pay this programmer about $30/hr. Adding in fringe benefits and your time to manage him, you are up to at least $45/hr, assuming a small to medium size company with low overhead.

So what can this programmer be expected to produce? For real-time application code, 200 LOC/man-month is reasonable to design, code, test, debug, and document. (Pressman, Software Engineering, McGraw Hill 1982). Of course, kernel code is even more difficult to write, but let's assume you have hired a whiz kid. Even so, you are looking at 10 months at $8,000/mo or about $80,000, total, if all goes well. And this is an optimistic estimate! (Actually, we have several man-years invested in smx - 'course we're not whiz kids.)

How would you like it if you could get this guy to do the job for a measly $5,000? To make it even better, suppose he writes some excellent manuals on the first day of work, so your other programmers can start right in using the kernel? Not only that, suppose he is such an excellent programmer that his final code is as good as code tested by 100 other programmers in a variety of circumstances. "Wow," you're saying, "What a deal!"

Well step right up, because this is the deal you get with a good commercial kernel!


What isn't in the kernel ends up in the application

We don't know the details of your application. But we do know, in a generic sense, what problems your programmers are going to face developing your embedded system application, and we have created general solutions for many of these problems. This will save your programmers a lot of time.

Of course, not every function of a full-featured kernel will be needed by a specific application. But it is rather difficult, even for an expert, to say in advance which features will and will not be needed. If the kernel you pick lacks needed features then you will incur the cost and delay for your programmers to create them. (Of course, you, and probably they, will never know this explicitly because there are so many different ways to skin a cat.)

Assuming there is a 16:1 cost ratio on favor of kernel code (as derived in the preceding section -- i.e. $80,000: $5,000) the odds greatly favor your choosing a full-featured kernel over a low-cost, minimal kernel (or worse, developing your own kernel). The wise approach is to evaluate kernel cost relative to your cost of software creation. If you buy a kernel which has 3 times the features actually needed (and, remember, it's hard to predict which specific features will or will not be needed), you are still more than a factor of 5 ahead!


Summary

One might debate this or that number or this or that point in the foregoing, but when the dust settles and the echoes die out, it is hard to shoot down a factor of 5 economic gain. Most business decisions are made on much smaller anticipated gains than this. The bottom line is that picking a quality kernel with quality support is a good business decision.


What About Time to Market?

This is the most obvious reason to buy as much as you can and to develop as little as you can. However, time to market has become an overworked cliché, so we have side-stepped it in this article.

We think that time to market is for Marketeers and CEO's to ponder. There are ample reasons for a company to take too long to get to market, besides product development time. These include limited cash flow, limited plant capacity, reluctance to take risks, poor planning, etc. Whatever the case, when your upper managers do decide what they want, they're going to expect a miracle from you -- good reason to have your ducks lined up in advance!

For those who prefer a more scientific man-month estimate, the COCOMO model (Boehm, Software Engineering Economics" IEEE Transactions in Software Engineering Jan 1984) predicts 19 man-months for 2000 lines of embedded kernel code vs. the 10 man-months we derived above.

Please contact me with any comments or questions about this article.

Ralph Moore
President
Micro Digital Inc

back to White Papers page