What Makes ‘Mission Critical’ Different?

By Sandeep Modhvadia, Chief Product Officer, Wind River

Wind River has served the embedded systems community since the introduction of VxWorks in 1987. We understand the diverse range of possible software applications for embedded systems and edge computing, wherein hardware is also an essential element. Our unique perspective, gleaned from the experiences of countless unique customers and applications, offers several examples to illustrate the distinction between mission-critical computing and consumer or business-to-business (B2B) computing.

Don’t be distracted by the overused term. Every application is “mission critical” to the people who rely on it. A time-tracking application failure might be a crisis for a marketing agency, and a connectivity dropout could play havoc with a retail point-of-sale system. However, while such failures may be emotionally upsetting and financially distressing, lives are typically not at risk. 

The requirement “This application cannot fail” may suggest that quality assurance and security testing are all that is needed to prevent a failure from occurring. However, with mission-critical applications, every unique requirement impacts the application infrastructure and the decisions made throughout the development lifecycle. The following real-world examples from Wind River customers illuminate the challenges of, and the technical remedies for, the development of mission-critical systems.

Aerospace: The software that controls jet aircraft cannot fail

If you have traveled on any commercial jet in the past 20 years, it almost certainly ran Wind River software. 

Developers and engineers design cockpit controllers and other aerospace components for worst-case scenarios. One way to ensure that everything continues to function correctly is to incorporate isolation into their systems. That is, one system can run completely independently of another, even when being executed on the same silicon. A technical element in this effort is to enforce robust partitioning through a hypervisor or complete hardware isolation.

Medical systems: A ventilator cannot be rebooted if a patient is attached to it

One ventilator manufacturer had a patient on its life-support equipment for three years. The ventilator never failed, and it was never restarted. A reboot could not be allowed to happen: If the equipment had been turned off, the patient would have died.

Consider the system architecture challenges in ensuring that a device will operate continuously -- no restarting or refreshing. They encompass everything from managing resources efficiently to ensuring a constant steady state despite an ongoing stream of data that has to be managed. How do you perform a critical update or fix a security vulnerability? Mission-critical systems have those requirements as table stakes.

The space case: “Wait until it’s parked overnight” does not apply to a Mars rover

VxWorks provides the core operating system of the Mars rover Curiosity. NASA can remotely send software updates to the spacecraft using an updating mechanism, not dissimilar to how vehicles receive over-the-air (OTA) updates.

The mission-critical element here is how such updates work. Nobody would perform an update on a vehicle while it was driving down a street. Most updates happen overnight, when vehicles are parked. If an OTA update fails for any reason, the system — the vehicle — can be reverted back to a stable version at the dealer or with the help of a mobile service technician. But if NASA encountered the same issue, it could “brick” Curiosity — without anyone available to reboot the system.

The rover may be an extreme example. However, many other edge systems are equally inaccessible (in the practical sense, anyway) and therefore require the same level of forethought and validation regarding system updates.

Automotive applications: Assisted driving systems must perceive emergencies and respond to them with precision

Imagine a car equipped with self-driving features at a four-way stop. As the vehicle proceeds through the intersection, an 18-wheeler suddenly appears that will be unable to stop. Can the advanced driving system react fast enough to recognize the approaching truck and then either apply the brakes or the accelerator to avoid an accident? Can it speed up even if it means overriding the digital controls to exceed the acceleration guidelines?

In scenarios like this, microsecond precision and responsiveness matter. The system certainly cannot get stuck in an undefined state where it is unclear what it should do. 

Nor is this challenge unique to automobiles. Many devices require split-second analysis based on inference at the edge, along with near-instant response times and the ability to respond to external stimuli. These automotive mission-critical lessons apply to many other industries.

Telecom: Calls cannot be dropped, even in a crisis

The 2025 Eaton fire in Southern California destroyed more than 9,000 structures. During the crisis, a major telecommunications company — a Wind River customer — had to ensure that 911 emergency calls in the area were never dropped. When someone calls emergency services, they need adequate time to articulate their location and describe the problem. A dropped call could mean the difference between life and death. 

Given that level of urgency, any cellular network operator must invest in reliable emergency services with optimal throughput — and do so affordably. The company concluded that it needed to isolate its hardware from software. That led to larger architectural decisions, such as the best way to create abstraction layers and the degree to which the company could deploy off-the-shelf hardware.

A Mindset Switch

Those examples are merely a sample of the circumstances that turn an application development project into a mission-critical endeavor. Those requirements usually add time to a project. The application must work reliably for years on equipment that would otherwise be replaced, and it must be capable of (certifiable) upgrades that provide the same assurance of quality as earlier versions.

Because it is difficult or impossible to apply a "move fast and break things" approach to developing mission-critical applications, the design process often takes longer than consumer or B2B developers expect. For instance, they have to make difficult hardware choices (since the lifecycles of these expensive systems can be measured in decades) and plan for exhaustive compliance testing. 

The good news is that information is being shared across industries, making it easier to design, deploy and maintain mission-critical applications. Supporting our customers connects us with engineers who design and deploy mission-critical (and sometimes not-so-critical) embedded systems, leading to many interesting conversations. Aptiv and Wind River play an active part in organized information-sharing activities, such as sponsoring the recent IEEE Space Computing conference and actively participating in open-source projects such as OpenInfra and Linux distributions.