Archive for the 'Automotive' Category

What do the Inchron Real Time Congress this week and my last weekend home project have in common? They both are all about complexity, real-time, apps and platforms those apps run on. In automotive and consumer domains, apps are running on platforms in systems of systems. The question to me at this point is how many platforms – like AUTOSAR, GENIVI, Android, IOS, Windows Mobile etc. – as well as versions of them can an apps interested user really handle?

Let’s start with the Inchron Real Time Congress, which I was attending on Tuesday and Wednesday. After BMW talked about  the networked car with several networked sub domains. Continental then talked about how to enable Human Machine Interfaces (HMI) with one hardware and hypervisors underneath (see the graphic on the left, Source: Continental). Other presenters from Continental, Audi and Volkswagen confirmed the trend to the networked car and the discussion during the day centered around the real time aspects of car-related applications.

While my next “apps driven” car purchase is likely still some time away, my home remodel reminds me in a nightmarish way of what is ahead of us in cars and other apps driven domains. After a one-year re-modeling project and expansion, one geeky upside is that I now have CAT6 installed throughout our home. Everything is installed in-wall. I am happy (and somewhat proud) to report that the engineer in me is still present as without a problem I was able to add Ethernet plugs and such during the last weekend. If this whole system-level gig does not work out, I definitely am still capable of planning and installing home entertainment systems …

Not unlike the networked car, our house now has several networked sub-systems, in our case the home office, bed room, living room and family room. Connected via CAT6, the closet in the bed room hosts a gigabit switch to connect the video server, an Apple iMac hosted in the home office, to the rest of the house. An Apple TV (Version 1) and a Samsung Blue-Ray Player connect via a receiver to a Samsung wide-screen TV in the living room. An Apple TV (Version 2) and an iPOD dock connect via a receiver to a Sharp wide-screen TV in the bed-room. A Comcast multi-room DVR connects from the bed room to the family and living rooms.

The second Apple TV was purchased pretty much specifically to enable more “Family Guy” episodes via NetFlix (OK, Caillou and Blues Clues are found here too). As always, the Apple interface is slick and intuitive. It took me 15 minutes from unpacking the box to streaming video via NetFlix. The nightmare started when I activated the internet service on my Blue-Ray player. The Samsung “Smart Hub” updated via internet. The Netflix interface looked much different on the Samsung “Smart Hub” platform and I had to tinker a while until I had signed up for a Samsung account, registered the DVD player and got to streaming video after about 90 minutes. It took me another hour to figure out how to get to the latest revision of the Samsung platform via internet, after which all apps needed to be upgraded as well. Now the interface for Netflix roughly resembles the Apple interface, but is less slick, slower and looks different enough to notice.

How do I explain these different interfaces to my wife and daughter? I have no idea. Why are they different, even on the same platform across revisions? Ideally they should not be.

To make things more complex …. our Samsung TV also has an internet “Smart Hub” interface with apps. Comcast just sent me a advertisement on their apps. I am hesitating to unpack the Sony play station for the family room – yet another platform and yet another apps interface.

At the system-level I am musing in this Blog mostly about aspects at the hardware software interface. The experience with my home network, combined with what I hear about the future of cars, drives me to some conclusions applicable to my world at work of tools enabling software development and system-level design:

• The versioning of platforms and apps running on it, needs to be solved before the mainstream user – like my mom, dad, wife and daughter – can adopt these new technologies. Linaro is a first step for Linux. We desperately need similar activities for AUTOSAR, Android and other platforms.
• Case in point: Gadget Magazine T3 just compared the HTC Flyer, the RIM Playbook and the ASUS EEE Pad Transformer, three tablets. The HTC runs Android 2.3 with a HTC Sense custom UI on it. The RIM Playbook runs the QNX user interface. The ASUS runs Android for tablets – Honeycomb. Three fundamentally different user experiences are OK in competition, but not in the same environment (like our house, or a car). Fellow Blogger Steve Leibson recently referred in his EDA360 Insider post to a PCWorld article on why there are little Honeycomb apps. Oh well.
• To get to mainstream adoption, we may need “Uber-Apps”, both for hardware and software, which stand above the actual apps. I finally may have a good reason to get an iPad, if it could be the “Uber-Interface” from which I can control all our apps and devices.
• “Owning the user experience” is more crucial than ever. Apple has mastered the art, but you have to commit to them completely. The situation in my family room would be completely unacceptable in a closed environment like a car. That’s why the car OEMs at the end will own every interface which touches the user. They will define the platforms their suppliers will need to enable in hardware and have to run apps on.
• Given that the tools I am responsible for sit right at the interface between hardware and software, monetization on apps we enable has always been a fascinating topics. With hardware providers (like Continental above) actively thinking about hypervisors to shield the software from the hardware, monetization on apps will become even more difficult for tool vendors.

