TrustMotion: The System Orchestrator for the Software-Defined Vehicle

Software-defined vehicles have become the industry's next competitive frontier. Yet behind every discussion about AI, centralized computing, and zonal architectures lies a more fundamental question: who will orchestrate the entire system? At AID 2026 in Suwon, AEM sat down with TrustMotion GM Chris Greentree, CTO Dr. Stefan Poledna and Country Manager Jaeyoon Cho to discuss why the middleware is evolving into a system orchestration layer, how AI can coexist with functional safety, why "China Speed" is reshaping global vehicle development, and what it will take to build truly software-defined vehicles.

by Sang Min Han  |  han@autoelectronics.co.kr
한글로보기




 
Looking at your background — 20 years at Honeywell spanning automotive hardware, software, and infotainment, then Elektrobit, NNG, and WideSense — why TrustMotion, now? I'm curious about the personal reason for choosing this opportunity among so many options.
Chris Greentree   It's a good question, because on paper this probably looks like just another step in a long automotive career. For me, it's the most exciting point in that journey — and it started long before the résumé.
I'm a mechanical engineer by training. I've had wrenches in my hands since I could crawl — my father owned a service station, and I grew up fixing cars from a purely mechanical perspective. But I was also always computer-focused, writing code from age ten. Software was never anything more to me than a tool — just another wrench, hammer, or screwdriver.
At Honeywell, I spent 20 years watching vehicles become electronic — automating old mechanical test rigs so a 12-hour turbocharger test could run in under 4 hours, fully automated, with far better data and repeatability. I think that's really where I started seeing what software could do. In my last six years there, I built a monetized automotive software business; some of those original team members were here in Korea, and Hyundai is still their customer today. I left in 2017 because the level of investment needed to really scale the business wasn't there at the time, and moved on to Elektrobit, where software became a genuine differentiator at real scale — over 3,000 people, and a global customer base. That's also where I learned the hard business lessons: OEMs were used to buying a screw, a metal box, a wheel — physical things, not software. Working with OEMs to understand how to pay for software they couldn't see was its own transformation.
At NNG, I saw how connected services could reshape user experience, but I also lived through a brutally price-competitive market where a full transformation of the business model was needed. That pushed me toward a handful of startups, including WideSense, where I got seriously into AI — optimizing energy efficiency and asset deployment for public transit, alongside a CTO I'd first worked with at Honeywell twenty years earlier. We eventually sold WideSense to a publicly traded organization, opening me up to work with even more startups in the automotive space.
What became clear across all of this — and I think this is really the heart of it — is that the next decade won't be about better ECUs or more software features. It's about vehicles that are fundamentally software-defined, intelligent, and capable of continuous evolution. And the software-defined vehicle isn't the "holy grail" of post-sale monetization the industry expected five years ago — it's the stable building block you need to stay relevant in the marketplace. TrustMotion sits right at that intersection: deep expertise in functional safety, embedded software, and vehicle motion control, at the moment OEMs are rethinking their electrical architectures — and now, with NXP, that software expertise is paired with world-class semiconductor technology. After a career spent working across suppliers, software companies, and mobility businesses, I wanted to be somewhere I could help shape the industry's future rather than simply participate in it. That's what made the decision easy.


 
TrustMotion emphasizes its status as a "neutral supplier" while being part of NXP. But from the perspective of OEMs using competing SoCs, there may be doubts about whether TrustMotion can truly be neutral — the same tension ETAS faces as part of Bosch. How do you manage this? 
Chris Greentree   At TrustMotion, neutrality isn't just a claim — it's built into how we operate. MotionWise abstracts the hardware and decouples software from the underlying SoC, so it's portable across chip platforms — essential when a vehicle's chips won't all come from one vendor. We work openly with multiple silicon vendors, third-party software partners, OEMs, and Tier-1s. And we keep strict data-governance walls between customer projects — we're TISAX-compliant specifically to protect that separation, which matters most when we're sitting across the table from a customer running a competitor's silicon.
The analogy I use most often with the team is the iPhone. The screen on your iPhone isn't made by Apple — it's made by Samsung, Apple's biggest competitor — because it's simply the best-in-class screen available. TrustMotion works the same way: we want to be the best-in-class safety software for the software-defined vehicle, so that Renesas, Infineon, and ST have no real alternative but to work with MotionWise. If a customer pairs it with NXP silicon, there's added benefit because we understand that hardware's DNA. But even with other silicon vendors, our software still gives them an edge — especially in the communication stack, where we build world-class, fault-tolerant communication.
And to be direct about it: Renesas, Infineon, and ST aren't our customers. Bosch, Aptiv, Hyundai, Ford, GM, BMW, Mercedes are. If those customers run multiple silicon vendors across their boards — which every OEM does, including Japanese OEMs who lean heavily on Renesas — what they actually want is a software stack that works identically across all of them. So Renesas and Infineon will want to work with us for the same reason Samsung supplies Apple: the end customer demands the best in class.
There's one more piece to this, though. Today's chips are becoming so complex that some of the newer SoCs are genuinely being called "monsters of complexity." Hardware alone can't take advantage of that — you need a software platform that abstracts the complexity and handles execution, communication, security, and safety together. This is why NXP wants to combine high-performance chips with the high-performance software that supports them: paired with NXP's CoreRide platform, MotionWise lets customers optimize hardware and software performance against their own KPIs, and speed up safety- and security-aware integration, linkable into a CI/CD-based software factory.


 
Many in the industry — myself included — still remember TrustMotion as TTTech Auto, or simply as "the MotionWise company." Rebranding alone doesn't change identity that quickly. What kind of company do you want people to remember TrustMotion in five years — and Stefan, having built MotionWise since the TTTech Auto days, what is its core essence today?
Chris Greentree   In five years, I want TrustMotion to be remembered not as a middleware provider, but as the trusted system orchestrator for software- and AI-defined vehicles — the partner that brings hardware, software, and AI together into safe, scalable vehicle platforms. That means less time thinking about individual products and components, and much more time thinking about the platform as a whole — the layer that lets OEMs, Tier-1s, chip vendors, and software partners actually work together in one open, trusted environment.
Why that, and not just "the MotionWise company"? Because I think the hardest problem in SDV isn't any single layer — it's making hardware, software, and AI behave as one coherent system. TTTech Auto and MotionWise gave us deep expertise in safety, determinism, and system-level excellence, and that foundation stays at our core. But the clearest proof of what "orchestration" actually looks like, in practice, is what we are doing with Ethernet: making it the real backbone of the software-defined vehicle, so OEMs can run audio-over-Ethernet and other capabilities, including low-cost end nodes with zero- and low-latency communication for a robust, stable system.
If there's one image I'd choose for that role, it's this: I want to be seen as the plumber of the software-defined vehicle.

