The RTOS minefield

• RTOS
• Project Management

In the modern world, shopping can be quite a challenge. Many products have numerous features and options and there is often a staggering choice of suppliers. It is rare that buying on price alone makes much sense. With a complex, technical product, like a real-time operating system (RTOS) this challenge can be very daunting …

The parameters applied to the selection of an RTOS are numerous. Here, in no particular order, is an incomplete list to give you a flavor:

• technical features/functionality
• optional components
• business model
• vendor experience/reputation 
• quality of technical support
• quality of documentation
• source code availability

This list could go on. I have often given a talk on this topic, which lasts about an hour and only scratches the surface.

There are some interesting nuances to the selection process that I will illustrate with a story of events that occurred a few years ago, when there were around 200 RTOS products to choose from:

A major, Europe-based company was planning an ambitious new project on quite a grand scale. A lot of embedded software would need to be developed and it was quickly recognized that an RTOS would be needed. A team of very smart guys was assigned to make the selection. They spent many weeks working their way through all the products that they could locate, carefully applying their criteria. Eventually, after much sifting and testing, they narrowed it down to two products, both from major players in the RTOS business. I will call them Company X and Company Y. They approached the two companies and sent their list of detailed requirements; it was a very long list. Both companies were keen to respond as they knew it was going to be a big order with much continuing business.

Company X responded to the request for quotation very quickly. They indicated that the long list of requirements could be readily accommodated and that their price would be $xxx. This price was well within the customer’s budget.

The guys in the sales team at Company Y were very worried. Their initial thought was that they were not in with a chance. Their careful scrutiny of the list showed that the required features fell into three groups:

1. features that existed in the standard product
2. features that could be implemented (particularly given the amount of money on the table)
3. features that were virtually impossible or that conflicted with other requirements

After much deliberation, the responded to the customer with their conclusions and quoted a price, $yyy, for the business. $yyy was just within the customer’s budget, but much higher than $xxx.

After a few days and clarification discussions between Company Y and the customer, Company Y received the order.

So, what was happening here? The order went to the company with the incomplete product and the higher price. This seems illogical until you consider that the customer’s RTOS selection team were very smart guys, as I mentioned earlier. They knew that the Group 3 features were not viable; their inclusion was a trap and Company X fell into it.

The Company X team wanted the business at all costs and figured that a fast response and lower price would get it. The technical challenges could be sorted out by Tech Support later. This was very short-sighted, as this was not just a single order; the customer was looking to establish a good, long-term working relationship with the RTOS vendor. Company Y had shown that they were honest and open.

So, the good guys won …

Sign in