[Troy Tiscareno]

Who's there?

[i_plod_an_dr_void]

Dang! Thought it was "Who's there", not "Who is it? Who?"...and I can't even blame mind-altering things for that.

[Richard Buckley]

Yes that is all true. Yet BB10-like running over QNX absolutely could. BB10 running on top of a RTOS QNX kernel didn't make for a good user experience? Of course it did. BB10 already plays nice with QNX, can't see why the brains or at least some of the functionality can't eventually make it to the smartphone itself instead of onboard. Unless you can prove it requires magnitudes of order more processing power than the next/gen smartphone chip won't be able to rise to - due to powersipping requirements. However the point is, it doesn't necessarily have to house "all" of the autonomous functions (it might handle some), it clearly could handle the existing requirements of battery/electric/combustion engine cars today and for the foreseeable future and likely some of the autonomous functions...and not sitting in the extreme temperature environment of the engine compartment while powered off, gives it some possible engineering simplification. It could even conceivably have reduced scheduling or even restricted functionality while operating the vehicle (like maybe no background updates for certain apps that don't make sense running while driving a car - where the "while-driving" becomes one of those bb10/dtek or built-in permission settings......and maybe, or maybe not adverts visual or audio for occupants.). Maybe it replaces the fm radio as well in these cars (not woofers and speakers)....not sure if they add "am" receiver into the existing SOC devices or not....climate control etc...

If I had a nickle for every time I had to deal with someone who thought the key to real time performance was more (or sufficient) processing power I would have been able to buy BlackBerry and keep BB10 in production.

Some of what you are describing, providing audio entertainment sources, trip guidance are already built into Android Auto and Apple Car Play. Even systems built before those were available like my 2013 Mitsubishi and 2014 Buick can do some of those things. Even supplanting the speaker systems in the vehicle is feasible.

But solving hard real time problems is not simply a matter of throwing more processing power at it. In fact many hard real time problems are more easily solved by throwing less processing power at them. A simple time invariant feedback loop system like anti-lock breaking could be performed by a software written to run on a smart phone. It would be quite easy to do since an ABS system needs only thousands of calculations per second and even relatively old SOCs are capable of doing a million times more calculations per second. The problem is guaranteeing that the calculations get done in time. That means that the ABS software has to be locked into memory and provided a guaranteed execution time slot. You are right QNX, even with BB10 running on top can can do this. Unfortunately if you have 8 cores and get to a point where 8 processes have to be executing at a given time then the system is completely committed. If you have to add a 9th process to that time slot then one of them will have to be late, which in hard real time can have similar, or even worse, consequences as failing. It doesn't matter that you still have billions of CPU cycles unused. However using a much lower performing processor dedicated to a fixed number of tasks related and interlocked tasks can do a better job.

What you can do with the billions of unused cycles and a good RTOS like QNX is use them to run Android Auto, Apple Car Play and a generic infotainment system without detracting from the real time needs of operating the vehicle. That can support not just the driver's smart phone, but all the passegers' phones as well. The future of autonomous vehicles does not lie in moving the processing to a portable device, which will always be more limited than what can be built into the vehicle and disappear from the system by simply being dropped out the window. It lies in using the "left over" cycles to provide a richer experience to all the occupants of the vehicle just like all the other options like air conditioning, leather seats, heated/cooled seats, high end stereo etc. provide. And that's why it is exactly what we are seeing from car companies.

[i_plod_an_dr_void]

If I had a nickle for every time I had to deal with someone who thought the key to real time performance was more (or sufficient) processing power I would have been able to buy BlackBerry and keep BB10 in production.

Some of what you are describing, providing audio entertainment sources, trip guidance are already built into Android Auto and Apple Car Play. Even systems built before those were available like my 2013 Mitsubishi and 2014 Buick can do some of those things. Even supplanting the speaker systems in the vehicle is feasible.

