Search Results

Traditional methods for optimizing an Electrical Distribution System have always been less than ideal. Engineers are typically left with unsophisticated and manual spreadsheet tools. Any detailed feedback on critical metrics such as cost or weight typically relies on another organization and requires week or months. The resulting EDS is inevitably suboptimized, not due to a lack of engineering ability, but rather the tools available. To ensure that the EDS design is optimized from the outset, the design environment itself must be enhanced. There are four key attributes to this design environment. Automation is required to ensure that designs are synthesized rather than manually created. There are many benefits of this, but efficiency and repeatability are most important to this conversation. The ability to measure and assess the design must be available in the design, while the engineer is designing. The metrics used to measure must be easy to create and modify.

Until recently, the electrical systems architecture that connects hardware devices and their accompanying control components were not separately a part of formal certification mandates. This changed with the advent of the FAR Part25 Subpart H EWISi (Electrical Wire Interconnection Systems) mandate. Interestingly this mandate, like certain others, does not impose specific solution. Instead it provides a structure that outlines what must be accomplished from a variety of perspectives - safety, signal separation, part selection, etc. The designer has some flexibility on which decisions to make, but those decisions can have significant cross-domain impact, which in turn, have influence on the intended product performance. What is needed is a method to design, verify and build virtually the entire electrical architecture with confidence that the best architecture is defined within the program constraints.

The development of experimental ORC systems is an extremely complex, time consuming and costly task. Running a range of experiments on a number of different component configurations may be prohibitively expensive and subject to equipment issues and failures. Yet ORC systems offer significant potential for automotive manufacturers to improve vehicle efficiency, reduce fuel consumption and vehicle emissions; the technology is particularly relevant for those involved in the design and/or manufacture of heavy duty trucks. This paper is focused on the validation of a computational ORC system simulation tool against a number of SAE published test results based on the European Stationary Cycle. Such studies on industry standard systems are essential in order to help promote confidence in a virtual prototype approach.

The evolution in automotive qualified electronic components, including the birth of powerful multicore System-on-Chip (SoC) platforms has fundamentally changed the approach to designing automotive electronic systems today. This evolution is not only happening on the hardware side, but also on the software design side where there has been consolidation of multiple domains onto a single SoC. This type of consolidation allows shorter time-to-market with consumer-ready features to address immediate market demands. This paper explores the reasons for this trend and available architectures for achieving consolidation. AUTOSAR on Linux is one of those architectures and has been popular in Advanced Driver Assistance Systems (ADAS) and infotainment applications, allowing complex functions to smoothly integrate into the vehicle network.

Meeting aerospace configuration control mandates involves a host of issues such as data access control, configuration context and release management, just to name a few factors. Currently, many companies rely on the existing product lifecycle management (PLM) environment to identify and sort out issues during data release. This has proven to be inadequate. In this paper, it is postulated that new design tools employing automation can save a great deal of time when meeting these mandates and eliminate errors as well. The tools are based on the model-based development (MBD) process, which puts much more emphasis on the actual data instead of simply drawings. This paper explores how leading aerospace original equipment manufacturers (OEMs) are adopting new capabilities for the designers during the development process in an effort to mitigate errors related to data inconsistencies.

Communication between electronic control units (ECUs) and vehicle gateways can span LIN, CAN, FlexRay, and Ethernet. Designing an in-vehicle network supporting multiple car platform variants, with respect to selecting the appropriate technology to connect ECUs and gateway networks, and making timing based analysis and synthesis is extremely challenging. This paper discusses how to handle a variety of communication protocols on an individual network level and how multiple networks relate to the overall communication design of a vehicle platform ensuring consistent variants.

AUTOSAR 4.x is being deployed by many of the world's top automotive OEMs. It has also seen increased adoption in regions outside of Europe. OEMs exert significant effort in the design, configuration, integration, and final build of AUTOSAR-based systems. This presentation gives an overview on the main advantages and critical gaps of adopting AUTOSAR to E/E design automation, including the digital interaction between Tier 1 suppliers and OEMs. This paper also discusses how the Electronics Architecture and Software Technology Architecture Description Language, or EAST-ADL, complements some of the weaknesses found in the current AUTOSAR release.

Increasingly, Ethernet is being used in automotive as a vehicle network backbone. It is ideal for service-oriented communications; streamed communications, such as Audio/Video Bridging (AVB) [1]; and Diagnostics over Internet Protocol (DoIP) [2] communications - areas in which high-bandwidth and reliable performance are essential. Designers are accustomed to network communication systems CAN, LIN, and FlexRay, but how will the timing performance be verified in an Ethernet network? This paper looks at network-wide timing analysis challenges where a mixture of CAN, FlexRay, and Ethernetbased busses co-exist. It is also worth noting that the AUTOSAR standard [3] supports timing definition for all elements in a mixed topology network, but again, accounting for the many different timing paths is a non-trivial process. Figure 1 The Ethernet backbone serving different domains.