As Canonical approaches its 20th anniversary, we have proven our proficiency in managing a resilient software supply chain. But in the pursuit of excellence, we are always looking to set new standards in software development and embrace cutting-edge quality management practices. This enables us to meet current technological landscape needs. It also paves the way for future innovation, motivating us (as ever) to make open source a key driving force across all industries. In this article I will explore how combining the openness and transparency inherent in open source principles with the right quality management frameworks enables us to lay new foundations for the software-defined industries of tomorrow. 

Open source adoption is growing and with it, regulation

The presence of open source software components in regulated industries has accelerated dramatically in the past couple of years and can be found everywhere, from the smallest industrial component to the largest ship in the world. Such a broad application domain brings additional complexity and heightened expectations that we address the evolving need for quality requirements. While language-specific standards were ways to address guidelines in a relatively simple world, this is not enough anymore. Instead, we need to adopt quality models that are not just a compliance requirement, but effectively a way to evaluate the produced engineering components. 

While these types of models are often developed in the context of regulated domains in specific industries, they can provide insights that are impactful across a broad range of applications. For instance, ISO 25010, a quality model that is the cornerstone of a product quality evaluation system, is a great framework to help engineers understand the strengths and weaknesses of specific artefacts using static code analysis. By using an objective, reproducible and independent quality model that follows ISO 25010 standard, Canonical can meet the expectations of a broad spectrum of industries and enable the opportunities that open source software brings. 

Adding independent quality indicators

TIOBE is supporting Canonical in getting an independent overview of its code quality by checking the reliability, security and maintainability of its software sources. The measurements are based on ISO 25010 and follow a strict procedure defined by TIOBE’s Quality Indicator (TQI). TIOBE provides real-time data integrated in programming environments and separate dashboards and makes use of best-in-class third party code checkers for Canonical.

Paul Jansen, CEO of TIOBE states: “We are thrilled to contribute to the success of Canonical. After having checked the code quality of a lot of Canonical’s projects in our independent and regulated way, it is clear that Canonical is scoring far above the average of the 8,000+ commercial projects we measure every day”.

At Canonical, we believe that Quality Management (QM) is an essential pillar in the development of open source software. That is why we added TQI as one additional control point across our software development lifecycle process. In most industries, the expectations towards innovation but also quality attributes, including the ones highlighted by TIOBE Quality Indicator, are very high. The integration of open source software with industry-recognised quality models marks a paramount step towards achieving excellence and leading to the production of superior software solutions.

Addressing quality management requirements in automotive

A prime example of the advantages of independent quality indicators can be seen in the automotive industry. This sector, with its high demands for safety and technological innovation, presents unique challenges that require impeccable quality and robust software solutions. As vehicles become increasingly software-defined, integrating open source software with industry-recognised quality models becomes not just beneficial but essential. Quality management works as a driving force – not just ensuring the reliability and safety of vehicles – but also the key building block for generating trust in open source within the automotive industry. 

As Canonical’s Automotive Sector Lead, Bertrand Boisseau, explains: “The results of the collaboration with TIOBE are crucial, especially in the realm of Software Defined Vehicles (SDVs), where the abstraction and decoupling of software and hardware development cycles is key. The TIOBE TiCS framework supports our R&D efforts related to automotive, enabling us to go beyond the expectations of this demanding ecosystem”. 

Conclusion

Our approach is designed to address the inherent complexity of modern software stacks, which are by nature heterogeneous. We make use of quality models like ISO 25010 as accelerators to enhance our quality management processes. At Canonical, these models are instrumental in enriching our continuous improvement practices with measurable data, while also aligning with the expectations of the broader enterprise landscape, particularly when combined with the openness and transparency open source software provides. 

If you have embarked on a similar journey to measure quality management in your organisation, I would love to hear about your experience. If you’re eager to join our mission in advancing precision engineering, please explore our openings starting with the Technical Manager Automotive and Industrial as well as our Lead Development Lifecycle Engineer positions. Stay tuned to follow our journey towards engineering excellence and connect with me on LinkedIn.

Download our latest Whitepaper: A CTO’s Guide to Real-time Linux

Welcome to this two-part blog series on real-time systems which asks the question: Real-time Linux vs RTOS, which is best for you? 

In Part I we looked at the basics of a real-time system where we explained that a real-time system must respond to events within a specified time frame, and provide timely and predictable responses to inputs within the allowed deadlines to ensure that the system meets its timing constraints. 

Part I also discussed the differences between a  Real-Time Operating System (RTOS) and PREEMPT_RT. In this blog, we will delve deeper into the differences between the two approaches to enable enterprises and developers alike to make an informed decision between PREEMPT_RT and RTOS based on the requirements of their systems.

