Today’s emerging economy — highly connected, highly intelligent, and highly automated — requires a technology foundation that is highly responsive and resilient. RTOSes, built to deliver precision with little to no latency, are well positioned to provide these capabilities.
The following are guidelines for selecting and implementing RTOSes:13
Ensure a strong security profile. For any device that will be connected to the internet, developers must select an RTOS that has gone through security certifications and was built for security. Security certifications for RTOSes are a fairly recent development, but they are increasingly important when security must be built in to every component in a system.
Ensure a strong ecosystem. Developers must consider these questions when choosing an RTOS:
- Is it widely adopted across the industry?
- Does it support the major hardware architectures?
- Does it have an active and engaged community?
Look for the latest features. When considering the available features, developers should confirm that the RTOS supports static memory allocation, has real-time tracing features, and integrates with the target memory protection unit.
Consider the middleware equation. While middleware compatibility is not an issue with most RTOSes, developers should nonetheless check for it. Include components such as low-level drivers, file systems, graphical user interfaces, TCP/IP stacks, encryption engines, and more in the analysis.
Evaluate performance. It might seem obvious, but the team must remember to look at performance factors such as RAM footprint, ROM footprint, reliability, and determinism. Consider the performance concerns for a given application, and whether or not every clock cycle will actually be important.
Consult the engineering team. The skills and years of experience on the engineering team matter, as do the members’ work stress levels, their interest in particular features, and the learning curve required by a given RTOS.
Consider cost in context. Obviously the budget matters. However, the costs of labor and maintenance could be significant compared to the price of even a commercial RTOS. Possible internal costs can also mount if an RTOS requires a steep learning curve or exhibits poor performance for the given projects.
Scrutinize the vendor. Developers should consider the company that creates and — just as important — maintains (or does not maintain) the RTOS. How long has that company been in business, and does it seem set to survive? Does its team respond quickly to requests for support, and is its code and documentation of high quality?
Managing sophisticated functions on the edge means that development implications are evolving rapidly. In addition to the challenges, there are many rising opportunities.
Ask yourself these five key questions as a team, including development, business, strategy, and operational members. Using a simple scale from 1 (yes, or extremely relevant) to 5 (no, or completely irrelevant), calibrate how fully you are maximizing your opportunities.
If you score between 4 and 5 for any question, reread these pages to see whether you are considering all the possibilities raised by employing RTOSes in embedded projects.
Contact Wind River to discuss your plans for your robotics system with an intelligent systems expert.