POSIX®—an open standard based on UNIX operating systems and their APIs—brings a powerful set of features and capabilities to the table for embedded application development, resulting in benefits to software vendors such as ourselves as well as to our customers. The following list is a brief set of answers to the question “What are the benefits of POSIX®” to our customers—the builders of complex safety- and security-critical embedded software systems.
Using any software API creates dependency. However, writing applications to a set of proprietary APIs ties those applications to some vendor’s operating system (OS). Of course, the same is true for any home-brew OS or supervisor. I’ve seen multiple large projects incur substantial costs because the developers wrote their applications to proprietary APIs. When they wanted to change the OS (or OS vendor), they realized they needed to rewrite their applications to be as independent of the underlying OS as possible. It would have been much easier (and cheaper) to make the desired changes if they had written their applications using the POSIX® APIs from the beginning.
To maximize your application’s portability, minimize its dependence on APIs—especially proprietary APIs. At LYNX, we recommend that our customers refrain from using our OSs (or any vendor’s OS) if they are not absolutely necessary or do not explicitly suit our customers’ long term needs. Some questions to ask yourself when you start using any proprietary APIs are:
These scenarios are not nearly as uncommon as they should be.
POSIX® is an IEEE standard. It is published by The Open Group and readily available on the Internet. Using the POSIX® standard for your application development frees you from having to rely on proprietary documentation from a single-source vendor—you can simply look the standard up online.
POSIX® APIs have been expertly designed and widely standardized to promote portability. They include generally useful abstractions like the filesystem, dynamic memory allocation to processes, threading, math, dates and time, etc. By using POSIX® APIs in your applications, you can port your application from OS to OS, system to system, and project to project—all while maintaining the minimum amount of rework required. This not only lightens the burden on engineers, but it can significantly lower time to market (TTM) and total cost of ownership (TCO). (We will return to these business-level benefits in Benefit #5).
Because POSIX® is well-designed (its origins date back to the birth of the C programming language at Bell Laboratories), the standard itself has remained stable over time. For example, when we joined the Open Group Future Airborne Capability Environment (FACE™) consortium in 2010, they were considering adopting the 2004 version of POSIX®. We felt that FACE™ should use the 2008 version of POSIX®, as it was a more recent version of the standard. LYNX decided to join the FACE™ consortium and successfully lobbied for the members to adopt the 2008 version of POSIX® for the FACE™ standard. Since POSIX® has remained stable for decades, even if you were to reference a newer or older version of the POSIX® standard, there wouldn’t be many differences.
POSIX®-based operating systems are by far the most popular and widely deployed. There’s a wealth of how-to information about POSIX® on the Internet—tutorials, examples, and explanations of when you might want to use certain APIs are a boon to engineers that are not only new to POSIX® but to those familiar with POSIX® as well. For example, you can find information on how to fork-and-exec a process to run a new application, how to use pthread_create() to create a new thread of execution in a multi-threaded application, and how to create and use a timer for an application’s heartbeat.
Even as an engineer with over 30 years’ industry experience designing systems from deeply embedded to high-bandwidth fault tolerant servers, I still search online to see how others are using POSIX® and what information people are making available to leverage POSIX® further. Search engines are one of my favorite tools to find information on POSIX® and I frequently explore websites like Wikipedia and Stack Overflow or browsing various university course materials.
Engineering experience is frequently cited as a major pain point for builders of complex embedded safety- and security-critical software systems. Linux is based on POSIX®—just like LYNX’s RTOSes—and there are hordes of recent graduates and university students that have experience with Linux as well as a large pool of experienced engineers that already program for it. Why not leverage all of that available Linux experience for your own embedded project by using POSIX®? You don’t have to use Linux to take advantage of their POSIX® experience. When you hire a university graduate with POSIX® application development experience, that experience translates from one POSIX® family OS to another because the application APIs are designed to be common and portable.
Don’t be limited to using only a select few experienced engineers that know how to use a given set of proprietary operating system APIs. Don’t wait while your new engineers learn those APIs, either. When you use POSIX® to build your applications, you gain the ability to leverage both existing and new engineering talent faster.
All the points we’ve discussed contribute to lowering your project’s development costs. Let’s review them in light of reducing TCO and TTM.
If you can avoid vendor lock-in by using POSIX®, then you are not beholden to an OS vendor for your next project. That gives you the leverage when it comes time to negotiate your contract for the next project, not your OS vendor. If you had written your application with their proprietary APIs, then the OS vendor has the leverage—not you.
Likewise, many organizations underestimate the hidden cost of open source software. Open source software is anything but free. Frequently, the engineering cost of maintaining "free" software with the need to watch for patches, apply any newly found patches, and trying to get disinterested third-party developers to fix bugs, becomes too burdensome for their project. If you find that the TCO of an open source OS is too high, then having written your applications with POSIX® will enable you to more easily switch to a proprietary OS (where the support costs are built into the business model).
With POSIX® you are not dependent on any one entity to have thought of a comprehensive and robust set of application APIs. The POSIX® standard is powerful and feature rich. Having a rich and well proven set of APIs will speed up development time, which, in turn, reduces engineering costs. Similarly, because POSIX® has such a wealth of tutorials and examples on the Internet, if an engineer gets stuck on any particular problem, then he or she can turn to a vast pool of available resources to help solve the problem. This of course also reduces engineering time, which reduces cost.
POSIX® can also allow you to staff your project more easily and in a shorter amount of time. This means you can start your project sooner—and perhaps with less expensive engineers, too.
A greater degree of freedom and flexibility to switch OSs and vendors at your discretion, free and easily accessible documentation, a vast knowledge base, boosted engineering expertise, and reduced TTM & TCO are why POSIX® is so useful to builders of large and complex safety- and security-critical embedded systems.
Lynx has over 30 years’ experience in helping customers across avionics, automotive, and industrial markets to realize the benefits of POSIX® for their complex safety- and security-critical embedded software systems. To learn more about how to leverage POSIX® for your project, please direct your inquiries to email@example.com or fill out the form below, and a representative will reach out to you within 1-2 business days.
Principal Field Applications Engineer
LYNX Software Technologies