Bottom line, apps have become a central part of system-level design and are impacting every step of the design process. Getting them fully adopted and which platforms will prevail, remains an interesting question. As always I am looking forward to your thoughts and comments!

Earlier this week I had the pleasure attending the Freescale Technology Forum (FTF). I was there to present on the Synopsys AUTOSAR activities, but was able to get a front row seat during Rich Beyer’s key note. I must say, the first FTF key note back as a public company after their IPO in may, left me nothing less but impressed. It also made me think about who really owns the system-level knowledge these days.

Rich Beyer’s key note opened with a brief video history lesson of former Motorola and Freescale devices, to a heart-beat-like sound track, somewhat reminding of the drums in the Terminator soundtrack. Rich opened with a discussion of challenges presented by us – the end users. Specifically he talked about the internet of things, connected intelligence, devices which adapt to our needs, have all our data in a cloud and even predict what we may want to adapt to us users. In most segments Freescale’s customers were present as well – if not live on stage, then at least via videos.

The chips Freescale develops were always present somehow, but the main event was always their use in end applications. The five “Global Diamond Sponsors” were all embedded software companies: ENEA, Greenheils, Mentor Embedded, QNX and Wind River, testimony to the fact that hardware and software are getting closer.

Five key areas were presented on in more detail:

• Smart Mobile: Here it was all about tablets, cell phones and smart devices which are so easy to use “that my mom could use them”. The new quad-core Freescale i.MX6 series based on ARM Cortex A9 was demonstrated – about one week after silicon samples were back from the fab.
• Networking: This area was all about the infrastructure development. Which capital investment becoming almost unmanageable in this area, the new Alcatel Lucent lightRadio™ (one node in Rich;s hand above) was introduced, apparently distributing the towered basestations into  much smaller array of devices, reducing power and offering major savings for operators.
• Medical: Freescale presented a very cool combination of sensors – installed under the bed and measuring heart rate and turns – with apps on a tablet bringing all your medical data together and then communicating with the doctor via a robot user interface
• Smart Energy: Fujitsu announced a partnership with Freescale around the energy network in Japan, essentially monitoring the network to optimize energy consumption
• Automotive: A triple zero is a good thing in automotive! Freescale outlined a roadmap how to get to zero defects, zero emission and zero fatalities. Apps are involved as well – together with GM Freescale demonstrated apps for the Volt – switching it on and off, pre-conditioning the cockpit and sending information from Google Maps automatically to the guidance system in the car.

In all the areas it strongly looked to me that Freescale as semiconductor company has actually more system-level knowledge than I ever expected – hence the title of this post. It is very clear that the design chain from IP Providers, Semiconductors to Integrators and OEMs is undergoing fundamental changes. With IP Providers heading towards sub-systems and Semiconductor Providers taking on more system responsibility, it will be interesting to see how the design chain will look five years from now!

One thing is clear: Embedded software and system-level design together with tools and methodologies enabling them, will be a key enabler to facilitate whatever changes are ahead.

As a follow up to the DAC workshop called “Intra and Inter-Vehicle Networking in Automotive: Past, Present, and Future”, fellow Blogger Karen Bartelson and I had the pleasure of talking to Wilfired Steiner, Senior Research Engineer from TTTEch, about the challenges of the design of fault tolerant systems.

The discussion covers a variety of topics including the importance of standards, what can happen if real time systems like car’s are not fault tolerant, the design challenges, how the relationships between IP providers and semiconductor companies work, the role of software and we even touched on how much fun standardization can be. You can listen to the full discussion here at our archive of Conversation Central topics.

The technical item which fascinated me the most, is the way how TTTEch and the standardization teams have built on top of an existing standard – Ethernet – capabilities to make timing deterministic. Wilfired explains the details of how timing packets are used to synchronize all network participants in the video below. To reap the benefits, some of the infrastructure needs to be upgraded, but for example in a car the developer has the appropriate design control to account for this upgrade.

