|
|
| January 2002 | Get BSD | New to BSD? | Search BSD | Submit News | FAQ | Contact Us | Join Us |
|
In my personal experience, BSD derived systems are being used more and more frequently for embedded work. BSD derived systems are displacing commercial operating systems historically used for such work at a high rate, particularly in prototype products and startup companies.
If you are considering building an embedded system, you would do well to learn from the examples of such companies as IBM, Apple, Array Networks (formerly ClickArray), Foundry Networks, Ricoh, Intel, and many, many others who use a BSD platform at the heart of some of their products.
The primary reasons for this, in my opinion, are startup cost, per unit cost, time to market, source availability, licensing, and available labor pool.
Consider a company building a first version product; they may be a startup, or they may be an established company attempting to enter into a new market. In either case, the budget is limited. Such a company is not going to be able to afford a license for an expensive product up front. For example, Java licenses are rumored to go in the half million dollar range, and they still need an OS to run on.
No matter what licensing model is used for a commercial embedded system software platform, there is always a up front cost for tools, services, reference platforms, and so on. Even if you have an in-house expert for the system you are licensing, there is, at a minimum, a "developer's kit" cost.
An obvious workaround to these problems is to use an Open Source software product. Not only does it resolve the problem with the up front cost of starting the project, it also resolves a number of the other thorny issues which will face the new product team and the business, later on as we shall see.
One major impediment to any new product trying to establish itself is COGS, or Cost Of Goods Sold.
While it's true that COGS bear little relationship to the optimal "street price" for marketing purposes, in most cases, COGS limits the bottom end price that you can charge and still make a profit. And profit on a product is dictated by the amount you get for it and what it costs to build it -- COGS. So a lower COGS means a higher gross profit margin.
Traditional embedded systems tend to have three major licensing models: An up front charge for the use of the software, per unit royalties, or a combination of the two. It is also common for there to be a "minimum commitment" for units, so that there is a minimum amount you will pay in the first year, regardless of whether you ship enough units to hit that cost level through unit sales alone. If you don't... you pay anyway: the vendor does not share your pain.
They may also have caps on royalties, but this is less common. Cisco negotiated cap with Standford which cost Stanford billions in royalties they would otherwise have been able to collect. Most companies licensing software have learned their lesson from this example. Count yourself lucky if you are able to negotiate such a cap; be suspicious about whether or not the vendor will be around in 3 years or 5 years, or if they are willing to cut a deal because they are in a precarious position.
In any case, the costs affect your COGS, no matter how you come by them. It doesn't matter if you are amortizing an up front payments to a vendor over an expected 1000 units in the first year (for the Java license example, this is $500/unit of extra COGS, not including per unit royalties, if any), or if you are paying per unit for VxWorks, and passing that cost directly into your COGS.
Again, an Open Source platform works around these problems.
A common problem for any new product is time to market. Once you decide to produce a product, you are, in effect, on the clock for your market window. If you act too slowly, your window will close and will be left hanging with a product that meets your requirements, but no market to sell to; a worse scenario is someone getting there ahead of you (worse, because you could always shelve the product and try again later, otherwise).
An Open Source platform resolves a number of the bottlenecks you will otherwise likely face: negotiation of license terms with the platform vendor, delay for acquisition of capital, and the other stall-points you tend to hit trying to use a commercial platform product.
Some embedded systems are also dissimilar in their operation on different target platforms. What this means is that you will not be able to start work until you have your target platform up and running. In the embedded systems arena this is the touch of death, since it means that you will need to serialize development of your platform and software (worst case), or face a potentially expensive, in time and resources, porting phase to the target once it is available (best case).
An Open Source platform lets you control the dissimilarities yourself, minimizing or eliminating them where they are most expensive to you. You can start work right away on the reference platform, with a reasonable expectation that the code will simply "port over" with a recompilation.
In other words, an Open Source platform permits you to start work right away without any of the platform relative delays that you would otherwise face.
Source availability is important, particularly to embedded systems devleopers. In some cases, it's an absolute necessity, since you must integrate third party proprietary drivers.
For example, the IBM/Whistle InterJet product used proprietary ISDN drivers licensed from Telenetworks, which could not be redistributed, and which needed to be ported to the system. The porting process would have been very difficult without source code, since, even with a vendor supplied DDK -- Driver Development Kit -- having working examples and being able to look at how the OS support routines were written and expected to be called was valuable, and saved much time and effort which would have otherwise been necessary in the porting process.
Another valuable reason for source code is sublicensing: if you wish to license your code to a third party, that third party would need to get a license from the platform vendor as well. The value of your property you are licensing would be diminished by the cost of the platform vendor license to the third party.
An Open Source platform resolves these issues
Because of the BSD license, and the fact that many embedded systems require the inclusion of proprietary technology for application specific hardware included with these systems, or intrinsic to the design itself, such as on board custom components, BSD systems tend to be a superior choice relative to other Open Source systems, where such intellectual property can not be kept private due to licensing issues.
One example is the Telenetworks ISDN drivers previously noted, it was not possible to distribute the source code, as would have been required with some other license.
Another might be codecs and other components in a Rockwell HCF winmodem (perhaps you are building a set-top box or a home gateway of some kind, and manufacturing cost is more important than available CPU (available CPU is rarely, if ever, a bottlneck in an embedded system).
Other examples abound.
A common workaround for this is to avoid the license issue entirely by loading the component as a module. The Linux based digital video recorders avoid this problem in their local multimedia filesystem by loading it as a module.
While it's possible to work around many of these licensing issues, it is not possible to work around all of them. For example, if the code in question exists in the boot path, then it's not possible to avoid the license issue using the "module trick", since you must have the module before you can boot, and you must have the ability to access media before you can load the module. This is why the Linux based digital video recorder product has a seperate boot file system which is not the same as its multimedia file system. If the driver in question were the driver for the boot device, e.g. a disk controller, network device, or proprietary cartridge, then you would have no choice but to release it.
The extra complexity introduced by such license issue workarounds, if they are even possible for your particular situation, is most often not worth the effort, since it increases your platform software dependence, and makes it much harder for you to be agile in the face of market demands. For example, if you need to jump platforms entirely because of a large client willing to commit to a large number of units, but only on their or a partner's platform.
A BSD based license gives you the advantages of an Open Source system, while costing you practically none of the disadvantages of a license that prohibits source distribution -- or of one that requires it.
A common problem, though less so recently, is available labor pool.
Even with the so-called "bust", the market for good people is still tight: it's still not an employer's market, if you want people who can get the jobe done right and on time.
One thing you can do to help combat this problem is to choose a platform that permits common engineering skills to be transferred over.
For a product based on an Open Source system like eCOS or RTMX, the number of people available who are skilled at doing work in that environment are limited. Likewise, a VxWorks based system means that you must find people capable of work in that environment.
While some skills are universal, and will transfer over easily, some skills by necessity can not. These people are still a scare commodity. Despite your best efforts, you will find yourself in a position of paying above market rates for at market -- or, even worse, below market -- skilled labor.
Once again, a BSD based system resloves the problem: the UNIX labor market is already well developed, and the skills are wide spread. Students come out of school knowing at least rudimentary UNIX programming, if they know programming at all. You would be hard pressed to find a hobbiest who has eCOS or VxWorks or even a Win CE developement environment installed on their home system.
For these and many othersreasons, which you will discover on your own, should you go down this path -- or which you have already discovered, perhaps to your detriment, should you go down another -- a BSD based system makes a good fit for your next embedded systems platform.
In future articles, I expect you will be able to see how to deal with embedded systems develeopment issues, from people who have been there already.