But solving hard real time problems is not simply a matter of throwing more processing power at it. In fact many hard real time problems are more easily solved by throwing less processing power at them. A simple time invariant feedback loop system like anti-lock breaking could be performed by a software written to run on a smart phone. It would be quite easy to do since an ABS system needs only thousands of calculations per second and even relatively old SOCs are capable of doing a million times more calculations per second. The problem is guaranteeing that the calculations get done in time. That means that the ABS software has to be locked into memory and provided a guaranteed execution time slot. You are right QNX, even with BB10 running on top can can do this. Unfortunately if you have 8 cores and get to a point where 8 processes have to be executing at a given time then the system is completely committed. If you have to add a 9th process to that time slot then one of them will have to be late, which in hard real time can have similar, or even worse, consequences as failing. It doesn't matter that you still have billions of CPU cycles unused. However using a much lower performing processor dedicated to a fixed number of tasks related and interlocked tasks can do a better job.

What you can do with the billions of unused cycles and a good RTOS like QNX is use them to run Android Auto, Apple Car Play and a generic infotainment system without detracting from the real time needs of operating the vehicle. That can support not just the driver's smart phone, but all the passegers' phones as well. The future of autonomous vehicles does not lie in moving the processing to a portable device, which will always be more limited than what can be built into the vehicle and disappear from the system by simply being dropped out the window. It lies in using the "left over" cycles to provide a richer experience to all the occupants of the vehicle just like all the other options like air conditioning, leather seats, heated/cooled seats, high end stereo etc. provide. And that's why it is exactly what we are seeing from car companies.

The question of processing power was more in line with the question of the size of code and cycles needed for autonomous systems (if some or all of the functionality is offloaded to the phone- can it handle it), so I should have included system ram and memory space on that point, and how much of the cpu cycles it would require and possibly bandwidth requirements. Not sure and I don't think the auto needs hardware implemented 1:1 core to dedicated critical processes of the QNX RTOS.

I still don't see the point of on-board entertainment cpu/and other vehicle operational processing, if the processing can all be offloaded to the phone (with the exception of the large touch screen). If a significant portion of drivers carry smartphones, might as well put them to good use in the car, plus some benefits to the auto-manufacturer to having performance stats updated periodically....or upgrades/ software "recalls" OTA/wifi easity performed.

The fail-safe of one process not tripping over the other is the microkernel QNX design advantage with memory protected processes, making it more safety certifiable, and theoretically tamper proof by another misbehaving process that might happen to be running, especially on the entertainment/non-critical apps side.

No need to have a dedicated device to support all occupants phone's in a vehicle...again that is likely redundant. A driver's phone as the operator of the vehicle could in itself provide a supporting role to other phone's as well, if the assumption is that other occupants will be allowed to control infotainment/car comfort features of the vehicles individually as well.

Well the key can simply be dropped out of the car window as well, and the functionality of the car ceases - well except for the fact there are safety features that prevent this. No doubt a key/lock slot of some design would be required for the drivers cellphone as well (perhaps specific adapters for specific phone models)....as the controls would all be accessible from the infortainment screen...which would still be desireable to be in the vehicle.
...unless of course its a budget model, in which case only the phone itself becomes the interface and there would be no additional touchscreen. Though perhaps the console touch screen might be portable/detacheable in the car as well....if the occupant in the back seat is watching a video/browsing the web/using an app etc......and if they break it or throw it out the window....well the automaker can sell them a replacement. Same for the smartphone - though a cracked glass should still probably allow for the vehicle to operate if the display of the phone gets toasted. I suppose there could be a dead mode and live mode to the phone...where in dead mode it only operates the basic vehicle, and live mode allows it to have near full functionality, and dead mode could be enabled to allow vehicle use without passcode, thumbprint etc if enabled.
Yes phase one of the "smart-car" is as you describe. I see this convergence of smart-car/dumb-car/electric car/combustion engine car and smartphone as phase two, which BB is uniquely qualified to capture....maybe Elon might be interested as well. Perhaps some markets might embrace and others resist, but there is clearly a potential - definitely fleet vehicle management (similair to radar), for corporate fleets light-vehicles, rentals-maybe etc.