Real-time Linux vs RTOS: Recap

An RTOS is specifically designed to meet the stringent timing requirements of embedded systems, industrial automation, automotive control systems, medical devices, and other applications where precise timing is crucial and missing a deadline is considered a catastrophic failure. In particular, an RTOS provides mechanisms for scheduling tasks, managing resources, and ensuring the execution of critical tasks.

In automotive, safety-critical applications, like braking and airbag deployment, must happen within milliseconds for the safety of the vehicle occupants.

On the other hand, PREEMPT_RT is one specific implementation aimed at enhancing the real-time capabilities of the Linux OS. Linux is not an RTOS, but the PREEMPT_RT collection of patches reduces the latency and improves the system’s responsiveness, making it more suitable for real-time applications.

PREEMPT_RT introduces kernel preemption, allowing Linux to preempt lower-priority tasks in favour of higher-priority ones

By aiming to make the Linux kernel more deterministic and reduce the time it takes to switch between tasks, PREEMPT_RT improves its real-time performance, enabling it to better support use cases with stringent timing constraints.

Real-time Linux vs RTOS: Key differences

From the above clarifications, a fundamental distinction between an RTOS and a real-time Linux kernel lies in their design philosophies. An RTOS is often purpose-built for real-time applications, prioritising determinism and predictability in task execution. Many RTOS products have undergone strict testing and certification, allowing them to be prevalent in mission-critical industries such as medicine, nuclear, or aerospace. On the other hand, Linux with PREEMPT_RT adapts a general-purpose OS to meet real-time requirements by enhancing kernel preemption.

RTOS is engineered to provide deterministic response times, ensuring tasks execute within specified time boundaries. Such a setup makes it ideal for applications where missing a deadline is not an option. On the other hand, even though a real-time capable Linux kernel is not a hard RTOS, its performance can be sufficient for many real-time applications without requiring speciality hardware or software.

When to use real-time Linux or an RTOS

System criticality

In scenarios where the correctness and timing of operations are paramount, especially in critical embedded systems like medical devices or avionics, an RTOS might be the preferred choice.

Application requirements

If a project demands a balance between real-time requirements and the flexibility to run various applications, real-time Linux with the PREEMPT_RT patch offers a more versatile solution. An RTOS is often specialised and resource-intensive. RTOS is purpose-built and has limited functionality compared to general-purpose OSes. This can be a drawback in scenarios requiring diverse applications beyond real-time constraints.

Every layer can be a source of latency in a real-time system, and tuning is normally required to meet application-specific requirements.

Resource-constraints

The software on a system, whether Linux with the PREEMPT_RT patch or an RTOS, must not excessively consume the system’s resources to provide an acceptable ROI. Real-time Ubuntu Linux integrates the PREEMPT_RT Patches to efficiently service most real-world low-latency, low-jitter workloads while enabling a well-balanced solution reducing overhead and maintaining responsiveness. Real-time Ubuntu Linux is less costly to maintain than RTOS alternatives and may be preferable in resource-constrained environments where maximising performance with limited resources is crucial.

Long-term support

Long-term support (LTS), whether for a Linux with PREEMPT_RT or an RTOS, provides a reliable foundation for building and maintaining real-time systems. LTS versions of an OS undergo extended testing and bug fixing, making them more stable. Timing and predictability are critical in real-time applications, where having a well-tested platform is essential to avoid unexpected issues that can lead to system failures or performance degradation.  Furthermore, LTS versions have a longer support life cycle than non-LTS releases, which is crucial for real-time applications in industrial or critical systems, where longevity and continuity of support are key considerations for system deployment and maintenance.

For enterprise-grade solutions requiring a real-time Linux environment with extended support and compatibility, Real-time Ubuntu, backed by the PREEMPT_RT patch, offers a robust solution.

Real-time Ubuntu 22.04 LTS is supported for 10 years via Ubuntu Pro

Hardware support

A real-time capable Linux kernel with the PREEMPT_RT patches often comes with broad availability of hardware support, as Linux runs on a wider range of processors than RTOS. To provide real-time scheduling and bounded latencies, some RTOS products have been developed from the ground up on specific hardware.

Making an informed decision

Real-time does not result in optimised performance: what matters is a deterministic response to an external event, aiming to minimise response latency, rather than optimising throughput. 