Dr. Stefan Poledna   This SDV transformation is fundamentally a way to bring software into the vehicle that can be upgraded over time, and that means two things: you get vehicles to the market faster, because you can push upgrades at later stages, and you keep vehicles more valuable over their lifetime by continually optimizing and adding features. That requires a runtime and execution environment where you have compute resources you can deploy software onto quickly and safely. This is because the car has to stay deterministic, safe and secure. Moreover, it must become possible that a software component that is developed once can be deployed to entry, mid-range, and high-end car models. It's like an iPhone upgrade reaching multiple iPhone models at once — except here the bar is much higher, because the upgrade has to preserve real-time behavior, safety and security across every one of those runtime configurations and architectures. MotionWise is what makes that possible: it keeps safety and real-time, deterministic behavior intact across multiple models and multiple E/E architectures.
Stefan Poledna is the company's technical DNA, now moving into the CTO role, while you take on GM. How is the division of roles designed between the two of you, and how do you complement each other? Has there been a case recently where your views actually diverged? 
Chris Greentree   Stefan and I have very complementary roles. As CTO and co-founder, Stefan represents the technical DNA of the company — his focus is our technology vision, advancing platforms like MotionWise, and keeping us ahead in safety, determinism, and system architecture. My role as GM is to translate that technology leadership into customer value and business impact — scaling operations, strengthening customer relationships, driving execution in the market. My focus right now, in my first three months here, is understanding the fundamental economics of where the business is today and where it needs to go, so we get the near-term priorities and the long-term path right together. Stefan is focused on making sure not just TrustMotion, but the broader NXP, has the right software vision for the next ten years — building blocks that apply to automotive, robotics, medical, anywhere the legacy TTTech Auto DNA can bring safe, zero-latency communication to a software-defined ecosystem. What makes it work is that we're tightly aligned — technology strategy and business strategy move hand-in-hand, which matters enormously in SDV, where innovation is worthless unless it can be deployed at scale.

