auto parts: October 2012

Recall? What recall?

Red Bend demonstrates firmware-over-the-air (FOTA) updates of QNX CAR 2 application platform at Telematics Munich

I think anyone with a passing knowledge of software development in automotive would agree that the infotainment systems currently under development are light years ahead of the systems that shipped only 5 years ago. The blurring of the automotive and the consumer experience is accelerating at an amazing pace. And the processing power being specified for next-gen infotainment aligns with what is expected in advanced smart phones.

It's no surprise, then, that the size of the code base and the complexity of the underlying software is growing at a similar pace. This complexity creates a maintenance challenge. On your phone, upgrades are pushed out regularly in a way that you barely notice: you get a notification of an update, push a couple buttons, and presto, you are up to date. In automotive, if we stick to the traditional methodology, this same type of upgrade would require a recall. You'd have to take your car to the dealership and they would reflash whatever needs to be updated. Expensive for the auto manufacturer and a big pain for the consumer.

Thankfully, people are thinking about this. Companies like Red Bend Software have cut their teeth in the mobile space, specializing in firmware-over-the-air updates, or FOTA for short. They can generate something called a delta file, which effectively encapsulates the difference (or delta) between what is currently on the end device and the new software build. In some cases, the file can be up to 50 times smaller than the new build. They also have the ability to track current load status of all the devices deployed.

So what does that get you? Using FOTA, OEMs will be able to minimize the network bandwidth required for upgrades and to manage the update process remotely, moving us all towards that Zen state of automagic. I don't know about you, but anything that saves me a trip to the dealer is a good thing.

Red Bend will demonstrate this capability by updating versions of the QNX CAR 2 application platform this week at Telematics Munich. So if you happen to be there, do stop to check it out.

Sad At Sears

The other day, I made a run to Sears, to buy a battery for my Craftsman li-ion compact drill. It's a great little tool.

I spent some time wandering through the hand-tool section, and realized that the old Craftsman brand is basically dead. Craftsman tools used to all be made in the U.S.A, to a nice level of fit and finish. Now I see two grades of Chinese made stuff--chintzy and somewhat nicer.

I used to buy only Craftsman hand tools, but it looks like when I need new ones, I won't make an extra effort. I can just as well buy Mexico/Taiwan sourced hand tools for slightly less money at Home Depot.

There are still mass market hand tools made in the U.S. with a no-B.S. warranty. Check out Klien and Channel Lock.

Can I get a roadmap? Amen!

I attended SAE Convergence last week, and I've got a couple observations that I'll be blogging about. Here’s the first.

The Panel
On the second day of the show, I attended a very informative OEM panel moderated by Paul Hansen. Paul asked the automakers what their suppliers could do to help them build their infotainment systems. Alan Amici from Fiat said, "I would like suppliers to share their roadmaps," to which the other OEMs nodded in agreement. On the surface, this seems like a rather gentle, generic request. However, I think it's actually a powerful insight that signals a fundamental change in our industry. Mr. Amici took a cue from our former president Theodore Roosevelt, speaking softly but carrying a big stick. Let me elaborate.

The History
If you stepped back in our way-back machine to three years ago or earlier, you'd find a persistent pattern. Every OEM would fully spec every software feature of every module. Which meant that every Tier 1 and software supplier, including QNX Software Systems, would have to jump through hoops trying to cut, fold, and tear their existing software to meet those custom specs. It also meant building tons of new software on top to fill the gaps. The reasoning here is pretty simple — an automaker is building a custom system, so why not build something that reflects exactly what they want? In this environment, we always presented our software roadmap and the OEMs would look politely, but it rarely influenced their designs. Instead, we ended up providing a completely bespoke version of our software stack.

The Change
About two years ago, we started to notice a powerful undercurrent in automotive that bucks this trend. Why the change? OEMs absolutely need to create consumer relevant products, and to reduce the time required to release them. More and more, they need to reuse rather than re-invent. Several OEMs at the forefront of this trend have already been exploring this. How? By working directly with the Tier 1 and suppliers to design the system with an eye towards heavy reuse of existing technologies, instead of trying to design each system from the ground up.