[PwrSurge]

The Hub in BB10 is far superior to the Hub in Android and navigating around the OS still feels smooth.

All that being said, I cannot possibly use a BB10 device as a daily driver for the simple fact that my work no longer supports BB10 (nor BBOS) and the apps I need for my personal life and more importantly, my professional life, just aren't there.

Which apps are those?


Posted via CB10

[conite]

Which apps are those?


Posted via CB10

How much time do you have? Would you like the listed sorted alphabetically, or by category?

[glwerry]

Which apps are those?


Posted via CB10

He is not alone.
For me it was the Google apps, but especially Hangouts. Our corporation uses dual-factor authentication and I was simply not able to get this working with the Cobalt-patched environment.
I tried using the web-based hangouts but it just wasn't workable.

So, I bade farewell to BB10 and moved to The 'Droid (PRIV). Life is still great over here in 'Droidland.

[Richard Buckley]

The question of processing power was more in line with the question of the size of code and cycles needed for autonomous systems (if some or all of the functionality is offloaded to the phone- can it handle it), so I should have included system ram and memory space on that point, and how much of the cpu cycles it would require and possibly bandwidth requirements. Not sure and I don't think the auto needs hardware implemented 1:1 core to dedicated critical processes of the QNX RTOS.

I still don't see the point of on-board entertainment cpu/and other vehicle operational processing, if the processing can all be offloaded to the phone (with the exception of the large touch screen). If a significant portion of drivers carry smartphones, might as well put them to good use in the car, plus some benefits to the auto-manufacturer to having performance stats updated periodically....or upgrades/ software "recalls" OTA/wifi easity performed.

The fail-safe of one process not tripping over the other is the microkernel QNX design advantage with memory protected processes, making it more safety certifiable, and theoretically tamper proof by another misbehaving process that might happen to be running, especially on the entertainment/non-critical apps side.

No need to have a dedicated device to support all occupants phone's in a vehicle...again that is likely redundant. A driver's phone as the operator of the vehicle could in itself provide a supporting role to other phone's as well, if the assumption is that other occupants will be allowed to control infotainment/car comfort features of the vehicles individually as well.

Well the key can simply be dropped out of the car window as well, and the functionality of the car ceases - well except for the fact there are safety features that prevent this. No doubt a key/lock slot of some design would be required for the drivers cellphone as well (perhaps specific adapters for specific phone models)....as the controls would all be accessible from the infortainment screen...which would still be desireable to be in the vehicle.
...unless of course its a budget model, in which case only the phone itself becomes the interface and there would be no additional touchscreen. Though perhaps the console touch screen might be portable/detacheable in the car as well....if the occupant in the back seat is watching a video/browsing the web/using an app etc......and if they break it or throw it out the window....well the automaker can sell them a replacement. Same for the smartphone - though a cracked glass should still probably allow for the vehicle to operate if the display of the phone gets toasted. I suppose there could be a dead mode and live mode to the phone...where in dead mode it only operates the basic vehicle, and live mode allows it to have near full functionality, and dead mode could be enabled to allow vehicle use without passcode, thumbprint etc if enabled.
Yes phase one of the "smart-car" is as you describe. I see this convergence of smart-car/dumb-car/electric car/combustion engine car and smartphone as phase two, which BB is uniquely qualified to capture....maybe Elon might be interested as well. Perhaps some markets might embrace and others resist, but there is clearly a potential - definitely fleet vehicle management (similair to radar), for corporate fleets light-vehicles, rentals-maybe etc.

Well then, I look forward to test driving a car that has part of its driving process done in a smart phone in the near future.

LeapSTR100-2/10.3.3.2205

[Dunt Dunt Dunt]

