DaveK’s Embedded Security Blog
Comment
Duane Benson
Hopefully some standards will emerge allowing at least some of the computing ...
David.Bailey_#1
Is this new ECU of the future, that controls everything, going to have ...
Muscle cars
Dave Kleidermacher
1/20/2012 3:42 PM EST
Software-borne features and system virtualization have become key differentiators for automotive OEMs.
Last week at CES, a significant portion of my meeting time centered on the use of system virtualization in next generation automobiles. Car manufacturers (OEMs) view system virtualization as a method for isolating safety and security-critical workloads (e.g. rear-view camera, ADAS, cluster, critical comms) from sophisticated "center stack" operating systems (e.g. GENIVI Linux, Android, Windows Auto) that host app stores, connect to wireless WANs and the open Internet, and generally must be assumed vulnerable to hackers. While the OEMs eye the transformation of physical ECUs and wires to virtual ECUs and virtual wires with some trepidation (after all, it affects the entire system of systems within the car and its supply chain), they generally embrace and encourage this path. Why? In addition to safe partitioning, system virtualization enables OEMs to:
Very soon (within a couple car development cycles), we will see head units with 8-core processors sporting 10+ GHz aggregate processing power, multiple GPUs, and a full complement of other co-processors and peripherals. These SoCs represent the performance-efficiency way forward for chip manufacturers, who also embrace system virtualization as the natural software architecture for enabling customers to leverage this silicon muscle.
The Tier-1 suppliers have sometimes resisted this concept. By breaking down ECU hardware barriers, implying delivery of virtual ECUs rather than physical, suppliers may contemplate a loss of autonomy and control. Furthermore, Tier-1s have tremendous investment and expertise in electro-mechanical engineering capability, whose value is reduced in a software ECU paradigm. Nevertheless, software-borne features have become a key differentiator for the OEM; the Tier-1 winners of the future will not be the ones who can meet RFP specs at lowest BOM but rather the ones with the best apps and app stores, network integration and speed, security, and multimedia. Herein lies the opportunity for Tier-1s with vision.
When we look back to 2010-20, we will conclude that discrete processor count and wiring content in cars peaked in this decade (we have 200 micros in some models today!), a transformation driven and enabled by multicore processors, virtualization, and the OEMs desire to better manage the vehicular electronics complex.
Dave Kleidermacher is CTO of Green Hills Software. He writes about security issues, sharing his insights on techniques to improve the security of software for highly critical embedded systems.
Last week at CES, a significant portion of my meeting time centered on the use of system virtualization in next generation automobiles. Car manufacturers (OEMs) view system virtualization as a method for isolating safety and security-critical workloads (e.g. rear-view camera, ADAS, cluster, critical comms) from sophisticated "center stack" operating systems (e.g. GENIVI Linux, Android, Windows Auto) that host app stores, connect to wireless WANs and the open Internet, and generally must be assumed vulnerable to hackers. While the OEMs eye the transformation of physical ECUs and wires to virtual ECUs and virtual wires with some trepidation (after all, it affects the entire system of systems within the car and its supply chain), they generally embrace and encourage this path. Why? In addition to safe partitioning, system virtualization enables OEMs to:
- lower production cost by reducing discrete processor/ECU count and wiring
- reduce weight, footprint, and power consumption for the same reasons--another feather in your green strategy cap!
- gain better visibility and control over the electronic infrastructure, reducing faults and improving TTM
- improve passenger experience by making the various digital interfaces more configurable and enabling information to flow across those interfaces far more easily than the current stovepipe hardware boundaries of today's cars
Very soon (within a couple car development cycles), we will see head units with 8-core processors sporting 10+ GHz aggregate processing power, multiple GPUs, and a full complement of other co-processors and peripherals. These SoCs represent the performance-efficiency way forward for chip manufacturers, who also embrace system virtualization as the natural software architecture for enabling customers to leverage this silicon muscle.
The Tier-1 suppliers have sometimes resisted this concept. By breaking down ECU hardware barriers, implying delivery of virtual ECUs rather than physical, suppliers may contemplate a loss of autonomy and control. Furthermore, Tier-1s have tremendous investment and expertise in electro-mechanical engineering capability, whose value is reduced in a software ECU paradigm. Nevertheless, software-borne features have become a key differentiator for the OEM; the Tier-1 winners of the future will not be the ones who can meet RFP specs at lowest BOM but rather the ones with the best apps and app stores, network integration and speed, security, and multimedia. Herein lies the opportunity for Tier-1s with vision.
When we look back to 2010-20, we will conclude that discrete processor count and wiring content in cars peaked in this decade (we have 200 micros in some models today!), a transformation driven and enabled by multicore processors, virtualization, and the OEMs desire to better manage the vehicular electronics complex.
Dave Kleidermacher is CTO of Green Hills Software. He writes about security issues, sharing his insights on techniques to improve the security of software for highly critical embedded systems.
|
|
|
|
|
Navigate to related information
ArLi
1/24/2012 7:49 AM EST
Well, some time ago we can read articles convincing engineers that they should put CPU inside each actuator/sensor and distribute "intelligence" among devices.
The reasons were: make design lighter, more robust and failsafe.
Does it sound familiar?
In fact there are quite good reasons to not centralize functions too much.
I.e. seat control has a little sense to be managed by the new car "super" computer - it can be done this way but harness (wiring) will be very expensive (because of many actuators and sensors involved). It looks that network connected autonomous device embedded in seat is a much better solution here.
From the car user POV it can be also a little problematic because it makes us more dependent on OEMs which will lead us to more expensive repairs.
There are coming interesting things in car design and as usual we can expect many pitfalls.
Sign in to Reply
cdhmanning
1/26/2012 2:32 PM EST
One of the main reasons to put micros in the sensors is to simplify wiring harnesses.
For eample, look at the complexity in the driver-side door. There is likely all of: a lock, multiple door locking buttons, door open detect, airbag, multiple mirror alignment buttons, the mirror, window up/down for all windows and one or more lights. If that was done with wire, we're talking somewhere near 20 conductors just for one door with all those signals having to be routed around the car to where the signals are needed.
With a micro that can be reduced to five or so wires going to a far simplified harness.
I forget the exact number, but an experiment in the 1990s which replaced a conventional wiring harness with body electronics stripped over 70 pounds of weight from the car. 70 pounds of copper is worth quite a bit - not to mention the cost of the connectors and building and fitting a complex loom - a very expensive business.
Sign in to Reply
David.Bailey_#1
1/31/2012 1:18 PM EST
Is this new ECU of the future, that controls everything, going to have guaranteed 100% uptime? Just five nines is hard and expensive. If it needs to be redundant, they need at least three. The ECU in my 2004 died. It cost $3,000 to replace and it only controlled the GPS, audio, and climate. They are not going to sell very many cars when the word gets out that this new car get totaled due to a bad solder joint.
Sign in to Reply
Duane Benson
1/31/2012 5:11 PM EST
Hopefully some standards will emerge allowing at least some of the computing power to come from multi-model platforms. That should allow volumes to go up and thus pricing to go down. I'm not talking about using mostly common components or a common system with custom mounting for each model, but something that is both bolt-compatible and software compatible. At that point, if the ECU dies, a mechanic or competent owner could pull the old unit, bolt and plug a new one in, download some software and be done.
Sign in to Reply