From a design tool’s perspective – the amount of software I those systems makes the use of early software development and techniques to enable it (like FPGA and Virtual Prototyping) basically mandatory. Wilfried commented on both simulation and formal techniques during the discussion we had.

It seems like BMW will start using Ethernet for rear view camera video transmission starting in some 2013 models … it will be interesting to see how the adoption of Ethernet and its extensions will evolve over the coming years.

No, not social networking in cars. I’ll leave that for a different time … This is about data and control carrying networks in cars and where they are going. Yesterday I attended here at DAC the Sunday workshop on “Intra and Inter-Vehicle Networking in Automotive: Past, Present, and Future”. It seems like Ethernet has won the battle, albeit not for all areas in the car.

First of all, this workshop was well organized, very productive and interesting – a big thank you to Paolo, Arko and Haibo for putting it together, and of course Alberto Sangiovanni Vincentelli for his championship and guidance.

What networks in a car you may ask? Most of us have heard of CAN, but there is so much more as I learned in the run-up to this event. In this post here a picture from Renesas with some annotations from our team. There are really five busses to look at today:

• CAN – most spread network in the car, some limitations with 1 Mbps bandwidth and non-deterministic behavior under high load >60%.
• LIN – low cost bus for body applications with 19.2 Kbauds and a UART interface
• MOST – designed for multimedia using optical fiber with bandwidth up to 150 Mb/s
• FlexRay – high performance (10 Mbps), deterministic, and secure network, mainly used in X-by-wire, ADAS, and high performance applications
• Ethernet – mainly used for diagnostics today, high potential for more

The morning session of the workshop did the setup from the user side. Alberto Sangiovanni Vincentelli started the day off with an insightful key note on the mega trends. He also pre-counted Ethernet as “winning 5:1” when previewing the upcoming presentations of the day. One key take away of his key note was the trend to design which fully separates function and architecture, which enables OEMs to ‘sandwich” the Tier 1 suppliers more by overtaking a more significant portion of the functional design in software, which then can be mapped into existing ECUs if there is enough performance left. Alberto was adamant that safety critical areas should be separated fully from infotainment like video and audio, safety being the main driving issue.

Harman International continued with an insightful presentation on the AVB extensions for Ethernet – soon to be fully standardized, followed by Prof. Huss from the University of Darnstadt describing simTD, a field test in Germany for Car-to-X applications with very interesting trial results. Raj Rajkumar showed simulations from CMU’s trials on timing guarantees in Vehicle to Vehicle (V2V) networks. What I found most interesting was that CMUs simulation showed that to be effective, only 7% to 8% of the cars need to be equipped with V2V communication. Raj also showed an App, which self-parks Boss, the  autonomous driving car which won the Darpa challenge. This certainly will come in handy during Christmas shopping when it is available.

National Instruments complemented the presentation from Harman with more details on AVB for Ethernet, TTTech gave a great overview of the Ethernet extensions to make Ethernet ready for timing critical and fault tolerant use. Austriamicrosystems did present a future which will see a symbiosis for in-vehicle networks.

After the morning sessions had kicked off with the design issues around Ethernet and left me with the impression that Ethernet is winning for most areas, I kicked off the afternoon session with an overview of challenges and solutions spanning from AutoSAR based architecture analysis, through signal integrity issues when laying out the network, though Ethernet IP and software development for testing. Mentor followed with their AUTOSAR and harness related offerings, Cadence focused on Ethernet IP. Further design solutions for networking related architecture development were presented by aquintos/Vector and Mirabilis, Symtavision closed the day with an overview of migrating from CAN to FlexRay and Ethernet using their formal techniques for timing analysis.

Most valuable was the Q&A. I bluntly asked whether Ethernet is winning or not and the answer was “mostly”. Ethernet definitely has a bright future for video, audio and infotainment in general, but also for more timing critical applications. It’s only downside seem to be cost and EMC issues. FlexRay is definitely not dead it seems, as it used for some timing related applications still. I also asked what the next bus will be which we tool providers need to prepare for. One answer pointed to wireless protocols as next frontier, which makes sense, as weight of cables is a constant target for cost and fuel reduction. Finally I asked who will actually own the other side of the vehicle to infrastructure (V2I) networking as somebody needs to manage traffic and all the data collected. This seems to be an unclear issue and the parties involved in current field trials mentioned that the OEMs need to get together to stimulate that portion. Lots of government and regulatory issues are at play here. It might be easier to create this infrastructure in areas like China’s future megacities, which are just being  planned and built.

