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. What is needed is a requirement development method that summarizes the operation and performance expectations at the feature level, that all impacted teams can understand and work to, with clear definition of each subsystems responsibility in the performance of the feature.
At this time, there is not a tool available to provide feature based architecture engineering. Many tools (UML, Rhapsody, Matrix X, etc…) are available for software partitioning, but fall short when hardware constraints also need to be considered. Previous publishing's from DeMarco and Hatley-Phirbhai, referenced in this paper, discuss the construct for functional partitioning from a software perspective within systems, but did not apply the concept across systems. This paper expands upon their concepts and extrapolates the method for use at a higher level in a vehicle application.
This paper does not propose a tool for use, but proposes a simple method utilizing available word processing and graphics tools to document an approach, focusing primarily on the content of the documentation required to define the feature and achieve the functional partitioning of the feature across subsystems. A database file was also developed to track the interfacing of multiple features on a single vehicle to enhance this process. Any movement forward into the development of feature based architecture development would need to take into account the measures identified in this paper.
This paper will introduce two artifacts, the Feature Function Description (FFD) and Feature Controls Architecture (FCA), as an intermediary step between vehicle level operational performance expectations and the subsystem development process.
The FFD does not focus on comprehensive system / subsystem performance as a whole, but documents the operation and performance characteristics of a feature, whose functionality is partitioned across multiple systems. This focus is customer based.
The FCA then provides a method to partition the feature into smaller parts (functions), and partitions these functional responsibilities across subsystems. It defines the individual requirements of each function and identifies the interfaces between functions.
This style of documentation was used extensively during the Chevrolet Volt development process and improved communication and understanding from Vehicle Line Executives and Chief Engineers, to component DREs, and software programmers, through the design, integration and validation process. Establishing the operational expectations of the feature up front, eliminated re-work and miscommunication, leading to reduced development time and a dramatically improved first time success rate.