Sin A Car: Paul Leroux

Showing posts with label Paul Leroux. Show all posts

QNX, Renesas to integrate R-Car SoCs and QNX CAR platform

QNX, Renesas to integrate R-Car SoCs and QNX CAR platform

Paul Leroux This just in: QNX and Renesas today announced that they are integrating support for Renesas R-Car SoCs into the QNX CAR applica...

7:32:00 AM

Autonomous, not driverless

<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPI9R5JTdt8f_Ry79uqtwziv8H7RhE7h4-8jj5Fwvo5eMTii56luXWSbYBYEEXAHARqnLNh1faz_6U6_ZyEEMd7i8pWvCf8zs-ucTDpGkQhgXNcB9BJGaVuH5zZoto6kethLv8bdXLK_w/s1600/paul_leroux_photo_crop_v3_thumb.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPI9R5JTdt8f_Ry79uqtwziv8H7RhE7h4-8jj5Fwvo5eMTii56luXWSbYBYEEXAHARqnLNh1faz_6U6_ZyEEMd7i8pWvCf8zs-ucTDpGkQhgXNcB9BJGaVuH5zZoto6kethLv8bdXLK_w/s1600/paul_leroux_photo_crop_v3_thumb.jpg" /></a></td></tr><tr align="center"><td class="tr-caption">Paul Leroux</td></tr></tbody></table>I don't know about you, but I'm looking forward to the era of self-driving cars. After all, why spend countless hours negotiating rush-hour traffic when the car could do all the work? Just think of all the things you could do instead: read a novel, Facebook with friends, or even watch Babylon 5 re-runs. Unlike Babylon 5, this scenario is no longer a page out of science fiction. It’s coming soon, <a href="http://qnxauto.blogspot.ca/2012/12/volvo-to-ship-self-driving-cars-in-2014.html">faster than many imagine</a>. That said, the story of the self-driving car still has a few unfinished chapters — chapters in which the human driver still has an important role to play. Yes, that means you. As I’ve discussed in <a href="http://qnxauto.blogspot.ca/2012/07/future-of-self-driving-car-aint-what-it.html">previous posts</a>, the fully autonomous car is a work in progress. In fact, some of the technologies that will enable cars to drive themselves (adaptive cruise control, forward collision avoidance, etc.) are already in place. Moreover, research suggests that these technologies can, among other things, <a href="http://qnxauto.blogspot.ca/2012/09/will-adaptive-cruise-control-spell-end.html">improve traffic flow</a> and <a href="http://qnxauto.blogspot.ca/2012/07/will-autonomous-car-tech-save-your-life.html">reduce accidents</a>. But does that mean you will soon be able to sit back, close your eyes, and let the car do everything? Not quite. Evolution, not revolution If you ask me, <a href="http://www.wired.com/opinion/2013/01/forget-the-internet-of-things-here-comes-the-internet-of-cars/">Thilo Koslowski</a> of Gartner hit the bull's eye when he said that self-driving cars will go through three evolutionary phases: from automated to autonomous to unmanned. Until we reach the endpoint, we should pay heed to the words of <a href="http://www.usatoday.com/story/driveon/2013/01/07/audi-toyota-driverless-cars/1815399/">Toyota's Jim Pisz</a>: autonomous does not mean driverless. <table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBaa1fpcHilPB1URKQlSj7PFIlhap3uH5QCcRdRdF8jdydMD4jkys4HOp9TthmsMZLltmaNa5UJd8lLZZXsX3rHCR_M8TNT9_bGPqeYP-IFQ_eZQzyM8020aD65i0yZCXP2cTZItyXfQo/s1600/jet_327_px.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBaa1fpcHilPB1URKQlSj7PFIlhap3uH5QCcRdRdF8jdydMD4jkys4HOp9TthmsMZLltmaNa5UJd8lLZZXsX3rHCR_M8TNT9_bGPqeYP-IFQ_eZQzyM8020aD65i0yZCXP2cTZItyXfQo/s1600/jet_327_px.jpg" /></a></td></tr><tr><td class="tr-caption" style="text-align: left;"><div style="text-align: center;">If planes can do it…</div></td></tr></tbody></table>Some folks hear this and are disappointed. They point to auto-pilot technology in planes and ask why we can’t have driverless cars sooner than later. The argument goes something like this: "It's much harder to fly a plane, yet we have no problem with a computer handling such a complex task. So why not let a computer drive your car?” If only life were so simple. For one thing, automakers will have to make autonomous cars affordable — doable but not easy. They’ll also have to negotiate a variety of legal hurdles. And in any case, driving and flying have less in common than you might think. When you drive, you must remain alert on a continuous basis. Lose your attention for a second, and you stand a good chance of hitting something or somebody. The same doesn't always hold true in flight. When a plane is cruising at 30,000 feet along a proscribed flight path, the pilot can avert his or her attention for 5 seconds and incur little chance of hitting anything. In comparison, a driver who becomes distracted for 5 seconds is hell on wheels. And, of course, auto-pilot doesn’t mean pilot-less. As Ricky Hudi of Audi <a href="http://ces.cnet.com/8301-34438_1-57563376/is-there-a-self-driving-car-in-your-future/">points out</a>, pilots may rely on autopilot, but they still retain full responsibility for flying the plane. So just because your car is on auto-pilot doesn’t mean you can watch YouTube on your tablet. Bummer, I know. An alarming solution <table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCaoqP3HuMqILfVSFL4bX9GJmuArh9U9kSUxgbaGcU8smIRVNunucbYQz7W7Y2mZu2Er8C6G84rf63b0pM6TvUHH0ZOxiInSV4YjZPPgMMF5913uj-YhhrbiY88h5BACN-BcWRedLr-8k/s1600/alarm_glasses_adas.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCaoqP3HuMqILfVSFL4bX9GJmuArh9U9kSUxgbaGcU8smIRVNunucbYQz7W7Y2mZu2Er8C6G84rf63b0pM6TvUHH0ZOxiInSV4YjZPPgMMF5913uj-YhhrbiY88h5BACN-BcWRedLr-8k/s1600/alarm_glasses_adas.jpg" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;"><div style="font-size: medium; text-align: start;"></div><div style="text-align: center;"><div style="text-align: left;">Source: <a href="http://blog.modernmechanix.com/">Modern Mechanix blog</a> (and yes, that should  read Frankfurt)</div></div><div> </div></td></tr></tbody></table>All of which to say, the driver of an autonomous car will have to remain alert most or all of the time — until, of course, autonomous vehicles become better than humans at handling every potential scenario. Now <a href="http://www.scientificamerican.com/article.cfm?id=autonomous-driverless-car-brain">that could happen</a>, but it will take a while. It seems that someone anticipated this problem in the early 50s when they invented “alarming glasses” — take a gander at the accompanying photo from the August 1951 issue of Modern Mechanix. Scoff if you will, but a kinder and gentler form of this technology is exactly what autonomous cars need. No, I'm not suggesting that scientists find a better way to glue wires to eyelids. But I am saying that, until cars become fully and safely autonomous, drivers will need to pay attention — after all, it’s tempting to drift off when the car is doing all the work. And, indeed, technologies to keep drivers alert <a href="http://www.tobii.com/gaze-interaction/global/Gaze-Interaction-fields-of-use/advanced-driver-assistance/">are already being developed</a>. Pre-warned means prepared Mind you, it isn’t enough to keep the driver alert; the car may also need to issue “pre-warnings” for when the driver needs to take over. For instance, let’s say driving conditions become too challenging for the car’s autonomous mode to handle — these could heavy rain, a street filled with pedestrians, or an area where lane markers are obscured by snow. In that case, the car can’t wait until it can no longer drive itself before alerting the driver, for the simple reason that the driver may simply take too long to assess the situation. The car will need to provide ample warning ahead of time. The more, the better That cars will become autonomous is inevitable. In fact, the more autonomous, the better, as far I'm concerned. Research already suggests that technologies for enabling autonomous driving can, in many cases, do a better job of avoiding accidents and improving traffic flow than human drivers. They also seem to do better at things like parallel parking — a task that has caused more than one student driver to fail a driving test. But does this all mean that, as a driver, I can stop paying attention? Not in the near future. But someday.