In the realm of real-time computing, the choice between Real-time Linux and RTOS depends on the specific requirements of an application. While Real-time Linux, especially with the PREEMPT_RT patch, offers a robust solution for many scenarios, dedicated RTOS may still be preferable in certain critical, embedded systems. Understanding the intricacies of both options is key to making an informed decision that aligns with an enterprise’s demands and constraints.

Learn everything you need to know about real-time LInux in our latest whitepaper.

Discover Real-time with our latest whitepaper: A CTO’s Guide to Real-time Linux

Welcome to this two-part blog series on Linux vs RTOS (Real-time Operating System). This series will explain the differences between achieving real-time requirements with a Linux kernel and doing the same with an RTOS.

Part I will explain the basics behind a real-time capable kernel running Linux vs RTOS. In Part II, we will delve deeper into the pros and cons of each approach and how to make an informed comparison between the two. Let’s get started.

What is real-time all about?

The demand for real-time capabilities is rising in the ever-evolving computing landscape, with forecasts indicating that nearly 30% of the world’s data will require real-time processing by 2025 [1]. To understand how to meet real-time requirements, it helps to have a clear definition of the concept.

“Real timeliness” is the ability of an Operating System (OS) to provide a required level of service in a bounded response time [2]. In a real-time system, not only does the correctness of a computation depend on the logical correctness of the result, but also on the time at which it produces it [3].

On the software side, alternative approaches are available to fulfil real-time requirements. Which one should your business adopt? Where should enterprises land on the Linux vs RTOS debate?

Real-time with Linux

Real-time computing via the Linux kernel is gaining traction as a valuable solution, especially in systems running the latest silicon, with precision and deterministic response times.

The concept of preemption lies at the core of real-time Linux. It involves interrupting the current thread of execution to process higher-priority events promptly. Deterministic response times are unattainable in Linux without kernel preemption. PREEMPT_RT, hosted at the Linux Foundation, is the de-facto Linux real-time implementation. While it doesn’t aim for the lowest latencies possible, it introduces mechanisms like priority inheritance and replaces locking primitives, making the Linux kernel preemptible with deterministic response times.

Real-time Ubuntu with the out-of-tree PREEMPT_RT patches, brings real-time capabilities to the forefront. Offering reduced kernel latencies as required by demanding workloads, Real-time Ubuntu provides a time-predictable task execution environment. Furthermore, Canonical has supported the Real-time Ubuntu Linux kernel for over 10 years, enabling device manufacturers to focus on their business drivers.

Meeting real-time requirements with an RTOS

An RTOS provides an alternative to real-time Linux solutions. Unlike general-purpose operating systems. RTOSes focus on deterministic response times and precise control over task scheduling. Enterprises often use an RTOS in mission-critical scenarios with extreme latency-dependent use cases, where a missed deadline results in system failure. RTOS excel at managing task priorities, allowing critical tasks to take precedence over less time-sensitive processes. This prioritisation is crucial in scenarios where the system must guarantee operations will occur within a specific timeframe.

On the other hand, an RTOS’ suitability for applications in critical systems where any form of system failure is intolerable, may comes with some drawbacks, which we will touch upon in Part II.

Is it always possible to achieve the “best performance” with either a real-time capable Linux kernel or an RTOS? And can development teams rest assured there is one clear choice between the two approaches dependin gon their systems’ requirements? Let’s find out.

Reducing latency with Linux vs RTOS

A real-time capable Linux kernel does not guarantee maximum latency because performance strictly depends on the system at hand. From networking to cache partitioning, every shared resource can affect cycle times and be a source of jitter. Every level can be a source of latency, from the hardware to the kernel and the application. 

Similarly, even the most efficient RTOS can be useless in the presence of other latency sinks. Specific tuning for each use case is required, and an optimal combination of tuning configs for a particular hardware may still lead to poor results in a different environment. This meant that follows that one can’t guarantee a maximum latency “in the abstract”, as performance strictly depends on the specific system.

Making an informed choice between real-time Linux vs RTOS

The choice between RTOS and real-time Linux hinges on the specific latency requirements of a system, balancing the need for determinism, overhead, and resource efficiency.

While Real-time Ubuntu Linux with the PREEMPT_RT patch offers a robust solution for several scenarios, a dedicated RTOS may be preferable in a critical embedded system. A real-time capable Linux kernel is ideal for strong latency-dependent use cases but for extreme latency requirements, an RTOS may be more suitable. Understanding the intricacies of both options is key to making an informed decision that aligns with a business’s demands and constraints.

Stay tuned for  Part II of this mini-series, where we will discuss the relevant considerations to keep in mind when choosing between a Linux kernel or an RTOS in a real-time system.

Download the latest whitepaper on real-time Linux now!