Search Results

The successful development of new products is contingent on clearly understanding product requirements and defining appropriate design activities to deliver the right product. Even if one can clearly understand the abstract requirements implied by the voice-of-customer (VOC), engineers still work best to a set of specifications that define the product in objective measures. The task of extracting the systems specifications from text versions of product requirements is not trivial. Full order dynamic models of mass, springs and dampers provide understanding of vehicle performance; however, the engineer has to define the dynamic characteristics based on his understanding of requirements and translate them into technical specifications. The result can be too dependent on human assumptions and judgments at this point. This work was done to understand how to apply Object Oriented Design (OOD) methodology to trace requirements of a mechanical system to design parameters.

This paper discusses a practical use of the Systems Engineering Process as it is implemented in a Truck OEM. The process presented is focused on the Electrical and Electronics area, but can be applied to other systems on the vehicle and to the vehicle level requirements. Systems Engineering rationale is summarized based upon historical impacts and the application of Systems Engineering to address those impacts. Prior System Development Processes are reviewed in light of modern Systems Engineering approaches, leading to the synthesis of the Systems Engineering Documentation Set for the Vehicle and the Vehicle's Electrical and Electronic Systems. The analysis for this approach looks at the application of Systems Engineering Principles throughout the lifecycle of the vehicle, going beyond the boundaries of traditional requirements gathering and analysis.

This paper describes the electrical system development for the headlight feature in an International High Performance Vehicle. Systems engineers developed several iterations of functional requirements, functional block diagrams, state diagrams, and body controller software requirements early in the development cycle at considerable engineering expense. The hardware design team found the functional block diagrams useful, however the software design team did not find the other artifacts useful. The software design teams chose to implement a design that was very similar to a current product offering and did not map to the system proposed by the systems engineering team. This paper provides examples of the Systems Engineering artifacts and shows when they were developed in the project timeline.