Virtual design, verification for e-Mobility(2)

A big challenge in integrating systems is that components invariably come from multiple suppliers. This compromises safety and quality. At the start of ECU-software integration, there may be thousands of errors present. The later that someone identifies the problems, the more it costs to fix them. Problems that manifest themselves once the car is in the customer’s hands become very expensive to fix. Business Week reported that Toyota’s 2009-10 recalls cost the company more than $2 billion, including legal costs, lost sales and warranty payments.

System engineering and simulation
So how can automotive design teams conquer the system design challenges that come with vehicle electrification? The problem scope is not limited to software and electronicsdesign teams must also consider mechatronics. Potential solutions need to support detailed physical modelling, conceptual design and implementation, and concurrent, multiple tiers of modelling and verification.

The history of car electronics has gone from simple power generation and distribution, through electronic control systems, to electronic drive systems. The cost of electronics has increased from 10% to 60% of the car for electric hybrids. The cost is not in software (manufacturing of software is mostly free) but in the electronic, electrical, and electro-mechanical components that make of up the vehicle.

Model-based embedded systems engineering

Carmakers need models for multiple purposes:

???For analysing/verifying the product need,
???To define software applications of the EE system, and
???To support simulation and verification of the plant/multi-physics/car system models.
Consequently, modelling requires the use of many different frameworks:

???AUTOSARsoftware running on a virtual processor,
???EAST-ADL2software running in an environment (plant included),
???VHDL-AMS/MASTmechatronics modelling and electrical systems,
???SystemC/SystemC-AMSsystem-level description of SoCs and interconnection of SoCs,
???SystemVerilog/Verilog-AMSSoC implementation, and
???SPICEIC analogue.
Bringing together all of these elements requires a platform that is capable of modelling and simulating physical systems, which enables full-system virtual prototyping for applications in analogue/power electronics and electric power generation, conversion distribution and mechatronics.

Semiconductors are the basis of all automotive electronics systems, while software runs on all the ECUs, mechatronics is what makes the software do something useful. To be useful, a platform must incorporate an electrical system architecture that links these key system components together.

Power generation, management and distribution
The core function of the vehicle is still the generation, management, and consumption of electricity. This is even more pronounced with electrification since the power train is now a factor in all of these areas. All of the electrical systems need to make use of low-power techniques so that the amount of electricity used by the vehicle can be reduced, and so, too, the battery size.

We can reduce the electrical load on the battery by optimising 12/24/48V loads, by reducing the amount of wire in the vehicle, and by designing more efficient HVAC (heating, ventilation and air conditioning) systems.

Compared to automotive, other sectors, like the mobile phone industry, have a lot more experience of applying low-power techniques. Battery life plays a large part in determining the success of mobile software platforms like Android. And in turn, software has a large part to play in determining battery life. For example, an application that wakes up the phone every 10 minutes for just eight seconds to perform updates can cut its stand-by time by half. Any software power inefficiency or malfunction can quickly cause a drop of 5x or more in standby time.

The complex, highly distributed software entities for power saving and management must be vertically integrated and cooperate to guarantee an efficient use of the battery in a mobile phone. The phone’s usage scenarios play an important role as they define how it interacts with the environment. However, how can you debug your phone while it is locked in your pocket? How can you make sure that scenarios are deterministic to compare different implementation options?