Dr. Stefan Poledna   This is a team effort in a moment of transformation. AI is coming in fast, and that means we have to anticipate customer problems before they're raised. If a customer tells us "I have this problem, can you solve it," we're already too late — we need answers for problems that are still on the frontier. This is where the company, from TTTech through TrustMotion, has always positioned itself: as a technology leader in deterministic, orchestration and safety-grade software. We've never chased the lowest cost on legacy tooling. Chris is on the business side, I'm on the technology-leadership side — that's how it should work.
In SDV transitions, we often observe in the field that organization and validation are bigger barriers than the technology itself. What has your experience been?
Chris Greentree   I'd strongly agree. In most SDV programs today, the real bottlenecks aren't individual technologies anymore — they're organization and validation.
Start with organization: if you look at the org chart of any OEM, it looks like the architecture diagram of their car — because ownership is still divided by function the old way, even as the car's own architecture is becoming software-defined. That mismatch creates real friction: we'll sit in meetings with multiple teams that each hold partial ownership over one element of a decision that needs to be made as a whole. It's a known, observed reality we simply have to work through.
Then validation: legacy OEMs run a well-established homologation process — typically 24 months from design freeze, covering two winter and two summer cycles. What we try to do is get a stable, validated platform into the OEM's hands as quickly as possible, because that's where the OEM actually starts building their own differentiation — their "magic." Once they have that stable foundation, they can keep iterating on top of it without redoing the whole validation cycle every time.
The ideal SDV scenario, to me, is this: you launch a vehicle not when a feature is a ripe banana, but when it's still a banana seed — before the plant has even grown — because the stable platform lets you keep building and validating new features on top of it, long after the launch.
It's a serious challenge, especially for safety-critical functions. This is why we want to give AI a sandbox to operate within — a space bounded by a safety environment the customer can validate without ever breaking that envelope.

Dr. Stefan Poledna   Both are structural issues. You don't fix them with better tooling alone. Internally, that's why we put such a strong focus on continuous integration and continuous deployment — nightly builds, nightly tests, fully automated, all validated against a deterministic execution environment. We see this extending in the future to connect directly with customer platforms too, so validation is carried across organization boundaries — an industry-wide shift toward continuous testing, integration, and validation that has to encompass AI algorithms alongside classical, deterministic algorithms and safety, together, within the same runtime. That's where our platform comes in: it hosts this variety of functions and gets them operating as one coherent system. Success in SDV isn't defined by the best individual feature — it's defined by the ability to reliably validate and deploy the entire system in production faster.


Chinese OEMs have created "China Speed" — 18-to-24-month development cycles, now reportedly compressing toward 12 months in China, Korea, and Europe alike. How do you evaluate this phenomenon? What should global OEMs learn, and what should they never imitate?
Chris Greentree   China speed isn't simply about development speed — it's a customer mindset. Chinese OEMs listen to the consumer, and they know that consumer won't wait. Someone in Germany might wait four years for a feature; the Chinese consumer won't — and increasingly, neither will younger consumers in Europe, North America, or Korea. What Chinese OEMs actually built is a much shorter cycle between customer feedback, engineering, validation, and release — that's the real achievement, far more than just "faster."
I've seen the culture behind it up close, too: I lived in China in 2003, '04, and '05, and every single day, on my way from my apartment to the office, there was a new building going up. That pace isn't just a metric on a chart — it's how the whole system, and the people in it, are wired to think.
This is where software-defined vehicles come in, I think: they let you move even faster than China speed itself, because you can launch a platform with features you didn't even know about at production time, and add them later through software — as long as you've given the OEM a stable platform with the lowest possible compute overhead for the base functions, so they have the headroom to build, and later replace, their own "magic."

