Monday, December 6, 2010
RIM acquires TAT
Now, we're happy to have them as a sister company. As of December 2nd, RIM acquired TAT. Although we worked with TAT before, I'm sure this means a lot more interaction between QNX and TAT in the weeks to come.
Wednesday, November 3, 2010
Automotive Meets Communication (AMC) 2010
Last week, I attended the AMC 2010 conference held in Bonn, Germany. Lots of participation from the telecom and automotive industry, talking about how they could and are working together to build the future of connected automobiles. I had a speaking panel spot that, although it was the only non-German language presentation, seemed to be quite well received. My presentation was about emerging trends in automotive, and the thanks to the material has to go to my colleague Andrew Poliak, whom I plagiarized from mercilessly. Of course, "borrowing" material happens all the time throughout the business world.
Here's a great case in point: one of the AMC speakers from BMW had a great word bubble diagram (attached below). The picture was a great one, mainly (in my view) because it included a "QNX" plug (red text; look in the lower right hand part of the "cloud"). Coming from BMW, who has been a big supporter of Linux, I just loved this slide.
The funny part of the story is that I was talking about how I was going to blog this with my colleague Paul Leroux, who is a ferocious blogger. I started out with, "say Paul, I've got this pic I want to show you, but you have to promise that you won't blog about it first."
"No problem," Paul said, as I opened the pic. Paul immediately gave an exclamation of surprise and then added, quite seriously, "I've already blogged about it, about a year ago. That guy is using my diagram!" He showed me in his blog where he had created the diagram.
It is getting so frustrating blogging about anything before Paul does--he even goes back into time to preempt me! Even if I start blogging during the event next time, I can't beat Paul!
Monday, October 25, 2010
Some things just never change
Here's a pic from last week at Convergence. Anything look similar? The Corvette has gotten sexier, and well... let's just say I haven't. Being that this is the new QNX Connected Car 2.0, it doesn't get driven too much. I got to back this beautiful machine out of the QNX garage before the show, for about 15 feet driving distance total.
I just hope it's not another 25 years before I get another chance at taking one out on the road. Not only would my retirement-age body probably break a hip getting down into such a low-riding car, I'd like it if I could still drive over 40 mph on the highway.
Thursday, September 2, 2010
QNX CAR with Apple iPod out
I don't think I'll be moving to Hollywood anytime soon!
Friday, August 13, 2010
Oracle sues Google over Android
The specific patents involved: 6,125,447; 6,192,476; 5,966,702; 7,426,720; RE38,104; 6,910,205; and 6,061,520. Oh, and they also claim copyright infringement to boot.
Is this a legitimate lawsuit? Is Google going to have to retract portions of Android or Dalvik? I could see Google trying to out-technology Oracle to solve the patents just out of spite, even if that has a big slowdown to the growing Android community. I don't know, and I'm not a lawyer. But I did read through the patents involved, and it seems that there are three groups of complaints.
One is on security mechanisms and resource protection of Java. That one seems like it will be hard to defend against, since Dalvik mimics much of the Java mechanism.
The other is on how class files are processed and packaged. My guess is that Google could probably get around this one without too much trouble by redoing their tools. You already have to recompile Java anyway for Android, why not redo how class files are handled?
The third area is around how the VM optimizes instructions. Parts of the claimed patents seem easy to avoid, but others do not. This could be a difficulty to work around, but I'm not certain.
Of course Google's other option is just to pay Oracle off. Would Oracle ask for an injunction on shipping Android devices to spite Google? Don't know. Either way, I suspect there will be interesting times ahead for the Android ecosystem.
Monday, August 9, 2010
Lies, Damn Lies. (or, QNX was *not* hacked in a car.)
“Hello, I’m a VxWorks device. Would you like to own me?”
This may sound eerily similar to my car hacking blog which discusses how a diagnostics port was used to subvert a car’s brakes and engine. What I didn’t mention then is that this hacked system also runs an RTOS: QNX.
Hmmm. Sounds damning, doesn't it? He follows this with an immediate pitch for a GreenHills Security Kernel product. I work for QNX, so I just had to look further.
I read the actual academic report that he bases his "information" on. Dave apparently doesn't understand cars or doesn't understand what problems his own company's product is supposed to solve. The reasoning used to implicate QNX by interpreting the academic report is faulty at best. The premise of the study is that with an OBDII tool you can send arbitrary messages on the vehicle bus. Since every car has an OBDII port (by government mandate for emissions monitoring and control), you can "hack" into every car. This "hacking" allows you to do all types of things to the car, from shut off the engine, control the brakes, reflash the telematics unit, etc.
In a word (or maybe two), "no duh". When you bring your car into the dealership, how do you think the techs communicate with it? They don't whisper it back to health! The paper describes doing things to the car while moving: they've set up a laptop with WiFi that they've plugged into the vehicle bus while driving along side in a chaser car. Not exactly something that is practical without physical access to your car. One of the things done in the hacking test is to replace the telematics unit firmware (the module running QNX) with a custom firmware image that lets them transfer messages between the low-speed and high-speed CAN buses as a bridge.
Oh my goodness! How could QNX allow a hacker to replace the RTOS firmware image?! In fact it's not a surprise, because that requirement is written into the specification. That's right. For a dealership to update the modules within the car, those modules need to be able to be reflashed. Every module has this requirement. I don't care if your car module is running the QNX Neutrino RTOS, or the QNX Neutrino RTOS Safe Kernel, or the GreenHills Superfragilisticexpialidocious kernel or Kumquat OS 9.9. If the module is actually operating properly, it will allow itself to be reflashed. Period. The purported problem cannot be solved by use of a security kernel whether from GreenHills or anybody else.
The true problem being pointed out by the academics is that the car vehicle network, for better or worse, was designed as if it were a closed system. The only thing that prevents malicious mischief is the difficulty of gaining physical access to the vehicle bus connectors. I would agree that vehicle buses probably need to start considering authentication / identity verification / challenge / response protocols in their design. Because the dealers will always have the requirement to fix/diagnose/update cars, they will have access to tools to let you do this. No matter what you could design to solve the "closed network" problem, it can be abused by unscrupulous people.
Tuesday, August 3, 2010
GenIVI report slams QNX. Independent view seems to differ.
Seems a little self serving for GenIVI to state that we won't be successful because we're not GenIVI. It's news to me also that we're withdrawing from the market, especially since we're hiring more people every day in support of the business we're continuing to grow.
Apparently the report doesn't hold water with independent analysts either. Roger Lanctot in his Strategy Analytics blog disputes quite a few points in the GenIVI report as simplistic or overstating the facts. He shows too that the report attempts to bolster the GenIVI point of view without providing any real evidence. Interestingly enough, the GenIVI report claims that it interviewed people throughout the industry, including QNX. I'd be interested to know who exactly they interviewed at QNX and what they contributed to that report.
The GenIVI Alliance publishes the summary report, but of course you can't read the full version of the report without joining GenIVI. (No wonder they have so many members! Maybe I should publish a slanderous white paper about GenIVI, but you have to join QNX CAR to read it :-)
Wednesday, July 21, 2010
QNX, BMW and Apple iPod Out
After RIM acquired QNX, I expected another round of the same customer concerns about QNX and our continued direction. It really hasn't materialized, I guess because this time around everyone clearly sees that there is a very natural fit to RIM and QNX. About the only thing we hear these days is the occasional question from customers about whether or not we will still support the technologies they care about. An example is: "since Apple and RIM are competitors, are you going to continue supporting Apple devices?"
The answer is, of course "yes," but the proof in the pudding, as they say. How about this:
http://www.ubergizmo.com/15/archives/2010/07/bmw_to_support_ipod_out_in_the_future.html
Apple's iPod Out feature is a brand-spanking new feature that Apple just released in OS4 that allows an iPhone or iPod Touch to pump an Apple-customized video HMI to an automotive head-unit. It's not available in any production models today, and BMW is the very first car company to announce support for it. I'll give you just one guess which operating system is being used for this project. (And despite BMW's highly public Linux strategy, please don't waste your guess on GenIVI :-)
Although the feature is hot off the presses, here's a shaky-cam snapshot of our very own Mike Shane running the QNX Neutrino RTOS with a preliminary version of the iPod out feature integrated into our iPod driver.
Biking in Oregon
Friday, July 16, 2010
The key fob is dead! Long live the key fob!
Okay. Combine that fact with some other recent announcements. Like the smart phone apps from Chevy for the Volt or the OnStar smartphone app that lets you access your vehicle. Delphi makes a system today that right now uses a combination smartphone with a souped-up key fob and range extender.
It's not hard to see that key fobs as we know them are going the way of the dinosaur. Why on earth are you going to carry one more huge lump on your key chain when you've already got your phone? I predict that within the next 3 years, key fobs will be those extra-expensive optional add-ons that will be sold only to the severely technologically challenged. Everyone else will download their OEM's specialized key fob app into their smartphone. Those key fob apps will use WiFi, Bluetooth, or a cellular network to communicate with their vehicle--unlocking it, starting it, and setting it up specifically for you. Smartphone apps won't require additional hardware costs. And they're already an indispensable part of the everyman's (and everywoman's) arsenal.
I'm looking forward to the day when I don't have a key fob, but a key fob app.
Tuesday, June 29, 2010
"Honk if you love Jesus...
Amusing bumper-sticker a friend of mine recently saw. I think it accurately encapsulates many people's thoughts on Texting while driving. It's also very interesting to note how many of us do it. I think it's one of those hypocritical things humans think where "everyone else is a danger, but not me--I'm the exception." Rules are always made for everyone else.
Infotainment systems are starting to have a wide array of capabilities--certainly we're creating technologies that provide people with more productivity, more connectivity, and more entertainment than ever before. Most people see this new technology as a good thing, but also understand the inherent risks of driver distraction. It seems that the most vocal combatants of using in-vehicle technologies are from older generations. The younger you are, and the more you take the Internet for granted, the less likely you are to see texting or calling or computer use while in travel as a problem.
I think the long term shift will be a combined societal and technical view. People will come to accept this informational bombardment and learn to work with it. As an example, look at the changes in societal views towards driving under the influence. Any movie from the 40's through the 60's shows an incredible caviler attitude towards alcohol. They don't seem to recognize it as a danger at all. There was no peer pressure, no fatality statistics, no laws, no personal tragedies, all forces combining to cut down on drunk driving. Today, albeit not perfectly so, people are in large part self-policing. They understand the risks and dangers, and although there are still fatalities, the public stigma and peer pressure keep the number of violators down.
If anything, technology use in the car will expand, not shrink. Today's youngsters are growing up with multitasked driving as part of their mental framework. By the time that all today's teenagers become senators and parliamentarians, I'd expect that all laws about texting while driving will have repealed, and cars will practically drive themselves.
Except for the personal helicopters--you'll still have to pilot those yourself. And they'll be hands-free only.
Wednesday, June 23, 2010
Earthquake at QNX
(All I can hope is that my blog posts before my uber-posting blogging coworker, Paul.)
Wednesday, May 19, 2010
Google Android: When is free not free?
I remember the first patently stupid patent I heard about was for an xor cursor (#4,197,590), when it was already in such common use everywhere it seemed ridiculous and offensive to patent it. Patents aren't supposed to be covering prior art, nor "obvious" inventions. That is one serious thing wrong with the software patent system. People who do open source development leave all their code out there to be examined and combed through. Combed through by lawyers for similarities to an existing patent arsenal. When a developer is clearly ripping off someone else's work, then a software patent makes sense. But if it's already floating around in the either or its obvious, it shouldn't get patented. Neither of those things is anywhere near possible for the patent office to determine with any amount of rigor. It seems fundamentally unfair that the only people who get to profit from software inventions are the ones with the cash and the time to pursue the patent process: big sharks, not little fish.
I'm not arguing on the validity of Microsoft nor Apple's patents. They could all be great inventions and 100% absolutely legit. And it's not Google that I'm worried about for protection against patent lawsuits. They're plenty big enough to take care of themselves. And I'm sure that HTC can just bump up the cost of their phones by a few bucks to pay for all the patents they're now licensing or will have to license. It's all the other hordes of software developers creating open source software on their spare time using their goodwill. Developers that don't have the time or resources to patent everything they've done. Developers who wouldn't know that what they're creating in the dead of night is accidentally similar to something in someone else's IP portfolio.
Watch out if your little pet open source project gets noticed. Patents aren't protection--they're a weapon in a software arms race. It's a minefield out there.
Thursday, May 13, 2010
Response to “Thoughts on Flash”
- “Flash is a closed system.”
- “Symantec recently highlighted Flash for having one of the worst security records in 2009.”
- “Flash is the number one reason Macs crash.”
- “Flash has not performed well on mobile devices.”
- “Fourth, there’s battery life.”
- “Flash was designed for PCs using mice, not for touch screens using fingers.”
Friday, May 7, 2010
ARM wrestling with Intel
Why Intel Will Be a Mobile Loser
Tuesday, May 4, 2010
RIM breaks into top 5 cell phone makers
Software is the key thing that differentiates the top smart phones from the rest of the pack. That puts the pressure on LG and Samsung, who haven't been traditionally strong in that area. And HP just acquired Palm to get the Pre software. It's going to be an interesting summer...
What's the newest Blackberry going to look like? Take a peek at this, announced last week at WES 2010:
Blackberry OS 6 preview video. One of my smart-alec coworkers said that apparently you have to learn how to dance to use the phone. Naw. You just have to like the Black Eyed Peas.
Atmel OS Survey
Atmel Community Page, middle right-hand side, and vote for QNX.
I think the fact that the survey requires a registration may be putting people off, but I know you're out there. Come on, show your support!
QNX at ESC 2010
ESC Keynote video, Day 3
(forward to 1:30 for my 15 seconds of fame :-)
Now, what went wrong? Nothing major, but end of the show was hectic. The fit between the lightboxes under the car was very tight. Enough air escaped from the tires where we had to manually lift the car to slide the boxes out during the show tear-down. (Thanks Dave and Dave!) We had to ship stuff from the show directly to Japan and Germany, which our shippers said they couldn't do, although our event coordinator Alison had checked with them first and they said they could. So we had to literally run a bunch of stuff over to Kinkos. (Thanks Kinko's crew!) And ESC scheduled me for a presentation after the show ended. Yes, that's right. Right in the middle of the shipping and booth teardown was my presentation about Smart Screens. How completely stupid is that? Obviously, I didn't have great attendance--just a handful of diehards to hear me talk about solving design issues with Smart Screens, using our Smart Energy Reference Design as a use case. (Thanks to you who stayed for my talk!)
I rushed off right after the talk to attend the San Jose Sharks vs. the Detroit Red Wings, with just minutes to spare. (Thanks Kroy and Ali!) I was one of the ten people in the stadium rooting for Detroit, but unfortunately we lost. There's still some time to make it up--go Wings!
Friday, April 9, 2010
Yesterday QNX Wins OCRI Award. Today QNX Acquired by RIM
Except that this morning there's a slightly more pressing bit of news and something a little more exciting to blog about. QNX will be acquired by RIM, which was announced this morning at 9AM. Exciting!
What does it all mean for our customers and our markets?
- We're staying in automotive, and increasing our focus on devices and connectivity with initiatives like QNX CAR.
- We're still going to be supporting Harman-Becker and all of our other automotive customers.
- We're staying in the industrial space, and continuing to support those customers and processors with real-time improvements, industrial protocols, and multicore support.
- We're going to be continuing our innovation in products and strategies around HMI development
- We're going to be expanding our staff to handle new challenges.
- We are scaling back unfettered access to Foundry27, but we'll still provide all of our BSPs in source, and our source code will still be available free of charge to customers who need it.
There are plenty of questions I can't answer, even if I knew the answers. But expect that new and exciting developments will be coming your way...
Tuesday, March 30, 2010
Old Programmers Don't Die--They Go Embedded
That's why it was fun to do a little reminiscing while creating my webinar. I roamed through a lot of my musty old code from years back. Sadly, I still remember programming over the years on a steadily improving array of equipment. I don't recall every line, but I do remember certain key lessons learned. For the reminder of those that should know better and the improvement for those who never knew, I tried to wrap up some of the most poignent best practices into my webinar.
My webinar's focus was on embedded programming, with good reason. Embedded is still an area where some of those older techniques are still useful. Yes, today there are better tools, compilers, frameworks, you name it. But you'll always have a few more limits and a little bit more constricted environment when programming an embedded device, no matter how powerful it is.
Case in point: I'm currently learning Objective-C for Mac/iPhone development. It's fun. It's been a while since I've had to completely bathe in a new environment, language, and paradigm, all in one. But most of the resources I've found are somewhat tedious. They cover details from a beginner programmer's standpoint. Instead of just telling me what's different, they insist on telling me everything and forcing me to wade through reams to get those little nuggets. Ugh. In this process, let me pass along a link to a very useful document, just in case you're a die-hard C++ programmer who wants to learn Objective-C and doesn't want to learn how to program from scratch. C++ and Objective-C are both object oriented dialects of C, but they're exceedingly different. (And thank you Pierre.)
What does learning Objective-C and the iPhone have to do with old-tyme embedded programmers? The iPhone has 32MB of RAM, but it doesn't support garbage collection, so you can't be lazy with your memory management. Not everything that Mac programmers have gotten used to will work on the iPhone. Because, it's (say it people) embedded. Maybe some of those old tricks will come in handy still after all...
Thursday, March 18, 2010
QNX turns 30! What was happening way back then?
Description:First commercial microkernel OS
Inventor:Dan Dodge and Gordon Bell
Impact on civilization: Showed it was possible to have a multi-user, multi-tasking, multiprocessor OS with real-time performance running on a PC with only 64K of RAM. It and its successors (QNX2, QNX4, QNX Neutrino RTOS) spawned many uses in reliability-critical industries.
Visicalc introduced on PC in 1981
Description: First commercial spreadsheet
Inventor: Dan Bricklin and Bob Frankston
Impact on civilization: Made personal computers a serious business tool instead of a hobbyist orgame machine. Visicalc was first created in 1979, but it effectively launched the Personal Computing industry, by bringing IBM to the party in 1981.
I remember this pretty distinctly--my Dad bought Visicalc for the Atari 800. It made heavy use of the slash key for doing almost anything. It was pretty limited compared to Excel. At the time, it was amazing to see numbers magically recalculated all over the page when you changed one little thing. All done in 48K. If you're feeling nostalgic, you can run a real version of this on your Windows PC for old-tymers found on Dan Bricklin's website.
Description:Common PC OS
Promoter/Inventor:Bill Gates / Tim Paterson
Impact on civilization: Created a common architecture for software development, spawning an industry. And created the world’s wealthiest person. (As of Mar 10, 2010 due to Mr. Gates' generous philanthropy and the depressed state of the stock market he was bumped down to the second wealthiest.)
Tuesday, March 9, 2010
Embedded World Germany 2010
My days were filled with press interviews, conference presentations and talking to customers. My nights filled with scouring the schnitzel and sausage-filled menus for something, anything, green to eat. The Olympics wrapped up while I was in Germany, and I got to have all my Canadian colleagues give me a good natured razzing after the Canadian hockey team beat the US 3-2 in overtime. I guess I can finally admit that hockey is Canada's game and winning the silver is not bad! Congratulations Canada!
The year's show was a great one for QNX. There was lots of activity and interest in our Industrial developments--our Smart Energy reference design, our Building Automation demo, our Industrial protocol work with partners, and our real-time control demo. On the automotive side, we were showing our latest QNX CAR with all the extra ng Connect features. That same QNX technology went into the 2010 Audi A8 MultiMedia Infotainment system with full multimedia and Google Earth maps which had everyone drooling. More than one person told me "this is my next car," and I don't blame them!
The show is now all packed up and everybody is home recovering from jet lag. So I guess I'll see everyone next year!
Friday, February 19, 2010
Toyota's woes: why simplistic solutions are dangerous
Much of the issue Toyota faced had to do with floor mats, which doesn't involve software, and broadening the "software-is-buggy" concern to the entire recall is alarmist. Even if the recall were wholly due to software, it is not realistic to remove software from today's automobile. Cars are not going to be designed without software, period. In fact, if anything, the opposite is happening: more and more software is going into cars. Customers want piles of features for cheap, and automakers want the flexibility that comes with software solutions. Innovation and driver safety is enabled by software: adaptive cruise control, digital instrument clusters, pedestrian and animal warning, hybrid powertrains, parking assist, and fuel saving ignition systems all require software to work. Lightweight drive-by-wire saves cost and enables safety features like lane drift adjustment . Anti-lock brakes, once a "scary" feature have now become common-place and standard issue. And infotainment and navigation systems are continually growing in popularity and demand. Becoming a luddite or a technophobe will not stop progress.
The other commentary is from a hardware engineer who is rather naive when it comes to software:
His effective point is that "hardware validation is successful, and hardware engineers can get it right, so move those methods to software." Firstly, that does not reflect my reality, where hardware problems and corner cases are found all the time in embedded development. Hardware bugs slip through the validation net for lots of reasons: inappropriate tests, unanticipated use, incomplete testing, improper design, and bad requirements to name a few. Hardware bugs are far more expensive to fix, so it's usually software to the rescue. Hardware appears "perfect" because there are almost always software workarounds helping the hardware along!
It is also almost insulting to think that applying hardware verification methods to software is the "fix" for automotive software quality control. It belies a poor understanding of software development, and can only be because the author does not understand software processes, the complexity of software, or how software is created. There is already an entire body of knowledge around software development processes, quality management methods, and best practices. Software methods are fundamentally differently than hardware methods because the two products are created and designed using orthogonal methodologies. Software engineering disciplines may not be as clear cut as designing a circuit board or an IC, but they exist already! Those methods are already well understood by automotive companies and suppliers.
If software keeps coming into the vehicle, and we need to make the vehicle safe, what can be done? What's done in industries like aerospace is things like dual-system redundancy, triplicate voting systems, or exhaustive test beds. Those things add tremendous cost and lengthen development. Car customers like you and me are not governments or airlines with multi-million dollar budgets buying products that will be maintained for several decades. No: customers are not only price sensitive, but time sensitive. Fickle buyers want this year's features today, not in five years.
You can use software to help. The earlier you find bugs, the better, and some systems are better at early identification of bugs than others. Multiple-address space designs are than single-address space designs by forcing erroneous code to crash. This is a good thing--it leads to far quicker isolation, identification and resolution of problems. A microkernel design like the QNX Neutrino RTOS isolates every system process so that device drivers, software stacks, and applications are all treated with that same level of rigor. Pro-active measures like high availability systems can ensure that software recovers gracefully from faults. It is your insurance that the software will still operate properly, even in the face of undetected errors. Time partitioning systems can be added to ensure that software is always getting the minimal required CPU cycles. Time partitioning protects against unanticipated log-jams of system activity that would otherwise cause missed deadlines and system failures.
QNX has been helping people design bullet-proof software in use in safety-critical systems for 30 years now. We know that it isn't easy. And we know that it requires discipline. But it doesn't require throwing out the baby with the bathwater. Nor does it require some kind of silver bullet. Just good practices and good software. And good management to pay attention to engineers when they say something isn't yet ready to go.
Thursday, January 28, 2010
The Power of a Tweet
Did anyone ever think Twitter could save lives? Not me. I hate to say, but I might be coming around on Twitter.
Monday, January 18, 2010
What is a Software Ecosystem?
So I found it exceptionally amusing that the first whole page of Google Image results on "ecosystem" were all the circle of life like this:
I posted this blog entry because on even further reflection, the food chain metaphor is actually quite appropriate. All the software companies are:
- Trying to eat each other (corporate aquisition)
- Trying to eat someone else's lunch (competitors)
- Eating someone's waste products (startups filling niches left by the big guys)
- Creating basic food at the bottom of the food chain (open source development)
- In a symbiotic relationship (services organizations)
- In a parasitic relationship (consulting)