The Apps
This effort to reuse instead of recreate will be necessary not just to reduce the time of delivery, but also to enable any type of cross-brand app experience. Apps that live in app stores require a consistent set of APIs. It’s very hard to do that if every single OEM is busy customizing and recreating every aspect of the system software. The “we’ll design our own” approach will result in fragmentation even worse than that experienced by the Android community. Unconstrained, it carries the threat of creating dozens of independent silos, with no ability to share apps between car makers. It means dilution of the already small automotive volume into even tinier markets — one for each automaker — which doesn’t bode well for anyone building automotive apps. OEMs will need to buck the desire to customize everything if they want to build a thriving app community.

The Punchline
When automakers are focused on their value-add, like HMI designs and custom features, instead of reinventing plumbing, it helps everyone. The OEMs, the tier ones, and the software suppliers benefit from using a consistent platform amongst themselves. So Mr/Ms Carmaker: would you like to see our roadmaps? We'd absolutely love to share them. We’d even like to help build them with you!

This post originally appeared in Andy's True Gryc blog.

Autonomous cars? Suddenly, I’m not so skeptical

Guest post from Emil Dautovic, European automotive business development manager for QNX Software Systems

As a driving enthusiast, I have always felt a bit skeptical about the notion of autonomous cars. The reason is simple: I actually enjoy driving and don’t want someone else to do it for me, in this case the car itself.

Recently, however, my skepticism has begun to soften. I am fascinated, for example, by the SARTRE road train project, where a lead vehicle takes responsibility for a platoon of semi-autonomous cars. Also, recent research from the U.S. Highway Loss Data Institute suggests that, when it comes to some driving tasks, ADAS systems can already put many human drivers to shame.

Autonomous drive will become especially important when today’s “always on” generation starts to buy cars in earnest. They will, no doubt, want to consume multimedia and interact through social media even while on the road, and automakers will need to accommodate them.

HMIs with more (and less) distraction
What would this mean for car makers? Among other things, the infotainment system in a self-driving car could offer an HMI mode that gives the driver more freedom to pay attention to non-driving activities. When the car subsequently needs a human driver (for instance, it becomes disconnected from a road train), the infotainment system could disable these features and immediately go back to a less distracting user interface.

Also, driver assist systems — such as those for detecting animals and pedestrians — would need to be integrated with the road train system to decide how to react when, say, a rabbit runs in front of the car. For instance, should the car brake and warn other cars of the fact, or would it be safer to simply keep driving? It will be interesting to follow this initiative and see how the technical and business aspects evolve, and how, for example, the owner of the lead vehicle will be paid.

For another interesting example of research into autonomous drive, check out the BRAiVE project led by the VisLab team at the University of Parma. The BRAiVE project uses a variety of sensors, with a focus on low-cost alternatives that could realistically integrated into in production cars.

Bells and whistles
So what kind of impact could all this have on a company providing automotive software platforms?

There will, I believe, be an increased demand for a platform that could run all of these applications, enabling the advanced use cases while ensuring that critical functions always have enough processor power. And, of course, the platform will have to be reliable. If this same platform could offer all the bells and whistles available in consumer electronics and demanded by younger drivers, the self-driving future might prove to be a bit closer than we think.

By the way, if you’re unfamiliar with the SARTRE road train project, check out this video:

More about Emil
Emil Dautovic is an automotive business development manager at QNX Software Systems, where he is responsible for the European automotive market. Prior to joining QNX, he worked as a business area manager for The Astonishing Tribe (TAT), where he built TAT's automotive business from scratch and helped transform the company into an important player in the automotive HMI field with leading automotive OEMs and tier ones. He has also worked at AU-System (later Teleca and Obigo), where he served as a consultant on GSM base station development and as a sales representative serving mobile phone OEMs and ODMs worldwide. Emil holds an M.Sc. in Electronic Engineering from Lunds Tekniska Högskola.

MI LG Chem Plant: Public Loan, No Batteries