Autonomous, not driverless

Paul Leroux I don't know about you, but I'm looking forward to the era of self-driving cars. After all, why spend countless hours ne...

6:34:00 PM

Using smartphones to prevent traffic jams

Using smartphones to prevent traffic jams

Paul Leroux Smartphones and driving don’t mix, right? Normally, you would get no argument from me. Driving is the one activity where a half-...

6:04:00 PM

The isolation imperative: protecting software components in an ISO 26262 system

<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjF70n8XEFXd-WCle6B_N5zb1HOWT6A2287uJL5IptS__jCjo-sMeLzRAv-qrES7Wnj9wEZiA4bLTxtEtJfmSDnchUPzbOIeuufEo685uCHndKAp_EbWo2F-A2ermk7zqXoap_GTGgnSh0/s1600/paul_leroux_photo_crop_v3.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="124" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjF70n8XEFXd-WCle6B_N5zb1HOWT6A2287uJL5IptS__jCjo-sMeLzRAv-qrES7Wnj9wEZiA4bLTxtEtJfmSDnchUPzbOIeuufEo685uCHndKAp_EbWo2F-A2ermk7zqXoap_GTGgnSh0/s400/paul_leroux_photo_crop_v3.jpg" width="87" /></a>Software components can be impolite, if not downright delinquent. For instance, a component might: <ul><li>rob other components of CPU time </li><li>rob other components of file descriptors and other system resources </li><li>access the private memory of other components </li><li>corrupt data shared with other components </li><li>create a deadlock or livelock situation with other components </li></ul> Shameful, I know. But in all seriousness, this sort of behavior can wreak havoc in a safety-critical system. For instance, let's say that a component starts to perform a CPU-intensive calculation just as the system enters a failure condition. Will that component hog the CPU and prevent an alarm process from running? The answer, of course, is that it damn well better not. It becomes important, then, to prevent components from interfering with one another. In fact, this principle is baked into the <a href="http://qnxauto.blogspot.ca/2012/10/the-iso-26262-functional-safety.html">ISO 26262 functional safety standard</a> for road vehicles, which defines interference as: <ul>"...the presence of cascading failures from a sub-element with no ASIL [Automotive Safety Integrity Level] assigned, or a lower ASIL assigned, to a sub-element with a higher ASIL assigned leading to the violation of a safety requirement of the element” </ul> To put it crudely, less important stuff can't stop more important stuff from happening. So how do you prevent interference? One approach is through isolation. For instance, a system may implement spatial isolation between application processes. This would include mechanisms for interprocess communication and interprocess locking that prevent one process from inadvertently affecting another. Mind you, there are multiple types of interference, so you need to implement multiple forms, or axes, of isolation. Time for a picture: <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhqXB2d5X4JJhti1Ph67QQmAb2Hd05LNAa3btIhcr6eHMPDLUjoDoWf3HrMEQxInso0iLhI1sM6G2zXrJpdIu80xyOij0PbeqfEo3Nsyd3K2NHL89TT25InUR9ltqO-w-ddW6vJHC1Yhlw/s1600/isolation_axes.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhqXB2d5X4JJhti1Ph67QQmAb2Hd05LNAa3btIhcr6eHMPDLUjoDoWf3HrMEQxInso0iLhI1sM6G2zXrJpdIu80xyOij0PbeqfEo3Nsyd3K2NHL89TT25InUR9ltqO-w-ddW6vJHC1Yhlw/s1600/isolation_axes.jpg" /></a> In general, you need to determine what does, and what doesn't, need to be isolated. You also need to identify which components are apt to be delinquent and build a cage around them to protect more critical components. Which brings me to a recent paper by my inestimable colleagues Chris Hobbs and Yi Zheng. It's titled "<a href="http://www.qnx.com/download/feature.html?programid=24546">Protecting Software Components from Interference in an ISO 26262 System</a>," and it explores techniques that can help you: <ul><li>implement the component isolation required by ISO 26262</li><li>demonstrate that such isolation has been implemented</li></ul> And while you're at it, check out the other titles in our <a href="http://www.qnx.com/download/group.html?programid=21552&tag=safety">"safe" whitepaper series</a>. These include "The Dangers of Over-Engineering a Safe System" and "Ten Truths about Building Safe Embedded Software Systems." And don't worry: there's nothing delinquent about downloading all of them.

