Do We Overdesign?

My daily driver (at least until my daughter gets her driver’s license in a few months) is a 1982 Honda Civic 1500 DX. It’s not much to look at – paint is faded and the upholstery needs extensive repair – but the body is pretty straight and it runs quite well for being 30 years old. Could I afford to drive something else? Yes. In fact, my family’s transportation fleet includes 4 other vehicles of 1998 vintage or newer. So why do I drive my Civic, keeping in mind the inconvenience of folding my 6 foot 6 inch frame up a couple of times just to get into the driver’s seat? It’s personal economics mostly. Around town my little car averages over 25 miles per gallon, and my best open road fuel economy so far is in the high-30s. Both are very pocketbook-pleasing numbers. But my Civic has an additional benefit that my other cars do not: simplicity. It’s basically an engine, transmission, four wheels, a gas tank, and a steering wheel. Not much else separates me from the driving experience. No air conditioning, power steering, power brakes, power windows, or power door locks. I’ll admit the carburetion is a bit complicated, but everything else is pretty simple. Despite being barebones transportation, though, my two youngest kids claim the Honda is part of the family and threaten me if I even mention “sell” and “Honda” in the same sentence. I’ve even thought of converting my Civic to an electric vehicle once its current internal combustion engine finally gets too tired – which at just under 107k original miles, and due to its Honda heritage, will most likely be several thousand more miles down the road. My Civic is just good, basic, reliable transportation that is both fun and economical to drive.

A couple of days ago while driving my Honda in weekend traffic, I was thinking about electric car conversions. One of my favorite pass times is wandering around the Internet looking at conversion projects, or even from-the-ground-up homebrew design-and-builds. In fact, I think a lot about electric transportation – Segways, bicycles, motorcycles, cars. The system components of an electric car are not much more complicated than my Honda Civic: an electric motor, transmission, four wheels, a bank of batteries, and a steering wheel. In a conversion project, the motor replaces my current engine, and batteries replace my gas tank, but the rest of the original car parts remain.  A conversion would cost me a few thousand dollars for parts, and a few weekends in my garage. Contrast this with current model year versions of electric or hybrid cars. Take the Chevy Volt, for example. A recent Reuters article claims the Volt’s current true cost, based on amortizing development costs across the to-date sales volume and adding in per-vehicle production costs, could be as high as $89,000, which is $49,000 over its current showroom list price. Ouch! Part of the huge cost-per-vehicle difference is due to the Volt’s system complexity, which is a combination of electric motor and gas engine powertrain technology, and trying to figure out how to make all the parts play nicely and safely together. But there are also pure electric vehicle examples, like the Nissan Leaf and the Mitsubishi i, that sport system technology well beyond a homebrew electrical vehicle conversion – and manufacturer’s list price tags, while not as shocking as the Volt’s, are still pretty scary. So why does a modern production electric or hybrid vehicle have to be so much more complex than simply swapping out an internal combustion engine for an electric motor (or, in the case of a hybrid, adding-in a gasoline engine/generator combination to charge batteries and/or run the motor directly)? I know there are a bunch of reasons, some dictated by government regulations, some by safety and reliability concerns, some by consumer demand, and some by car company what-if engineering. But it seems to me the current electric and hybrid vehicle offerings may be too complex for their own good – the Volt’s real price tag, whatever it happens to be, is exhibit one.

Naturally, examples of system complexity are not limited to the automotive market. Apple Inc., for example, recently announced their iPhone 5. No matter your feelings toward the Apple brand, you have to admit the iPhone was a personal communications game changer when it first debuted in 2007, and it continues to lead the market and set standards today. But I wonder sometimes if we design complex systems just because we ‘can’, without first stopping to ask if we ‘should’. Being an engineer, I admire companies and fellow engineers who do cool stuff, where I usually define “cool” as doing outside-the-box design typically involving some pretty complex engineering work. In fact, the cool factor is often proportional to the complexity of the problem solved or function realized. And I feed my family by helping my company market design tools that do an amazing job of modeling and analyzing complex system behavior. I’ve worked in this industry, with the SystemVision class of tools, for over two decades, and I’m still awed at what engineers can design or analyze with a capable system development environment. But are designs more complex because tools like SystemVision make more complexity possible, or is complexity really necessary, and the tools just make complex design practical? I think the answer is quite subjective and depends on the end product. At present, I don’t need an iPhone 5 class cell phone, nor do I need a Chevy Volt class electric or hybrid car. Both would be way cool, and I’m sure I would enjoy owning and using them, but neither would add enough value to my life to justify either the financial or life-energy investment. My un-smart cell phone makes calls and lets me text to keep in touch with my kids (they usually don’t answer phone calls, but will promptly respond to text messages), and someday I may get around to converting my Honda to run on electrons instead of dead dinosaurs. For others, however, the investment may be both justified and necessary. What do you think?

