The first thing we map onto this is the cable harness tools. These are state of the art tools. We also have tools that allow user to do tradeoffs as he does design, to maximize or minimize the wiring in the electrical system. Of course, Mentor is number one in the PCB area right now in the world. We also have very strong tools in the IC flow. The Cable Harness System has an architecture piece that again allows the designer and the developer to do tradeoffs.

Then we go to the part of the electrical architecture design in terms of Vehicle System Architect (VSA), the product we are talking about today. With VSA you can think of doing the topology tradeoffs, doing all of the mapping and seeing here is all the software function I have. What is the optimal way to map them onto the different pieces of hardware, onto the different control units? Furthermore, because we have the CHS Architect and VSA, we are setting up communication between these tools to be able to make tradeoffs on a bigger scale. For instance, if I move this electronic function to this ECU and I then move that ECU to the front of the car, what impact will that have on the buses in terms of the actual wiring implementation? We can build these kinds of tradeoffs now. In addition to the VSA, we also have the networking tools. We can do Flexray, CAN, and LIN plus cluster synthesis. What that means in every day language, is that you get the three major protocols (and if Ethernet comes on, it will just be another one of these protocols). We are going to look at the bus and the specifics of a given bus architecture. You will be able to load up the bus and be sure you have an appropriate amount of packets and communication between each of these ECUs, so that you do not overload the bus at any given time just for safety and functional reasons. That is called the communication clusters and how to build this cluster via synthesis. There is this whole huge amount of commodity software, basic software.

One of the tools we have at test customers (teacher customers) is Autosar compliance testing. It is nice that we have all of these common software modules but the idea is that are they compliant with the Autosar specification. If they are not, you can build them cheap but they won’t be any good for anything. We are building tools both for our own basic software and for basic software from other vendors to be sure that they are compliant. On top of this we have the full notion which is in the conceptual portion of the Autosar standard. The application layer is actually broken down into multiple software components. We have hooked those together with the notion of the operating system and the runtime environment. We would like to bind all of this together and compile that without actually running it on the real ECUs. We would like to see if they would functionally run together. We would like to find any inconsistencies in the operating system in just the application layer so that we can debug the software. So we have a virtual integration. We also have a tool we are doing that is capable of doing that. And then we have tools that will be doing the ECU configuration.

We talked about the Autosar basic software that goes hand and hand with the Autosar compliance testing. Finally, in terms of software, most of the software today is generated by hand. The industry is moving much more toward synthesized software just as today if you were thinking of building a huge microprocessor, you would not be laying out in gate nor would you be writing it by hand in RTL. The same migration is going on for embedded software. We have a tool called BridgePoint, where you can write the functions at a high level and then you can generate the source code. We are weaving all those together so as you generate the code, it is aware of all the interfaces that it needs into the run time environment layer. Finally, we have a tool called SystemVision which is a parametric tools that looks deeply into each of the different areas of hydraulics, electronics, and mechanics; any of the basic physics. You can simulate these mechatronics environments. A lot of these systems have challenging integration task. The idea is for us to do as much of that integration virtually as possible.


Consider the picture below.



When you look at this picture, you might think that this must be an FPGA that has been autorouted. But this is really a software diagram. Each of the white boxes has 67 functions within this climate control system. Those 67 functions are hosted in software components. That’s how Autosar breaks them down. 67 functions, 1400 tasks and between those tasks 1300 signals communicating between them. All this stuff is clustered inside three ECUs. And this is a simple system that just turns on the heating system rather than a specialized breaking system or transmission systems. Just imagine how big those are.

This climate control system was one of our benchmarks for a customer. There were some 300 competitors in this area. The nice thing was that we had designed these tools from the ground up around the Autosar meta model. So we could do designs very quickly and very efficiently. We won this benchmark very readily.

VSA manages the logical architecture where you can define software components, where you can group them in different combinations and where you can do the software component mapping onto the ECUs. The overall idea, the methodology, of Autosar is that you take the whole system and you design it holistically. Then you distribute it out to different ECUs. This tool is designed to do that. You can also look at different ECU properties like CPU loading and memory requirements. Of course, it has specific communication mangers and protocol managers for CAN, LIN and Flexray. It looks like we will also be doing Ethernet. It depends upon demand. The VSA goal for architecture and design is to bridge this gap of logical function design and implementation in the architecture. The whole goal is to bridge the gap at a higher level. One is at the functional level and one is at the system level.

What we are striving to do is to provide useful feedback to the developers so that they can make tradeoffs during the design, so they can make logical and physical tradeoffs. Things like, if I move these functions, will it run fast enough, can I get enough bandwidth on the bus, am I minimizing the weight and wiring in the car?

VSA covers a lot of different roles or areas of the design community: software engineers, software architects, system architects, network designers and ECU engineers. We believe that as these tools come on line, people have a common pallet to talk and to work with. These roles may change. They may collapse into one role. The good news is that people can do more in depth studies to make cars safer, more reliable and have more functions. Once all of the different roles or people bring together the different electrical systems then it can be all stored in some kind of configuration management system. Then that configuration management system is stored holistically and sent to the Tier One suppliers like Delphi and Bosh. They can go and see the high level system and can see how to implement the exact hardware for the ECU that you need. In the mean time, there is going to be these third party software suppliers (us included) to provide the basic software layer, the ecosystem.


What are the benefits of VSA? Why should someone buy this tool?
VSA enables concurrent and iterative engineering according to the Autosar process.
We developed our tools on an Eclipse-based infrastructure which has been good for us. It has a big payback in terms of allowing us to integrate different tools that we’ve had at Mentor together into a common environment very quickly. Historically it has taken months, even years, to integrate some of our tools together. So this has been a good tool for us. Actually, this is one of the infrastructures that Autosar promotes and encourages developers to use. We cover the full Autosar system design for the software, the system and the ECU resources. Mentor had been around 28 years. We are probably the oldest EDA company and one of the oldest software companies; so software lessons learned and applied.



You can find the full EDACafe.com event calendar here.

To read more news, click here.


-- Jack Horgan, EDACafe.com Contributing Editor.