For decades, VxWorks® was a safe default for real-time and mission-critical systems in aerospace and defense, and that reputation was earned. But a foundational RTOS is not a one-time purchase — it is a multi-decade dependency. When you choose the software beneath a mission system, you are betting less on what the product does today than on where the company behind it is going tomorrow. For programs built on VxWorks, that second question — where is this vendor going? — now has a different answer than it did a few years ago.
The Center of Gravity Has Moved
Wind River, and VxWorks with it, is now part of Aptiv — a large, capable technology company whose growth strategy is built around automotive, mobility, and Linux-based edge compute. There is nothing wrong with that strategy; it is a rational bet on enormous markets. It simply is not an aerospace-and-defense strategy.
Companies invest where they grow. Forward R&D, product roadmaps, and go-to-market energy follow the largest opportunity — and for Aptiv, that opportunity is measured in automotive volumes and software-defined-vehicle platforms, not in DO-178C artifacts, MOSA mandates, USG flow-downs, and twenty-year sustainment tails. A&D remains a real business inside that portfolio, and the installed base will be supported. But there is a meaningful difference between a product line maintained as valuable legacy and one that is the engine a company is building its future on. For VxWorks in A&D, that has quietly shifted from the second category toward the first.
The Question Has Changed
Not long ago, the calculus was simple. VxWorks came from the recognized leader in A&D and embedded real-time software, so the question — “how much of this vendor’s roadmap is aligned with my program’s future?” — answered itself. For a large prime, a mid-tier integrator, or a small specialist alike, the answer was: quite a lot.
That question now reads differently: how much of an automotive-and-edge roadmap is being built for my mission? The honest answer is not zero — but it is not what it was. That gap is worth examining directly, with a few fairs, non-accusatory questions any program can put to any foundational vendor:
-
Where is forward R&D investment flowing — toward safety-critical, DO-178C, and MOSA-aligned A&D needs, or toward automotive and edge scale?
-
When your platform needs a new certified capability in 2030, who inside the vendor is chartered and funded to build it?
-
How close do roadmap influence and the account relationship stay to A&D, versus being optimized for a different market?
-
Over a twenty- to thirty-year platform life, is your segment a growth priority or a maintained legacy line?
These are questions about strategic alignment and long-term commitment — not about any company’s competence or good faith. They are simply the questions a decades-long dependency deserves.
Why The Foundation Makes This Urgent
Software is no longer a component of the platform; increasingly it is the platform’s foundation — enforcing safety boundaries, isolating workloads, hosting mission and security functions, and running AI at the edge. The deeper a supplier sits in that foundation, the more your program inherits that supplier’s priorities. When the vendor’s growth is aligned with your mission, that dependency is an asset. When it is aligned with a different market, the same dependency becomes a risk you carry for the life of the platform.
Re-evaluating Does Not Mean Starting Over
Here is what turns concern into a plan: re-examining the foundation no longer requires a disruptive rewrite. The transition programs fear most — re-hosting a certified application stack onto a new operating system — is not the one required. With a modular open systems architecture built on the LynxSecure separation kernel, LYNX MOSA.ic is introduced as a new foundation beneath the software you already field. Your existing VxWorks workload runs unmodified, as an isolated subject in its own partition, while the program regains control of the foundation, the certification story, and the roadmap. You keep the software investment; you change what it runs on — and whose future you are betting on.
How It Works
The separation kernel provides static, immutable space and time partitioning, statically assigned device ownership, and controlled, declared communication between partitions. Each operating system runs as a peer subject, and none can interfere with another’s resources. Because the kernel is small and stays out of the data plane during operation, the trusted computing base is compact and certifiable, and the isolation argument is strong enough to support mixed criticality — up to DO-178C DAL A in one domain beside lower-criticality domains. For the mechanics, see “Open IMA: Running Third-Party OS on LYNX MOSA.ic”.
A Phased Path — Modernize On Your Schedule
Phase 0 — Assess: An architecture and readiness assessment inventories the guest OS and workloads, maps target hardware and BSPs against supported platforms, and reviews the certification baseline — producing a modernization and certification-scope roadmap. Low commitment, high clarity.
Phase 1 — Rehost: LYNX MOSA.ic is stood up as the foundation and the existing VxWorks runs unmodified as an isolated subject, proven first on a non-critical subsystem — the platform in place with no rewrite.
Phase 2 — Bound & Consolidate: A structured delta-certification determines what evidence carries over and what must be re-verified; multiple line-replaceable units consolidate onto one platform; and new safe and non-safe workloads are added beside the legacy stack.
Phase 3 — Modernize Selectively: Individual functions move to native modules where it pays off — LynxOS-178 for DAL A domains, Linux for rich workloads, bare-metal Lynx Simple Applications for deterministic functions. Nothing forces the pace; each phase stands on its own.
What The Program Gains
Roadmap Alignment: A foundation from a vendor whose growth market is your mission, not a sideline.
Architectural Control: Provable isolation and no single-vendor lock-in; you influence the foundation.
Bounded Certification Scope: Isolation the kernel enforces and evidence, not a re-certify-everything exercise.
Consolidation and SWaP-C: Collapse multiple LRUs onto one deterministic platform.
A Path To The Modern Edge: Run AI/ML across CPU, GPU, or NPU beside the certified legacy stack.
Lifecycle Longevity: A foundation built to be sustained, patched, and recertified across decades.
Why Lynx
Lynx builds for aerospace and defense. It is not a legacy line inside a larger, differently-focused portfolio — it is the center of gravity of the company. That focus shows up where it matters to a program: a separation-kernel foundation designed so no single operating-system or vendor decision locks the platform; support measured against platform lifecycles rather than product cycles; and a deliberately low-risk way in — an assessment-led engagement that proves feasibility before you commit, and a phased path that lets you keep the software you trust while you modernize the foundation, and the compute beneath it across CPU, GPU, and NPU, on your own timeline.
Start With An Assessment
The first step is a low-cost architecture and readiness assessment. In a few weeks you get a clear picture of feasibility, certification-scope impact, consolidation upside, and a phased roadmap — whether you proceed.
Contact Lynx to scope one for your program.
