Search Results

To cope with the increasing number of advanced features (e.g., smart-phone integration and side-blind zone alert.) being deployed in vehicles, automotive manufacturers are designing flexible hardware architectures which can accommodate increasing feature content with as fewer as possible hardware changes so as to keep future costs down. In this paper, we propose a formal and quantitative definition of flexibility, a related methodology and a tool flow aimed at maximizing the flexibility of an automotive hardware architecture with respect to the features that are of greater importance to the designer. We define flexibility as the ability of an architecture to accommodate future changes in features with no changes in hardware (no addition/replacement of processors, buses, or memories). We utilize an optimization framework based on mixed integer linear programming (MILP) which computes the flexibility of the architecture while guaranteeing performance and safety requirements.

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.

Vehicle communication networks are challenged by increasing demands for bandwidth, safety, and security. New data is coming into the vehicle from personal devices (e.g. mobile phones), infotainment systems, camera-based driver assistance, and wireless communication with other vehicles and infrastructure. Ethernet (IEEE 802.3) provides high levels of bandwidth and security, making it a potential solution to the challenges of vehicle communication networks. However, in order to be used in control applications, Ethernet must provide known timing performance (e.g. bounded latency and jitter), and in some cases redundancy. This paper explores use of Ethernet for in-vehicle control applications.

Given the fast changing market demands, the growing complexity of features, the shorter time to market, and the design/development constraints, the need for efficient and effective verification and validation methods are becoming critical for vehicle manufacturers and suppliers. One such example is fault-tree analysis. While fault-tree analysis is an important hazard analysis/verification activity, the current process of translating design details (e.g., system level and software level) is manual. Current experience indicates that fault tree analysis involves both creative deductive thinking and more mechanical steps, which typically involve instantiating gates and events in fault trees following fixed patterns. Specifically for software fault tree analysis, a number of the development steps typically involve instantiating fixed patterns of gates and events based upon the structure of the code. In this work, we investigate a methodology to translate software programs to fault trees.

The increase in the number of electronic control units (ECUs) in the modern vehicle, combined with increased software complexity and more distributed controls has led to an extreme testing challenge when it comes to the verification and validation of body-control ECUs. In general test engineers have to deal with more software configurations, more closed-loop interaction between ECUs, and more fault conditions than ever before. By adding Unified Diagnostic Services (UDS) over CAN to a Hardware-In-The-Loop (HIL) test system, Lear was able to increase test automation and provide wider test coverage by automating the ECU flashing process, adding diagnostic identifiers and trouble codes to their test scripts, and providing a quick and easy way to exercise ECU I/O. Lear chose to implement their HIL testers on the open PXI[1] hardware platform, utilizing National Instruments' VeriStand software framework.

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.

Modular instrumentation is being widely used in noise and vibration measurement systems that demand higher channel counts and the wider dynamic range that 24-bit delta-sigma ADCs make available at lower costs. This is an overview how flexible modular instrumentation employing the latest software technology can be used in making high precision noise and vibration measurements where higher sampling rates, higher channel counts, increased dynamic range, and distributed architectures were needed in smaller packages. An example where this is being used is in acoustic beam forming in aircraft pass by noise tests to measure and distinguish engine and airframe noise sources.

ECU designers are seeking more flexibility from HIL test systems. Often their needs are met by the development of custom hardware, either internally or by HIL test system vendors. Many systems also rely heavily on the use of multiple expensive microprocessors to achieve the required timing and synchronization performance. This paper discusses an alternative based on PC technology and reconfigurable I/O hardware. The HIL test system designer uses a graphical programming interface to reconfigure not only the real-time software portion of the system, but also the FPGA-based I/O hardware. This increases flexibility and lowers cost by providing capabilities such as generating simulated outputs synchronized to crank angle and implementing multiple serial communication protocols.

The increasing number of features and complexity of today's automotive software architectures bring new challenges to the product development cycle. As a product is being developed, there is a need for information created during the early phases to flow seamlessly into subsequent phases. For example, information defined for an ECU during the design phase should be re-used when that ECU is tested during manufacture. Challenges often arise from the fact that one vendor's tools may be appropriate for design, but a different vendor's tools are best suited for manufacturing test. This paper discusses business and technical issues surrounding the transfer of information between such tools. Two case studies are used for discussion. One deals with databases describing signals transferred over an in-vehicle network and the other discusses simulation models as both transition from early designs through various test phases.

Empowering the end-user is the primary focus of most software developers, whether in the general computing industry or in automotive instrumentation applications. End-users' expectations for both ease of use and flexibility in software products are high. Products in the general computing industry, such as Microsoft Word and Excel, have set standards for what a user expects from a software product. Because of the complex nature of most analytical instrumentation applications, it is difficult to deliver a software product for these applications that is both easy to use and flexible for many applications. And, if the product does exist, it usually comes with a relatively high price tag. There are, however, some lower cost software development tools available for instrumentation applications that combine a good mix of flexibility and ease of use. These tools require some development on the part of the end-user, but they do not require a computer science background.