The isolation imperative: protecting software components in an ISO 26262 system

Software components can be impolite, if not downright delinquent. For instance, a component might: rob other components of CPU time rob othe...

9:40:00 AM

An (info)graphic look at self-driving cars

An (info)graphic look at self-driving cars

If I were in the insurance industry, I'd be following the development of autonomous cars with keen interest. Think about it: all those c...

9:56:00 AM

First look: HTML5 SDK for the QNX CAR platform

First look: HTML5 SDK for the QNX CAR platform

Whenever I hear the word “ripple,” I think of ice cream: butterscotch ripple, chocolate ripple, lemon ripple, and (yum) strawberry ripple. W...

1:16:00 PM

The 10 qualities of highly effective hands-free systems

<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhJPq2tNT1-b76-UN7kJTtYO15jYb5oJ6dRyxopN5-gTDCZuDx_2RQEV__RkwHZxyBUsV_g1cRbUh6iy9hrxETJ34PD8McVwHCuwXPfr0WC_28dHd1W8y9mUIeOk2reT2MhSR6jjWD_U7U/s1600/paul_leroux_photo_crop_v3_thumb_100_px.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhJPq2tNT1-b76-UN7kJTtYO15jYb5oJ6dRyxopN5-gTDCZuDx_2RQEV__RkwHZxyBUsV_g1cRbUh6iy9hrxETJ34PD8McVwHCuwXPfr0WC_28dHd1W8y9mUIeOk2reT2MhSR6jjWD_U7U/s1600/paul_leroux_photo_crop_v3_thumb_100_px.jpg" /></a>The first time I saw — and heard — a hands-free kit in action was in 1988. (Or was it 1989? Meh, same difference.) At the time, I was pretty impressed with the sound quality. Heck, I was impressed that hands-free conversations were even possible. You have to remember that mobile phones were still an expensive novelty — about $4000 in today’s US dollars. And good grief, they looked like this: <iframe allowfullscreen="" frameborder="0" height="315" src="http://www.youtube.com/embed/8iE0OH5FmiU?rel=0" width="420"></iframe> It’s almost a shock to see how far we’ve come since 1988. We’ve become conditioned to devices that cost far less, do far more, and fit into much smaller pockets. (Though, admittedly, the size trend for smartphones has <a href="http://www.phonearena.com/news/Average-display-sizes-keep-on-growing-in-tech-smartphones-lead-the-way_id35634">shifted into reverse</a>.) Likewise, we’ve become conditioned to hands-free systems whose sound quality would put that 1998 kit to shame. The sound might have been okay at the time, but because of the <a href="http://en.wikipedia.org/wiki/Contrast_effect">contrast effect</a>, it wouldn’t pass muster today. Our ears have become too discerning. Which brings me to a <a href="http://www.qnx.com/download/feature.html?programid=24275">new white paper</a> from Phil Hetherington and Andrew Mohan of the acoustics team at QNX Software Systems. Evaluating hands-free solutions from various suppliers can be a complex endeavor, for the simple fact that hands-free systems have become so sophisticated and complex. To help simplify the decision process, Phil and Andrew have boiled the problem down to 10 key factors: <ul><li>Acoustic echo cancellation </li><li>Noise reduction and speech reconstruction </li><li>Multi-channel support </li><li>Automatic gain control </li><li>Equalization </li><li>Wind buffet suppression </li><li>Intelligibility enhancement </li><li>Noise dependent receive gain </li><li>Bandwidth extension </li><li>Wideband support</li></ul> Ultimately, you must judge a hands-free solution by the quality of the useful sound it delivers. By focusing on these 10 essentials, you can make a much sounder judgment (pun fully intended). Recently, Electronic Design published a version of this paper <a href="http://electronicdesign.com/communications/essentials-automotive-hands-free-communications">on their website</a>. For a longer version, which includes a decision checklist, visit the <a href="http://www.qnx.com/download/feature.html?programid=24275">QNX download center</a>.

The 10 qualities of highly effective hands-free systems

The first time I saw — and heard — a hands-free kit in action was in 1988. (Or was it 1989? Meh, same difference.) At the time, I was pretty...

7:04:00 AM

Sin A Car