According to a local news report, the LG Chem battery plant recently built in Holland MI is sitting idle. After building pre-production test units, the workers are now basically idled, spending their time cleaning the grounds, training, and wasting time.

Workers at LG Chem, a $300 million lithium-ion battery plant heavily funded by taxpayers, tell Target 8 that they have so little work to do that they spend hours playing cards and board games, reading magazines or watching movies.

So what happened? Simply, lack of demand from GM for Volt batteries.

Full story here: http://www.woodtv.com/dpp/news/target_8/Volt-no-jolt-LG-Chem-employees-idle

Word of the day: Electrification

At this week’s Convergence in Detroit, Mark Reuss, NA president of GM, told a crowd at Tuesday’s keynote, “Hybridization is no longer enough; electrification is the future.”

What struck me most about this statement was the word, electrification; I had yet to hear it in the automotive context. So I did what anyone with a rocket stick would do, I googled it on my way home. The trail led back to GM’s blue paper on sustainable urban mobility, Roadmap to 2030.

For some time now I’ve been thinking about getting an electric or hybrid car but have been bemoaning the lack of choice. Apparently, the fact that a new ground-transportation paradigm requires wide-spread societal alignment hadn’t occurred to me. You just put up a few recharging stations, right?

GM EN-V electric concept car
Source Wikipedia

GM makes eight recommendations in their blue paper, two of which I find to be particularly interesting:

Integrate electrically powered, connected vehicles into a multi-modal transport system that incorporates sophisticated inter-city transport, comprehensive subway systems, traditional vehicle movement, and specialized smaller urban vehicles
Identify a series of “lighthouse” projects to demonstrate the potential and viability of connected electrically driven vehicles in a controlled environment such as an eco-city or small town

It is nice to see a company taking such a definitive stand and boldly painting a vision for the future; this kind of creative thinking is what we need.

I was surprised to discover the blue paper is from 2010; still if you haven’t already read it, it is worth a look. You can download the paper from the GM web site.

In-car infotainment and the art of doing more with less

Granted, the title for this blog post doesn't have the pizazz of, say, "Zen and the Art of Motorcycle Maintenance." (Are you old enough to even remember that book?) But it does capture the gist of a webinar that Andy Gryc will deliver next week.

His title for the webinar is "Squeezing high-end technologies into low-end infotainment systems." Admittedly, it's more direct than mine. Which is fitting, given that Andy has direct experience designing in-car systems. OnStar, for example.

But I digress. I'm sure you'd like to know what Andy plans to cover, so here's the overview:

Squeezing high-end technologies into low-end infotainment systems

Today's infotainment systems have it all – full multimedia, mobile device integration, POI-enabled navigation, speech recognition, high-resolution graphics, and cloud connectivity. The only problem is all of these features come with a big price tag.

Join Andy Gryc, automotive marketing manager, for this webinar, where he answers the question: Is it possible to build an infotainment system that meets today's customer demands with yesterday's price tag?

A 50-minute session (plus Q&A), this webinar covers a number of techniques to help slim down your next infotainment's BOM cost; it also suggests ways to target the luxury segment as well as the more cost-conscious, high-volume one with the same basic technology.

Date:

Time:

Duration:

Registration:

Click here to register

Who should attend:

Hanging out with the cool kids at the EcoCAR booth

If you read Jin Xu's post earlier this week, you are already up to speed on the EcoCAR 2 competition established by General Motors and the U.S. Department of Energy. If you didn't read it, here's the skinny: To drive home with first prize, university teams must reduce the environmental impact of a 2013 Chevy Malibu without compromising performance, safety, or consumer acceptability. If that sounds hard, it is. Which explains why, out of 150 university teams that applied to compete, only 15 made the grade.

Today, at SAE Convergence, I was lucky enough to meet two of the talented young people participating in this competition: Ahmed Uddin from Wayne State University and Andrew Palmer from Ohio State University. Ahmed and Andrew had just finished delivering remarks at the EcoCAR booth when they stopped to chat with me about their projects.

The EcoCAR 2 Chevy Malibu