I still don't see the point of on-board entertainment cpu/and other vehicle operational processing, if the processing can all be offloaded to the phone (with the exception of the large touch screen). If a significant portion of drivers carry smartphones, might as well put them to good use in the car, plus some benefits to the auto-manufacturer to having performance stats updated periodically....or upgrades/ software "recalls" OTA/wifi easity performed.

The fail-safe of one process not tripping over the other is the microkernel QNX design advantage with memory protected processes, making it more safety certifiable, and theoretically tamper proof by another misbehaving process that might happen to be running, especially on the entertainment/non-critical apps side.

No need to have a dedicated device to support all occupants phone's in a vehicle...again that is likely redundant. A driver's phone as the operator of the vehicle could in itself provide a supporting role to other phone's as well, if the assumption is that other occupants will be allowed to control infotainment/car comfort features of the vehicles individually as well.

.

Sound just like the argument for the PlayBook.... why build a full tablet when most users will have a smartphone anyway.

I read an article about one of Tesla's smart-cars.... it had over 65 "processors" in it. Why, because most cars are made up of components built buy other companies, each with their own patents and "IP" to protect and each responsible for providing a complete "system". While it might be possible to have one processor do all these calculation, it really just not practical. Besides processors aren't really that expensive.... Cost is more in the licensing of IP (for ABS, Window Heaters, Flashers, AC Controls.....) and in the development of the software. Why build in those cost to a phone, if it might not even be used ?

[Richard Buckley]

...

I read an article about one of Tesla's smart-cars.... it had over 65 "processors" in it. Why, because most cars are made up of components built buy other companies, each with their own patents and "IP" to protect and each responsible for providing a complete "system". might not even be used

That and if you count all the CAN bus nodes, they add up pretty quickly.


LeapSTR100-2/10.3.3.2205

[Emaderton3]

How much time do you have? Would you like the listed sorted alphabetically, or by category?

I don't understand why someone has to justify it when they say they can't get the apps they need on BB10.

[bb10adopter111]

I don't understand why someone has to justify it when they say they can't get the apps they need on BB10.

The point is that there are way too many to count. BB10 is a poor choice for Android apps in 2017+. There have been solid work around in the past, but, at the end of the day, the Android runtime is simply too old. I live my BB10 phones, but I don't try to run Android apps anymore on them. In use an Android phone for those (rare) occurrences.

Posted with my trusty Z10

[Emaderton3]

The point is that there are way too many to count. BB10 is a poor choice for Android apps in 2017+. There have been solid work around in the past, but, at the end of the day, the Android runtime is simply too old. I live my BB10 phones, but I don't try to run Android apps anymore on them. In use an Android phone for those (rare) occurrences.

Posted with my trusty Z10

Yes but some people still don't believe that!

[i_plod_an_dr_void]

Sound just like the argument for the PlayBook.... why build a full tablet when most users will have a smartphone anyway.

I read an article about one of Tesla's smart-cars.... it had over 65 "processors" in it. Why, because most cars are made up of components built buy other companies, each with their own patents and "IP" to protect and each responsible for providing a complete "system". While it might be possible to have one processor do all these calculation, it really just not practical. Besides processors aren't really that expensive.... Cost is more in the licensing of IP (for ABS, Window Heaters, Flashers, AC Controls.....) and in the development of the software. Why build in those cost to a phone, if it might not even be used ?

No, my argument is just the opposite of the playbook, why have two devices with a lot of overlap, when one can provide the function of both. The playbook was dealing with a totaly different market segment, from the smartphone alone....few people rely on SMartphones for their complete browsing usage in more developed markets for example.

