Building an embedded system, how do you choose which operating system to use? Do you really need an OS?
The benefits of using an OS are many. In addition, software components often require a scheduler, queues, semaphore, mutexes etc. Using an OS also has the advantage of simplifying the dependency between the application and the hardware. The OS provides its own environment to the software application making the processor an abstraction layer within the system.
By encapsulating your application within the operation system and its drivers (yes, you may have to write one or two of them to support you custom hardware), each processor, new or old, supported by the OS, becomes a suitable candidate as a target platform. Of course you may face the task of rewriting all your custom drivers… However, porting these should probably be less time consuming than a total rewrite of the entire design.
That said… What OS will be your silver bullet?
Sadly none…
Probably, the choice will always become a compromise. Often you may have a culture within your company or a company policy to use a certain OS, which of course constraints your options. So what to choose?
The answer I’m thinking of is: The OS that is the most cost efficient.
The OS to select also depends on you available developers, export restrictions, product lifetime, components, product volume, IPs… Licenses… The list can of course be very long…
Some points worth looking for are:
• Does the OS support your processor?
• Does the OS support your tool chain?
• What third part dependencies do I get as a result of selecting a certain OS?
• Cost of support?
• Second source of support and source code (or precompiled modules)?
Of course, I now assume that all candidates fulfill the technical requirements constraining the selectable set. On one side, open source OS’s comes free, that is: they are not attached with significant license cost. But, you might need to share any changes you make and if not being careful the code that must be shared may include code that is both sensitive and business critical. You will also have access to the OS’s source code and in some cases even paid support.
On the other side, there are the proprietary operating systems where you might get the support agreement when buying the license. In these cases, there is a supplier that can claim quality of the OS implementation. In some cases, some OS’s are even considered almost de-facto standards. Your business secret is also protected since there is no need to share the changes you make, if you’re allowed to make any changes.
The selected operating system should be the operating system that is most economically feasible and that fits the technical requirements, legal issues, etc. Considering the economics, how easy is it to find help and how easy is it to find developers that have the required knowledge to use the OS in question? If the competencies are hard to find, even an OS with low license costs becomes economically unfeasible. Do you have developers available or do you need or hire new people or consultants?
If we can use an OS already known to our developers, we will save both training cost and get developer acceptance. Most important, the developers will probably have a short start-up time.
Sometimes the debate of what OS to select becomes almost religious. In this sense, it might be better to select an OS based on what’s practical with respect to the product, the organization, and the system’s lifetime and with respect to maintenance.
A proper software design will probably ease the dependency of the OS and processor; hence the processor (or even the OS) might be changed later on to a calculated cost. Therefore, in spite of not being the most suitable for the product, a certain OS available at the right time (for practical reasons) may become just as good starting point as the target OS given the benefit of fast start-up.
A clever design easing the dependency of the OS will manage the risk of changed preconditions. If a change or update is needed in the future, the cost of changing the OS or the processor can be derived from the original work. Therefore the cost and the risk can be managed already from the very beginning of the development of the product in question.
By
Mattias Almljung,
Altran Technologies Sweden AB