The Wayne State team dub themselves the Hybrid Warriors, and they are modifying the Malibu with a parallel-through-the-road PHEV. In a nutshell, the modified Malibu has two power trains, with an electric motor in back and a 2.4L engine in front. By taking this parallel approach, the team has actually upped performance, even though they replaced the stock engine with a power plant that cranks out less power, takes up less room, and puts out fewer emissions. Before these modifications, the car went from 0 to 60 in 9.5 seconds; now it takes only 8.9 seconds.

Meanwhile, the Ohio State team has opted for a series-parallel PHEV that uses an electric motor for the rear axle and a 1.8 L engine for the front. The systems can operate in charge-depleting, charge-sustaining series, and charge-sustaining parallel modes. Personally, I was fascinated by Andrew Palmer's description of the team's infotainment system (redesigning the center stack is an optional component of the EcoCAR 2 competition) and how they aim to make phone connectivity more seamless.

Cooler yet, the team is working on augmented reality, using a BlackBerry PlayBook. Picture this: You hold a PlayBook over the engine of your car, and the screen overlays a transparent view of the engine. The possibilities for this kind of functionality are enormous, and I invite you to check out two blog posts (here and here) from another Andrew — QNX's Andrew Poliak — for examples of how augmented reality could pimp your next ride.

Before you go, remember to follow @QNX_Auto on Twitter, where I will continue to tweet out reports from SAE Convergence.

HTML5 SDK for the QNX CAR 2 platform — the back story

Kerry Johnson

Today, at SAE Convergence, QNX Software Systems announced the new HTML5 SDK for the QNX CAR 2 application platform. I’d like to provide some insight into this announcement, describe what you can expect to find in the SDK, and explain how it builds on the HTML5 capabilities already available in the QNX CAR 2 application platform.

Enabling apps for the car
Almost every consumer who owns a smart phone or tablet is familiar with the app experience: you go to an online marketplace, find apps of interest, and download them onto your device. With the HTML5 SDK, the automotive team at QNX is creating an analogous experience for the car.

Just as Apple, Android, and RIM provide SDKs to help vendors develop apps for their mobile platforms, QNX has created an SDK to help vendors to build apps for the QNX CAR 2 application platform. The closest analogies you will find to our HTML5 SDK are Apache Cordova and PhoneGap, both of which provide tools for creating mobile apps based on HTML5, CSS, JavaScript, and other web technologies.

App developers want to see the largest possible market for their apps. To that end, QNX also announced today that it will participate in the W3C’s Web and Automotive Workshop. The workshop aims to achieve industry alignment on how HTML5 is used in the car and to find common interfaces to reduce platform fragmentation from one automaker to the next. Obviously, app developers would like to see a common auto platform, while automakers want to maintain their differentiation. Thus, we believe the common ground achieved through W3C standardization will be important.

It bears mentioning that, unlike phone and tablet apps, car apps must offer a user experience that takes driver safety into consideration. This is a key issue, but beyond the scope of this post, so I won’t dwell on it here.

So what’s in the SDK, anyway?
As in any SDK, app developers will find tools to build and debug applications, and APIs that provide access the underlying platform. Specifically, the SDK will include:

APIs to access vehicle resources, such as climate control, radio, navigation, and media playback
APIs to manage the application life cycle: start, stop, show, hide, etc.
APIs to discover and launch other applications
A packaging tool to combine application code (HTML, CSS, JavaScript) and UI resources (icons, images, etc.) with QNX CAR APIs to create an installable application – a .bar file
A emulator for the QNX CAR 2 platform to test HTML5 applications
Oh yeah, and documentation and examples

The development and deployment flow looks something like this:

Emulator and debugging environment
The QNX automotive team has extended the Ripple emulator environment to work with the QNX CAR 2 application platform. Ripple is an emulation environment originally designed for BlackBerry smart phones that RIM has open sourced on github.

Using this extended emulator, application developers can test their applications with the correct screen resolution and layout, and watch how their application interacts with the QNX CAR 2 platform APIs. For example, consider an application that controls audio in a car: balance, fade, bass, treble, volume, and so on. The screenshot below shows the QNX CAR 2 screen for controlling these settings in the Ripple emulator.