The codebase in the near past of a car Chevy volt was like 10million lines (including entertinment functions onstar etc (if online reports are correct, and these figures do seem to be disputed - )Autonomous? something like 100million lines of code. Smartphone? somewhere around 15million+user installable apps......so we're talking maybe the same order of magnitude.
65processors? Circuits? or Processors? Lets see ECM., Transmission, Engine, ABS, OBDII , ignition, fuel delivery system? sensors, instrument cluster? climate control? miscellaneous electrical, then the biggies of Entertainment centre, and maybe Autonomous driving function (which if anything require more sensors). What major 'processors' am I missing? Battery management for electric?
IP holders don't particulary care where (what platform) the code is stored, on-board computer or the embedded smartphone, as long as it is robust, provided I imagine it is protected (Wink to QNX /BB10x). I think they'll do what the automaker wants done. Don't know how 'safe' the code of current multiple devices are currently . Obviously the automaker absorbs the costs, and the savings, and the engineering benefits of the easy access black-box and more functionality of the BB-10x Transport (or is that Ignition phone, or the bb10 Driver phone (lol) phone, and the user benefits from and experiences the enhanced functionality.

Again the Entertainment and Ignition and Security lock of the car totally doable through the smartphone. The others maybe as well. Two cars? Well there's a phone for each as there currently is a key for each and multiple cpu's for each. For your personal apps, sure synch the two or don't your choice. No problem again.

If you don't own a car, fine you don't need the Ford F150 or the Chevy Volt or the Dodge Grand Caravan app for your smartphone. But if you do....voila it comes with the car, and if you byod (certified devices only) I'm sure there's a small discount in the price of the vehicle.

[donz88]

I'm behind you, sir....

Posted via CB10 via awesome  Passport SE.

[i_plod_an_dr_void]

and If a smartphone can be a tuberculosis detector...proof of concept....
https://asunow.asu.edu/20171025-solu...tious-diseases
.... why can't a QNX based bb10x be your secure daily driver (literally car driver)

[conite]

and If a smartphone can be a tuberculosis detector...proof of concept....
https://asunow.asu.edu/20171025-solu...tious-diseases
.... why can't a QNX based bb10x be your secure daily driver (literally car driver)

Just sounds like an additional and unnecessary failure point.

[app_Developer]

Just sounds like an additional and unnecessary failure point.

I think the point is not to make the car safe or profitable or gain marketshare, the point is to stretch reality just enough to save the all-important BB10.

Maybe that could be the title slide to the presentation to Ford's BoD?

[Dunt Dunt Dunt]

and If a smartphone can be a tuberculosis detector...proof of concept....
https://asunow.asu.edu/20171025-solu...tious-diseases
.... why can't a QNX based bb10x be your secure daily driver (literally car driver)

No one is saying it can't be... just that they doubt car manufactures will want to do it as there would be very little cost savings and much more risk.

[i_plod_an_dr_void]

Just sounds like an additional and unnecessary failure point.

True. For some the enhancing of the Brain is just an additional and unnecessary failure point, given all those joints,organs,nervous system and fuel delivery conduits, and that power processing and waste managment systems.

[bobshine]

I don’t see car features coded into a smartphone and even less giving a free smartphone when you buy a car.

It’s like a while back, someone suggested that BB should sell smartphones in banks so it comes already comes with a bank card in it.

What I do see though is integration: look how slowly smartphones are starting to integrate into homes (homekit, google home), but also look how Apple is integrating its accessories (apple watch, ipad).

Basically you approach the car with your smartphone in your pocket and the car unlocks, adjusts seats and mirrors and displays your apps, playlist.

[bb10adopter111]

Why on earth should I need a phone to operate a car?

If we're being arbitrary, why not require a tennis racquet, a camera or a puppy?

I don't carry my phone with me when I don't have to. That would be a deal-breaker for me.

[Richard Buckley]

This was tried back in 2011 just putting the owners on a tablet seemed like a good idea to the geek in me, but it didn't sell and for many good reasons.

https://jalopnik.com/5829989/hyundai...r-luxury-sedan

LeapSTR100-2/10.3.3.2205

[Richard Buckley]

No one is saying it can't be... just that they doubt car manufactures will want to do it as there would be very little cost savings and much more risk.

I'm saying it won't happen.

LeapSTR100-2/10.3.3.2205

[Elephant_Canyon]

why not require… a puppy?

I, for one, wholeheartedly support this idea.