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.
Jack Horgan - Contributing Editor


by Jack Horgan - Contributing Editor
Posted anew every four weeks or so, the EDA WEEKLY delivers to its readers information concerning the latest happenings in the EDA industry, covering vendors, products, finances and new developments. Frequently, feature articles on selected public or private EDA companies are presented. Brought to you by EDACafe.com. If we miss a story or subject that you feel deserves to be included, or you just want to suggest a future topic, please contact us! Questions? Feedback? Click here. Thank you!

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.




There is a colorful picture showing the software stack. If you start at the top there is an application layer. The red bar is the interface. You can imagine an application for a given breaking system. That application would live above that line. The red line would bind in those applications into all these standard different pieces of software as drivers. They call all of these the basic software. There are four services (software services, communications services, memory services and I/O services). Basically, it says if you have an application, it might have to talk to memory, to the operating system, to a CAN or a LIN bus, or directly to an actuator. All of these interface layers or driver layers are all commodities now, all standard. That is the message of Autosar. The black bar is the final application layer, meaning the microcontroller application layer. That binds together the commodity software, the basic software modules into the specific pieces of hardware. Once you make that interface once for a given processor, a specific piece of hardware, you can use that over and over. The task is minimized. You can really interface your application to this layer. The green vertical bar is the backdoor to the Autosar standard. It says that if all those other standards and interface layers defined in the Autosar community fail, we can still have a direct connection from the
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.




« Previous Page 1 | 2 | 3 | 4 | 5  Next Page »


You can find the full EDACafe event calendar here.


To read more news, click here.



-- Jack Horgan, EDACafe.com Contributing Editor.




Review Article Be the first to review this article
CST: Webinar

Aldec Simulator Evaluate Now

Featured Video
Jobs
ASIC Design Engineer for Infinera Corp at Sunnyvale, CA
Senior PIC Test Development Engineer for Infinera Corp at Sunnyvale, CA
Applications Engineer for intersil at Palm Bay, FL
RF IC Design Engineering Manager for Intel at Santa Clara, CA
Upcoming Events
Essentials of Electronic Technology: A Crash Course at Columbia MD - Jan 16 - 18, 2018
Essentials of Digital Technology at MD - Feb 13 - 14, 2018
IPC APEX EXPO 2018 at San Diego Convention Center San Diego CA - Feb 24 - 1, 2018
CST: Webinar series



Internet Business Systems © 2017 Internet Business Systems, Inc.
25 North 14th Steet, Suite 710, San Jose, CA 95112
+1 (408) 882-6554 — Contact Us, or visit our other sites:
AECCafe - Architectural Design and Engineering TechJobsCafe - Technical Jobs and Resumes GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy PolicyAdvertise