Search Results

48V mild hybrid engine is one of major eco-friendly technology for global CO2 reduction policy. The 48V mild hybrid engine enables to operate torque boost, recuperation and ISG status by MHSG(Mild Hybrid Starter and Generator). The FEAD(Front End Auxiliary Drive) system is a very important role to transfer MHSG power to crankshaft at the mild hybrid engine. The conventional FEAD configuration is relatively simple because it transfers power from crankshaft to auxiliary drive components in one direction. But the FEAD configuration of 48V mild hybrid engine is not simple due to bidirectional power transmission between crankshaft and MHSG. For instance, in case of torque boost mode, the tight side of auxiliary belt is entry span of MHSG. On the contrary, the tight side of auxiliary belt is exit span of MHSG at recuperation mode.

Engine ECU testing requires sophisticated sensor simulation and event capture equipment. FPGAs are the ideal devices to address these requirements. Their high performance and high flexibility are perfectly suited to the rapidly changing test needs of today's advanced ECUs. FPGAs offer significant advantages such as parallel processing, design scalability, ultra-fast pin-to-pin response time, design portability, and lifetime upgradability. All of these benefits are highly valuable when validating constantly bigger embedded software in shorter duration. This paper discusses the collaboration between Valeo and NI to define, implement, and deploy a graphical, open-source, FPGA-based engine simulation library for ECU verification.

Automotive HW/SW architectures are becoming increasingly complex to support the deployment of new safety, comfort, and energy-efficiency features. Such architectures include several software tasks (100+), messages (1000+), computational and communication resources (70+ CPUs, 10+ buses), and (smart) sensors and actuators (20+). To cope with the increasing system complexity at lowest development and product costs, highest safety, and fastest time to market, model-based rapid-prototyping development processes are essential. The processes, coupled with optimization steps aimed at reducing the number of software and hardware resources while satisfying the safety requirements, enable reduction of the system complexity and ease downstream testing/validation efforts. This paper describes a novel model-based design exploration and optimization process for the deployment of a set of software tasks on a dual-processor control module implementing a fail-safe strategy.

LIN is a low-cost, low-speed vehicle communication sub-bus becoming increasingly pervasive in automotive subsystems. It is a simple, UART-based master-slave protocol designed as a low-speed supplement to a CAN or FlexRay bus. Its primary application is cabin comfort and human interface hardware such as dashboard controls, power seat harnesses, and power door/window systems. As automotive network designers attempt to reduce wiring complexity and lower system cost, modular, inexpensive sub-buses like LIN become an attractive option. This paper presents an overview of the LIN standard and its applications, and then proposes an architecture for rapid development of LIN networks via hardware simulations of LIN nodes. Using inexpensive, off-the-shelf hardware, LIN sensor and actuator applications can be tested in-place without microcode development, speeding overall network development time.

In many measurement applications, there is a need to correlate data acquired from different systems or synchronize systems together with precise timing. Signal Based and Time Based are the two basic methods of synchronizing instrumentation. In Signal Based synchronization, clocks and triggers are physically connected between systems. Typically this provides the highest precision synchronization. In many NVH applications size and distance constrains physically connecting the systems needed for making measurements though the inter-channel phase information of simultaneously sampled signals is crucial. In Time Based synchronization, system components have a common reference of what time it is. Events, triggers and clocks can be generated based on this time.

Almost every automotive noise, vibration, and harshness (NVH) engineer who has ever looked at a fast Fourier transform knows the difference between instruments with 90 dB and instruments with 120 dB of dynamic range. NVH engineers understand instrumentation specs such as 24-bit resolution analog-to-digital converters and alias-free signal bandwidth. However, with modern noise and vibration instrumentation systems now being almost completely built on the PC, these specs neglect the most important X factor: the PC itself. No other aspect can affect the performance of an instrumentation system for a sensor array more than the components of the PC. Fortunately, a variety of off-the-shelf PC technologies built on industry standards are available to make it easier and less expensive than ever before to instrument and manage data from large systems. But an NVH engineer must wade through a sea of options to choose the right PC technologies for desired instrumentation system performance.

With the abundance of electronic devices and sensors in automotive technology, it has become increasingly important to establish efficient, cost-effective device validation methods for CAN, J1939, and GMLAN. An easy method of validation is simultaneous sampling of multiple measurements for comparison. For instance, if you have an ECU that receives inputs using CAN, and controls analog outputs, you can measure both CAN and analog data to verify that the ECU algorithm is behaving properly. This paper will discuss techniques for sharing timing and triggering signals between CAN, analog, and digital hardware to prevent clock drift and start latencies and reduce operating system jitter. We will cover techniques to use a common clock to drive multiple boards and specify events to trigger multiple board acquisitions. Timing and triggering signals can be shared in a PC through timing and triggering cables or in PXI through the PXI Trigger bus in the backplane.