Okay, we're gonna get going with the next presentation now. Once again, I'm Ryan Brinkman, the Auto Analyst at JP Morgan. We're very happy to have Grant Courville, the Head of Product Strategy at QNX. He's gonna walk us through the story. We'll engage in, in, in some, some chat. I turn it over to you, Grant. Thanks so much for being here.
Thank you. I'd like to thank the team at JP Morgan for inviting us and all of you that are here today. I know it's been a long day. So we'll spend about the next seven or eight minutes talking a bit about QNX and trends that we're seeing and whatnot, and then we'll jump right into a Q&A. My name is Grant Courville. Yes, I'm Head of Product Strategy at QNX. I started with QNX, essentially, in the late eighties, call it still a startup at the time. And been with QNX through the acquisitions by Harman International and, of course, by BlackBerry, so very exciting. Left for a few years to go work with a defense company, to spin up their safety-certified software business and whatnot, and then came back to QNX.
I'll share a bit, we'll jump into the Q&A, and hopefully, we'll all learn a bit as we go. Safe Harbor statement, mandatory. Thank you, Tim Foote. For the Canadians in the crowd, yes, you can add a U to the word harbor, but I won't spend time reading this given the time that we have. Let me just jump right into it. Firstly, what do we provide from a BlackBerry QNX perspective? We're part of the IoT unit. At BlackBerry, there's IoT and cybersecurity, QNX is part of the IoT unit. We provide foundational software, if you think about it, think about the hardware or the silicon. We are the layer directly above that. We are managing the hardware, we are managing the processes in the system.
We are that layer that has to work and has to work all the time, reliably in the system, and that's what our customers count on us for. We provide things like an operating system, the QNX real-time operating system, hypervisor, which relates to virtualization technology that you're starting to hear more and more about when it comes to domain controllers. We have middleware and frameworks for ADAS controllers and whatnot, communication software. What we've done with our software, which is different than what you might see elsewhere, is we've safety certified our software to the highest levels across multiple segments. ISO 26262 is for automotive safety, IEC 61508 is industrial safety, IEC 62304 is medical, and then, of course, there's the rail safety standards. There's also emerging standards and ratified standards in automotive now for cybersecurity.
Think of ISO 21434 and WP.29. Much longer conversation, but essentially, they're industry standards now that you can aim for and get assessed to. We've been certifying our software for well over a decade. Very difficult to do. Big investment, but it's an investment we chose to do many years ago and continue to invest in. In terms of our foundational software, think about, again, middleware and applications sit on top of what we deliver. What you're seeing in automotive is obviously more of an adoption of software, and you'll hear the term software-defined vehicle and whatnot. What we're seeing in the vehicle is more systems in the car that can actually run our software, moving from little microcontrollers to more complex systems, to systems that are making use of 32-bit and 64-bit processors.
Essentially, there's more systems in the car with more complexity that we can run on. These are an example of some of those that you see. Traditionally, many years ago, we dominated infotainment. Today, you can look at where we're winning, which is digital cockpit, which is the dash of the car and software in the dash of the car, ADAS systems, so to do with safety, secure gateways, for instance, and you're starting to hear about domain controllers, and we won't have time to talk a lot about that. Effectively, the message is: there's more software in the vehicle, there's more systems in the car that we can run on than there used to be, and the need for safety, security, and reliability continues to grow. Again, that's been our foundation, that's been our the fundamental part of our culture for decades.
In terms of the vehicle, I think... I'm sure you've all seen various iterations of this, of the architecture, but essentially, you've heard numbers like 100 ECUs or systems in a car, 150 ECUs in a car. Some are little microcontrollers, some are microprocessors. Again, microcontrollers tend to be your fixed function type systems, and your microprocessors tend to be your more complex systems. As consumers, as we wanted more and more functionality in the vehicle, more capabilities in the vehicle, the traditional approach was add another ECU and wiring and power and whatnot to it. What's changed, and we're just starting to see that now, automotive, keep in mind, is very evolutionary, nothing happens overnight, is a move towards domains. You might hear the term zonal controller. You might hear the term central compute.
The net-net of it is that many of these discrete ECUs, these fixed function systems, are moving now into more high-performance compute platforms. The first instantiation or the first, what you're seeing first now is, is the domain controller called the cockpit domain controller. That's a reality. That's in vehicles. We had our first cockpit win, years ago, and what you're seeing there is our virtualization technology, our acoustics technology, some of our middleware, excuse me, we're running in the cluster just like we used to before. Software content in the dash of your car, what you're seeing now is Android, for instance, for infotainment. That's the first place you're really seeing a domain controller in a vehicle. From a consumer perspective, you wouldn't know if it's a domain controller, with everything consolidated or whether it's separate systems, and that's actually just fine.
You want it to work, you want it to work always and reliably. Over time, you will see zonal controllers, you will see central compute, again, this is very, very evolutionary, and we're right at the heart of it because we take pride in working very closely with our customers. We are always, always learning, and that's a big part of our success. ... Some of the numbers. We had a great year last year. I won't go over all of the numbers, but we had a record number of design wins. If you think about the cycle in automotive, essentially, you go from the competition part of it to an award, where you are granted that program or that platform. There's development for, say, two to three years, plus or minus, and then you hit production, which is easily five years and beyond.
Anytime you see numbers related to us, related to a design win, that's fuel for the future. That means we've won a program, our vehicle, or our software will be in those vehicles as a start of production, which, again, about three years or so, plus or minus from design win, and then for many years to come. We focus very much on, on those design wins. Of course, there was a recent number published by TechInsights that says we're in 235 million vehicles on the road. That's a number that continues to increase, that we're also very proud of, and of course, multiple systems in those vehicles. The other thing as well, is that we're seeing in the industry, is obviously there's the, the whole movement towards electrification and electric vehicles. There's your established volume players.
Essentially, electrification is an opportunity to relook at the architecture of the vehicle, relook at all of those systems in the vehicle. What we've seen with the, the new entrants is that they're looking to make use of foundational software that's proven and trusted in automotive. We've been in automotive since 1998. We've worked hard to earn that trust. We will continue to work very closely with our customers and deliver the safe, secure, and reliable software that we do. Again, customers are looking to build on top of that. They realize that the value is not necessarily in that foundational software, what we sometimes call the, the undifferentiated heavy lifting, software.
The marketing people don't necessarily like that. Essentially, it's that layer that has to work, has to work always safely and securely and be ultra reliable. Build on top of that. That's the trend that we're seeing in software-defined vehicles. Building customers or Tier 1s, our automakers are building that middleware, building the applications, building the connected services on top of the software that we provide. There you go. How am I for time? I zipped through that. Normally, I speak for much longer than that. Tim has told me he'd get the big hook out if I rambled on, so I promised I wouldn't do that.
Maybe a few questions, including for us, you know, maybe software noobs or whatnot. What exactly do you mean by foundational software? What does foundational software do and what doesn't it do?
Good question. If you think about a system in the vehicle or an embedded system, you'll have the silicon, whether it's from the common silicon vendors, you'll find in automotive, so the Qualcomms, NXPs, TIs, Renesas, and others. Above that sits a layer of what we call foundational software, which will typically be the real-time operating system or the operating system called QNX, or be virtualization software, which you might hear the term hypervisor. It's the layer that interfaces to the hardware, that manages the hardware, and that makes sure all of the processes and all of the applications that the OEMs are developing and others are developing, are adhered to the rules that they've put in place. We make sure that they're separated, make sure they get the priority that is needed.
Essentially, the way to look at foundational software is it's absolutely critical to the operation of your system. Another way of putting it is if you think of a, a desktop PC running, say, Microsoft Windows, Windows is the operating system, then you have the applications on top of it. What we provide may not be glamorous, but to us, it's software that we worked on and, and, and we've been in critical, complex systems for literally decades, but it has to work, has to work all the time.
Yeah, we covered Harman before they were purchased by Samsung, and they talked about QNX being used in, like, roller coasters or just super safety-critical things that cannot fail or people will die. Is that essentially?
yeah, exactly, and that's where-
No blue screen of death.
Yeah, we don't like that, no. Yeah, we, we add a lot of value in safety-critical systems. Systems with a level of criticality, whether it's safety-critical, whether it's security-critical, that's where we add a lot of value. That's where we've literally spent decades. Our original history was in industrial automation, control systems, and whatnot. We're absolutely still in those markets. Think robotics, think conveyor control, factory automation, process control, but the level of criticality of these systems has, has now entered the vehicle and it will continue to be part of the vehicle, as well as the level of complexity. What I always like to say is complexity are, is our friend. We know how to deal with complex systems, and we know how to help our customers deal with complex systems.
and, and, and what, what is the distinction between, you got the safety-critical systems, and then you've got the, you know, the non-safety-critical systems, and, you know, how important is it that they stay, like, separate from each other? What was the key distinction between them?
Good, good question. You might hear us use the term functional safety, and this is where you have industry standards that define functional safety. I mentioned ISO 26262 earlier, which is the functional safety standard for automotive, and there's similar functional safety standards for, for other segments. Essentially, a safety-critical system is one where if something goes wrong, something bad will happen. I'm speaking very simplistically, but could cause harm, harm to the people involved or the environment around you. So think of systems, if we talk automotive just for a minute, think of systems such as lane keep assist, adaptive cruise control, lane departure warning, driver monitoring systems, and the number of safety systems in the car keeps growing....
whether it's an automated system or talk autonomous, if you want, but these are systems that are there today to assist the driver, to assist in the safe operation of the vehicle. That would, say, be a characteristic of the of safety-critical systems in the vehicle. Non-safety-critical systems in the vehicle could be something like, for instance, maybe your infotainment system. That does not have a safety requirement. It's not, it doesn't impact the safe operation of the vehicle. From a QNX perspective, what we've done is we take our software development tools and our operating system and our hypervisor, and we deliver safety-critical versions of that software and development tools and non-safety-critical certified versions of that software.
Now, what we've done from a product strategy perspective, which is very different than what you'll see out there from others, is that we use, it's a common operating system, with common interfaces to the operating system and common development tools. In other words, we take our, our standard operating system with all of the APIs, or our non-safety certified operating system, with all of the programming interfaces and development tools, and we bring that through the safety certification process. Why that's really important is if we think of where the automakers are, are, are going, is everybody's trying to adopt a platform approach. I'll use the word platforming, for instance. In other words, have common foundational software across the vehicle.
Well, the best way to do that is to make sure that the software, the foundational software you're using and the development tools you're using, can be common, whether it's a safety-critical environment or a non-safety-critical environment. By virtue of the investment we make, and that's extra overhead on us, because what we do is, for instance, we'll do safety impact analysis on our non-safety certified software, just like we do on the safety-certified software. Yes, more overhead for us, but a tremendous benefit for our customers, 'cause they can adopt a common platform approach, which, again, is where automotive is trying to go to and is starting to go that way, again, so they can build on that platform to provide the value to customers or cost reduction and, and whatnot.
Curious, who your key competitors are. I think it's clear that Apple CarPlay would sit on top of you as a non-safety critical, right? Android Auto, but doesn't Android Auto also have aspirations to do what you do as well? If you don't win an award, who might you lose it to?
Good question. Really, the way I try to characterize it is there's sort of the safety-critical systems in the vehicle and there's the non-safety-critical systems in the vehicle. In the safety-critical side, if there's any degree of complexity, we typically win. Back to my complexity is our friend, and we've been dealing with that for many, many years. We typically win in the safety-critical environments, where there's a level of complexity in the vehicle and elsewhere. In the non-safety systems, in vehicles, for instance, that's where you'll pretty much see us or Linux. That's generally what you'll see, and we'll compete head-to-head with Linux and any other OSes that are out there from a non-safety-critical perspective. Again, where we can provide added value is that platform approach, safety to non-safety.
The other thing I should, I should mention as well, in case you didn't notice, we made an announcement in May about our QNX Eight operating system, and the focus on QNX Eight is to keep all the goodness of the architecture that we have, which is a microkernel architecture and whatnot, but with a laser focus on performance and scalability. Because if you think about where automotive's going, and even beyond automotive, they're looking to adopt more high-performance multi-core systems, whether it's 16 core, 32 core, and so on. What we've done is, for the last few years, kept it very quiet, but we've been doing a lot of research and prototyping of our microkernel, and we made some surgical changes to the microkernel such that it'll be the most performant OS we've ever released.
It, it will scale almost one-to-one with the number of cores in the system, and that's exactly what our customers are looking for. That's what our silicon partners, who we work very closely with, are looking for. That'll allow us to go head-to-head with anybody on these high-performance systems.
Maybe you could describe, too, what's meant by a hypervisor? It's been a while, but I think Harman used to talk about, you know, the ability to run a safety-critical and a non-safety-critical, maybe on some of the same so-called multi-domain controllers or hardware, because they're able to segregate it via some sort of a software hypervisor. I don't know what any of this means, so maybe you can?
Really? I was gonna say-
Yeah
you've done your homework, for sure.
I just remembered that.
That's a really key point. We have virtualization technology. You'll hear the term hypervisor, and again, think of it as a foundational layer, and what the hypervisor can do is it can actually run multiple different operating systems above it. It could, for instance, run QNX in what's called a virtual machine. It could run a safety-certified version of QNX in a virtual machine. It could run Android in a virtual machine. It could run Linux in a virtual machine. Where this becomes very important, and you touched on it, the notion of mixed criticality. If you think of the, actually the digital cockpit in the vehicle, I mentioned earlier, infotainment is not a safety-critical environment. The digital instrument cluster and portions of the cluster, such as the telltales, and the PRNDL, for instance, and whatnot, those do have a safety requirement.
We have a hypervisor, and you've seen many announcements about our hypervisor and a number of wins we have in the market. With our hypervisor, we're able to have a safety-certified hypervisor and segregate infotainment from non-infotainment. Non-infotainment could be your instrument cluster, could be multifunction displays, for instance, and to your point, be able to support that with, say, Android, running infotainment. We work very closely with Google to the point where we can run Google Android out of the box, binary unchanged. With our hypervisor. It's not just about the hypervisor itself, it's also about there's something called VirtIO, that it's an industry standard that allows you to share access to hardware.
At the end of the day, there's still one CPU, there might be one Ethernet controller, and you need to, you need to manage the access to that in a safe way. We've brought our-- not only our operating system through to the highest level of certification, ASIL D, as in Delta, for ISO 26262, we've also brought the hypervisor and certified it through to the highest level, to ASIL D as well. We've also certified some of our shared frameworks or VirtIO that I mentioned. We recognized years ago that having safety-critical, safety-certified versions of our software is extremely important. We also recognized that extending that to the hypervisor, which is really an extension to our operating system, taking that through safety certification is also very important.
One note on safety certification, it's not just about the software, the ones and zeros. It really is about that, yes, but also your culture and your approach to software and the mindset. You have to always keep in mind what you're doing could have safety-critical impact. Very much from a culture perspective, you can't just throw software people at safety-critical software, arguably any complex software, and expect a positive result. It has to be wired into your culture, and that's something, again, that we, that we decided many years ago and continue with today. I notice there's a question. I'm not sure if we're taking live questions afterwards.
No, we are. We are.
Thank you for the presentation.
Okay.
This is super helpful. Maybe two questions.
Yeah.
First one, who actually do you deal with? Is it OEMs or the Tier 1 suppliers for these systems?
Mm-hmm. Okay.
Secondly, when you talk about, the domain controllers, we know Aptiv has SVA, and Aptiv is also a partner for you.
Mm-hmm.
How does that work? Similarly, is Mobileye also a competitor for you?
Okay, good question. With respect to Tier 1s and OEMs, so that's been a shift that we've seen in the industry. Traditionally, our direct customers were mostly the Tier 1s, and we would work very closely with the OEMs, primarily in the research teams and whatnot. I'm going back many years now. What we've seen in the, in the industry, the shift that we've seen occur, is the OEMs are investing more in software, are building up their software capabilities. They realize that there's value to be had in software and connected services. What we've seen now is that we are, effectively not only engaged with the OEMs directly, even more, that we're actually supplying to the OEMs directly, both software and services. That's contractually and whatnot.
Our customers remain Tier 1s, absolutely, 'cause some systems, the, the OEM will pursue, I'll say, the more traditional model of working through the Tier 1s. Whereas other systems, other wins that we'll have, especially when you deal with OEMs that are looking at more of a platform approach. They realize that to adopt a platform approach successfully, it's a, it's an environment where the OEM really has to be more in control. We work a lot more with the OEMs today than we ever have, both from an engineering perspective and a business perspective, and you've seen many announcements from many OEMs around investing more in software. That's, was the first question. Second question, I'm trying to remember, was SVA?
Yeah.
Sorry?
SVA and Mobileye.
Yeah, Aptiv is a customer of ours, has been a long-time customer of ours. SVA is an architecture that they put forward, obviously, for the software-defined vehicle, and obviously, they can tell you a lot more about that, a lot much more about that, more so than, than I can. They, they remain a customer, and as I mentioned, at the end of the day, they're a customer, our OEMs are customers, other Tier 1s are customers, and obviously, they'll all make the right decisions for the right reasons as it pertains to which foundational software that they'll make use of. Tim, I don't know if you wanted to add at all to that.
No, I think that, that covers it.
Yeah.
That's good.
Yeah. Yeah, Mobileye, you know, traditionally you know, provided a system in the vehicle, and they, they're adopting more of a, a platform approach, for instance, and whatnot. As I said, today, Mobileye is not a customer of ours. However, you know, who knows what the future holds, as they say?
Oh, okay. First question, just to put this in context, can you tell us what % of BlackBerry's profits you represent today, and what you think you're gonna represent, say, in five years, if you've given that sort of information? Then the second question, just very simply, just to elaborate on that: so where does Wind River fit with what it is that you do? Because we hear a lot about that. Yeah, you take it.
Yeah, okay. Thank you for the question. We don't actually break out the bottom line by BU, but we do give the gross margin by business unit. QNX sits within the IoT division or business unit, and it's running in the low 80%. Not to diminish Grant's role, but in terms of the roadmap, the product roadmap, is very much informed by what the auto industry is after. We can be quite targeted in terms of the development of our products. We work with pretty much everyone in the industry, and we're in 235 million-plus vehicles. We can be sort of fairly lean in some of the OpEx areas as well.
By implication, I think you could, you could derive that, QNX is a, is a fairly robust, business at the bottom line, but we don't give specific numbers around that.
Yeah, I, we, yeah, we just don't break that out. It's something we, we could, we could look at in the future.
Okay. Well, earlier in the year, didn't, didn't BlackBerry say that they were, you know, exploring the potential to separate some of their-- one or more of their?
Yeah
-businesses? Grant, you mentioned you've been at QNX for, like, 18 years.
A while.
So it was a standalone company, is that right? Then it was bought by Harman and then sold to BlackBerry. Is that the history?
Yeah.
It has been standalone. Could, could it be standalone, again?
Yeah. We were private from 1980 to 2004, when we were acquired by the automotive division of Harman, and then we were acquired in 2010 by BlackBerry.
Hmm.
Yeah. Beyond that, I'll let Mr. Foote comment.
Yeah, I mean, no, thank you for bringing up the, the review. I mean, there's only a limited amount I can say, Ryan, in terms of a process that's ongoing, but clearly, we've, we've got a strategy which involves top-line growth, delivering operating leverage, and producing a, a much stronger EPS and cash flow going forward. We've given some outlines on, on how we see that. We think we're gonna achieve breakeven in the Q4 of this current fiscal. Then moving into the next fiscal year, we move into EPS positive and cash flow positive.
However, we're not unaware of where the, the stock price is at, and ultimately, the fact that we've got 2 BUs that, in the very short term at least, have got a different customer base, different technology set, and there may be opportunities to deliver more shareholder value quicker. To that end, the board and the management have undertaken, they've engaged with Morgan Stanley and Perella Weinberg, and we're just exploring other opportunities at this point. We've given an outline that we expect that process to be done, certainly by the end of summer. Take that to be...
What % is automotive of QNX's revenue?
Broadly speaking, it's an 80/20 split, 80 being the auto side of things, and then 20 being the general embedded market. As Grant was mentioning, like, many of these safety-critical applications, they apply just as much in medical and industrial, rail. There's a whole heap. I'd say the difference being is when you get into that general embedded market, it becomes a lot more fragmented. You get very few OEMs that are making 5 million units of anything, when you move into these type of markets.
Is it that, there's a couple roles for QNX in the cars? Is it that you're, like, some sort of foundational software, but then also, do you get used for infotainment application, or?
For, for QNX, it's primarily the foundational software, and then some, I'll call it some middleware, that builds on the foundational software. In infotainment, we're seeing a trend towards, Google Android-
Mm-hmm
... and derivatives of that. Again, we work very closely with Google to make sure that that's all tightly integrated and, and supported and whatnot. Again, out of the box with our hypervisor and our virtualization, tech. Excuse me, that's where we still, we still have systems in infotainment. We still have wins in infotainment, and we absolutely dominated infotainment years ago. If you think about infotainment just for a minute, at that time, it was absolutely the most complex system in the vehicle, had absolutely the most software in the vehicle, in a system, and absolutely the most, suppliers into that system. Again, back to, you know, what I was referencing earlier, where complexity is our friend. It's our friend 'cause we know how to deal with it.
It took many, many, many years to develop that expertise and the processes and whatnot to deal with that. Historically, when you'd hear the 100 million lines of code in a car, which is obviously the popular number, that was advertised for many years, most of that, most of those lines of code were in the infotainment system. Again, we, we were quite successful in that area. Today, it's starting to shift to the digital cockpit, and this is where you'll see Android, you'll see QNX, you'll see our acoustics, you'll see our middleware, our hypervisor and whatnot. You mentioned earlier Wind River and VxWorks and whatnot.
To be honest, we don't see them much in automotive, where we do see them, and I'm here representing IoT, is we do see them in, you know, industrial and medical and other environments. In automotive, as the systems have become more complex, really don't see them much anymore.
Just in, in terms of your relationship with the OEMs, are you, are you involved to the point of silicon design?
Design-
Are you, like, embedded? You know, is the relationship and the tech so embedded that you're now being involved in the silicon design as the OEMs take on that actual silicon design themselves and ownership of that silicon design?
Okay, you're using the word design, and I wanna be careful how I answer the question. We work extremely closely with the silicon vendors in automotive. It's not just about running on those platforms. It's about very tight integration, optimizing where they've added, I'll say specific value, specific things that they've done, such as accelerators and whatnot. Again, out of the box, you will see things like Snapdragon Ride, as an example, that's pre-integrated with QNX. When an OEM receives that platform with QNX, with our hypervisor and other software, it's all pre-integrated. NVIDIA DRIVE OS, for instance, is yet another example where QNX is integrated. Quote, unquote, "out of the box," you will see a tight integration and optimization and ongoing roadmap, very tightly coupled between ourselves and the silicon vendors. That's just a couple examples. I mean, there are others.
Extremely important, especially again, as you think about the type of software that, that we provide. We are in absolute lockstep with the silicon vendors, and to your point, we work very, very closely with the OEMs. With regard, we, again, we, we pride ourselves on staying in our lane. We provide the expertise that we can. As I mentioned, we're always learning, but we work very closely with silicon vendors, the OEMs, the Tier 1s. Again, we can provide that enabling software for them, and over a long period of time.
Simon? Yeah.
Yeah, thanks for taking the time for the presentation. Just want to understand with that shift, from more decentralized architectures to more of a centralized architecture. We've seen a couple of different executives today talk about how the car is more and more becoming a phone on wheels. Can you help us think about, like, what, like, how fast this market is growing? Like, to roughly contextualize it, whether it's single digits or like 20, 30, 50, how should we think about it?
I'll answer from a software architecture perspective. I mean, the market numbers, there's many people that are putting out number of market numbers out there in terms of number of vehicles and whatnot. I'll just state, as Amit said earlier, automotive is very evolutionary. Don't buy into the hype, for instance. Again, it's a one-ton, two-ton critical device that has to work reliably, and that now is adopting connectivity. All of a sudden, security becomes even more important, and to defend against attacks, which is why you're seeing the security standards, for instance, with some real teeth to them, appear in automotive. Definitely evolutionary. Today you're seeing the move from the traditional architecture to adopting domains, and I mentioned digital cockpit as being the first one. You're seeing consolidation of ADAS systems.
What used to be discrete systems into a single system, which is more complex, which again, is where we provide a lot of value. You'll see that evolve into, say, multiple domains, perhaps a zonal architecture, and you're seeing multiple, multiple examples of zonal architecture. As I mentioned, then you'll hear the term central compute, which again, is I won't say a step up, but an even more high-performance system that you'll see in the vehicle. Very evolutionary, will take many years to occur. As I said, beyond... it, for us anyways, it represents even more of an opportunity.
The net-net is it's more systems in the car where we can run our software, as the foundational elements to them, and more data in the car, which is where BlackBerry IVY comes in, for instance, where it can actually work with the data, normalize the data, provide common interfaces to the data such that OEMs can now scale and build out a developer ecosystem and add value at that level as well. That's completely above the QNX layer, the foundational software layer.
You still do some infotainment, and you compete against Android Auto there, but does Android Auto also have aspirations to do foundational software, too?
There's Android Auto, which is essentially software that will run on your, on your mobile phone, and then there's what's called client software that runs in the vehicle, and that will run on top of QNX, will run on top of our hypervisor. There's Android Automotive OS. That runs in the vehicle, and that's where you'll see the Android stack for infotainment, perhaps. Either one of those are 100% complementary to what we do.
If it's Android Automotive OS and infotainment, that's where you'll see our hypervisor and acoustics and virtualization and whatnot. If it's Android Auto, we've supported Android Auto forever, as well as CarPlay. I mean, since even before they were released.
Interesting.
We think so. We think so. It's pretty exciting. As I mentioned, we're in the plumbing of the vehicle, and whatnot, and, and quite proud of it. I've really enjoyed working with QNX, the customers, BlackBerry, I mean, it's been great, and for, for us, really, it's, again, more systems in the car, more software in the car, and really enabling that, that evolution of the vehicle.
Why did BlackBerry purchase QNX? Was it to, to run the operating system for their phones? You know, is it, is it critical for them, for, for BlackBerry to, to own QNX? How, how, how's the relationship there?
Going back a few years, but to 2009, 2010, they had BBOS 7 at the time, and yes, we were absolutely acquired, for, to, to be the next generation BlackBerry operating system or, or, BlackBerry 10 for the handsets at the time, for the BlackBerry PlayBook at the time, while at the same time being able to serve our other markets, which obviously, you know, we've done very successfully. Originally, yes, we were acquired to be that, that next generation operating system, BlackBerry 10. Maybe there'll be a part 2 to the movie, I don't know. We'll see. Yes, that was the original impetus for the, for the acquisition.
Okay, great. It looks like we've run out of time. Please join me in thanking Grant and Tim.
Thank you.
Thank you. Thanks, Ryan.