Dr. Stefan Poledna   And that customer-centricity raises the stakes on validation — you need to be certain that a new function never pushes the system outside its safety boundaries. This is what our correct-by-design approach is built for: tooling and analysis built into the platform itself, so any change is checked against its real impact before it ships — does real-time performance hold, does everything stay safe. This increases automation, reduces testing iterations, and actually speeds the whole process up. That's the right way to chase speed. Cutting corners on safety, quality, cybersecurity, or long-term maintainability isn't.


 
I'm curious about the revenue models of middleware companies in automotive software. OEMs are reluctant to spend on software, and Tier-1 suppliers are under margin pressure. Who has to pay for TrustMotion to grow into a sustainable business, and why? 
Chris Greentree   Companies in our position have a responsibility to drive real innovation and genuinely solve OEMs' problems — so far, the industry has mostly delivered building blocks that enable individual ECUs, without addressing the broader SDV challenge. The value chain is shifting, and so is who pays for what. Software used to be bundled into hardware and effectively invisible in the cost structure; that model is breaking down. OEMs increasingly buy software as a separate, strategic asset rather than a component of an ECU.
OEMs still own the vehicle platform, the customer relationship, and the lifetime revenue — but how they pay is changing. OEMs pay directly for core platform software — middleware, OS, system integration. Tier-1s co-invest and integrate, embedding middleware into their own system deliveries. Software providers like us monetize through licenses, engineering services, and long-term royalties. It's a layered, ecosystem-driven model. Middleware isn't just another cost line — it's what lets OEMs avoid bigger costs down the road: less integration and revalidation work, more strategic independence, and a real shot at entirely new revenue models.


 
AI seems to have become the foundation of every industry. What do you think is the most overrated, and the most underestimated, change AI is bringing to automotive? 
Chris Greentree   AI is clearly one of the most transformative forces in our industry, but I think it's misjudged on both ends.
What's overrated: first, the idea that AI alone will "solve autonomy." End-to-end AI models and VLMs are gaining real traction for next-gen systems, and there's a strong belief that better models and more data will simply make full autonomy fall into place. In reality, a monolithic AI model isn't safe enough to be solely entrusted with driving decisions — you need a safe, secure architecture with redundancy that can handle failures in the AI model itself, and in other software, compute, and communication components. Second, the focus on visible features over invisible complexity — the hype centers on things users can see, AI copilots, ADAS features, generative interfaces — but the real challenge, and the real value, is integrating AI into deterministic, safety-critical systems where behavior has to stay predictable and certifiable.
What's underestimated: first, AI as an engineering productivity and integration engine — the biggest immediate impact of AI isn't necessarily in vehicle features, it's in how vehicles are developed. As coding itself becomes less relevant because AI generates it, specifications, safety, and security become far more relevant — that shift from feature innovation to engineering acceleration is where a lot of real value is being created today, even though it gets less attention. Second, the sheer scale of the validation challenge AI introduces — agentic AI effectively gives you scalable programming teams, but traditional automotive systems were deterministic, and AI-driven decision-making brings statistical, non-deterministic behavior, limited explainability, and enormous data collection, curation, and annotation needs, which makes validation far more complex and resource-intensive. Third, AI works as a system-level capability, not a point solution — its real value only shows up once it's integrated across edge systems in the vehicle, cloud and data pipelines, and development and operations processes together. The industry is increasingly recognizing that.

Dr. Stefan Poledna   I'd add a concrete technical point to your second question: the validation challenge. The state of the art today is clear: with AI we cannot get to the necessary safety level with a single monolithic AI model just by training with more data and running the models again and again. We cannot entrust human life to a monolithic AI black box model alone. That's simply not where the technology is. You need real safeguards, with redundancy, diversity — not just more training.
In some domains you genuinely can't avoid AI — perception, object classification — because the AI approach beats the traditional approach outright. What you can do there is run diverse AI models in parallel, trained on different data, with different model types, so they don't share the same failure mode. Combine two strong, different models, and you can reach the safety level you need.
In other domains, physics becomes the guardrail for AI. Vehicle dynamics, friction, stability, thermal limits — you already know the control laws, so if an AI trajectory says "drive like this," you check it against those laws and reject it if it's unsafe. It's not just more testing — it's a fundamentally different kind of engineering.


