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.

Industry standards and practices define a number of mathematical and physical methods to estimate the cargo carrying volume capacity of a vehicle. While some have roots dating back decades, others try to assess the utility of the space for cargo by subjective measurements. Each these methods have their own inherent merits and deficiencies. The purpose of this paper is to highlight the differences in calculated cargo volume amongst the following practices: Society of Automobile Engineers (SAE) J1100[1] International Organization for Standardization (ISO 3832)[2], Global Car manufacturer's Information Exchange group (GCIE)[3], Consumer Reports[4]. This paper provides a method and associated rationale for constructing a new cargo volume calculation practice that attempts to harmonize these procedures into a more contiguous practice. This homologation will benefit publishing industry, vehicle manufacturers and customers alike.

Vehicle development typically occurs by independently documenting requirements for individual subsystems, then packaging these subsystems into the vehicle and testing the feature operation at a higher level, across multiple subsystems. Many times, this independent development process results in integration problems at the vehicle level, such as incomplete feature execution, unexpected operation and information disconnects. The development team is left to debug and create inefficient patches at the vehicle level due to time constraints and / or planned release dates. Without architecting solutions at the feature level, miscommunication of expected feature operation leads to wasted time, re-work and customer dissatisfaction. While the development of vehicle level technical specifications provide feature expectations at the vehicle level, they do not solve the problem of how this operation is to be applied across multiple systems.