Search Results

Commercial vehicles carry more than 10 billion tons of goods - approximately 70 percent of all freight shipped and travel over 450 billion miles each year in the United States. These vehicles are the exclusive mode of delivery in over 75 percent of U.S. communities. Such utilization and dependency demand commercial vehicles be reliable, durable, and cost effective. The heart of these commercial vehicles (Classes 3-8) is the diesel engine. The widespread use of the diesel engine can be attributed to its reliability, durability, and cost effectiveness. However, the 2007 and 2010 EPA emissions regulations are creating significant challenges for diesel-powered commercial vehicles. Engine and vehicle manufacturers must strike a balance between emissions, performance, and affordability. A consequence of the evolution of the diesel engine to meet the increasingly stringent emissions regulations is that more effort to accommodate the associated changes is driven to the vehicle manufacturers.

This paper presents a compact temperature control device to cool down hot exhaust gas coming out of an aftertreatment emission control system. Active DPF (Diesel Particulate Filter) regeneration is required for aftertreatment emission controls to meet the 2007 EPA (Environmental Protection Agency) PM(Particulate Matter) standard. However, regeneration of the DPF temporarily elevates temperatures in the filter to eliminate accumulated soot. This can increase the temperature of the exhaust gas. The temperature control device in this paper draws ambient air into the hot exhaust stream and mixes them together in such a fashion to maximize temperature drop and minimize back pressure for a limited space without any moving parts or supply of extra power. The simple and compact design of the device makes it a cost-effective candidate to retrofit to an existing aftertreatment system.

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.