In the era of AI and autonomous driving, safety-certification systems like ISO 26262 are built on deterministic systems, while AI is inherently probabilistic. These two fundamentally clash, and it's affecting the market. What does TrustMotion think about this contradiction?
Dr. Stefan Poledna   Let's be direct about it: AI, on its own, cannot yet be trusted with human life. Training with more data and running the models again and again won't get us there by itself — anyone who believes more GPUs and more virtual training alone is enough is wrong. It makes the model better. It doesn't make it good enough to trust with a life, and it doesn't make its runtime behavior deterministic.
This is also why ISO 26262 can't simply be applied to AI. It's not that the standard is bad — it's built around requirements, design, code, and test cases, which presumes deterministic coded behavior. And AI isn't that. There are ongoing industry initiatives looking at SDV-specific standards for the safety of "intended functions," and the standards themselves are evolving: ISO 26262 manages failures in E/E systems, while SOTIF (ISO 21448) addresses risk in systems that work correctly but are still unsafe because of their own limitations or the complexity of the environment. The industry is moving from a purely deterministic safety model toward a combined deterministic-and-probabilistic risk framework — and, as I mentioned earlier, that's where redundancy and physical guardrails do the real work of keeping AI bounded.

Chris Greentree   In practice, that means you can use AI for mission planning and motion planning, and then use physical models to validate that the planned motion won't push the vehicle into an unstable state.
Dr. Stefan Poledna   Same logic applies to the battery — if AI is doing battery optimization —
Chris Greentree   — you still run a final validation to confirm the command won't push the battery past a thermal limit.
Dr. Stefan Poledna   So AI introduces probabilistic behavior, but safety doesn't become optional — it becomes a system-level discipline. You don't certify AI in isolation; you certify the architecture that keeps the system safe despite that uncertainty. Certification is turning into a system-level problem now, more than a component-level one.


 
Ten years ago, competition in this industry was about making better individual parts. Now OEMs, Tier-1s, semiconductor makers, and software companies all talk about platforms and ecosystems. What will be the decisive capability over the next ten years — and what position does TrustMotion want in that game?
Chris Greentree   I think the industry has fundamentally shifted from optimizing individual components to mastering system complexity. Ten years ago, success meant building the best ECU or sensor. Going forward, the winners won't be the ones with the best individual component — they'll be the ones who can integrate and continuously evolve an entire vehicle platform, at scale, across the whole ecosystem. Vehicles are becoming integrated software platforms, not collections of parts; value is shifting toward software capability, integration maturity, and ecosystem control rather than scale or manufacturing strength alone. What actually matters now is system-level integration, real platform thinking that carries through the whole lifecycle, and being able to run an ecosystem rather than just a supply chain.
Our ambition is clear: we want TrustMotion positioned as the system orchestrator and trust layer of the SDV ecosystem. Not another point solution — the foundation the whole system runs on. We sit at the system level, connecting hardware, middleware, and applications, so behavior stays predictable and safe even as architectures get more heterogeneous. And we provide the layer that lets OEMs bring in multiple partners without losing control of the whole. The biggest value in this new world isn't created at the edges — it's created by making the whole system reliable and deployable at scale. The winners will be whoever can hold together complex, software-defined systems across an open ecosystem — and that's the role TrustMotion wants for itself: the layer that makes scalable, trusted autonomy possible.

