June 29, 2009
Autosar and VSA from Mentor Graphics
Please note that contributed articles, blog entries, and comments posted on EDACafe.com are the views and opinion of the author and do not necessarily represent the views and opinions of the management and staff of Internet Business Systems and its subsidiary web-sites.
Serge turned the conversation over to James Price, Marketer for the VSA.
What are the various types of networking technology involved in automotive electronic systems?
There are four different ones. Three of them are related in terms of networking protocol, CAN , LIN and Flexray. CAN has been around a long time and has wide acceptance in European and American cars. It is a two wire system. There has been a lot of effort in how to make it as efficient as possible. However, it does have some issues, bandwidth and sometimes reliability issues. Those can impact car production. There is a kind of a Catch-22 in that Flexray really was the answer to these issues. It had better reliability and bandwidth but the problem was it had a high cost of adoption. While CAN was lower cost and had some problems, the problem was that nobody wanted to go out and put the
money into Flexray adoption because it was complex and cost more. CAN probably had a longer life than you might think it should have had. Flexray has had a slow adoption rate. There are a couple of versions of CAN. One version was as simple as a one wire system with chassis return. That had all kinds of problems. The twisted wire version was much better.
The other standard that is emerging and which is really a commodity is Ethernet. That has to be considered especially for entertainment because there are lots of systems that understand Ethernet as well as available chips and hardware.
Editor: CAN (Computer Area Network) is a vehicle bus standard designed to allow microconcotrollers and devices to communicate with each other within a vehicle without a host computer. The CAN protocol was released by the Society of Automotive Engineers (SAE) in 1987. The LIN (Local Interconnect Network) bus is a small and slow network system that is used as a cheap sub-network of a CAN bus to integrate intelligent sensor devices or actuators in today’s cars. CAN, LIN and Flexray all have supporting consortiums.
What is Autosar?
What brings all of this stuff together is Autosar. Autosar has its first production vehicle coming out in the BMW Series 7. Autosar has several portions. One portion is methodology, one is conceptual and one is the hardware/software design aspects of doing electronic systems in cars. Autosar is the “AUTomotive Open System Architecture”. It is intended for designing automotive software and electronic architecture. It is a huge standardization effort. It will require retooling. It is a good opportunity for a company like Mentor Graphics because we can offer tools now that we have a standard in place. From the vendor’s point of view we can provide some automation to help
bring along the design process much like years ago when people were designing schematics by hand, laying out chips by hand. Of course that is now automated. Autosar adoption is proceeding in spite of the economic downturn. It is interesting because there is this pot of gold at the end of the rainbow of in terms of different cost savings. Cost savings was the motivation for Autosar in the first place.
Imagine you had a car with 80 ECUs. That’s the high end. Maybe the low end of the spectrum might be 5 ECUs. Somewhere in the middle (20 – 30) might be the typical domestic car here in America. The ECUs are the boxes that the electronic systems are hosted on. Each of these ECUs is unique. What often happens is that the Tier 1 suppliers that make these boxes for the car companies, whether it be Delphi or Bosch, would maybe bid those initial contracts for electronics pretty low but then they would make up the revenue in terms of charging for lots of fixes and updates to the boxes because it was a proprietary thing. The whole idea of Autosar is that it is not proprietary anymore. In
fact a big portion of the embedded software that binds the application layer into the hardware is a commodity now. This is the whole motivation. In the case of 80 ECUs, you might have 5 to 10 different types now. You can reprogram them for the 80 specific different functions. This is where the cost savings comes from. There is a catch phrase they always talk about in terms of Autosar. The phrase is “collaborate on process and compete on implementation”. You have the application layer of the embedded software as the unique value you add for your company.
There is the notion that we have a bunch of software components and a bunch of ECUs on the bus and we are going to map this software component (this piece of application software) on a given ECU, on a given piece of electronics for a variety of reasons and tradeoffs including here’s other functions that will run similarly and can run faster. Some of these might not be intuitive at first glance but now that you have tools that can track this whole system as you build it, it can automatically allocate application functions to the hardware ECUs.
application layer right into the hardware. They call that the complex drivers. In a nutshell that is what Autosar is.
Another way to look at the problem we are trying to attack, is that we want to maintain or increase the performance of a car and we want to have all these systems scalable and to be as or more reliable than they are today. We want to maintain or decrease cost. We have a given weight. Packaging is just a given, a bounded condition. The car is only so big. With the balance of all those issues in the car, now we put the likes of the topology, the wires, the different electronic systems, the functionalities of all the actuators as we try to duplicate our living room experience in a car. How do we do that? If we were to do this with ECUs without standards, the integration of all these
different tasks would be open ended, a runaway condition. What we are trying to do is linearize the design task as you add more and more of these different functions and issues inside the architecture and keep this controllable.
Let us isolate this down to what is the electronic and electrical engineering design flow. We start with some requirements. Then we look at the architecture of the system as a whole so we can start doing some reasonable tradeoffs. We break this down into the specifics of the network, the specifics of the embedded software, the specifics of the cable harness and the specifics of the hardware in terms of PCBs and ICs. Under each of different areas, we encourage validation.
Let’s overlay what Mentor Graphics has.
You can find the full EDACafe event calendar here.
To read more news, click here.
-- Jack Horgan, EDACafe.com Contributing Editor.
Be the first to review this article