Using the Ripple emulator to test an audio application. Click to magnify.

In this example, you can use the onscreen controls to adjust volume, bass, treble, fade, and balance; you can also observe the changes to the underlying data values in the right-hand panel. And you can work the other way: by changing the controls on the right, you can observe changes to the on-screen display. The Ripple interface supports many other QNX CAR 2 features; for examples, see the QNX Flickr page.

You can also use the emulator in conjunction with the Web Inspector debugger to do full source-code debugging of your Javascript code.

Creating native services
Anyone who has developed software for the QNX Neutrino OS knows that we offer the QNX Momentics Tool Suite for creating and testing C and C++ applications. With the QNX CAR 2 application platform, this is still the case. Native-level services are built with the QNX Momentics suite, and HTML5 applications are built with our new HTML5 SDK. We've decided to offer the suite and the SDK as separate packages so that app developers who need to work only in the HTML5 domain needn't worry about the QNX Momentics Tool Suite and vice versa. Together, these toolkits allow you to create HTML5 user interface components with underlying native services, where required.

QNX, NVIDIA team up to deliver infotainment solutions

Today, at SAE Convergence, QNX announced that it is working with graphics leader NVIDIA to bring infotainment solutions to the automotive market. As part of this initiative, the companies will integrate support for the NVIDIA Tegra processor into the QNX CAR 2 application platform.

The Tegra system-on-chip is the size of thumbnail, yet it incorporates a quad-core ARM CPU and a GeForce GPU, as well as dedicated audio, video, and image processors.

The NVIDIA Tegra visual
computing module

“QNX Software Systems and NVIDIA have a proven track record of delivering on production programs for Audi... and we’re excited to add support for Tegra to the latest generation of our automotive platform,” said Linda Campbell, QNX director of strategic alliances.

Speaking of Audi, NVIDIA is bringing an Audi A6 to SAE Convergence, equipped with an infotainment system powered by technology from QNX and NVIDIA. The system bristles with high-end features, including 3D navigation with Google Maps and Google Earth, as well as natural voice recognition.

For more information on this announcement, read the press release, and for more information on QNX activities at SAE Convergence, visit our Convergence overview page.

SOLD - GTO - Z16A Half Cut

SOLD To Local Customer
This Half Cut GTO - Z16A - Engine 6G72 - Turbo - Manual ( 4WD ) , Selling Together With All The Parts Shown In The Photos

Selling As Is Where Is Basis

To View Engine Revving, Click Video Below :-

General View Of The Half

General View Of The Speedometer

Mileage Reading :- 110803 Kilometers Or 68,849 Miles

Chassis Number

Front View Of The Engine Bay

Side View Of The Engine Bay

Inner Part Of The Engine

Top View Of The Turbo

Bottom View Of The Turbo

General View Of The Undercarriage

Bonnet - Red Circle Indicate Damaged Area

Close View Of The Damaged Area

Driver Side - Fender - Good Condition

Aftermarket Absorber - Brand :- GAB - Soft/Hard With Brake Caliper And Rotor

Brake Caliper With " MITSUBISHI " Wording - Good Condition

Driver Side - Fender - Good Condition

Aftermarket Bumper - Red Circle Indicate Damaged Area

Close View Of The Damaged Area

Passenger Side - Fender - Good Condition

Aftermarket Absorber - Brand :- GAB - Soft/Hard With Brake Caliper And Rotor

Brake Caliper With " MITSUBISHI " Wording - Good Condition

Passenger Side - Fender - Good Condition

Aftermarket Rear Absorbers - Brand :- GAB - Soft/Hard And Console Box

Original Side Skirt - Good Condition

Long Shaft

Rear Axle With Complete Frame

General View Of The Half Cut

SOLD - Altezza Half Cut

SOLD To Local Customer
This Half Cut Model Altezza SXE 10 - Engine 3S-GE - Beams VVTI - Manual , Selling Together With All The Parts Shown In The Photos

Selling As Is Where Is Basis

To View Engine Revving, Click Video Below :-


                                                   General View Of The Half Cut