Post Author

Posted September 17th, 2012, by

Post Tags

, , ,

Post Comments

No Comments

About Mike Jensen's Blog

Views, insights, and commentary on mechatronic system design and analysis. Mike Jensen's Blog

Comments

Add Your Comment

Archives

June 2014
  • Wow Factor
  • May 2014
  • SystemVision 5.10.3
  • March 2014
  • IESF 2014: Military & Aerospace
  • Engineering Oops!
  • Big Engineering
  • January 2014
  • SystemVision Model Wizard
  • December 2013
  • SystemVision 5.10.2
  • Modeling: An Engineer’s Dilemma
  • October 2013
  • What is Your Legacy?
  • September 2013
  • Automotive IESF 2013
  • July 2013
  • Simple Design Solutions
  • June 2013
  • SystemVision 5.10
  • May 2013
  • Engineering Muscle Memory
  • EDA vs. Windows 8
  • March 2013
  • VHDL-AMS Stress Modeling – Part 3
  • January 2013
  • VHDL-AMS Stress Modeling – Part 2
  • VHDL-AMS Stress Modeling – Part 1
  • December 2012
  • Practice! Practice!
  • November 2012
  • Sharing Tool Expertise
  • October 2012
  • Preserving Expertise
  • Virtual Prototyping — Really?
  • Innovations in Motion Control Design
  • September 2012
  • Game Changers
  • Do We Overdesign?
  • August 2012
  • Tsunami Remnants
  • July 2012
  • A New Look at Device Modeling
  • SystemVision 5.9
  • June 2012
  • Veyron Physics
  • May 2012
  • Rooster Tail Engineering
  • April 2012
  • Automotive IESF 2012
  • Teaching and Learning CAN Bus
  • March 2012
  • Analog Modeling – Part 6
  • Analog Modeling – Part 5
  • Analog Modeling – Part 4
  • February 2012
  • Analog Modeling – Part 3
  • Analog Modeling – Part 2
  • January 2012
  • Analog Modeling – Part 1
  • Connecting Tools and Processes
  • December 2011
  • Turning-Off and Tuning-In
  • Use vs. Experience
  • Analyzing the Big Picture
  • November 2011
  • Simulating for Reliability
  • October 2011
  • SystemVision 5.8
  • VHDL-AMS Model Portability — Fact or Fiction?
  • September 2011
  • IESF 2011 Moves to Frankfurt
  • Simulation Troubleshooting
  • August 2011
  • Qualities of VHDL-AMS Quantities
  • Military & Aerospace IESF 2011
  • Touring Johnson Space Center
  • July 2011
  • Engineering versus Science
  • June 2011
  • System Reengineering
  • May 2011
  • Integrating Hardware and Software Design
  • Engine Remote Start
  • Integrated System Design
  • Simulation Experiments (Part 3)
  • April 2011
  • Automotive IESF 2011
  • Pushbutton Cars
  • System Simulation with FEA-Base Motor Models
  • March 2011
  • Simulation Experiments (Part 2)
  • Simulation Experiments (Part 1)
  • Japan: Patience and Grace Amid Disaster
  • Top Gear = Driving Fun
  • February 2011
  • Buoyancy
  • Ideas in Motion
  • January 2011
  • The Mechanical Half of Mechatronics
  • Detroit Auto Show
  • Signal-flow vs Conserved System Modeling
  • SystemVision 5.7…Ready, Set, Go!
  • December 2010
  • SystemVision and Windows 7
  • Friction Vacation
  • Simulation Beyond Volts and Amps (Part 4)
  • November 2010
  • Simulation Beyond Volts and Amps (Part 3)
  • Simulation Beyond Volts and Amps (Part 2)
  • Simulation Beyond Volts and Amps (Part 1)
  • October 2010
  • SAE Convergence Recap (and an Unexpected Surprise)
  • VHDL-AMS Black Belt
  • Converging on SAE Convergence
  • System Design vs System Repair
  • September 2010
  • What’s the “AMS” in VHDL-AMS?
  • How Sensitive is Your System?
  • Do You Trust Your Simulator?
  • August 2010
  • What’s in a SPICE Model?
  • Cycling + Gravity = Pain
  • NI Week: Fun for Engineers
  • June 2010
  • Are You a Flexible Thinker?
  • VHDL-AMS and Switch Hysteresis
  • May 2010
  • VHDL-AMS Revisited
  • Segway to U3-X
  • Atomic Glue
  • March 2010
  • IESF Recap
  • February 2010
  • IESF is Coming…
  • System Level HDL-topia
  • January 2010
  • Mastering Design Abstraction
  • The Joy of Disassembly