Dr. Stefan Poledna   Once you get down to the deployment level, this is what "orchestration" actually means: develop once, deploy everywhere. One reason new entrants have outpaced established OEMs is structural — a newcomer launching one or two car models can build everything green-field and move fast. An established player with entry, mid, and high-end models across multiple brands faces a completely different problem — and as newcomers grow their own lineups, they'll eventually hit very similar challenges. This is where our platform actually matters: develop a software function once, and deploy it across multiple platforms in a fully automated way, backed by continuous validation and integration, communication, and scheduling — so the software is built once and deployed to many. It's also where neutrality comes back in: at the vehicle level, no single semiconductor supplier will ever supply every chip in the car, so we need that neutral position to make one software version deployable across old and new models, entry to high-end alike. I call it develop once, deploy everywhere.






 
TrustMotion emphasizes the importance of system orchestration that enables the safe operation of AI, rather than focusing solely on AI itself. At the same time, Korea is rapidly advancing its transition toward Software-Defined Vehicles (SDVs), led by Hyundai Motor Group. What do you believe is the most commonly overlooked aspect in AI-enabled SDVs, and what strategic significance does the Korean market hold for TrustMotion? 
Jaeyoon Cho   Korean OEMs are accelerating the adoption of AI across a wide range of domains, including AI-based ADAS, AI Cockpits, and in-vehicle agents. At the same time, they are moving aggressively toward SDV architectures and centralized computing platforms. I believe this represents a very positive transformation and positions Korea among the leaders shaping the future of the automotive industry.
However, one observation from the field is that much of the discussion remains focused on improving the performance of AI models themselves, while comparatively less attention is given to how AI can be safely operated within the vehicle system. Unlike conventional IT systems, vehicles require real-time performance and functional safety. No matter how advanced an AI model becomes, its decisions must remain within the physical limits of the vehicle and comply with strict safety requirements.
Therefore, one of the most important challenges ahead is building a system architecture where AI and safety-critical functions can coexist. AI should be able to create new value, while the system itself must be capable of validating and managing AI-generated outputs within defined safety boundaries.
In this context, TrustMotion is focused on providing system orchestration technologies that enable runtime environments where AI and safety-critical functions can operate together safely and reliably. We are also introducing physical models for edge-AI and physical AI applications so that AI-generated vehicle control commands remain within safe operating limits.
This is one of the reasons why Korea represents such an important market for TrustMotion's global growth strategy. Many companies around the world are talking about SDVs, but only a limited number of OEMs are simultaneously deploying SDV architectures in high-volume production vehicles while advancing centralized computing and AI-based vehicle platforms. In that sense, Korea is one of the most important reference markets where future vehicle architectures are not only envisioned, but also implemented and validated in real-world programs.
Korean Tier-1 suppliers are also facing significant challenges. As ECU consolidation and the transition toward Central-Zonal architectures accelerate, they must create new roles and sources of value while navigating increasingly intense global competition and OEMs' efforts to expand their own system design responsibilities.
In this environment, the traditional supplier-customer model — where one party develops a product and the other simply purchases it — is no longer sufficient to address emerging challenges or drive meaningful innovation. More than ever, the industry needs partnerships that enable companies to jointly develop, validate, and continuously evolve new technologies.
For this reason, the role of TrustMotion Korea goes far beyond introducing or selling products. We aim to serve as a trusted partner that helps customers navigate and implement their SDV transformation. In particular, we seek to work closely with customers in areas such as system orchestration, the safe operation of AI-based vehicle systems, and the implementation of fail-operational architectures.
Ultimately, competitiveness in the AI era will not be determined by who deploys the most AI, but by who can build the safest and most trustworthy AI-enabled SDVs. I believe Korea is one of the few markets that has both the ambition and the capability to lead that transformation on a global scale.


 
Chris Greentree   I'm genuinely excited about this market. I've been coming to South Korea for more than 20 years, and I keep seeing real vehicle innovation on the road here. I think we're at a turning point in the industry — and as more SDVs hit the road, it becomes even more exciting to be a driver and owner of a modern vehicle.

Dr. Stefan Poledna   I'm genuinely impressed by the Korean automotive industry and the progress it has made over the past several years. We're proud to be part of that, and proud that our software is already running in Korean cars on the street. We want to keep building on that and continue to be a valuable partner to this industry.

 

---

Related Article: AI Doesn′t Replace SDV — It Depends on It

AEM(오토모티브일렉트로닉스매거진)

---