Tip:
Highlight text to annotate it
X
MAN: Well, I hope everyone enjoyed their lunch,
and I apologize for the entertainment.
[ Laughter ]
Thank you, Jim, for putting that together.
That was excellent.
We have two speakers here this afternoon
that are gonna educate us.
The first is Mr. James Crocker.
He is the vice president and general manager
of the Sensing and Exploration Systems
at Lockheed Martin Space Systems Company.
In his past career, he's been a program director for the --
take my notes here -- Next Generation Space Telescope
at Ball Aerospace & Technologies Corporation.
He has a lot of experience with NASA, though.
You can go back to his days
at University of Alabama, Huntsville,
where he did some design work for Skylab.
He's won numerous, numerous awards,
including the Space Telescope Science Institute
Outstanding Achievement award
and two NASA Public Service awards.
So, please join me in welcoming Mr. James Crocker.
CROCKER: Teflon and Tang --
two of the famous spin-offs of NASA space exploration -- not.
We all know that there are an enormous number of spin-offs
of space exploration,
but Tang and Teflon, I'm sure you know,
were not one of them -- or two of them.
A lot of myth goes into what we do in space exploration,
and a lot of myth goes into things.
And sometimes the things that are true get lost with --
and trivial -- get lost with the important things.
And one of the important thing --
I think the most important contribution that NASA has made
was in the area of systems engineering.
NASA didn't invent systems engineering,
but certainly, in the time
that ran up to going to the moon -- and since then --
NASA has developed this to a state of the art
far beyond what industry had before then.
And when you think about it, it was the perfect opportunity.
Think about the first thing we do in systems engineering --
is we really set the high-level requirements.
And who set those for going to the moon?
Well, it certainly came --
I don't know who actually wrote the speech for Mr. Kennedy --
President Kennedy -- but when he said
to put a human on the moon before the decade's out
and return him safely to the Earth,
I think you see the perfect systems-engineering
high-level requirements.
"We're gonna do it in a time frame that's defined.
"What are we gonna do?
"We're gonna put a human onto -- land a human on the moon
"and, most importantly --
"at least, for that human and his family --
bring them back safely to Earth."
Systems requirements at that level
were part of what laid out the opportunity for us
to, in fact, get to the moon before the end of the decade
and return the astronauts home safely.
So, can you teach systems engineering?
Well, absolutely you can teach systems engineering.
That's what you're doing.
But teaching something and have people get something
aren't necessarily the same thing.
And one of the things I've observed
is that systems engineering is special.
It's different from many of the disciplines
that many of us have.
I'm an electrical engineer by my undergraduate degree,
and I know about electrical engineering.
Many of you are probably mechanical engineers
or software engineers.
And it takes a certain mind-set to do engineering.
Typically, most of us who go into engineering
go very deep into a field.
We really know electrical engineering
or some subset today --
communications engineering or whatever.
But to do systems engineering really takes a person
who can not only go deep, but who can go very broad.
You've heard of, you know, a mile deep and an inch wide.
Systems engineers have to be a mile deep and 10 miles wide.
I know you know that.
But more than that,
systems engineers have to do something else.
Systems engineers have to be leaders and communicators.
And that's not something,
I think, that comes natural to many engineers.
And so we either have to learn those skills,
or we have to have at least a natural ability
to carry some of those things out.
So, why is that important?
Well, I think it's important
because of a story that's at least 800 years old,
and that 800-year-old story -- I've tried to --
I first heard this story in a book
called "The Mythical Man-Month."
It was written about the IBM 360 computer
and the operating system that was written for that --
at the time, the largest piece of software
ever developed for anything.
And in that story is a story
of some stonecutters and a traveler
who, 800 years ago, as the story goes,
came up to Avignon, France,
on a misty day and was rushing to a meeting.
But he was interested in three stonecutters
who were working in front of this project.
And he asked the first one what he was doing,
and the guy sort of grumbled and said,
"I'm -- I'm cutting stone.
"Get away. Don't bother me.
I'm cutting stone."
So, he went up to the second stonemason.
He said, "So, could you tell me, sir, what you're doing?"
He said, "I'm being the best stonemason in the county.
"And if I work really hard,
I can be the best stone maker in the entire country."
He went up to a third stonemason
who was just as intent on the carving
and the work that he was doing,
and he asked him what he was doing.
And this stonemason stopped,
put down his hammer and chisel, and stepped back
and, with maybe a tear -- but great pride -- he looked up,
and he said, "I'm building a cathedral,
"a cathedral that will stand to the glory of God
for the next several centuries."
You see, that's what systems engineers do.
Systems engineers build cathedrals.
When you look back over history
and you look at the great things that have been accomplished,
things that come to mind like the pyramids,
things come to mine like going to the moon,
the International Space Station --
If you look at the great achievements --
the Hubble Space Telescope --
and the people who built that were building cathedrals.
They may have been, in the case of NASA, cathedrals of the sky,
but cathedrals no less.
And the essence, I've learned, over the years of doing that,
of building that cathedral,
lays at the heart of systems engineering.
Today I'm gonna talk about a couple of stories and --
It's been my experience
that you can teach the tools of systems engineering,
and that's a necessary part of the foundation.
But to actually do systems engineering,
you got to go do it.
It's not something that you can simulate.
It's something that you learn by doing.
The basic foundational principles
of systems engineering
can be learned by all of us, by anyone.
Actually conducting systems engineering,
the art of systems engineering,
the art and science of systems engineering come by doing.
I say this all the time.
In my career, I've seen over and over and over
the confusion of doing systems engineering
with using the tools of systems engineering.
It takes both,
but you can't confuse one with the other,
as many of you know.
So, communication and leadership skills are important,
that basic engineering understanding,
a broad understanding of engineering
and the disciplines that are involved are important.
There's a couple of other things that are important, too.
When I was studying management, program management in school,
I noticed that they always form a project office
with a program manager, a scheduler,
a finance- and business-operation person,
and a systems engineer.
That's kind of -- And you can be a little larger or smaller.
You might throw a contract person in there, too,
but that's the essence of the program office, right?
But of all of those,
there's this symbiotic relationship
between the systems engineer and the program manager
that I found to be extraordinarily deep
and extraordinarily important
when you're trying to get a cathedral built.
And that is this demarcation and this push-pull
between the program manager and the systems engineer
in a project that, if done right,
will lead you to success,
and, if done wrong, will lead you down
some very interesting roads and highways.
In my experience, the purpose of the program manager
is very similar to the purpose of the systems engineer,
but they're a bit of an antithesis with each other.
The program manager is to get the program done on time
and on schedule.
That's their fundamental job.
The systems engineer is to make sure
that all of those things are done,
but also that this thing works.
And there's a great book called "Launch Systems Failures."
It details every failure of every launch
and satellite system going back to Sputnik.
And in that, as I read it,
the thing that struck my mind about this book
is that, with rare exception,
a failure of a system is a failure in systems engineering.
It's either a failure of analysis,
it's a failure of requirements understanding.
I mean, you can go through and just tick it off.
This system failed
because somebody did not understand the requirement
or it didn't get flowed down properly.
This system failed because we didn't test as we fly
or fly like we test.
Some requirement wasn't understood.
So, this is about communication and it's about leadership.
And understanding that dynamic
and not having either the systems engineer
overpower the program manager
or the program manager overpower the systems engineer
is, I think, critical to what is so important today,
which is delivering what was asked for that works
on time and on schedule.
If either of the systems engineer
or the program manager overpowers the other,
you'll come in on the wrong side of that equation.
You may get something that's phenomenal,
eye-watering technically.
It may do a million things extremely well.
It may have a huge amount of margin.
It just may take forever
and cost an infinite amount of money.
And today -- Of course, we never have,
but today, particularly,
we don't have an infinite amount of time and money.
On the other hand,
if the program manager side of the brain gets too much engaged,
you can deliver on cost and on schedule,
and you can have system failures.
A lot of people talk about "faster, better, cheaper"
and that it was a failure.
No, it wasn't.
If you look, in fact, at what Dan Goldin said,
he said, you know, "We're gonna do more projects.
"We will have more failures,
but at the end of the day, we will have achieved more."
If you look at the statistics, the statistics on that
were exactly what Dan Goldin said they would be.
He said, you know, "We're gonna probably lose 3 of 10,
but we'll do 10 rather than 5."
So, that led to -- But in that mentality,
program managers drove cost down.
There was no -- There was no place where you could say,
"Good enough on cost."
It was, you know, cheaper, cheaper, cheaper, cheaper,
and we got to a point
where we pushed ourselves off a cliff, perhaps.
But, still, we did 7 out of 10.
So, see, you got to understand that dichotomy and the brain
between the program manager and the systems engineer.
And getting that balance right, in my experience,
is the single most important thing
that systems engineers do for the success of the program.
So, I'm gonna stop the theory
and go to a couple of --
Let me get -- I'll get this one.
Sorry.
[ Speaking indistinctly ]
So, I'm gonna tell you two stories
because I think that stories about systems engineering
are the best way to learn about systems engineering.
I'm gonna tell you two of my stories, two of my experiences,
and then we'll talk about them and see what you think,
maybe how things could have worked out differently.
The first story I'm gonna tell you about is this one.
Some of you were here and some of you weren't here
in the day that we got the first images back
from the Hubble Space Telescope.
I was up at Johns Hopkins,
at the Space Telescope Science Institute,
and the images came back down.
And they were supposed to look like the ones on this side --
on my side --
and the images looked like images on the left side.
The Marshall team was down.
They were thinking, "Well, we're just not focused.
If we can -- You know, there must be some alignment problem."
Worked and worked and worked, and the more people worked,
the more they realized there was something fundamentally wrong.
I was down in the basement of the Science Institute,
sitting with Dr. Chris Burrows.
Chris is an interesting guy. Chris was at ESA.
There was about 15% ESA membership
up at the Space Telescope Science Institute at that time.
And Chris was an engineer,
but -- oh, he's an astronomer and astrophysicist, actually.
But Riccardo, the director, said,
"You need to learn some technical things."
So he gave him Born and Wolf, and Chris went back
and read it -- on optics -- over the weekend.
He came back, and Riccardo said, "You finished it already?"
And he said, "Yeah."
And he said, "So, what do you think?"
He said, "Well, on page 247, the guy's really wrong.
He derived this incorrectly."
So, you can understand Chris really knew stuff.
He was I think the youngest PhD at Cambridge since Isaac Newton.
So, Chris had written this program.
And I said, "So, what are you looking at?"
He said, "Well, I'm just analyzing things,
"and there's a fundamental flaw in the mirror.
Basically, the mirror, I think, has spherical aberration in it."
Well, this is the first I've heard about spherical aberration
in the telescope, and it was a --
So, I said, "So, what do you do about it?"
Chris said, "Well, there's nothing you can do about it.
It's built into the mirror, and you can't adjust it out."
Those were dark days for a lot of us.
It resonated with the country.
The Hubble Space Telescope had been --
I don't want to say hyped, but certainly anticipated.
The day before launch, Bryant Gumbel had been down.
They did a special broadcast.
Everybody was looking forward to Hubble.
You know, people in the general public
like astronomy and telescopes.
They can understand it. They can see the pictures.
And so this was gonna be discovering
the secrets of the universe.
And so when it became apparent
that there was a fundamental flaw in the system,
this was the type of press that NASA was getting.
And it was not fun
to be part of the Hubble Space Telescope program at that time
for any of us, in academia, where I was at the time,
or industry or in the government, certainly.
You remember, this was coming on the heels --
We had -- This was the second return to flight
after the first shuttle accident.
People were thinking, "NASA's lost their way.
They just can't do the big thing anymore."
And I would say systems engineering
would be at the heart of that.
So, being a systems engineer,
that kind of struck really close to me.
So, what do you do about that?
Well, interestingly, some --
Dr. Holland Ford at Hopkins and Dr. Bob Brown said,
"Well, you know, there's a lot of us who've spent our life
"working on the Hubble Space Telescope.
"We should put a team of people together --
"industry, NASA, academia -- Let's go broad.
"I mean, ESA is 15% of this. Let's go get Europeans.
"Let's get the best engineers, opticians --
"everybody in the world --
"and let's go systems-engineer this thing.
"Let's figure out how to fix it.
We're not gonna --"
or as Gene Kranz would say, "Failure here is not an option.
"We've all invested
"too much of our lives and careers in this mission
to possibly not do everything we can to see how to fix it."
Well, in fact, there was a path already going down.
JPL was building the Wide Field Planetary Camera 2,
which was a replacement for the one on board.
And it was serendipitously fairly straightforward
to make a correction in the Wide Field Planetary 2 instrument
to cancel out the error that was made in the mirror.
The mirror was, in essence, as I'm sure all of you know,
was ground incorrectly
because the tool used to make the telescope was --
to make the mirror had been set up incorrectly.
So, you can take a 6-inch ruler that's incorrect
and you can cut a 6-inch board all day long
and you will cut it wrong.
And what's exactly what they did.
They cut, cut -- cut, check, cut, check,
but they were using the wrong tool to do it.
So, this --
Charlie Pellerin thought this was a really good idea.
Charlie ran the -- He was an associate administrator
for Space Science at the time.
And Charlie supported this, he funded this,
and we had several meetings to go out and figure it out.
Now, there was a pretty interesting approach.
This document -- Actually, I Googled it --
You can get it online now --
talks about the process, the systems-engineering process
and the creative process that was put together.
And I think what -- We finally got to a solution,
and it was a bigger solution
than just "Replace the Wide Field."
You see, astronomers were on this committee, as well.
And what the astronomers knew
was you can't do astronomy and astrophysics
with just an imager.
You have to have a spectrograph.
The science comes as much or more from the spectrographs
than from the imager.
So, had we rushed up
and just put the Wide Field Planetary 2 replacement in
on the first servicing mission
and changed those two instruments out,
we would have maybe had a P.R. success,
but we would not have had a scientific success.
So, "How do you fix all the instruments?" was the problem.
So, the first thing that we did was all of the --
The team really focused on the optical solution.
It was an optical problem,
so we got locked on to the optical solution.
Peter Drucker, who's a great management guru,
said, "It's more important to be doing the right thing
than to be doing things right."
Now, at the end of the day, you have to do both.
We weren't doing the right thing.
You would think, from a systems-engineering perspective,
that, "Well, you focus on the optical solution."
When I walked in the room the first day, I looked around,
and I knew some of the people in the room
were eminent optical engineers
from Europe,
from the U.S., people from JPL.
And I thought, "Man, you know, I'm an electrical engineer.
"I know a little bit about optics,
"but I'm not gonna be able to work on that problem,
"so I'm gonna think about a different problem
that maybe I can work on."
But they did a phenomenal job. They basically did all the math.
They said, "You know, there's three places we can fix this.
"We can fix it in the far field
"by putting some sort of corrector plate
"in front of the telescope.
"We can correct it in the near field,
"do something between the primary and the secondary.
"We can do three plates.
"Here's this elegant three-plate solution
"that'll allow you to correct the aberration.
"We can do it in the instrument field,
"you know, like the Wide Field Planetary Camera 2,
"where we correct something in the instrument.
Or we can actually do something in front of the instrument,"
and, in fact, it was Dr. Murk Bottema
at Ball Aerospace
who had this rather interesting design
for a two-mirror corrector system.
But the problem was we also had an astronaut --
Bruce McCandless -- who was on this committee.
And as we put these ideas forth
and ran the math and showed the sensitivity
to thermal and vibration of all these different designs
and got the best one for this, they turn to Bruce and say,
"So, Bruce, how would we put this in the telescope?"
Now, McCandless, as you probably know,
was on the first deployment mission, but Bruce had worked on
making sure the telescope was serviceable
and how to do things for, really, 10 years before the --
more than that before the telescope was launched.
So, Bruce knew the Hubble Space Telescope intimately,
and Bruce would say -- as any astronaut would say --
"Well, I can do that, but they won't let me.
"They won't let me because it's too fragile
to carry up to the shuttle,"
or, "They won't let me because it'll place the crew at risk,"
or, you know, "You're gonna ask me
"to go down the barrel of this telescope,
"and, you know, they're gonna be worried
"that I'm gonna snag my suit or can't get out.
So, we can't do it."
So, the very first time Bruce said that,
I said, "Ah, I know what I'm gonna work on.
"I'm gonna think about not the fix
"or which of the fixes that have been proposed,
"which are about 30 or 40,
"all of which would 'work,' theoretically.
"I'm gonna think about, 'How would you do the fix?'
"And I'm gonna do my trades based on,
'Which one of these are easier or actually possible to do?'"
So, as I went down that route, there was another problem.
So, we had all these trades.
We had done all the trades
on what was the best optical solution.
I started doing trades on,
"Okay, which ones were implementable?"
and the problem was -- none of them.
Not a single one of the ideas that had been put forth
were doable.
The corrector plate, which everybody loved on the front --
I mean, it was just -- I don't know -- three meter in diameter,
a 1/4-thick magnesium fluoride.
I mean, how hard could that be to build
and then carry up on a shuttle without breaking it
and figuring out how to put it in place?
So, each one of these, I went through.
I had built models of the focal plane out of Styrofoam.
I'm a really great model guy.
When I think about things, I like to see them.
I built things, and so it's going on and on
and couldn't figure out how to do it.
Had an epiphany in a shower in Munich,
where we were having the last meeting,
where the maid had actually left --
You know these showers in Europe?
They go up and down, and they --
on the little rods that slide up and down.
You see them here now,
but in the day, they were kind of unique.
So, I did this and slipped it out,
and when I did, it just dawned on me
that I had to get into a different thinking space
to solve this problem.
And the different thinking space was,
"What if we sacrificed one of the instruments?"
There are four instruments in the aft shroud of Hubble.
If we sacrificed the least usable, the one most affected,
which would be the high-speed photometer,
we could put a new instrument in,
and all those optics could be in that instrument.
And then, just like that shower,
they could deploy out and put the corrective optics
in front of the other instruments.
So, that's -- This is what --
Because I built these models,
I knew that the focal plane of the telescope, where these four
telephone-booth-sized instruments came together,
was really only about the size of a large pizza.
And all of the apertures for each one of the instruments
were fairly close together,
I mean, within an area about this big.
So, if we took one of the instruments out,
packaged these optics in it, put the instrument back in,
it could then flip out these corrective optics
in front of the other instruments.
And when I put the chart up,
McCandless' face got really -- He said, "That'll work."
He said, "That'll work because that's the way
we designed the system to be serviced."
So, what we had done was we had all been focused on
the optical solution, which wasn't the problem.
The problem was different.
The problem was,
"How do you get the correction into the telescope?"
And that came up with the idea of COSTAR.
And as a matter of fact, if you walk down the block
just a few blocks and go to the Smithsonian,
this is a picture of COSTAR
now deployed over in the Smithsonian --
because on the last servicing mission,
when we took the last instrument out,
all of the new instruments had this COSTAR correction
built in to them.
So, we don't need COSTAR anymore.
MAN #2: ...taken it someplace. I'm not sure where.
CROCKER: Taking it someplace --
MAN #2: Yeah, I was just down there week before last.
CROCKER: Oh, they're gonna move it over to where the telescope is.
MAN #2: So they've got it packed up.
CROCKER: So they got it packed up.
Okay. So, you can't look at it.
But -- So, that was kind of one thing.
So, the first lesson I got from this is,
"Make sure you're solving the right problem."
It's so easy to get locked in to solving a problem
that you know how --
It's sort of like, you know, when you lose your contacts
or you lose something and it's dark.
You want to go look for it by a streetlight.
It's really easy to get locked in to doing something
that you know how to do,
as opposed to solving the real systems-engineering problem
and trade of understanding what the real problem is.
And so, that was the lesson for me from COSTAR.
The other thing is one about leadership and salesmanship.
When we proposed this idea, we all thought --
I mean, it was so hard to get here.
We thought it was --
We thought it was just the obvious solution.
When we tried to sell that,
we got a million reasons why you shouldn't,
and the one that was the most powerful,
the one I had to think about the most was,
"Well, wait a minute.
"If you put this in the telescope
"and you deploy all these arms
"and you can't get it out of the telescope
"on the next servicing mission,
"we've not only lost -- or it doesn't work --
"we've not only lost this instrument.
We've lost all the actual instruments."
So, we thought about all of the secondary implications,
the unintended consequences of putting COSTAR in.
And we had a simple solution, and that was the --
by some simple design features, we eliminated that problem.
Number one -- each of these arms
naturally would have a dual redundant motor
to deploy it or stow it.
But if both of those fail, there's a little shoe here.
And when you retract the tower,
those little shoes flip each one of the mirrors up.
And then somebody, we knew, would say,
"Well, so, what if you can't retract the tower?"
We said, "We'll have a dual winding on the motor,"
but on top of that, there's a 7/16-inch bolt.
That's what the astronauts use
to actually install all these instruments.
You run that bolt back.
It turns the whole motor arm --
not the motor itself, but the whole casing.
So, even if the bearings were frozen up,
it would pull this back.
So, we had anticipated what the objections would be,
and we had simple --
I mean, this didn't add anything to the design on the front.
Putting a shoe on this, on the front end, cost nothing.
Putting a 7/16-inch retraction
that'll pull the whole thing back
when you're doing the design really was a design issue.
It cost nothing. So, it added nothing.
Now, to do it on the other end
would have been enormously expensive,
so we had thought about that.
So, as I think all of you know,
the Wide Field Planetary Camera was successfully installed
along with COSTAR on the first servicing mission.
I think we did this in 30-some-odd months,
from the time we started till the time we got it done.
But to me, it was --
The two big lessons that I learned personally out of this
were -- number one -- it's more important
to be doing the right thing than to be doing things right.
At the end of the day, you have to do both,
but if you're not working on the right problem,
you will never get to the right solution.
And then secondly, part of systems engineering --
particularly a new approach to doing something --
you really have to think through this whole thing to the end.
What are the objections gonna be not only from a technical,
but from risk -- particularly from risk?
And there's also the political environment
that you're working in.
NASA at the time could not afford a failure.
We could not go up and service the Hubble Space Telescope
and fail.
I mean, quite literally, the --
we were betting the agency that this would be successful.
Three -- Three strikes, and you're out.
I mean, if we were not successful --
or even the perception of not being successful --
it could have been a very bad day.
So, that's COSTAR, and let me --
Of course, it was installed on the first servicing mission.
K.T. was able to use the standard procedures to go in.
She pulled the old high-speed photometer out,
installed COSTAR, deployed it,
everything came up, and it worked
because this was the way it was designed to be serviced.
So, we took advantage of a built-in design feature.
And then on the last servicing mission that we just completed,
COSTAR was removed,
and the Cosmic Origins Spectrograph
installed in its place.
And now, for the first time, we have the real power of Hubble,
all five of the science instruments working on Hubble,
and returning phenomenal research.
Let me tell you about one other interesting story,
and it's about -- I'll be brief on this.
I want to talk just a little bit about
the James Webb Space Telescope.
I could spent a lot of time talking about Webb,
but let me just tell you one story.
The challenge with Webb,
the challenge with the James Webb Space Telescope,
fundamentally was, "How do you package a cryogenic --
"at the time -- 8-meter telescope for launch
"in such a way that you can reliably deploy it
at the end of the day?"
And there were several designs.
I won't go into all of them,
but there were three kind of fundamental designs
at the end of the day.
One was called the heart,
which was hexagons that kind of, you know, unfolded.
One would flip over. Another would flip over.
And you'd stack them like potato chips.
The interesting thing about that approach
was that was the most volume-efficient way
to package an optic --
basically to stack them like potato chips
and then...unfold.
There was another one that was interesting,
and basically, you know -- Mirrors are mirrors.
Another that was interesting
was basically one that was a kind of popular design.
It had never been flown, but people basically took the mirror
and they broke it into a fold-up, fold-down petal.
So, that was the fold-up, fold-down petal.
That was pretty good. Basically, you get up there.
The secondary mirror is fixed on a tower
and basically you fold these two up and these two back,
and you got a mirror.
And that was kind of the --
kind of preferred thinking in the design.
There's two problems with that.
One is you've got --
Actually, it was three petals up, three down.
So you got six deployments.
And if any one of them fails, you have a problem.
With the heart approach, the hexagon approach,
I think there were 38 deployments that you had to do.
So, I'm using this paper plate
because the late Wally Meyer from Ball
and Bob Woodruff, who was a fabulous optical designer,
and myself were sitting in the back of the room up at Goddard
when they were having the industry day,
and we're thinking about this.
And we were thinking,
"Okay, we know a lot about the requirements for this telescope.
"We have to quit thinking about, 'What's the way you fold it?'
"and think about, you know,
'What's the right way to be thinking about this problem?'"
And it's really twofold.
The two biggest problems you have to solve
were -- number one -- How do you fold it
so that you can deploy it the most reliably,
with the fewest number of deployments? -- number one --
and number two -- This is a cryogenic telescope.
It operates at -- you know, in the -- several --
a few 10s of Kelvin degrees.
And so the other problem's gonna be the --
the thermal connectivity of the back plane.
You get a degree-or-two difference
across the back plane,
because of its conductivity and it's not gonna hold its shape.
So, there were some pie plates.
You know how hard it is to find these today?
You know, these were in the back of the room
at Goddard at the time.
So, I went up and picked up a pie plate.
I said, "You know, Wally, if we fold it like a table,
like one of these drop-leaf tables, then --"
As a matter of fact, if this is the reflective surface
and then the secondary is on a three-bar linkage,
then to really get a really good 4x8-meter telescope,
you just got one deployment.
Basically, the secondary has got to flip down.
And then, if the two wings do deploy,
then you've got a full 8-meter telescope,
and we've done it with three deployments.
And that was like half of anything else.
But the most important thing
was every other design tore the back plane.
And when you tear a back plane,
you got to put the thermal conductivity back together.
So, you're dependant on some sort of connection now
that you got to remake for the thermal conductivity,
whereas if you fold it,
you don't have to tear the back plane.
And you could even imagine
having a copper strip down the fold here
so that you can have
a continuous thermal back plane across it.
So, in essence,
although Ball teamed with TRW and this sort of thing,
that -- that -- that concept of the design actually survived.
And so when you look at
the James Webb Space Telescope today,
you'll see this cord fold, we called it,
or drop-leaf-table fold.
And the way we got to that design
was thinking about what the real problem was.
Here again, if you're designing a telescope,
you get locked in to the optical design,
and you missed the fact that, for this application,
the optical design was interesting,
but the how to fold it
and package it for maximum reliability on deployment
and, at the same time,
how to get that thermal conductivity of the back plane
were the two deep systems-engineering requirements.
So, the thing I learned, here again, from this is,
it's more important to be doing the right thing
before you do things right.
And so both of those were really --
really a great education for me.
So, you can see how the telescope is stowed,
and basically the three-bar linkage deploy is the secondary.
Once that happens,
you got a really good telescope at that point.
I mean, at that point, you've got a telescope
that actually performed about 80% of spec.
And then you deploy the two outlying wings,
and you got the whole thing.
So, systems engineering is an art,
and I say it's an art
because it's -- it's art in the sense of practice.
You don't learn to play an instrument by reading books.
You learn to play an instrument by playing an instrument.
And if you're gonna play in an orchestra,
you learn to play an instrument by playing with others.
And the thing that I like most about these stories is,
is that you're playing with others.
It was -- It was not --
When you look at both of these in retrospect from this side,
well, of course that's the way you would do it.
But when you look at them from the other side,
when you don't know how to go install this thing,
it's -- it's different.
It's -- It's -- It's -- The best solutions are,
"Well, of course you would do it that way,"
when you figure it out.
But trying to figure it out is not easy.
So, getting your mind into a systems-engineering approach
of "What's the right question to do this?" --
I think if you just take one thing away
from what I've told you today,
it's more important -- or first, I would say,
make sure you're doing the right thing
because you can't do the wrong thing right,
no matter how hard you try.
So, with that, I'd like to spend a few minutes with questions
and plan to take -- You can play "Stump the Speaker."
Is there a mike? Do you need a microphone or...?
WOMAN: Is there...
MAN #2: Under the table.
CROCKER: [ Speaks indistinctly ]
MAN #3: Jim, I'm gonna make an observation on all this.
It's that no matter how --
no matter how obvious that thing looks now --
And, you know, you made pretty light
of how hard that thing was to build.
CROCKER: Yeah.
MAN #3: And over and above the fundamental systems,
there was a lot of work that went in
to try and figure out just how to make that thing work
when there wasn't a better way.
CROCKER: So, I'll tell you just two quick stories on that.
The other thing you had to know about COSTAR
was we had to have a really deep understanding
of what was possible.
The optics on this telescope were state-of-the-art.
They were as good as engineers could achieve,
the laws of physics would allow.
Let me just tell you a little story about these optics,
which are the size of nickel, dimes, and quarters.
Well, the guys assured me that the optics were doable.
So, of course, when you come up with an idea,
I got asked to be team leader to go build this thing.
So, we've put out a contract to HODS, Kodak -- Kodak, HDOS,
and UTOS to build these optics.
We were gonna let -- There were three sets.
We were gonna let each team start with a different set,
and whoever got them first, we would take them.
We had to have these optics.
Well, they started making these optics,
and they couldn't make them.
"Well, why not?"
So, I fly out there and I start listening to the presentation.
And the guy said, "Well, it's because
they're anamorphic aspheres on a toroidal blank."
I said, "Okay. So, tell me what that means."
"Oh, they're potato chips." I'm like, "Oh, okay."
So, we got to make an object
that's like got a different radius of curvature
in this direction and in this direction,
and we have to polish them
to three angstroms RMS surface roughness.
I mean, that's like, you know, three atoms out of place.
And so they couldn't do it.
Well, Frank Cepollina -- Frank comes up to me, he says,
"Well, you know, there's this little company out in California
"named Tinsley.
I think they can make these optics."
So we get on a plane and we fly out there, and they said,
"Yeah, we can make those."
And I said, "Well, show us how." They said, "We can't."
"What do you mean, you can't?"
"Well, we do it in this back room."
So, we thought, "Man, this is gonna be expensive
because we got these other three contracts."
"Well, give us a price."
Well, they came back and said,
"Well, we'll make them all for --
I don't know -- $250 million -- $250,000."
I was like, "Wait a minute.
That's less than -- These guys can't know what they're doing."
It's less than what any one of the other vendors
was charging us for one optic."
Anyway, long story short, they went in the back of the room,
they came out, they made all the optics, they did in time.
All the other three vendors failed.
That's how close we were.
If we hadn't have found Tinsley,
we wouldn't have been successful.
The second thing that made this hard
was we had to know where the entrance apertures
to the other instruments were... to 0.1 millimeters.
And we're thinking, "We're not gonna be able
to get that accurate enough for drawings,"
until I ran into the cafeteria to Olivia Lupie.
Olivia was with the high-speed-photometer team,
the instrument that we were taking out and sacrificing.
They were pretty upset with us,
that we were taking their instrument out
and sacrificing it to put this in.
So, I was talking to Olivia,
and I don't know how this problem came up, but she said,
"Oh, that's not hard."
I said, "What do you mean, it's not hard?"
She said, "Ooh, ooh, ooh," and she gets real excited.
She said, "That's what I've been doing for the last 10 years."
"What? What?"
"Well, the P.I., Bob Bless, hired me
"because I have to know where every one of those apertures are
"because the high-speed photometer --
"Basically, you're gonna be looking at a star
"with another instrument, and then I have to --
"I wrote the software to send a command
"to not only move that star
"into the high-speed photometer aperture,
but to a particular filter in there."
She said, "I know all of this to 1/10 of a millimeter."
So I said, "Oh, you're on our team, Olivia."
So, Olivia came in there.
So, a lot of this was communication.
If we'd have tried to this on our own, we would have failed.
"Cepi," at Goddard, knew these instrument vendors.
They'd been building all of these instruments.
Olivia knew -- had been working for decades to get all this.
So -- So, how to deploy it, how to get that right,
how to get the optics right, how to hold this thermally --
So, we were -- It was a real study in communication
and reaching out to the industry.
But the thing we had was --
Everybody working on that program then and today
were building a cathedral,
and everybody really got together to make it work.
But this was really hard. It was really hard.
We were very fortunate that we were able to pull this together.
It really took a team of an incredible number of people
to make this work.
Yeah.
MAN #4: Question --
and it'll probably be real hard to answer --
but oftentimes, even throughout history,
not just what we're doing at NASA,
serendipity occurs, you know?
Stuff happens, and -- and fixes arise.
You know, you mentioned communication.
What are some other things
that would kind of help foment serendipity?
Because it seems like a lot of success comes out of that.
CROCKER: There's a --
I couldn't agree with you more about the serendipity part.
I'll say two things about it.
One is -- There's a wonderful series --
There's actually a book.
There's also an NPR series called "Connections" by Burke,
and he talked about how coal miners in Wales
ended up needing a pump, and because of that,
it really led to the development
of the internal combustion engine.
So, you go on, and there's these serendipitous things.
My experience is --
As a matter of fact, there's a recent book out
that actually says the rise of humans as a species
actually came about because of trade,
because cities actually formed as trading centers,
and ideas spread like viruses.
So, somebody who was building boats
would learn about something that somebody was doing
building carts, and so it was --
This serendipity actually led to an explosion
and to why humans dominate the planet.
I don't know if I believe that or not,
but that's some related stuff --
theories in anthropology.
So, I think that to help that process,
two things have to happen.
One -- systems engineers,
who are usually the architects of these systems,
need to be more than broad across their discipline.
They need to be broad, broad.
And by that -- I mean, if you look in my briefcase,
I'm reading "The Power Broker,"
which is about politics in New York in the '30s.
And I'll tell you -- if you don't think that what we do
has some political side to it, mm, you should think again.
And another book is "The Cambridge Lectures" by Hawking.
And so I think that, first of all,
you got to get out and read what's going on
or has gone on across a number of fields.
When you look at --
When you look at new ways of doing things
that come into a field, they usually come from another field.
So, you just need to be broad in your reading.
But secondly, it's this kind of interaction.
It's getting people together and telling their stories
about what worked, what doesn't work, this sort of thing.
And it's like -- I mean, I'm so pleased to see --
having somebody from GM come in and speak
because, I mean, the automobile industry
is going through a revelation --
a revolution in innovation right now,
as they switch to electric vehicles
and, you know, the thinking of how to put all of that together.
So, it's a really hard question, but I think that we're driven,
because of being engineers, to go deep into something.
We have to want to get out and go broad.
And in fact, the best systems engineers --
I personally think --
are those who just have an immense amount of curiosity.
When you go up to something
and you see something that's nothing to do
with anything you're doing on a day-to-day basis
and you don't understand it
or you don't understand why somebody does it that way,
you just have this burning desire to say,
"Gee, I wonder why they need it that way."
And so I think it's that desire
that sets the best systems engineers apart,
that they really don't like anything they don't understand,
why somebody did something that way.
There's almost always a reason
for the irrational rationality of humans,
and it's usually not irrational when you get to the bottom.
It's just getting to the bottom is really hard.
MAN #5: I just have a comment.
I'm working on the JWST,
and I'm the lead mechanism engineer for optical telescope.
And I know that it's a nightmare for mechanism engineers.
CROCKER: That's why you want the fewest number possible.
MAN #5: Yes, because each --
got 18 segments in each of the 7 actuators.
And not only that, but that portion works with cryo,
but the electronics is on the warm side,
underneath the sunshield.
CROCKER: Hardest telescope ever been --
MAN #5: Yes.
So, I mean, I'm -- I like to have a success
'cause I don't want my name
to be in "The Washington Post," okay?
[ Laughter ]
But it's a really -- I think it's a --
We are cutting into the edge of technology
to drive not only the actuators,
but how we can do the radiation-wise, thermal-wise,
and electrical-wise, that we can drive this mechanism
as well as the optics to get a better picture than Hubble.
CROCKER: Yeah, James Webb is an incredible, incredible machine.
And the -- At the end of the day,
cryo actuators of the kind of precision that you need
are incredibly challenging, never been done before.
So that's why -- And knowing that,
having built cryo instruments previously,
I knew that the minimum number of actuators
would be a good thing.
MAN #5: So, right now it's almost 138.
CROCKER: And most of those are on the...
-MAN #5: Primary segments. -CROCKER: ...primary segments.
There's an old story -- Talking about connectivity,
do you know where the primary segments came from for Webb?
So, I was sitting down.
I got asked to go over by Riccardo Giacconi,
who was head of Space Telescope Science Institute,
who is Italian.
He got asked to go over to Europe
because they had a program over there called the VLT.
It was $1 billion over budget and slipping year after year.
So, Riccardo called me up, and I went over there.
Long story short, one of the major problems with the VLT
was the secondary mirror.
The secondary mirror had to chop at like 30 hertz,
and basically this 8-meter telescope --
and the secondary mirror's like 1.1 meter and weighs a lot.
And so when you chop at 20 hertz,
it shakes the whole telescope.
So, we had to do something lighter.
They were trying to do it out of silicon carbide,
but they couldn't make silicon carbide, and it cracked.
I said, "Well, let's do it on beryllium."
And everybody looked at me like I was an idiot.
And I said, "Well, no, beryllium would be great
"'cause it has the lowest Young's modul--
"had the best Young's modulus
and you can machine it and light-weight it."
So, we made these 1.1-meter beryllium secondaries
for the VLT.
We made them on time, on schedule.
We put them on the telescope.
They chop them. They're lightweight.
They're stiff. They don't move.
And so when we were sitting in the back room, Wally said,
"So, what kind of -- "Everybody's using zero..."
I said, "Let's not use zero... That would be the wrong thing.
Let's use beryllium."
He said, "Well, gee, that would be really hard."
I said, "No, no, it's not hard. You go to Brush Wellman.
"See, so we had developed this supply chain,
"So you go to Brush Wellman.
"They got this spherical HIP powder.
"You can HIP it, and then you can machine it.
"And the guys that machine it are down at Axsys --
"what used to be Speedring -- down in Cullman, Alabama.
"And they just made these mirrors for the VLT telescope,
"and they're all set up to go.
"And then we'll take it out to Tinsley
"because Tinsley can actually polish these beryllium
"because when we were out there
"building the Hubble Telescope mirrors,
"I happened to look in there,
"and they were building this beryllium stuff
"for another customer, who will remain nameless.
And so I know they can do that."
So, here again, it was that serendipity connectivity
because if you try to go sell a beryllium telescope
and you couldn't point to the fact that there's already --
I mean, the TRL level would have been considered,
you know, insane because we had --
serendipitously, we had developed
these beryllium mirrors on another telescope.
So -- But...
So, serendipity.
MAN #7: Question here.
I guess my question is geared more toward trying to dig out
some insights about collaboration
versus intellectual-property protection.
And we're moving into a new era,
where we're trying to spur the growth of commercial sectors,
particularly for space launch.
So, as we're starting to think about those things,
I know that various companies out there would love to see
intellectual-property protection on our part
so that there could be a competitive advantage for them.
That apparently rolls back
to what we do on a day-to-day basis.
And yet and still, us systems engineers --
we really want to talk about these things
because it's the sparks we get from others.
Could you share some insights of maybe your spin
on where you think NASA could or should be?
CROCKER: So, the question is intellectual property,
and it's a great question.
Let me start by recommending a book to you,
and the book is called "The Birth of Plenty"
and it asks the fundamental question,
"What happened in the late 1700s
"that caused an acceleration in people's lifestyle worldwide?
"What happened?
What were the things that came together?"
Because for millions of years before that,
I mean, fundamentally, people lived at --
99% of people lived --
99.9% of people lived at a subsistence level.
So, the book explores the things that came together that changed,
revolutionized things, and I won't list them all.
I'll just tell you one. One was property rights.
And basically, if I can have a way
where I'm legally protected
so that the fruits of my invention are protected,
it encourages me to go off and do something.
Many systems in countries before that time, if --
As a matter of fact, my grandfather --
my great grandfather claims to have invented --
and I don't know this,
but he claims to have invented the Cullman planter,
which was a seed planter that kind of revolutionized planting.
And it was stolen from him, okay?
So, that was kind of the -- that was kind of the --
a way that things work.
I mean, the law did not protect property rights,
either land or, particularly, ideas.
The first telescope actually was patented in 1608
by Hans Lippershey in the Netherlands.
He didn't get the patent because they said, "Oh, gee.
I just put two -- I mean, how could that be?"
I mean, he didn't invent anything.
He just put two pieces of glass together.
Truth of the matter is, they saw the military application,
and they were hoping to keep it quiet
because you didn't -- spy scope? Right.
So, this whole thing about property rights
really comes down to a deeper level
of you want to share things, all right?
But when you don't have the ability for companies
to have property rights,
then you won't get investment from companies.
So a company's not gonna put $100 million into something
unless they can protect that investment or those ideas
in one of two ways -- one is trade secrets.
They just don't tell you what they're doing.
That doesn't work well in our environment
because we want to know what you're doing
because we want to know if it's going to work.
Because just because you're building a rocket
and you might give me the rocket,
I'm gonna put a billion-dollar satellite on it.
So I want to know that your rocket is gonna be successful.
So, the way this has kind of worked itself out in our society
is in academia, people get rewarded for publishing,
so you get tenure because you shared your ideas,
and that's how you get rewarded.
In the industrial side,
basically you spend your money, your time, and your investment,
and you get intellectual property.
And so that's how you get rewarded.
I do work IRAD with a number of universities,
and the biggest problem we have with universities
is getting the property rights to the IRAD worked out.
They want -- Some universities want you to give them money
and you do the research and then they'll publish it,
but it's hard to convince a stockholder
that you should give me money so I can give it to somebody else
so they can share it with everybody.
So, this is a really hard problem.
So, however, what I believe is, is that there's -- there's --
The way you approach this is in two levels.
One is basic research.
You really don't know what the application is.
You're doing basic research maybe to get some aha's,
and usually when you get basic research, it's the --
that's 10% of the problem
getting it to a commercializable, usable form
where all the money gets invested.
So a lot of times the TRL-01 things,
you know, people kind of share that
because it leads to these serendipitous things
and that sort of thing.
But above that, it's very hard to do.
I don't know how you do it
because you got to tell me what the incentive is
because there's certainly an incentive on the user side
to get as much "free" stuff as you can,
but that incentive is a little shortsighted
because what you really want to do is have companies invest
either their own money or their own IRAD
or, if nothing else, then their "A" team
to be working on your problem.
But if they don't walk away with something from that,
they have a hard time explaining it to the people
who pay their salaries or to the shareholders who support it.
It's a really interesting problem,
and the only way I've see it really work in the long term
is, at the end of the day,
somebody has to walk out with something
that has either trade secret or an I.P. --
intellectual property to it.
Otherwise, it's like the...
If you think you're going to invest
all of your time and effort into this,
and then you will have no fruits of your labor at the other side,
it will stifle creativity and innovation.
[ Speaking indistinctly ]
MAN: Your speaker today is Mr. Robert Vitale.
He's the Senior Staff Research Engineer at General Motors.
Worked a lot of advanced technology vehicle concepts,
including the Hy-wire concept.
I don't know if you guys are very familiar with it,
but if you Google it online, there's some great videos of it,
drive-by-wire fuel-cell propulsion.
He followed that up with some work on the appropriately titled
Sequel hydrogen vehicle
that was the first to travel 300 miles
on a single tank of hydrogen -- interesting there.
And currently he's working on extensions of those --
fully electronic vehicles with autonomous controlling.
So, please welcome Robert Vitale.
VITALE: Thank you, Chris.
[ Applause ]
Thank you, everybody, and thank you for the opportunity
to come and present to this prestigious group.
When I got the call from my boss,
who actually couldn't make it today
because he was flying in from Shanghai,
asked me if I could come in and talk about
some of our projects and some of the concept processes
we do within General Motors, I jumped at the chance.
What I wanted to do today is bring things down
from the Hubble level down to the ground level
and talk about some of the things
that we do at General Motors.
It's great to talk to a sister division, by the way.
But basically what we -- what we have within the corporation
is a process by which we go through,
and we look at a lot of ideations
and where do ideas come from.
I'm sure that in the process of going through your program here,
you run through those issues and those questions all the time --
where do the ideas generate from, how do they get started,
how do they get grown, how do they get wrapped around,
how do they get produced, and how do they get promoted?
So, basically what we do within the company
is start with a concept initiation.
This is a very fundamental term every engineer
and everyone developed or working in engineering
understands and starts to learn through experience.
I've been with General Motors 34 years.
I started R&D back in 1976
and grew with the company
and learned quite a bit about this type of approach.
I also am a EE by academia and training,
but during the process of my 34 years,
I learned to be an M.E., I learned to be a manager,
I learned to be a promoter, I learned to be a marketer,
and I learned to be quality.
So I sort of kind of have been fortunate
to wrap a lot of those areas within my understanding.
So, where do we start within GM?
We start with a kernel or an idea,
and that kernel generates a lot of talk,
a lot of buzz among different groups.
The kernel generated from any number of sources.
Many times it comes from leadership,
and leadership being our directors --
anywhere from our board of directors
down to our immediate bosses.
It comes from engineering that have the "aha" moment
as we discovered something or we thought of something
that can fix an issue or enhance an issue.
It can come from marketing.
Our marketing department within General Motors,
like any other motor company,
constantly looks at what the competition's doing
and what the customer and what the market trends are doing.
And sometimes it comes from customers.
General Motors, for a number of years,
has an open policy of looking at ideations or ideas
sent in by customer base,
and we've recently, since we've reorganized
after our bankruptcy last year,
we've really -- And you probably have seen this in the media --
we really have hyped up
our interface with customers significantly
to the point where our North American president,
Mark Rice, is out at dealerships
talking to customers on base levels,
getting ideas, and getting input and feedback.
So, this kernel, or these set of kernels or set of ideas
are sort of kind of gathered together,
and much like I was listening to when I got here earlier today,
gets into generating different ideas, or brainstorming.
Everybody knows the term "brainstorming."
Every engineer knows the term "brainstorming."
We go through, we look at those ideations,
and we build variants around those.
So we take a single idea, and we tear it apart.
We try to see how many fathoms there are to that idea,
and what are variants approaching?
Where do they work with? Do they approach technology?
Do they define a need or satisfy a need?
Do they look at performance or customer experience?
So, unlike your organization,
you have a pretty finite set of customers.
Whereas, with an automotive company,
we have a very wide base set of customers,
everybody that drives a Cobalt to a Cadillac.
So, there's a number of ideas that we look to
to brainstorm to satisfy that wide bandwidth.
After we've gone through
a number of brainstorming processes,
and I've done brainstorming sessions,
which everybody here has done.
They've lasted a half a day, or they've lasted a full week,
depending on the bandwidth
of the ideations that we were developing
and the areas of the corporation
or the product that they would hit.
Once we get past that phase,
we go through what's called the down selection,
and we allow the really premier ideations or innovations
to start to bubble up to the top,
and at that point in time,
we sort of kind of garner these and template them,
and we start a project initiation,
where we begin our project to start scoping out
how we can move these ideas or these new innovations forward.
So, the most feasible solutions we look at can --
These are just three bullets
I've just sort of arbitrarily picked.
They can be new technologies, they can be benefits,
or they can be viability.
But there's many other bullets out there
that can support the development
or down selection of the brainstorming areas.
We use a little process called the three I's --
insight, invention, and integration.
These three I's
are what we start to build our project around.
We start with our insight --
in this case, understanding our customers,
understanding their needs, understanding their wants,
understanding ideas that come from customer-based approaches.
From insight, we move into invention.
We know if we have a series of ideas
that are sort of kind of already been out there a little bit
and we want to expand on them
and maybe apply them to a new product,
then we can go into and look in how those meet
or how those match with unmet needs.
We do search, invent, and share.
So the invention process
is pretty innate within the corporation
from the standpoint of we do a number of templates,
but we also look at how the innovation
can benefit very, very far visions.
And then once we get past that area, we get into integration.
As was stated before, you really don't get into understanding
until you build hardware,
until you build the items
and you have the touch, feel, understanding,
and characterization of the systems,
whether they be a subsystem or a complete holistic system.
So, we at General Motors try to live by much of this approach.
This is not that old.
This whole area of approach is only about 15 years old.
It was developed back in the mid '90s, late '90s,
where we started to learn
that if we looked far enough in the future --
And it was interesting because, as I was saying over here
earlier in the afternoon before your session,
I heard the term "look 20, 30 years ahead" --
you know, vision.
And that's basically what we have been doing
for the last 15 years
is try to identify and get our arms wrapped around
what our industry would be like 15, 20, 25 years from now.
So once we go through this,
let's take this and sort of kind of matrix it out
and look how we format, or template, a project
within General Motors.
We talked about the three I's.
So we start with -- we start first with insight,
and we put a time frame on that
anywhere from three to five months.
We do our research.
We go out and we have different groups
that support the corporation do different types of research.
And this is what we call our Learn portion of our cycle,
our Learn/Create/Build cycle.
So we look at this, and we go through,
and we define future opportunity for space
of the ideations that have been generated.
We start to identify critical skills needed for the project.
Who do we need at this portion in the problem?
We talked about bringing team members in.
So we bring people that are good in strategy,
people that are good in knowledge synthesis,
and people that are good with customers.
We also, at this point in time, look at suppliers,
outside suppliers.
And we also begin to form our team.
One of the things that we've learned within General Motors,
and I know I've learned explicitly,
is that when you bring team members together,
you often bring people together that come --
that wear a mask or a filter over their brains, okay?
I heard the term "working out of the sandbox"
or "working outside the box."
If you're going to do innovation,
you have to break down the box
and get rid of the sand altogether.
The problem is that we understand people
come into a team that are brought together
from all different parts of the company,
and many of them wear these face masks like they're swordsmen,
and these masks act as filters,
and those filters are based on experience,
understanding, academic backgrounds,
and even their own personal outlook on life.
Many of you, I'm sure, have been inside brainstorming sessions
where you come up with an idea, and you post it up there,
and somebody will say, "You got to be kidding.
"That will never work. Won't happen, never work.
Forget it. It's not gonna work," okay?
It's those type of people that don't allow that filter to fail
or that mask to fail and allow the ideas to flow in
and try to get their arms around it
to try and see if they can go through the innovative process.
After the insight portion, we move into invention.
Now, two to four months
seems like a very short amount of time for invention,
but that's just an arbitrary statement.
Sometimes inventions go anywhere from six months to a year
depending on the complication and breadth of the project.
Here we create,
and we bring, again, in
creative, problem-solving people.
Now, that's a pretty broad statement,
but that creative, problem-solving group
includes engineers, includes designers,
includes graphic artists, includes animators.
It includes a wide breadth of group of people to support that.
And then we get our deliverables looking at strategic concepts,
where we prioritize development.
So, based on the specific application of the project
and the goal for the project, these --
this time of invention goes through --
it sort of marches on into a templated area
where we start to find out
where we get into the areas of intellectual property,
where we get into the areas of innovation,
and where we get into the areas of product application.
Will this idea fall into a product line,
or will this idea fall into a new development altogether --
something that's outside the box?
Once we get past that area, we start to look at integration.
So we get into the Build mode.
We go through, and we start to look at our critical skills
of product design and product development.
Here we bring in our production people,
and we say, "Okay, you people are the experts
"at building these in a mass approach --
"bring cost down, make quality parts,
"make a mass amount of parts.
"How can we do this part of the integration
to build this specific type of vehicle?"
At this point in time,
we also will have deliverables of experience.
We make an experience demo.
In other words, we make it real.
We're getting back to the touch/feel part
of understanding what's out there.
External organizations include fab shop,
production-capable suppliers.
We go outside.
We do contractual with suppliers.
We try to keep as many of our skill sets
within the corporation,
but because of the situation over the last few years
with our economy and the redevelopment of our company,
many of our outside production suppliers
are helping us to go through innovation.
At this point in time of our company,
we're also now bringing our suppliers
into the early stages of development.
So sometimes our suppliers will show up at the invention mode,
or show up even at the insight mode
because we utilize some of their skill sets, as well.
It gets into an issue here during the invention
if you have a supplier in to do I.P.
And getting involved with a supplier to do I.P.
can bring in to many conflicting issues
based on how the contracts are written.
So, once we get past the integration stage --
Oh, let me talk one more thing about --
before I leave this, as we talk about team and resources.
Many of the teams that are assembled
to do these specific types of projects
have two types of characters in them.
We have a core team, then we have a support team.
The core team is assigned by leadership,
and the acronym is Program Manager, Lead Engineer,
Design Manager, Lead Designer Analyst, and Graphics Specialist
are all the type of people that will stay on the project
from start to finish.
Then we rotate people in from different support areas
to allow to get support from areas
that we need specific critical skills --
such as, for example, the insight.
GPR is our Global Product Research Team.
A T.I. is a Total Integration Engineer.
A C.I. is a Climatic Engineer and Integrator,
and then we have a trends analyst.
When we get over to invention,
we bring in a design engineer, designer, animator, graphics,
and knowledge management.
And then as we get into our integration,
we get in again to design engineer, designers,
packaging, animator, and graphics.
But you have to understand that many of these subsystems
that are being developed inside this framework
can include hardware, software,
graphics, human machine interface, propulsion,
electrics, networking --
just a wide bandwidth of subsystems
that we have to integrate.
If we take that matrix and build it
into sort of kind of a circular motion,
we come up with this little design
that we developed about five years ago
called User-Centered Design Innovation.
It begins at the centroid of the matrix,
where we start with product scoping.
As we go through the rotation --
we did that Learn, we did that Create, and we did that Build.
This circles around all three of those.
So as we go through and develop
specific ideations and innovations,
we continually rotate within this matrix.
At a certain level, the ideation will do one of two things.
It will fall off and get tabled and said,
"Okay, we can't do it.
Let's not waste any more time and money on it,"
or we'll move up into the next generation or the next level.
And as it gets wider and wider in this --
in this Learn, Create, and Build circle,
it starts to end up towards its product implementation.
So, we go through, and we do project scoping.
We look at ethnographic concept generation.
We build functional mock-ups. We get user feedback.
We actually will do clinics.
We'll take a mock-up that's only partially designed,
and we'll take it out, and we'll showcase it to the public,
or we'll showcase it to a specific sect in the market
and allow them to look at it and allow them to give us feedback
that helps us to continue the process.
As we move out, we refine the concept,
go into build production with feasible proof of concept,
and if that proves positive,
it makes its way all the way up to product implementation.
At that stage of product implementation,
what happens is the ideation of the project
gets handed off to a brand-new group,
a brand-new set of engineers and support personnel.
At that point, it gets moved into production.
We are here to develop the ideas
and generate the ideas from proof of theory
all the way to proof of concept,
and once that gets accepted,
and it's usually deemed by our leadership
as the go/no go from their standpoint,
it gets handed off to our production people
where they go through and take it into development
because they have to develop --
They have to make it cost-effective,
they have to meet quality, and they have to do it in mass.
So, these are just some little sidelights
and some of the things that have been worked on
over a number of projects over the last few years.
We had one up here where we had customers who said,
"what can we do to our S.U.V.s to help them with their dogs?"
They want to be able to have something so that the dogs --
they can carry their animals, and --
Who in here doesn't love their animals, okay?
And we had customers say, "Well, you know, what can we do
"to help the animal in the back of the S.U.V.?
"We want to design some sort of platform for them.
"We want to make it easier for them
to get in and out of the vehicle."
So we actually designed a ramp system
that fits in the back of a tailgate
that could easily fold out,
and as it turned out, from that process,
we actually developed a twofold idea.
One -- the idea the ramp works to help the animal or the dog
get up into the back of the vehicle.
The second is, if you leave it in place and fold it down,
it now becomes a secondary table if you're tailgating, okay?
So, those are the kinds of things
that sort of kind of blow out and give us the ideations.
So, here you can see we got a picture
of the design of the ramp here,
and then here it's in position as that -- as a ramp.
So, these are the kinds of interfaces
that we have within the ideation generation.
So, we learn as we go.
We learn our mistakes.
We use our mistakes because to fail is normal.
You always will fail.
You will fail what you fail to learn.
That's the key.
Work is enabled by building a team.
In our case in General Motors,
we have a global network of team support in our process.
We have design, which is our major portion
which puts the finishing touches
that makes you the customer like the way it looks.
One of our former leaders, Mr. Robert Lutz,
always said that if a car doesn't look good, somebody's --
the customer's not gonna bother getting into it, okay?
Next is planning.
We need to look at long-term planning and strategic ideation
of what's going to happen 10 years in the industry from now.
We do that by watching our customers,
watching our competitors, and watching ourselves.
Next we have a group
called the Advanced Vehicle Development Center,
Global Technical Engineering,
R&D in Engineering, which I'm part of,
that all work together on a global basis.
That includes our Opel Division.
That includes our North American Division.
That includes our China Division
and includes our Holden Division down in Australia.
So, people will build a team --
Leadership will build a team together
using personnel from all of these different structures.
Advanced Purchasing -- a very important part of the team.
If we have to go out and do contracts with suppliers
and we need to do competitive contracts with suppliers,
Advance Purchasing, which is a totally separate group
from normal Purchasing within the company,
goes out, has the skill sets to negotiate quality contracts
at a reasonable price and a reasonable cost.
Strategic Marketing -- very important to understand
where we're going to be within 5, 10 years from now.
So Marketing looks at all of those aspects.
Regional Innovation Groups -- every region has an idea
or innovation group for their particular market.
We build a car for North America,
it's not gonna sell in Mexico, okay?
When we built the Nova -- Everybody remember the Nova?
Okay?
You know what Nova in Mex--
You know what Nova in Mexican means?
"Don't go," okay?
That was just a good example of the fact that whoever did
the strategic planning of that, or the marketing of that
didn't do their research, didn't do that work, okay?
So, these Regional Innovation Groups
help us to understand what the specific region --
If we're building or designing a vehicle
for that particular market,
such as our China market right now.
We have a complete set of group of people over there
that are specifically expertised in their region.
Global Product Research -- We watch our competition.
We watch our competition very closely,
and you would be amazed to understand
what we do within our own OEM areas.
There was a point in time when I was --
part of my job was doing competitive assessment,
and I remember when I was doing teardowns.
We bought a Prius -- 1997 Prius, right-hand drive --
bought it right from Japan --
not even in the United States yet.
And we did it to do a competitive assessment
on their technology and how they work.
That Prius -- And if you drive Prius,
please don't take this the wrong way.
My oldest son works for Toyota.
Talk about our dinner conversations.
[ Laughter ]
This Prius couldn't get out of its own way.
It was a rattle trap. It was noisy.
It was terrible on performance. It was a right-hand drive.
It was just -- It was unbelievable.
Well, Toyota actually finally understood
that the American market would not approve of that vehicle
because of its performance,
so they held of its introduction over a year and a half
to bring it more into what the U.S. customer would like.
Chrysler, when they first brought out the PT Cruiser,
came to us and said,
"Hey, we'd like to take a look at your Corvette.
We'll swap you a Cruiser for a Corvette."
We did.
We dropped off a Corvette at Chrysler,
and they dropped off a PT at us.
We went through, did our own analysis.
Things like that have been going on for a number of years,
although the public doesn't know.
But it helps because the OEMs,
such as Chrysler, Ford, and GM,
all watch each other very closely,
and it's now to the point
we're all watching each other's backs very closely.
Technology Planning --
What technology do we need to use, okay?
A good example between Ford and GM, for example --
and I use this all the time -- is Ford has come up with SYNC.
Now, SYNC is a very popular addition to the vehicle.
Who in here has one inside the vehicle, okay?
Do you like it? Are you happy with it?
You love it. Okay.
They did it right because they went to Microsoft
and had them build it for them, okay?
Who in here has GM products?
Okay. Thank you very much.
[ Laughter ]
I can now afford the plane ride home, okay?
Have you ever used your OnStar?
WOMAN: [ Speaking Indistinctly ]
VITALE: Okay. OnStar has been around for over a decade,
and it's been touted as one of the best telematics.
It's just won several awards last year
as being the best telematics development,
because not only do we provide safety for our customers,
we provide service for our customers in a concierge.
We provide safety and crash notification.
We can unlock your doors, and now we've added diagnostics.
So if you're driving down the road
and the "Check Engine" light comes on,
you can go online to OnStar,
and they can tell you exactly what's wrong,
or they can tell you, "A," you can continue driving,
or, "B," if you need to pull over
or get to a service station.
OnStar is -- And this is not a sales pitch,
but OnStar has been
just a huge development source and base for us
within the corporation to take telematics to the next level,
and that comes into Technology Planning.
Competitor Technology Intelligence --
we just talked about that a little bit.
We're constantly looking at each other.
And then finally looking at Strategic Initiatives.
Where's the leadership of our company want to see us go
within the next 20 years?
As of last year,
was just trying to make it through the next 12 months.
Okay.
So, with that, let me sort of kind of
just summarize very quickly.
I heard this word come up before -- "collaboration."
Collaboration is used
exclusively within the corporation
to promote creativity and teamwork,
multiple expertise, and ensure customer buying.
Customer Insight -- getting to understand the customer.
Now, the word "customer" --
Now, if I say I work for an automotive company
and I say "customer,"
the first thing you think about is yourselves.
There are customers internal to GM, as well.
If we develop a new control system
that we feel is advantageous for our Powertrain Division,
our Powertrain Division becomes our customer internally.
If we design a new control system
to give you better performance in ABS brake controls,
then the braking system
or braking group becomes our customer.
So, we have internal customers as well within the corporation
that comes from -- that helps us
to go through our development process.
Innovation from Insight provides solutions
that will resonate with consumers
rather than technology for technology's sake.
And I heard this stated before.
You don't want to put technology
just because it's technologically better
than anybody else.
If the customer derives satisfaction out of it,
it enhances their experience, then it's worth it.
If it's there just because it's a new tech process,
it's not worth it.
And then finally, a Demonstrator Iteration --
makes development process faster and more effective
through cycles of learning --
going back to that Learn/Build --
or Learn/Create/Build cycle,
and then building the MULE Properties
to validate the theoretical,
and that's where I'm gonna sort of kind of
use this term roughly --
segue into the next part of my presentation.
Back in 19--
Back in 1999, I got a phone call from my director,
Dr. Lawrence Burns, who was V.P. of R&D for a number of years,
and it was kind of funny
because I actually was an engineer
working on powertrain controls back in the early '70s
when Dr. Burns got hired in, and he actually worked with me,
and I sort of kind of mentored him for a little bit,
but he went through the ranks of the corporation,
and Dr. Burns was a visionary.
He was a visionary in respect
that he looked outward 20, 30 years for the corporation
to understand where GM needed to go
from the standpoint of clean energy.
The fact of the matter is that the internal combustion engine
has been around here for over 100 years.
It's been well-refined.
But the fact of the matter is, too,
is that we can see right now that the issue
that we're suffering through from the Gulf of Mexico
is that we need to move away from oil.
Now, engines are not gonna disappear.
They'll be around for 10 years.
They'll be around for 15, probably 25 years.
But they're gonna become more refined.
They're gonna become cleaner,
and they're now gonna become part of a propulsion system
as to being only a propulsion system.
So, with that first call I got in 1999,
we put together a team.
He hired a young PhD from Chrysler
called Dr. Chris Borroni-Bird,
who was working on fuel cells for Chrysler at the time
and wanted to do some very unique development,
but Chrysler said no.
They didn't want to put the money or time into it.
So Dr. Burns hired Chris, who's now my boss,
and we started to put together a vision,
and that vision was basically reinventing the automobile.
And I'm sure many of you have heard this term reiterated
in press and media for General Motors all the time,
but Dr. Burns had a very focused vision on what he wanted to do,
and both Chris and his team --
myself and three other engineers --
took that vision and started to build something around it,
and the first thing that came out of the process --
I'm sorry. I'm jumping ahead of myself.
The four areas that we wanted to build his vision around
included advanced propulsion.
We wanted to build vehicle electronics,
controls and software that were a jump ahead of our competitors.
Telematics -- We wanted to take the OnStar systems
and bring it to a new level, and then advanced materials.
With the development of new technologies and materials
all the way down to nanoparticles,
we felt there was a very viable application
for those types of materials,
which we have started to use and will now start showing up
in some of our products in the next couple years.
So, the first vision was the AUTOnomy.
This is a vehicle that was -- a revision I should say --
that incorporated a couple of very fundamental systems.
One, the capability to have all of our control systems --
propulsion, braking, steering,
anything dealing with controlling the vehicle --
in the flat chassis.
This flat chassis that we reference,
we sort of kind of nicknamed the "skateboard."
And the idea is that skateboard
becomes a self-sustaining property
that you can put different body modules on top of it.
So, what we were doing
was looking at how we could advance technology
and how we could advance the business model, as well.
For example -- and this is what we,
you know, sort of kind of built our vision around --
is the fact that if you are a commuter
that drives a certain number of miles a day,
and you want a small vehicle to drive back and forth,
or a compact vehicle to drive back and forth,
you would have one body on it during the week.
If you want to take the family out
for a short ride on the weekend,
you can either own the body or possibly go to a dealer
and rent a new body for the weekend
and just swap it.
So -- But, again, this was a vision
that was 20, 25 years out,
because none of the technologies existed yet
where we could a propulsion system in a chassis this small.
Now, albeit that this is all electric drive --
there's no engine in this --
in this case, our dream was four wheel motors.
And, actually, the four wheel motors
grew into what we call a dream of an eCorner,
where the eCorner now acted -- now produces active suspension,
propulsion, braking, and steering, all in one unit.
It just sort of kind of hangs off in the body --
or off in the chassis.
So, from here, we said, "Okay, where do we need to go?"
We're talking about systems engineering,
we're talking about fuel cell, we're talking about...
Well, what kind of -- what kind of...
We knew we needed hydrogen.
Do we use solid? Do we use liquid?
Do we use gas?
Oh, by the way, we have to do full electric braking,
full electric steering.
We have to have several levels of networking in there.
We have to be able to have high-speed controls.
We have to be able to cool it, we have to be able to heat it,
and we have to be able to talk to it.
So there was a number of engineers
that were brought into the program
to wrap their arms around this.
What we did was the first iteration.
We talked about the cycling, the burn, the create, the build.
Here's the first iteration that we did.
It was called the Hy-wire.
The Hy-wire was exactly what we looked at in revision,
but we utilized current technology
that we had our hands on at this point in time.
It was a flat chassis.
It incorporated everything that we had in our vision.
It included electrical traction system,
full by-wire systems control,
so we had both steering and braking by-wire,
compressed-hydrogen tanks.
We ran about 1 1/2 liters of pure, compressed hydrogen
at about 350 bar.
We had hydrogen in the fueling system
that would be able to tell us flow rate inside there,
as well as temperature,
so we can keep hydrogen very stable.
We have a fuel-cell stack.
General Motors has been working on fuel cells for a long time.
The first fuel-cell vehicle we ever built was in 1969.
It was built in the back of a van,
and, believe me, it was a big stack.
[ Laughter ]
We have now since targeted.
And one of the things that we had from our vision
was to build a fuel cell
that will give us one kilowatt of energy
for one kilogram of mass.
And we're close to approaching that now,
which is a pretty -- pretty -- pretty awesome project.
Now, NASA's been using fuel cells a long time.
Every one of your orbiters,
every one of your on-board vehicles had a fuel cell on it.
Okay?
So, this was one of our third- or fourth-generation stacks
we were able to fit what's inside.
Now, this chassis is 11 inches thick,
and it contains everything we need to drive the vehicle --
By-wire brakes, air management, cabin heating,
universal docking connector.
I actually was able to get five patents
on different connecting systems
that I designed for this vehicle.
And then steer-by wires --
steer-by-wires steering rack and body mounts.
So, we took the vision of the skateboard
and put it into reality,
so we built an actual running model.
The process basically gave our designers
a whole world of freedom they had never experienced before.
Designers who love to design cars
are artists that understand math.
Okay?
They were they given the opportunity.
We told them, "You can design the interior of the vehicle
"any way you want.
We just need an area that we can sit someone in,
and then we'll devise and develop
a human-machine interface
that will allow the person or people to drive the vehicle.
So they developed and designed this body,
which is completely flat from front to rear --
no humps, no welds, nothing, no foot pedals.
We took all the foot pedals away,
and we gave all the controls to the hands.
This particular unit, I had a good deal of design.
I had a team of engineers working on this.
And, basically, this vehicle is driven by twisting the throttle,
squeezing these hands for braking,
and then we use the cantilever system
for steering back and forth.
When you first think about it,
it seems a little bit arcane on how it handles,
but it actually handles very well.
In order to test our theory,
we actually -- we built the vehicle in Italy.
That was fun.
We actually brought in a gentleman
who had just broken both his legs in a skiing accident,
and we asked him to drive the vehicle.
We wanted to get his response on how to drive the vehicle,
'cause he couldn't use his legs.
They were just broken.
I mean, they were gonna come back.
But he drove the vehicle
and found it very natural to drive it.
He felt that it was really nice to drive.
That gave us a great feeling,
because we felt we were on the right path.
One of the things we did, too, on this vehicle,
we told the designers we didn't want any mirrors.
There's no mirrors on the vehicle whatsoever.
So we developed a camera system.
We embedded cameras into the bodies,
so we'd have four side-rearview-mirror cameras,
with monitors on each side.
And then the center camera, or the center display,
here was a rearview camera.
That also sort of gave us an understanding
of how people would interpret, looking straight down
and seeing a rear vision in front of them --
how the feedback to the brain would add to that.
And once they tried it, it became very natural.
So, here is a picture of the body being removed.
And, again, based on our vision, we were able to design the body
so it could lift within 10 minutes
and be completely removed mechanically and electrically.
And what I'd like to do now is just give you a jog --
we'll see how well our audio works --
is give you a couple of videos.
Oh, forgive me, the audio here are not...
Turn this guy up a little bit.
Yeah, there you go.
[ Volume increases ]
Let me play that one more time for you.
[ Ringing ]
I would venture to say
this thing is taking its first initial orbit.
Okay?
This was one of the first times
that we drove the vehicle in public,
where we have public and journalists there.
The sound you're hearing is actually not the fuel cell.
It's the air compressor inside,
processing the air -- atmospheric air --
under pressure to be pressurized in the fuel-cell stack
to mix with the hydrogen
and then go through the process of separation.
So, the vehicle was kind of interesting to watch
and observe as it drove around.
Now, you have to understand,
because of this new 11-inch chassis design we had,
we really didn't do a great deal
to look at handling capabilities inside the vehicle,
from the standpoint of how it handled
compared to a production vehicle.
This vehicle only had about an 80-mile range
and the electronically governed speed
is about 45 miles an hour.
We were gonna let journalists drive this vehicle
and other people
and make sure they didn't get too carried away.
This next video is a couple of...
[ Vehicle screeching ]
Oops.
Where'd they go?
Okay, what happened here?
Let's close this guy.
[ Vehicle screeching ]
We rented an abandoned airstrip in France
and built a course to drive the vehicle on
to sort of kind of test its capabilities
of acceleration and maneuverability,
as well as handling.
So, as you can see,
the steering system is just a cantilevered approach.
At least the guy is having a ball.
We think he liked it. He was having too much fun.
He ran out of hydrogen.
The vehicle had...
The vehicle had no lithium-ion batteries
or battery systems on it.
The total -- The fuel cell was the total source of energy
on the vehicle.
So it had a very poor performance.
It took almost 14 seconds to go from zero to 45 miles an hour,
and that's totally unacceptable by any driver, okay?
But it was only a partial iteration of the theory.
It was only the first level of development.
Once we were successful, we actually built two.
We built two chassis.
We built two chassis and one body.
And we actually did this complete project in 19 months,
which was really an excessive --
I should say, an aggressive -- project.
And what we did is we had one chassis go down a pathway
to develop a propulsion system,
and we had one chassis go down the pathway
to develop all the controls and electronics and networking
so that we could merge them together as we got closer
to getting everything developed up to a certain level,
blend everything together under one chassis
and have it work.
And that process worked rather well for us.
So, you want to talk about bringing several groups
of system engineers and support engineers together
to work as a team, this was very critical.
The chassis was built with cooperation
from a company called [Speaks indistinctly]
and our sister division in Mainz-Kastel in Germany.
And the body was built by a coach builder
called Stile Bertone in Italy, in Torino,
where we had the coach builder.
So we would be -- The teams would be flying back and forth
between the two cities as we were going through
the project development and completion,
to make sure everything stayed on track.
The Hy-wire was a great success
from the standpoint of what we wanted to achieve,
but it wasn't where we wanted to go.
We still wanted and needed to go a lot further.
The second iteration of the vehicle,
of the process and project, was the Sequel.
This vehicle, we wanted to ensure
that we will have several areas of ideation
that were thought about and started in Hy-wire,
but we wanted to bring it to fruition in the Sequel.
That included, we want better performance --
zero to 60 in 9 seconds --
we wanted a 300-mile range,
and we wanted it do drive just like a production vehicle.
We wanted to ensure that when somebody got into it,
they couldn't tell the difference
between this or a Malibu they bought off a lot.
So, with that, let me just give you a quick...
[ Mid-tempo music plays ]
[ Cheers and applause ]
So, the vehicle itself was the culmination
of all the work we did on the Hy-wire
plus another three years' worth of work
on this particular project.
It took us three years to do this project
because we basically were looking at the fact
that we wanted something that was completely roadworthy,
had all the amenities of a standard vehicle,
and when somebody got in to drive it,
they didn't feel any different
than they were driving a normal production car.
This, however,
did have a complete set of different metrics.
It had zero to 60 in 8 1/2 seconds.
It had 8 liters of hydrogen on board,
compressed at 700 bar to give us a 300-mile range.
It had all-wheel steer and all-wheel drive.
So all four wheels steered independently.
I shouldn't say "independently,"
but based on our control algorithms.
The rear wheels had 6 degrees of freedom,
and the front wheels had a full 35 degrees of freedom.
We had all-wheel drive, where we moved forward
taking just a single-axle traction motor,
and we included two rear-wheel motors, as well.
It had a lithium-ion battery packed on it,
which was about 4 1/2 kilowatts.
So, we took all the things we wanted to do
and built it into this product.
We built two of these,
and they ran for almost 3 1/2 years,
going around the world to different venues.
One sits in China automobile museum right now,
and the other one sits in our other museum in Warren.
The team -- getting back to our Sequel team --
comprised people from around the globe
that were involved in the project.
Again, we utilized our Opel division,
which has the expertise in fuel cells.
And there's now many of those engineers
that moved to our New York subsidy,
which is where we build all our fuel-cell stacks now.
The program was so successful that,
after the completion of the Sequel,
leadership in the corporation
decided to expand it a little bit further.
So we've developed a GM Project Driveway,
which is a hydrogen-powered vehicle.
We built 100 vehicles, and this was back in 2008.
We've built 100 vehicles,
and those fleet of 100 vehicles
have logged over 1.5 million miles successfully.
You may have even seen them driving around Washington,
because Washington is one area where we've had them staged,
as well as the West Coast.
And right now, the next level of the program
is General Motors, Chrysler, and another OEM
have signed an agreement
with the state of Hawaii and The Gas Company in Hawaii.
We're going to build an infrastructure
of refueling stations
to start testing the capability and potential
of building fueling stations for a fleet of vehicles,
and Hawaii seems like the perfect place to do it.
I applied for the job. They wouldn't give it to me.
[ Laughter ]
I got sent to China instead.
What did I do wrong? Okay.
So, with that, what I'd like to do
is move into the next set
of the next project that I've been involved with --
the Electric Networked-Vehicles.
This is a project that was developed
specifically for the World Expo in Shanghai.
GM has a pavilion out there,
and our leadership wanted to take --
i.e., Dr. Burns and my boss -- wanted to take the next step
from the hydrogen approach
and go to a full electric system.
So the EN-Vs were developed --
Electric Networked-Vehicles were developed --
but we wanted to go a little bit further
and sort of kind of fall outside the sandbox,
right into the gravel pit.
These vehicles travel on two wheels.
They don't travel on four. Okay?
We wanted to talk about going into a cooperative program.
We went into a program with Segway Corporation.
And everybody -- Has anybody here ever driven a PT Segway?
Okay?
We took that theoretical,
or we took that actual, operational system
and developed it into a larger package
and a better control package
that we could run a vehicle that contained two people
that will drive -- that will drive in these vehicles.
We have three variations,
and I have a video that will talk about that real quickly.
But let me just talk about -- Before I get into that video,
let me talk about where we're going with the DNA,
or the reinvention of the automobile.
Again, we look at many of the current DNA that we look,
we currently use energizable petroleum,
powered mechanically by an engine,
controlled mechanically, stand-alone,
totally independent -- totally dependent on driver,
and a vehicle size for maximum use of people and cargo.
Where we're going,
or where we have been going over the last decade,
into the new DNA,
is energized by electricity and hydrogen,
powered electrically by electric motors,
controlled electronically, connected --
this is a very key next level for telematics --
and then also semi- and full-autonomous driving,
which I'll talk about in a moment,
as well as vehicles tailored specifically to specific use.
This is especially interesting right here,
because we're gonna put this in production in November,
when the vehicle the Volt comes out.
The vehicle -- The Volt vehicle
is totally powered by electric motors.
Even though it has a small engine on it,
that engine has absolutely zero
to do with propulsion on the road,
other than to maintain battery charge
and provide onboard power to the rest of the systems.
So it acts as a genset on the vehicle.
I'm sure everyone here can relate to that.
Full propulsion is controlled.
It is driven by the electric motors,
and there is no mechanical connection
between the engine and the wheels whatsoever.
The engine only runs at two speeds.
It runs at a low-idle condition,
or it runs at a specific fixed speed for the generator set.
Getting back to talk a little bit
about the autonomous approach,
one of the things we've done
on the Electric Networked-Vehicle
is build in the capability to understand where I am,
what's around me, and take me where I want to go.
We have onboard GPS systems and digital map systems
inside of our onboard computers that tell --
the vehicle knows exactly where it's at
in reference to its position on Earth --
GPS plus another technology -- what's around me.
It has the capability to sense both visually,
ultrasonic, lidar,
as well as connection between one vehicle to another,
transmitting data back and forth of where they're at.
And it takes me where I want to go.
The capability to program the vehicles
where you would like to have them take you
and then follow a specific path, obey all the traffic rules,
and deliver you to your place in a safe mode.
We also, on the EN-V vehicles,
designed an interface for smartphone,
so that you basically can have the smartphone
and call the vehicle when you need it.
So if it's parked in a parking garage three blocks away,
you can get on your phone, talk to it,
and tell it, "Come on, get me, I'm ready to go to work."
It will wake up, pull out of its...
This is not theory. We have exercised this.
It will wake up, drive down the pathway,
and you can see on your phone where it's at,
because it will have an overlaid map.
It will also show you vehicle speed,
battery state of charge,
and any other thing it wants to tell you,
like, you know, maybe the cupholders are dirty
or something like that.
So, we've taken that level of approach
to do this.
Here's an interior shot of the vehicles.
One of the things, again, here is,
it's a fully electric system.
We have deployable HMI systems here.
And, again, we went back to the very same premise
we did with the Hy-wire.
It was where we have all the controls at hand.
We have steering, throttle, and reverse.
And these are deployable.
These are left-hand and right-hand drive, as well.
Although one thing I didn't mention was, on the Hy-wire,
with a push of a button, that whole HMI system
goes from left-hand drive to right-hand drive.
So we allowed it to be utilized in almost any country.
So, by-wire-deployable, autonomous drive capability.
Oh, and you can autonomously drive
while you're sitting in it, as well.
Unique interior for two passengers,
small footprint, full electric,
full-circle turn on axis.
We don't need reverse.
You can turn on axis, turn on a dime.
These particular vehicles
have a 40-kilometer range and a 40 KPH speed limit.
Full telematics with onboard cameras and sensors.
One of the things we also allow it to do is that we said,
"Okay, if you drive it autonomously,
what are you gonna do -- read a book, watch a movie?"
Well, we can also -- We developed a video-chat system
where you can talk to another vehicle.
You can talk to three vehicles at once,
or you can talk to three vehicles
and someone that's at home, through their system.
So we built that capability in it, as well.
We exercised that capability.
Full connectivity,
V2V, video chat, I.D., and mapping.
One of the things that we're looking at,
in the next advancement of technology for telematics,
is the capability for vehicles to understand their environment.
Okay?
What's going on in traffic patterns
three cars ahead, three miles ahead?
How often are you in a situation, in driving,
that, all of a sudden, traffic stops,
but you have no idea what's going on?
The approach we've taken is what we call V2V --
vehicle-to-vehicle interface connectivity --
is that if a vehicle is at the front
of, say, this traffic jam,
it can broadcast situation or broadcast information
either to the other vehicles or to the infrastructure --
infrastructure being the government, okay?
In other words, everything that's, like,
all the way down the pathway of the roadway.
And then a smartphone interface.
Okay, with that, I'd like to show you just one real quick.
ANNOUNCER: Imagine a vehicle
that is smart enough to drive itself.
GM's electrical networked vehicles, or EN-Vs,
explore the idea of autonomous driving
by connecting with other vehicles on the road,
which allows for safe and connected transportation.
The easiest way to see
how all of the conceptual pieces come to life
is in the build of the vehicle itself.
GM has manufactured three variations of the EN-V,
each targeted at urban markets around the world.
The Miao, Jiao, and Xiao
each have their own look, style, and personality.
While the design may vary
from one model of the EN-V to the next,
the hardware and technology is essentially identical.
At GM's design center in Warren, Michigan,
the EN-V teams are working to bring the concept to life.
The manufacturing process is an ambitious one,
but the fabrication teams embraced the challenge.
Because of the EN-V's functionality,
the building materials must be extremely light.
That's why the team uses carbon fiber
and advanced plastics for most of the vehicle's body.
Paint and all materials are actual production-based
and will wear well during the six months of use
in the Expo pavilion.
The EN-V's composite carbon-fiber shells
are molded to match the specific design of each vehicle.
All in all, the shell will weigh only about 70 pounds --
considerably lighter than any conventional vehicle.
Numerous components of the vehicle,
from the hinges to the interior panels,
are made of advanced plastics instead of aluminum.
Not only does this reduce weight,
but plastic parts can be manufactured
in days instead of weeks,
saving valuable time in the production process.
The EN-Vs will be pieced together at a framing station.
This is where one of many quality checks takes place,
to ensure proper functionality
of the vehicle's many components.
The three variants are beginning to take shape.
The assembled shapes look like futuristic Bullet trains
and mini helicopters.
As the complex parts of the vehicle
are added in the manufacturing process,
the unique characteristics of the EN-V become more evident.
The EN-V reimagines
some of the most basic components of a vehicle,
from the door to the seats.
Miao has the look and feel
of a mysterious, high-technology autonomous robot.
The Jiao has the flair and excitement
of a European couture collection.
And the Xiao expresses happiness, joy,
and sunny optimism.
Once the body is near completion and mounted to its drive system,
the vehicle is ready to undergo a series of vigorous tests
on durability, handling, and vehicle communications.
The EN-Vs will make their world debut
at the World Expo 2010 Shanghai
and will show the world GM's vision
for the future of urban transportation.
VITALE: What has currently been developed is,
we have two -- R2A and R2B --
which are basically robotic systems
with over -- I think it's 42 degrees of freedom,
with a capability to do many, many things.
The arms themselves have the capability
of lifting 25 pounds --
25 or 30 pounds, something of that order.
So this has been something
that we've been working with NASA since 2007,
and I believe it's a 5-year contract or 5-year program.
And I'm sure that you'll be hearing more about this,
if you haven't already, I'm sure.
Is there anybody here
that's been involved in that program at all, intimately?
Okay.
So, it's, you know...
A couple of my colleagues have been involved in this,
so I've been sort of kind of on the edge,
listening all the time to what's going on
and see where we're going with this.
So, I know that the project was developed to allow --
to do two things --
one, because General Motors was looking to take
their next-level technology and plant operations
from just simple robots that we have now,
into more articulated systems
that would help better benefit production quality
and production application.
And I think -- I believe that NASA's look at this
is also to look at the capability
to put one of these in space to work with --
next to the astronauts, to help them out, as well.
So, we haven't done feet yet. We just did the torso.
So, with that, I'd like to thank you
and also congratulate you on completing your program.
Thank you.