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.

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.

The GD₃ or GD Cubed method of problem prevention has been applied to product changes and to test results at the component, subsystem and vehicle level. GD₃ stands for Good Design - Good Discussion - Good Dissection. Good Discussion of changes (Design Review Based on Failure Mode) identifies BUDS of PROBLEMS that may arise from interfaces and areas of change. Good Dissection (Design Review Based on Test Results) is applied to physical test samples during and after tests to identify Buds of Problems that may not be obvious from inspection of the parts or test results. The paper first describes implementation of the GD₃ principles and methods supporting Good Discussion (DRBFM) and Good Dissection, and then discusses how they are applied and embedded in the Vehicle Development Process at General Motors Co.