Overall a great workshop with interesting insights. Ethernet definitely seems to have a bright future in cars!

I have driven what could be the future of Urban Mobility. I have driven in it, to be precise – somebody else was controlling it. The future looks exciting, a bit concerning at times, but definitely interesting. Interesting especially for electronics, because the type of developments necessary to enable future Urban Mobility is pretty mind boggling and a definite driver for semiconductors and new design techniques.

But let’s back up … what is Urban Mobility? By 2030, according to a presentation recently given by GM at the SMART Technology Conference in San Francisco,60% of the world’s population will live in urban areas, up from 50% today. Within 20 years, 80% of wealth will be concentrated in cities. And as the urban population increases, traffic congestion in large metro areas will become an even bigger issue than it is today. If you have traveled to Taiwan, you have seen scooters everywhere. Similar scenarios are true in Chinese metropolitan areas with bicycles. As congestion improves, Urban Mobility becomes a real issue and concepts like GM’s EN-V may offer a solution.

Courtesy of GM-Ventures I was able to check out two of the rare concept cars in their Palo Alto office. The picture here shows me in the EN-V Miao (Magic). The one I was actually able to drive in is called the EN-V Xiao(Laugh). Quite cool. It feels essentially like an enclosed Segway for two people. When starting, it lifts off and balances on two wheels (here is a pretty cool animation of the chassis and drivetrain).

In terms of electronics, the EN-V is a goldmine for future electronics. It features GPS, a smart phone for remote parking and retrieval, a forward vision sensor for object and collision detection, and forward range sensors for slow speed object and collision detection. The En-V drives autonomously so that passengers can relax and do video conferences with friends and family while on the way to work. It finds parking spots itself and communicates with other vehicles on the road, for example, to negotiate access while approaching intersections. I have seen videos (animated that is), in which the EN-V approaches a four way intersection without stopping – all courtesy of object detection and inter-vehicle communication.

The design challenges in a complex system like that are huge and offer great potential for more and improved design tools. Just think of laying out the network within the device and all the cross-talk effects. The protocol and software effects for networking within the vehicle as well as between vehicles are a definite challenge. The coordination of all the information necessary for driving and presenting it using a Human Machine Interface (HMI) is a very complex task in itself. And of course bringing together all the mechanical and electronic effects will require complex cross-domain simulation.

The EN-V is a concept vehicle today. If it becomes a reality then automotive electronics will create even more complex challenges and require new design techniques. The industry is definitely well aware. If you want to hear first hand about some of the requirements, challenges and potential solutions, there will be a full day workshop called “Intra and Inter-Vehicle Networking in Automotive: Past, Present, and Future” at the upcoming Design Automation Conference in San Diego. I will be there and give a presentation how Synopsys enables design for automotive applications. Join us for the discussion, I am looking forward to seeing you there!

Well, as January is always over I went back into the garage and checked my IEEE Spectrum from January 10 years ago to think about the predictions from that time. The topic  of the 2001 forecast issue was “Always On – Living in a Networked World”. Overall I am mighty impressed how accurate the outlook of the IEEE team of editors was!

My favorite article of the issue is The 21st Century Engineer by Joseph Bordogna of the US National Science Foundation. Although addressed to the overall engineering population, we EEs can find ourselves very well in here. Bordogna refers to five new capabilities that are shaping the future of engineering— terascale, nanoscale, complexity, cognition, and holism. All of them find themselves in our day to day world of system-level design as we refer to it in our industry.

