The embedded systems developer’s journey has changed over the years, with the advent of new technology introductions and different demands by the users and applications. With that in mind, I interviewed Michel Genard, Wind River’s Vice President of Products, where we discussed just how those changes have affected the embedded developer.

ECD: Take me through the embedded developer’s journey.

Genard: As with all things embedded, no two journeys are the same. And yet, how we tackle design challenges are somewhat in common. You always start at the system level where you need to think about the kind of system you’re designing in terms of the end application. Then, you decouple the system in small pieces or subsystems. This is an important aspect of the design because it’s where critical decisions are made about which technologies, APIs, interfaces, etc. to use.

The next step is to figure out which parts of the design need to be prototyped to validate your assumptions and that the features are possible. This process should be quick and not expensive.

Next, you take into consideration the specific hardware resources, like the CPU (or FPGA), the GPU, accelerators, the processor interface, etc. Based on these hardware decisions, you now go back to your software and determine which type of operating system makes the most sense, whether open source and Linux would suffice, or a real-time operating system (RTOS) is needed.

Throughout this process, you need to think about the life cycle of your system—what needs will you have down the road and what will you do with all the data you collect?

The key to this journey is having a vendor that can take you from design to development to deployment and offer choices whether you want to start with an RTOS or you’re thinking about open source, or whether you need certification.

ECD: What are some changes to the embedded landscape that you’ve witnessed recently?

Genard: The embedded systems world is changing rapidly. The pace of innovation is gaining momentum due to advances in technology and increased competition. OT and IT systems are beginning to merge or at least find common application development ground.

Developers of embedded system software see the benefits of developing in the cloud and are moving to modern methodologies in search of greater efficiency, productivity and portability. In addition, both hardware and software development are moving faster than ever before. New software engineers are coming into embedded systems with a high comfort level with abstraction and prefer to focus on the application rather than the underlying infrastructure. As a result, they want to build embedded systems using IT-like methodologies, programming languages, and frameworks. At the same time, engineers are leveraging low-cost hardware like the Raspberry Pi to build inexpensive prototypes and move quickly from concept to functioning device.

ECD: What is your definition of real time and when is an RTOS required vs. open source?

Genard: Let’s start with what’s not real time, which is fundamentally when your application can perform the given task within the required time range. It’s what we call “good enough.” Alternatively, an RTOS gives you determinism in the sense that you can predict from an execution flow point of view how the system will behave. And you can predict this accurately in terms of execution time. There are always going to be latencies, whether it’s 10 ms or 100 ms. But you must determine what amount of latency won’t disrupt your system.

RTOSs are responsible for processes and machines of critical importance. Think planes, trains, automobiles, and even Mars Rovers. In many cases, the proper functioning of the RTOS ensures the protection of human lives and the environment.

Alternatively, during prototyping, open source is the most convenient choice. This is because you have access to lots of code, and you can see how the community has adopted similar technologies. When you have use cases that are compute intense (e.g. machine learning) an open source framework or OS can be the right choice as well, side by side with an RTOS for the most constraint and control aspect of the application. Where open source could become problematic is when you look at it from a pure IP point of view. In other words, as the vendor or OEM, do you care to have your source code available to the community?

The confusion lies in that some developers incorrectly associate open source verses non open source with real-time verses non real-time. These are two drastically different discussions. The real debate comes back to the system infrastructure, and whether it requires determinism.

ECD: What are your options if your design needs to be certified?

Genard: There are essentially two kinds of certification. There is certification against safety and certification against security, and they are fundamentally different. One protects the system from harming anyone, the second protects the system from the outside trying to do harm (i.e. hackers). Ultimately, the outcome may be the same, where you can prove that your system complies with some standard, or the system will achieve some security standard, meaning that the system can’t be compromised.

Therefore, you first need to decide what you want to be in compliance with. For example, if you’re going to deploy your system in an industrial environment, you think about safety. Or if security is required for an IT kind of deployment you may need different compliances.

Certifying for safety often comes down to the lines of code, because you have to prove that every line of code has gone through a very strict design process, including coding, testing and validation. So the goal is to minimize the lines of code, a process called optimizing code.

Security is slightly different because it's not so much about the lines of code. Rather, it's about rigorous testing of just about everything in the system in order to comply.

ECD: How has the role of the RTOS changed over the past few decades?

Genard: The world of embedded systems is undergoing a significant evolution, affecting the role of the RTOS and the design of applications that rely on determinism, ultra-reliability and performance. Once isolated and purpose built, embedded systems are rapidly adding new capabilities like greater connectivity, reusability and flexibility. They’re increasingly software-defined.

Today’s RTOS must keep pace with innovation and embrace modern development practices. They have to be able to work with new, more complex processors. Their design should enable the new, faster development cycles in the industry. This means being compatible with the frameworks, languages and methodologies being embraced by the new generation of embedded system developers.

What hasn’t changed though are the fundamental requirements of an RTOS. It must meet all of these new criteria without any compromises on security, safety, performance and reliability.

ECD: Finally, are there any disrupting and/or enabling technologies we should be aware of?

Genard: 5G communications comes to mind first. 5G is not just a new communications standard that lets you do things faster. 5G fundamentally redefines things, such as latency. The minimum acceptable latency in 5G is far lower than something like 4G LTE. Some people are referring to it as “ultra-low-latency.” This allows you to do things in real-time that you were not able to do before. Obviously, there are antenna and radio access issues, but that shouldn’t have a big impact. 5G has the potential to make “autonomous” at scale a reality with edge compute deployment.