• Terascale takes us “three orders of magnitude beyond present general-purpose and generally accessible computing capabilities”. Indeed, with the design starts shifting to smaller geometries, the overall complexity in our domain has grown tremendously. Moore’s Law would predict a 32x complexity increase over the last ten years in hardware alone. The addition of software makes it even more complex, perhaps not extending to the mentioned three order of magnitude, but still quite a bit, and certainly enough to push system-level design tools and method closer to mainstream.
• Nanoscale “will take us three orders of magnitude below the size of most of today’s human-made devices”. OK, no question there now that we are discussing 16nm/15nm technology nodes.
• Complexity to the point “where the components of a system never quite lock into place, and yet never quite dissolve into turbulence, either…” (referencing Mitch Waldrop’s book “Complexity”). Well, things lock well into place in the world I live in (and can go to layout afterwards). But still, complexity has grown so much that we are now approaching – according to latest Semico data – 57% IP Reuse in chip-design expecting it to grow to 73% in 2015. Just the number of IP blocks per chip has grown to an average of 50 in 2010 and is expected to grow to 113 in 2015. For comparison, a 2006 Semico report has the percentage of re-use in 2001 at about 10% and the average number of re-used blocks at around 10. Quietly IP Re-use has addressed over the last ten years part of the system-level design challenge, only to create new ones instead: A big portion of today’s challenge lies in IP Integration.
• Cognition, defined as “the mental process or facility by which knowledge is acquired”, Bordogna believes to be “on the verge o a cognitive revolution that may dwarf he information revolution”. I would fully agree and as a result we in the area of system-level design are thinking a fare share of our time of the right abstraction levels at which the systems we help to design can be comprehended. Thinking in transactions instead of signals is only one step …
• Holism, according to the dictionary is “the concept that an entity is greater than merely the sum of its parts”. Bordogna concludes that the “hallmark of the modern engineer is the ability to see connections among seemingly disparate components, and to integrate them in ways that exceed the sum of their respective capacities”. I fully agree and think we certainly could do that  more in my world, but I do see progress here as well. As a result I am more often meeting new people – not that there is something wrong with the ones I know – but it is refreshing to for example talk to colleagues about the system-level challenges in optics and mechanics. We often do find interesting new connections – like in the emerging world of mechatronics for automotive system-level design.

My other favorite, really interesting articles of this issue are:

• Philip E. Agre’s “Welcome to the always-on world“, in which the author talks about the outlook of email being checked anywhere, anytime, something which has become full reality for most of us (which device are you reading this on?).
• Linda Geppert’s “The new chips on the block [network processors]“, which talks about the challenges in networking which have lead to what we now know as “multicore design”.
• Elisabeth A. Bretz’s “The car: just a Web browser with tires” quotes Scott McNealy saying ““Why not think of everything as just an Internet node? So a car is just a [Web] browser with tires.” I did ride this car by now, Scott was right 10 years ago …

Bottom line it is fun being part of the engineering community and I certainly meet a lot of people fitting Bordogna’s description of the 21st Century Engineer, who “will need to be astute makers, trusted innovators, agents of change, master integrators, enterprise enablers, technology stewards, and knowledge handlers. They will need more than first-rate technical and scientific skills. They will need to embrace complex systems and the issues they present, and reach the right decisions about how huge amounts of time, money, people, knowledge, and technology are tasked to a common end.”

Watching today’s electronics projects reminds me of playing Monopoly when growing up. The term “Gehen Sie nicht über Los” has become somewhat proverbial in German language for “game over” situations. It is printed on the card in Monopoly which sends you directly to jail, does not let you pass the starting field and does not grant you the per round income. Missing a deadline in a project can be like that, only the result is not jail but a dead project, a dead company or a pivotal point in a project manager’s career. And that’s where system-level design comes in to the rescue ….

In day to day situations when discussing with customers the value of system-level design, I am trying to use their language and visualizations they are used to. This week Mazda announced the adoption virtual prototyping for Electronic Control Unit (ECU) verification. This makes me think of the specifics of the automotive world and how nice some of their visualizations can explain the value of system-level design.

Common visualization in automotive is the V-diagram as shown on the left. From Vehicle requirements the specification process proceeds through system design sub-system design, ECU specification to the actual ECU development. Once the ECU is done, the development process is on its upswing of integration, testing the ECUs, integrating sub-systems to verify them within the system and finally validating the vehicle.

This makes me think of Monopoly because finding a defect late in the development cycle and potentially not being able to fix it is like going directly to jail, it leads you back into the downward phase of this process. And, like in Monopoly, you certainly won’t collect any additional bonus here.

However, if one applies virtualization – virtual prototypes for example, then that means essentially moving the whole integration phase to the left. As a result that means more tests on virtual prototypes earlier, augmenting the use of hardware prototypes later in the project. As John Day writes in his this story on the Mazda adoption, together with time savings, users will find less bugs during the traditional hardware software integration phase. They can also do more directed testing, i.e. produce corner cases which are hard to re-produce or even dangerous in real life tests.

And of course they can collect their money during the next round, just like in Monopoly when having the “get-out-of-jail-free” card.