• No results found

Approaches to vehicle modularization: - An industrial product architecture analysis

N/A
N/A
Protected

Academic year: 2021

Share "Approaches to vehicle modularization: - An industrial product architecture analysis"

Copied!
57
0
0

Loading.... (view fulltext now)

Full text

(1)

Approaches to vehicle modularization

- An industrial product architecture analysis

Ștefania Andreea Florea

Master of Science Thesis TRITA-ITM-EX 2018:371

KTH Industrial Engineering and Management Machine Design

(2)
(3)

Examensarbete TRITA-ITM-EX 2018:371

Tillvägagångssätt för modularisering av fordon - En arkitekturanalys av en industriprodukt

Ștefania Andreea Florea Godkänt 2018-06-11 Examinator Ulf Sellgren Handledare Ulf Sellgren Uppdragsgivare SCANIA CV AB Kontaktperson David Williamsson

Sammanfattning

Detta M.Sc. examensarbete innehåller resultatet från ett projekt som utförs i samarbete med Scania CV AB i Södertälje. Projektet är inriktat på arkitekturanalyser där olika modulariseringsmetoder tillämpas på ett komplext system. Scania har en känd och framgångsrik historia inom modularisering, som anses spelat en viktig roll för att bli ett av världens ledande företag idag. Därför ville produktbeskrivningsmetodavdelningen på Scania undersöka ett motordelsystem för att få en bättre förståelse för sin nuvarande arkitektur. För detta ändamål har lämpliga modulariseringsmetoder använts.

Systemet Extreme High-Pressure Injection (XPI) valdes av författaren för undersökning och modulariserades med två olika metoder: Heuristisk metoden och DSM (Design Structure Matrix) – metoden, med hjälp av IGTA ++ klustringsalgoritmen. De resulterande klustren från båda metoderna analyserades och jämfördes med de från den nuvarande arkitekturen. Baserat på dessa analyser föreslogs en modulär arkitektur slutligen av författaren.

Avhandlingen identifierar de arkitektoniska skillnaderna efter tillämpning av

modulariseringsmetoderna och belyser de möjliga faktorer som kan påverka analysresultaten. Den avslöjar också att DSM-analyserna visar de mest liknande klusterförslagen med den nuvarande arkitekturen. Utvecklingen av systemkonfigurationen undersöks också genom att använda den tidigare versionen som referens. Ett annat syfte med uppsatsen är att svara på frågan om systemets flexibilitet när det gäller teknikskifte.

(4)
(5)

Master of Science Thesis TRITA-ITM-EX 2018:371 Approaches to vehicle modularization - An industrial product architecture analysis

Ștefania Andreea Florea Approved 2018-06-11 Examiner Ulf Sellgren Supervisor Ulf Sellgren Commissioner SCANIA CV AB Contact person David Williamsson

Abstract

This Master Thesis encloses the results of a project conducted in collaboration with Scania CV AB in Södertälje. The project is focused on architecture analysis when modularization methods are applied to a complex system. Scania has a known and successful history in modularization, which it is claimed to play an essential role in becoming one of the world’s leading companies today. Therefore, the Product description methodology department within Scania wanted to investigate an engine subsystem in order to have a better understanding of its current architecture. For this purpose, there have been implemented suitable modularization methods.

The Extreme High-Pressure Injection (XPI) system was chosen by the author for investigation and modularized using two different methods: Heuristic method and DSM (Design Structure Matrix) method using IGTA++ clustering algorithm. The resulted clusters from both methods were analyzed and compared with the ones from the current architecture. Based on these analyses a modular architecture was finally suggested by the author.

The thesis identifies the architectural differences after applying the modularization methods and highlights the possible factors which may influence the analyses results. It also reveals the DSM analyses show most similar cluster proposals with the current architecture. The evolution of the system configuration is also investigated by having its previous version as reference. Another purpose of the thesis is to answer the research question regarding the system’s flexibility when it comes to technology shift.

(6)

FOREWORD

This chapter presents the author’s gratitude to the persons who contributed with knowledge, time and support during the entire project.

This Master Thesis was the author’s final project before obtaining a M.Sc. degree in Engineering Design, at the Royal Institute of Technology (KTH) in Stockholm, Sweden. The project was done for Scania CV AB in Södertälje, during a 20 weeks period.

I would like to thank my industrial supervisor David Williamsson at Scania for sharing valuable knowledge, good support and collaboration within the company during the whole project. I would also like to thank Ulf Sellgren, my supervisor at KTH, for the guidance throughout the project and help when it was most needed. A special thank you to all experienced engineers at Scania for sharing suitable information needed for my project, encouraging and giving me useful feedback.

Ștefania Andreea Florea Stockholm, June 2018

(7)
(8)

NOMENCLATURE

This chapter presents the abbreviations that are used in this Master thesis.

Abbreviations

R&D Research and Development

CI Compression Ignited

XPI Extreme High-Pressure Injection

CR Common Rail

HPP High Pressure Pump

IMV Inlet Metering Valve

ECUs Electrical Control Units

EMS Engine Management System

FSM Fuel System Management

HPC High Pressure Connector

MVD Metering dump valve

TRV Thermal Regulating Valve

LP Low pressure

HP High pressure

Mech. Mechanical

h. human

CAD Computer-Aided Design

DSM Design Structure Matrix

IGTA++ Idicula-Gutierrez-Thebeau Algorithm, (clustering algorithm)

(9)

TABLE OF CONTENTS

SAMMANFATTNING

(SWEDISH)

3

ABSTRACT

5

FOREWORD

6

NOMENCLATURE

8

1

INTRODUCTION

12

1.1 Background and problem description

12

1.2 Project purpose

13

1.3 Delimitations

14

1.4 Methodology

14

2

FRAME OF REFERENCE

16

2.1 Product architecture

16

2.2 Modularization methods

18

2.2.1 Function-mean tree analysis

18

2.2.2 Heuristic method

19

2.2.3 Design Structure Matrix clustering method

26

2.3 Modularization at Scania

28

3

ARCHITECTURE ANALYSIS AND REPRESENTATION

30

3.1 Subsystem identification

30

3.2 Subsystem function analysis

35

3.3 Modularization: XPI System study case

37

4

PROPOSED MODULAR ARCHITECTURE

47

5

DISCUSSION AND CONCLUSIONS

50

(10)

5.2 Conclusions

51

6

RECOMMENDATIONS AND FUTURE WORK

53

6.1 Recommendation

53

6.2 Future work

53

7

REFERENCES

55

(11)
(12)

1

INTRODUCTION

The current chapter describes the background information and the problem description, research purpose and limitations, but also the methodology and tools which are used in the project.

1.1 Background and problem description

Scania is a well-known heavy truck, bus and engines manufacture and since 2014 is part of Volkswagen group AG, one of the largest vehicle manufacturing groups. The company has a successful history in the in modularization, which played an essential role in becoming one of the world’s leading companies today.

The benefits of modularization have been discovered by Scania in the early 1930s. Then it has been discussed over the possibility of combining several small components in different ways in order to obtain different types and specific performance of their trucks, buses and engines. As the market expanded in terms of multiple applications, the customers’ demands became also more diversified. The concept of modularization was more clearly formulated in the late 1990s. The ambition of satisfying the world’s most demanding customers required continuous improvements over the years. Also, according to Scania’s vision, modularization begins and ends with the customer (SCANIA CV AB, Modularization, 2010).

In the heavy truck industry, it is very important to create products with high flexibility and proper product configuration. In this way, they can be easily adapted to each customer’s needs, as well as to the new technology that is continuously changing. A modular product architecture enables a product to be highly flexible, therefore suitable for different types of heavy vehicles. At the moment there is no deterministic approach of choosing an optimal modular product architecture, but the process can be guided as functional elements are treated in a modular way. (K. Ulrich) The powertrain can be considered the system which provides the driving force behind the mobility. A system approach of the powertrain refers to collecting all its individual components - which can be also grouped into subsystems – and analyzing how they are combined and interact with each other. (Vehicle Powertrain Systems, First Edition. Behrooz Mashadi and David Crolla). One of the complex subsystems among others within the powertrain is the engine, which has been chosen to be the focus. Figure 1 illustrates a common D13 engine with 6 cylinders used in a Scania truck R450.

(13)

Providing an efficient modularization of a complex subsystem such as engine might be a difficult, as this involves a large number of hardware components, electronics and software with multiple functions. Therefore, the Product description methodology department from R&D would like to investigate, as a study case, a more detailed level of engine subsystem in order to get an improved understanding of its current architecture for a Scania R450 truck. The results are needed for a further development of a subsystem which is set as a long-term goal.

1.2 Project purpose

The main purpose of this project is to investigate the deliverables listed below. In order to obtain accurate results, it is required to have a great understanding of how specific mechanical, electrical and software subsystems work together as a whole. Therefore, a multidisciplinary approach of the present architecture should be performed.

● Identify a specific subsystem within the engine which will be further investigated in terms of product architecture modularity.

● Identify and implement suitable modularization methods for the chosen subsystem within the engine.

● Present the interaction of components in the subsystem and the function distribution between subsystems ‘elements.

● Present a comparison between the results of the modularization methods and the current architecture of the subsystem.

● Suggest a modular architecture of the subsystem as result of methods applied where the specific modules and their interfaces are clearly stated.

There have been also identified the following research questions to be answered in this thesis project:

1. How are the architecture results affected after applying the modularization methods? Which method reveals more similar module proposals with the present architecture? 2. How flexible is the current architecture in terms of function distribution and technology

shift?

3. How has the subsystem configuration evolved from a previous version and what might be the reasons?

An overall purpose of this thesis work is to study the architecture of a complex engine subsystem in order to provide a clearer view of its structure after applying different modularization methods. Analyzing how different modularization methods affect the architecture results is also part of the thesis aim. The project results, enclosed in this thesis, will be used as background knowledge for further modular development of the system.

(14)

1.3 Delimitations

Due to high complexity of the topic and desired derivable to be given on time, there have been considered the following delimitations of the research project:

● The time frame for the research project is limited to 20 weeks of full time work.

● An engine subsystem from a specific Scania truck will be chosen for modularization, where an average limit of 25 components will be considered due to the complex configuration and a short period time for investigation. The number of components might change during the research due to specific function relations that are considered for investigation.

● In the modularization process it will be used a cross-functional approach of the components and interfaces; however, the focus will be on hardware configuration. The control and command functions will be shown in more detail in the functional flow chart.

● Customers’ demands are neglected due to lack of certain information and less time for conducting external interviews. The research will focus on the subsystems’ technical approach for the subsystem modularization.

● The detailed information about the subsystem will be gained by discussion with Scania experts who are involved in the designing and developing process of the subsystem components and software.

● There will be discussed in detailed only the components and interfaces within the subsystem selected for the project purpose.

● A current architecture will be analyzed without reducing the number of components during modularization process.

● There will be no further investigations of the subsystem performance after modularization. ● There will be no design improvements made of the current architecture analyzed, this

aspect is reserved for a future work.

1.4 Methodology

To achieve the purpose of this thesis, a few scientific methods and tools will be used which are further explained in more detail in the next chapter, Frame of reference.

In order to establish the scope and purpose of the project, it is essential to acquire fundamental knowledge regarding different aspects of modularization and engine subsystem functionality. Therefore, the first step of gathering background information will be performed by literature studies based on relevant published books, journal articles, previous courses literature. Also, a pre-study process was carried out at Scania’s Product description methodology department, where valuable information was shared by experienced engineers.

The second step involves identifying a suitable subsystem within the engine of a R 450 Scania truck which will be further modularized. The current subsystem will be approached also having as reference a previous configuration version for a better understanding of its technical evolution. As modularization implies a great understand of the product architecture, there is a need of identifying the subsystems’ function distributions and interactions between components. Therefore, a Function-means tree analysis of the subsystem will be performed, which is a Top-down functional deposition where both the functions and technical solutions are identified. After the functional decomposition, the interactions between the technical solutions will be presented in a Component architecture diagram of the chosen subsystem.

From multiple existing methods, the modularization of the chosen subsystem will be performed by implementing two methods, Heuristic and DSM (Design Structure Matrix) method. The

(15)

Heuristic method implies breaking down the main function of subsystem into smaller

sub-functions based on flow type passing through it, which are usually material, energy and signal flows. Based on the possible routes or conversions that these flows experience within the system, there are three heuristic strategies which identify the possible modules: dominant flow, branching flow and conversion-transmission flow. The DSM method aims to reduce the technical complexity by using a clustering algorithm which calculates the potential modules. In the current thesis it will be used the IGTA++ clustering algorithm due to its high efficiency of providing accurate results within a short time.

The results from these two modularization methods will be further compared with the present architecture in order to identify the differences and also possible explanations of the current architecture. As a result of the analysis it will be also proposed a modular architecture of the subsystem. The subsystem will be roughly compared with an old version with the purpose of understanding how it has been evolved and why.

In order to manage the project and carry out the required tasks in time, a Gantt chart was used as a project management tool for a better visualization of the work and remaining time. Moreover, there will be short meeting two times a week with the entire team at Scania for checking the project progress and express opinions about the current work and the problems that might occur.

(16)

2

FRAME

OF

REFERENCE

This chapter presents the theoretical aspects of diesel engine which is on focus in this thesis project, Scania’s modularization principles and the modularization methods used.

2.1 Product architecture

Product architecture is defined in an informal way by Ulrich (1993) as ‘the scheme by which the function of a product is allocated to physical components’. Although, the product architecture can be defined in more detailed in other 3 ways as follows:

1. The arrangement of functional elements.

2. The mapping from functional elements to physical elements.

3. The specification of the interfaces among interacting physical components.

A functional element describes what a product should perform. The functional elements within a product and their interconnections are presented in a schematic way which can be call a functional structure or diagram. The interconnections between different functional elements are usually represented by signal, energy or materials transfer or exchange, for instance there is a signal transfer type between a particular sensor and the electrical control unit. However, the functional structure can be created at different detail levels depending on the purpose of the product architecture analysis.

Considering the second definition given by Ulrich for product architecture, a physical element usually refers to a component within a product. The mapping between functional to physical elements describes the functional dependencies between components, which might be a one-to-one, many-to-one or one-to-many. Therefore, in a one-to-one mapping, a component is performing only one function which is associated with a decoupled design. In the case when a component is performing multiple functions or a function is performed by multiple components, the design is considered coupled. In most cases decoupled design is preferred as it is easier to be adapted to different design requirements. Although, coupled design is chosen when the technical performance is on focus.

A physical interface-mentioned in the third definition-describes the link between two interacting components. Interfaces can involve special (geometric) connection such as a bearing mounted on a shaft or a non-spatial connection such as the link between the control unit and an actuator. Ulrich defines the interface specification as ‘the protocol for the primary interactions across the component interface’. The specifications may include for instance the position of components related to each other, a force acting on one component or dimension of the geometric contact. The architecture usually is connected with the type of interfaces identified, coupled or decoupled, within the product. Therefore, a modular architecture involves decoupled interfaces between two components. Decoupled interfaces allow a change in one component without changing the configuration of the other component. If the components are coupled, any change in one component requires a change in the other one in order to establish the overall function. One example of simple product visualization with coupled and decoupled interfaces is shown in Figure 2. In the coupled design, the box thickness is directly dependent on the bed thickness, while the design with decoupled interface the bed and the box are independent on each other.

(17)

Figure 2 - An example of decoupled (left) and coupled (right) interfaces for a product (Ulrich, K. 1993- The role of product architecture in the manufacturing firm)

Based on the mapping type between functional and physical elements, there can be distinguished two types of product architecture, modular and integral. In reality when it comes to complex products the two types are combined at a certain level.

Modular product architecture and types of modularity

As mentioned above, modular product architecture involves a one-to-one mapping from functional elements to physical elements where the interfaces between components are decoupled.

The meaning of module sometimes differs when it comes to academic field and industry which can often lead to confusion. The term module plays the key part in the current projects and it can be defined as functional building block with standardized decoupled interfaces and which can perform one or various functions. Each module can present multiple module variants. These variants are considered alternatives which can differ in terms of shape, color, performance, etc. The modular architectures are divided into three types based on how the interactions between components are organized. The three modular architecture types are described below and illustrated in Figure 3.

Slot-modular architecture

The slot-modular architecture presents interfaces between components which are different one from another. In this case the components cannot be interchanged within the product.

Bus-modular architecture

In the bus-modular architecture the components are connected to a common bus using the same interface type. One example is the USB port which can connect different types of devices (mobiles, tablets, etc.) to a universal plunger, external battery or computer via a cable with the same USB interface.

Sectional-modular architecture

In this type of architecture, all components are connected via identical interfaces without having any common bus as in the bus modular architecture. This type of modular architecture is quite common in furniture products such as desks or sectional sofas, where different components can be added or moved in different ways to obtain multifunctional products.

(18)

Integral product architecture

Usually if high performance is one of the main requirements for a product it is difficult or less profitable to create a modular architecture. In many cases, these complex product types are not modular at all or only at a high system level and integral overall.

Integral product architecture implies a complex mapping between functional elements and physical components and/or the interfaces between the components are coupled (Ulrich, 1993). In this case, no change of any components can be done without affecting the others.

The company’s strategies can also have great influence upon the decision in having whether a modular, integral or hybrid product architecture.

2.2 Modularization methods

As the current thesis aims to presents the architecture of the current architecture of the chosen subsystem, there will be implemented two modularization methods, heuristic and Design Structure Matrix (DSM), and the results will be compared and evaluated. The function-mean tree analysis will be firstly made as its results will be used as inputs in these two methods. The following section describes the functional analysis and the modularization methods.

2.2.1 Function-means tree analysis

Function-means tree is a conceptual design method used for modelling a product by generating a systematic decomposition of functions based upon casual relations between functions and means (technical solutions).

The method implies a simple tree representation including two types of nodes: 1. Functions – describes what needs to be performed.

2. Means or Technical solutions – describes how the functions can be performed and may be represented upon the case as a subsystem or just as a single component.

The decomposition starts with a top-level function established as the main function. Further, it continues in a hierarchical structure where the functions and mean are arranged on different levels regarding the causal relations between them (Robotham, 2002). The representation may include means with multiple functions required to support them. Also, the method can be used to show alternative means which can perform a function an overall mean may be considered in this case. One function-means tree representation can be seen in Figure 4.

(19)

Main function

Means

Subfunction 1 Subfunction 2 Subfunction 3

Mean 1.1 Mean 1.2 Mean 2 Mean 3

Subfunction 3.1 Subfunction 3.2

Figure 4 - Function-means tree representation

Although there is no standard rule for determining the lowest level of function-means representation, the decomposition should be conducting at a practical level (e.g. not considering every nut or screw in the system). This aspect is essential to be remembered especially when it comes to complex systems where a too detailed decomposition might be too difficult to be managed leading also to valueless extra information. For instance, the components delivered from suppliers, such as gearboxes, can be considered the lowest decomposition level as the focus is on their overall function within the system architecture.

The function-means tree is a Top-down decomposition approach which provides a better understanding of system’s functionality and can be used as first step in the modularization process of a product. The results can be further used as inputs in several modularization methods such as DSM where technical solutions are essential in identifying the modules or in Heuristic method which is based on a function-block diagram.

2.2.2 Heuristic method

The principle of heuristic method defines the functional modeling by breaking down the overall function of the product into smaller and easy solvable sub-functions-based flow of energy, material or signal passing through the product (Stone,1999). The method can be used in the conceptual phase but also for analyzing a current product architecture, the functional independence being the main requirement for a modular product design.

Complex products usually have overlapping functions of the same components, therefore the interactions between modules should be minimal.

Stone (1999) proposed a detailed structure of heuristic method implementation in order to identifying the product architecture and generating suitable modular concepts. The main steps are presented in Figure 5 and explained in more detail further.

(20)

Figure 5 - Main steps in the Heuristic methodology for a Product Design Architecture [Stone (1999)-A heuristic method for identifying modules of product architecture]

Step 1- Gather Customer Needs

The first step of gathering information related to customer needs is essential especially in the conceptual phase of an existing product development or when a brand-new product is launched on the market. Identifying the specific needs of the customers is not an easy task to be proceeded, however it has been lately proven that one efficient method for this matter is the semi-structured interview. Further, the interviews should be evaluated in as objective way as possible to reflect the accurate requirements for the future product. Once the needs are identified, they need to be ranked from most to less important ones.

Step 2- Derive Functional Model

The first step in obtaining the functional model is creating a Black Box Model which represents the main function of the product or system and the main input and output flows. The input flow needs are identified based on each customer need established in Step 1. For a clear view of the whole methodology, it is considered the Power screwdriver example illustrated by Stone [4], which has a quite low complexity level. Figure 6 illustrated the black box model for the power screwdriver.

(21)

Figure 6- Black box model for a power screwdriver [Stone (1999)- A heuristic method for identifying modules of product architecture]

Further, each input flow illustrated in the black box model is carried out through a sequence of sub-functions that operates on the flow. The sub-functions sequence for one flow need to be consider from its entrance to exit of the system or product. In the case when a sub-function converts its input flow into another flow type, the function chains are followed until the flow exists the whole system or product. The sub-functions are usually expressed in a verb-object form. The function chains can be either sequential, parallel or coupled with respect to the input flow. Figure 7 and Figure 8 illustrate 2 different function chains for the power screwdriver example.

Figure 7 - Sequential function chain for electricity and torque flow [Power screwdriver example, Stone (1999)]

Figure 8 - Parallel function chain for human force flow [Power screwdriver example, Stone (1999)] As we can see in Figure 7, there are about five sub-functions released in a specific order for the electricity to be finally converted into torque. Therefore, the sequential function chain is defined as a group of sub-functions which operate in a specific order for obtaining the result and shares a common input flow.

(22)

On the other hand, the parallel function chain can be described as a set of several sequential function chains which depend on a common sub-function but are independent of each other. The parallel branches can operate in the same time or individually. In the parallel function chain example in Figure 8, the human force flow has a common sub-function ‘import human force’ and it branches into 4 sequential chains which operates independent on each other and in the same time.

In order to avoid confusion among different terminology regarding functions and flows, the functional model chains are expressed in a functional basis form. The functional basis covers a standard vocabulary where each set of functions and flows are expressed in a verb-object definition form. Table 1 illustrates a few examples of function terminologies which are defined by multiple standard synonyms.

Table 1- Examples of function terminologies for expressing the functions and suitable synonyms

Class Basic function Synonyms

Channel Import Export Transfer Guide

Input, Receive, Allow, Form entrance, Capture Discharge, Eject, Dispose, Remove

Move, Lift, Channel, Transport, Transmit, Conduct, Transfer, Convey

Turn, Spin, Unlock, Constrain

Connect Couple

Mix

Join, Assemble, Attach

Combine, Blend, Add, Pack, Coalesce

Convert Convert Transform, Liquefy, Solidify, Evaporate,

Condense, Integrate, Process

The flows are expressed in the same way as the functions by breaking them into several classes (in general there are three flow classes: material, signal and energy) and specified as basic or sub-basic flows upon the case. There can also be used ‘complement flows’ for specifying different flow types within the same class. Table 2 shows 2 examples of material and signal flow descriptions.

Table 2 - Examples of function terminologies for expressing the flows and suitable synonyms

Class Basic Sub-basic Complements

Material Human

Liquid Gas Solid

Hand, foot, etc.

Signal Status Control Auditory Olfactory Tactile Taste Visual Verbal, tone Temperature, roughness Displacement, Position

The functional basis form aims to express the function chains in a standardized verb-object structure as there are several cases of misunderstandings among designers if different terminologies are used within Heuristic method.

(23)

When all the function chains are released for each input flow, they are mapped together in order to obtain the final functional model. There might be cases when new sub-functions are added in order to connect some function chains. For instance, in the power screwdriver example there are added two flows (screw, bit) and ‘human force’ parallel chain is combined with the sequential flow of electricity. The final functional model for this example is illustrated in Figure 9.

Figure 9 - Power screwdriver functional model, Stone (1999)

Step 3- Identify heuristic modules

The Heuristic method is using three types of approaches in identifying the module based on the possible experiences of the flows within the product (Stone, 1999). These approaches are applied to the functional model already defined in the previous section. The three strategies are further described and illustrated for the Power screwdriver example as follows:

1. Dominant flow

The dominant flow heuristic defines a module as a set of sub-functions which a flow passes through, from the entry until it exits the system or until it is converted to another flow type within the system.

The identified sub-function set forms the interface of the module and any other flow which crosses this interface is considered an interaction of the current module with the rest of product architecture. Figure 10 shows a basic representation of the dominant flow applied to a system.

Material

Energy

Dominant flow module

Interaction Interface

(24)

2. Branching flow

The branching flow heuristic identifies the flows which converge or branch into parallel function chains. Each limb of the parallel function chain can be considered a module. Each module has the interface with the rest of the product in the branching point. Figure 11 shows a basic representation of the branching flow applied to a system and Figure 14 exemplifies the branching heuristic approach for Power screwdriver case.

INTERFACE

INTERFACE Flow branch module 1

Flow branch module 2

Flow branch module 3

Figure 11 - Branching flow module representation

3. Conversion-transmission flow

In the conversion-transmission flow approach the sub-function conversion from a type or flow to another and also coupled conversion-transmission sub-functions can form a module. As it is shown in Figure 12, there can be 3 cases of module identification:

● if the flow A is converted directly into a flow B, the conversion sub-function forms itself a module;

● if a pair of sub-functions converts the flow A into flow B and also transmits the flow B it can be considered a module;

● if is conversion-transmission of flows is done by a chain of sub-functions, the whole chain can be considered a module.

Convert

Convert

Transmit flow B

Convert FUNCTION

FLOW B Transmit flow B

A B

A B B

A B B B

Conversion module

Conversion-Transmission pair module

Conversion-Transmission chain module

(25)

After the three methods are applied on a current product architecture, the identified modules according to each heuristic type are compared with the actual existing parts in the product. In this way the accuracy of the modules is evaluated and it can be discussed the possibilities for an improved modular system, i.e. several sub-functions can be combined into one or separate modules.

As the modules are identified from a function structure, there is a high probability of overlapping modules or the case when one module can be a subset of another module. We can take as example the dominant flow method (Figure 13) and branching flow method (Figure 14) applied for the Power screwdriver functional model.

Figure 13 - Dominant flow modules marked with colored blocks for Power screwdriver example

Figure 14 - Branching flow modules marked with colored blocks for Power screwdriver example According to the Dominant flow heuristics (Figure 13), there can identified 4 modules in the power screwdriver: Supply electricity module with the common electricity flow; Transmit torque module;

Hand interface module with hand flow input which subsets the Coupling module traced by the bit

(26)

The Branching flow heuristics for the same example brings up new modules such as Manual use

module with the subset Rotate module and Weight transmission module (Figure 14). However,

some modules overlap with the ones identified with the first method such as the

Coupling/decoupling module and the Coupling module formed by the Dominant flow method or

the Actuating module being a subset of Supply electricity module in the Dominant flow method. There is no fixed rule for choosing which module to be implemented for the case when there are identified overlapping modules or modules which are subsets/oversets of other modules. One thumb rule suggested by Stone (1999) is to implement the module with the smaller number of sub-functions as it is easier for a particular function to be identified. Also, the customer needs can play an important role in the final module selection.

STEP 4 - Verification of heuristic methods and Modular concept generation

Stone (1999) verifies the accuracy of all 3 heuristic methods previously applied to the functional model by using a database of 70 different products as reference where the Power screwdriver is a part. The modules found using each heuristic method are associated with the actual modules in the Power screwdriver. As there are overlapping modules resulted from all heuristic methods, there are identified unique modules which are compared with the total number of actual modules. The verification is based on a statistical analysis of products from a wide application range which can give an average number of unique modules: 6 average modules in this case above.

2.2.3 Design Structure Matrix clustering method

DSM (Design Structure Matrix) is a network modeling tool which is used to represent a system’s architecture by enclosing the system’s technical solutions and the relations between them (Eppinger, Browning, 2012). DSM tool is suitable for a wide range of applications, including architecture representations of a product, process and organization. However, Product architecture DSM is the focus in this Master thesis.

There are four types of relations in a DSM between the technical solution: spatial, material, information and energy as shown in Table 3.

Table 3 – Relation types within a DSM

Relation type

Description

Spatial (s) Physical interaction between the technical solutions.

Material (m) Material transfer between two technical solutions; i.e. fuel, water, etc.

Information (i) All types of data or signals transfer between the technical solutions.

Energy (e) Energy transfer between the technical solutions.

DSM has a compact format where the relations among N technical solutions (components) are mapped into an N x N matrix. Figure 15 shows an example of a system’s block diagram and its

(27)

corresponding DSM matrix representation. The DSM is not necessarily symmetric as it is visible that the matrix includes relations in two directions (i.e. spatial relation between A & B) and also in one direction (energy from D to A).

Figure 15 – Block diagram (left) and its corresponding DSM (right) of a system. There are four relation types (orange=energy; blue=material; green=information; red=spatial)

The DSM’s purpose is to reduce technical complexity by creating clusters (modules) which comprise as many relations as possible and as less as possible between them. As a result, the interfaces between the components will also be much simple. For a simple system as the one presented above, the clustering can be done manually by moving columns and rows in a spreadsheet application, see Figure 16.

Figure 16 – Clustered DSM for the system example

Figure 17 shows the modular design of the system example presented above after clustering. The system presents two modules, module 1 which clustered most of the relations and module 2 consists only of component C. Between the two modules there are two information relations which also provide a simple interface.

(28)

For a complex system the modules (clusters) are created by using a clustering algorithm as it is easier and faster to obtain the best module candidates. In this thesis IGTA++ clustering algorithm proposed by Börjesson [5] is used as it is an efficient tool which has a high computational speed (One complete clustering is performed in about 0.34 seconds). The algorithm must run with several number of iterations until the convergence in the results is reached.

Some relation types between technical solutions can be given different weights based on their importance that is considered within the system. For instance, in some cases the spatial relation might be more difficult to be obtained by using a standard interface than the information relation which can use a standard protocol (Eppinger, 2012). The change in the relations weights may affect the configuration of the proposed clusters. In the example above all relations have the same weight. However, they can be used as reference in order to see how the system changes when different weights are applied to some relation types.

2.3 Modularization at Scania

The ambition of creating trucks and buses for a particular purpose and also competitive in comparison with other alternatives for the customer, placed Scania’s philosophy around satisfying the customers’ demands with their continuously optimized tailor-made products. Therefore, Scania’s core values are summarized in Customer first, Respect for the individual and Quality. In company’s vision, modularization starts and ends with the customer, hence one important aspect is understanding each customer’s specific needs. A good modularization implies that the customer

demands are implemented as fast as possible without the number of parts and components growing unrestrainedly over time (SCANIA CV AB, Modularization, 2010).

As the terminologies for modularization used internally in Scania differ from the ones used in academic field. Hence, it is important to have a clear view of their definitions of concepts in order to understand their way of modularization. The main concepts and definitions involved in the process are formulated as follows:

● Component is described as the final product manufactured in Scania’s component workshop, while a part is an item which cannot be broken down, i.e. fastener. When these components are combined in different ways, variants are created. The modular toolbox includes all components that are used in Scania.

● Performance is used to describe a property or group of properties that a component must meet in order to satisfy the demand of the customer.

● Component series is a series of components divided into different performance levels also called performance steps. Components in these series fulfil the same function in a design but are divided into different performance steps.

● Standardized interface is the area which connects two different component series and is independent of their performance steps.

From company’s point of view, to modularize means introducing a component series with standardized interfaces for a given function. This may also involves adding/removing a performance step in an existing component series while maintaining the same interfaces. The main focus remains however on optimizing the performance steps to meet customer demands. There is a need of standardized interfaces which means finding one and the same solution despite different

customer needs that motivate multiple performance steps. (SCANIA CV AB, Modularization, 2010). One essential aspect and the key of further development is that the modularization concept

(29)

The custom-made solutions which match the customer’s specific requirements is made with the help of Scania’s toolkit called Modular Toolbox which contains all pieces available for creating the desired truck, bus or engine. The Scania modular system is represented by a hierarchic generic product structure. This means that the entire collection of parts and components included in the product is covered in the system. Therefore, there is one individual structure which manages all the possible variant combinations of trucks, buses and engines. Once different variants are created, the system determines if the combination is valid or not based on different conditions. When a valid combination is found, the rest are disabled. In the system, different variants are separated using variant codes which indicate what component should be included in a specific product. This means that the code is composed of the variant families that describe a function or property. To sum-up, the variant codes are correlated with performance steps concept.

It is important that a product structure is not conditioned by the main component to decide the choice of variant family, but the performance of individual component. Another crucial aspect to be taken into consideration is separating the structure that describes the physical location of the component and interfaces describing the technical performance.

(30)

3

ARCHITECTURE

ANALYSIS

AND

REPRESENTATION

This chapter presents the process steps of the thesis work where the modularization methods described in the previous chapter are applied to a particular subsystem as an industrial study case.

3.1 Subsystem identification

In the current project, the Scania R 450 truck is provided with DC13 Compression Ignited (CI) diesel engine which has a piston displacement of 13 liters. The maximum power is 450 hp at the engine speed of 1900 rpm. Maximum torque is 2350 Nm, between 1000 and 1300 rpm. This engine complies with the Euro VI emission requirement.

As the entire engine is a complex system including thousands of components, for this project it has been chosen to be analyzed in more detail the architecture of the Fuel injection system coupled with the injection control provided by Engine Management System as a study case. The main aspects of these two subsystems and their current architecture will be further explained.

Extreme High-Pressure Injection System

The fuel injection system within the DC13 engine for the Scania truck R450 is called XPI (Xtreme high Pressure Injection). It is a Common Rail (CR) system developed and manufactured by Cummins and Scania and provides the highest injection pressure among other common rail systems. The great performance of the XPI system ensures that the engine is supplied with the right amount of fuel, at an average pressure of 2000 bar, at the right time.

The main XPI system components and the fuel overview circuit are shown in the Figure 18 and explained further in this section.

Fuel is sucked from the tank by the Feed pump. Before reaching the feed pump, the fuel enters through connection A and it is drawn through Suction filter where water is separated from fuel and automatically drained to fuel tank via Venturi device. The hand pump is used to prime the system with fuel in case of failure or when the cartridges have been changed. Further, the fuel passes the ECU cooler and reaches the feed pump which increases the fuel pressure to 9-12 bars using a mechanical regulator and pumping the fuel through connection B in the pressure filter. Here, the fuel is filtrated again from smaller debris that might damage the high-pressure pump (HPP), accumulator or/and injectors.

The surplus of fuel from feed pump is drawn back to fuel tank via Venturi device. The air is continuously bleeding from filter housing via a bleeding pipe. Pressure filter has also a safety valve which is used only in emergency cases when the feed pump regulator fails. Further, the fuel reaches inlet metering valve (IMV) which controls the amount of fuel that needs to be pumped to HPP. IMV is electrically actuated by ECU which receives information from the pressure sensor in the accumulator.

The fuel pressure is dramatically increased by HPP from 9-12 bar to an average of 2 400 bars. HPP camshaft is mechanically driven by the engine transmissions and drives further the feed pump’s impeller, as both pumps are mounted together. During idling, the injection pressure is low (approximately 500 bar), so the IMV allows only a small quantity of fuel to be injected and the rest is led back to tank via a Venturi device. In the opposite case, when the load is high and there

(31)

is a need of a higher injection pressure, IMV allows a greater amount of fuel and less quantity drains back. The high-pressure fuel is pumped in the accumulator and transferred further to injectors via high pressure connectors (HPC). When a fault occurs and the pressure in the accumulator exceeds 3000 bars, the safety valve or metering dump valve (MVD) opens and drops the fuel pressure to 1000 bar, draining back a part of the fuel.

The fuel injectors are electrically controlled by ECU which supplies an electromagnetic valve with voltage in order to open and inject fuel into the cylinder. The injectors are stroke-time-controlled and the common rail system enables 3 types of injection (pilot, main and post injection). Excess hot fuel from the injectors is returning to fuel manifold back to the fuel tank. The returning hot fuel flow from manifold is regulated by a check valve. During cold running the check valve is closing and the fuel is returns to thermal regulating valve (TRV) inletting hot fuel to feed pump.

(32)
(33)

Engine Management System (EMS)

Electrical Control Units (ECUs) are nowadays used in almost every motorized vehicle and have an essential role in achieving the emission limits according to the legislation while providing an efficient and safe driving experience for the driver. ECUs consist of several hardware units and software which are continuously receiving input information from different sensors in order to process the required output signals for the actuators. Due to fast technology shift, the electrical and electronic systems tend to have higher configuration complexity and their multiple functions within the vehicle must be able to be controlled by ECUs. From a modularity point of view, there is a need for several control units for different functions. The ECUs exchange information between each other via CAN (Controller Area Network).

The powertrain ECUs within Scania vehicles are divided into GMS (Gearbox management

system), EMS (Engine management system) and EEC (Exhaust Emission Control) which are

developed in-house. The fully automatic gearboxes are only purchased from the suppliers which include the GMS.

In the current project the focus is on Fuel injection system in a diesel engine, which has one of the most vital vehicle functions and it is controlled by EMS. The EMS has the main function to read the sensor values and calculate the responses which are sent further to the actuators in real time while monitoring the engine control functions for both software and hardware in terms of safeness. The fuel injection is particularly controlled by the Fuel System Management (FSM), which is a part of EMS. Figure 19 shows a schematic representation of the FSM which includes two software modules for controlling the high-pressure pump and injector. The software has a standard configuration but the parameters differ depending on the engine type and fuel system components. Thus, the parameters are grouped based on the hardware, for example there can be a particular load for one type of pump, injector or combustion chamber. There are approximately 100 parameters for the pump and 1000 for injectors’ control, which lead to a high complexity of the overall software configuration. Moreover, for each variant the values of these parameters are different.

(34)

Figure 19 – Fuel system management schematic representation

In Scania’s internal system every specific truck can be decomposed from a system-level to a very detailed level including all the small parts such as nuts and bolts. As part of the engine system, both XPI and EMS present a break-down structure of components which is illustrated in Figure 20. This product break-down structure presents how components are grouped in the current system architecture. The components marked with green color are not considered in this study case analysis.

XPI System

Fuel filter Injection Fuel pipes equipment Fuel filter assembly Bracket filter Injector Injector clamp HPC Fuel pipes HPP Bracket Accumulator; Pressure sensor; MVD

HPP; Feed pump; IMV

Manifold assembly Pipes HP Venturi Pipes Bracket Electrical system engine

Alternator Motor Hardware Control system Sensors and cables ECU Cooler EMS EMS housing and covers Exhaust gas pressure sensor Cables Support parts Standard parts

Figure 20 - Product break-down structure of XPI system and Electrical system engine for Scania truck R450 Both subsystems previously illustrated in a hierarchical way are represented for a better visual way in the Component cluster diagram, see Figure 21. The Component cluster diagram illustrates the proposed clusters of the system architecture. This type of representation will be also used for the

(35)

results of the modularization methods as it will be easier to compare them by noticing the differences/similarities. Tank Hand pump TRV Suction filter ECU Cooler Feed pump Feed pump regulator Pressure filter Safety valve Bleeding Restrictor LP Venturi HP Venturi IMV HPP Accumulator MVD HPC Pressure sensor Injector Manifold Overflow valve Flow cooler Check valve Alternator MOTOR Injector software Pump software Module 1 Module 2 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11

Figure 21 - Component cluster diagram of the current architecture

3.2.

Subsystem function analysis

An efficient architecture analysis requires a good understanding of the XPI System in terms of how the functions are distributed and related to the components. In order to gain this knowledge, it was performed a Top-down functional decomposition by using the Function-means tree method. Figure 22 shows the Function-means tree representation of the XPI system where the white boxes indicate the functions and functions, while the green ones show the components or sub-systems which perform these functions.

Starting with the overall function of the XPI System within the engine, there were identified four main sub-functions: to store, to distribute, to return and to control the fuel. As the fuel circuit is a closed loop at some extend, the fuel distribution from tank to combustion chamber was divided in two subsystem, low pressure and high pressure, while there is also a return route for the extra fuel which is sent back to tank. Due to high complexity of the software structure including multiple

(36)

parameters as inputs, the fuel control is divided into pressure and injection control including the technical solutions without further decomposition.

Supply fuel to engine Fuel injection system Control fuel Fuel management control Distribute fuel Stock fuel

Tank Low pressure subsystem Return fuel High pressure subsystem Separate fuel from water Filtrate

microparticles Suck fuel

Feed fuel to HPP Pre-filter Pressure filter Feed pump Regulate internal pressure Spring regulator

Inlet hot fuel

TRV Maintain

pressure Bleed air

Safety valve Restrictor Pump fuel hand pump Self draining Venturi device Increase fuel pressure Feed fuel to accumulator Store fuel HPP Feed fuel to injector Feed fuel to cylinder Accumulator HPC Injectors Manifold MVD Venturi device Accumulate hot fuel Prevent overpressure Return fuel leakage Regulate hot fuel Check valve Control fuel pressure Control injection Receive pressure signals Receive other inputs Pump software Injector software Pressure

sensor Parameter inputs

FUNCTION

Mean

In the functional decomposition process, it was firstly used a CAD file of the entire Scania truck assembly in order to easily visualize and identify the main structure components of the XPI system. The components were associated with the identified main functions in the previous background self-study. The Scania engineers experienced in XPI hardware and control system had an essential role in obtaining the information for accurate function decomposition. The whole system was clearly explained during several meetings where also documents with useful information were shared.

The components identified as means or technical solutions in this Top-down function analysis are used in the Component architecture diagram illustrated in the Figure 23. The diagram is a representation of the XPI components and the interaction between them. As explained in the previous chapter, the interactions describe transfer of different flow types such as: information, spatial contact, energy or material which are marked with different colors.

Figure SEQ Figure \* ARABIC 3

(37)

Figure 23 - Component architecture diagram

The Function-means tree decomposition is the starting point in the modularization process as the results, both functions and means are used further as inputs for Heuristic and DSM methods. The functions are mainly used in the heuristic method, while the technical solutions are used in the component diagram where the interactions can be easily identified and finally implement them in the DSM method. The implementation of both modularization methods is described in the next section.

3.3 Modularization: XPI System study case

For the study case analysis of the XPI system architecture there have been implemented two modularization methods which have different approaches towards the system but share a few common aspects. Heuristic method illustrates the architecture in a function-block representation where the focus is on the system’s functions and the input/output flows. On the other hand, DSM provides a matrix-based representation of the system which highlights the interactions between the components or functions.

Heuristic method

The analysis of XPI architecture is mainly focused on two steps of this method: functional

modeling and modules identification. The first step in the heuristic method, Gathering the customer needs, is neglected due to the boundaries of the Master thesis. Therefore, the functional

(38)

model is derived without establishing the general input and output flows which reflect customer needs.

The results from the Function-means tree analysis were used as input for creating the functional model. The flows that pass through each sub-function were identified. This is an easier approach for identifying the path of the flows through the system as there were already established the function chains.

In the case when a new product is launched, the functional model can be developed according to theory, by creating function chains for each flow and then aggregate them.

The final graphical representation of the functional model for the XPI system is shown in Figure 24. There are three types flows which pass through the system: material, energy and signal. In this Master thesis the technical solutions are illustrated in a white box under the function they perform and are not represented as flows. In this way, it is provided a clear view of the functions and their corresponding technical solutions.

As a result of the flows trajectories through the system, the suggested modules according to the

Dominant flow heuristic approach are shown in Figure 25. The modules proposed according to the Branching and Conversion-transmission heuristics are shown in Figure 26.

Heuristic method is a function-based approach of the product architecture; therefore, it is important to notice that the created modules are made of functions and not technical solutions. In order to be able to further compare these results with the current architecture and the results from DSM, the functions from each module identified are replaced with their corresponding technical solution. The results are illustrated in a Component cluster diagram representation in Figure 27.

In this study case the modules according to Dominant flow were identified based on the main fuel path to cylinders (see Module 3 and 6 in Figure 27) and based on the returning paths (see Module 1 and 7 in Figure 27). The Branching heuristics identifies multiple modules and submodules which are overlapping in most cases the modules obtained with Dominant flow heuristics. The module according to Conversion-transmission heuristics (Module 4, Figure 26) is not overlapping with any other module within Heuristic method. Heuristic method presents no common clusters with the current architecture; however, it is important to remember that the clusters are formed in this case based only on material, information and energy relations.

(39)

STORE FUEL PUMP FUEL Inlet tank/ hot fuel SEPARATE FUEL & WATER Cool ECU unit SUCK FUEL DRIVE FEED PUMP Regulate internal pressure PUMP FUEL Continuously air/fuel bleeding MAINTAIN FILTER PRESSURE FILTRATE MICROPARTICLES Import human force Actuate hand pump SELF DRAINING Fuel Fuel Fuel Fuel Fu e l Fu e l Fuel Fuel Fuel Fuel h. force h . fo rc e Fuel h. force h. force mech. force mech. force CONTROL FUEL QUANTITY SUCK FUEL LEKEAGE PUMP FUEL TO ACCUMULATOR TRANSMIT TORQUE DRIVE HPP STORE FUEL MEASURE PRESSURE PUMP FUEL TO INJECTORS PREVENT OVERPRESSURE PUMP FUEL TO CYLINDER Fuel Fu el Fuel Fuel Fuel Fuel Fuel Fuel Fuel Fuel m ech. f or ce Torque mech. force Torque Torque Torque Air mech. force mech. force mech. force mech. force REGULATE HOT FUEL R e tu rn ed f u e l Wa te r

Returned fuel Water

Returned fuel R e tu rn e d f u e l Air Air ACCUMULATE

HOT FUEL MAINTAIN PRESSURE

OVERFLOW COOLING Fuel leakage Returned fuel Fu e l l e a k ag e Hot fuel Hot fuel Hot fuel

Hot fuel returned

H o t fu e l r et u rn Hot fuel Hot fuel Hot fuel mech. force mech. force Tank Hand pump TRV LP Venturi Suction filter ECU Cooler Feed pump Feed pump Feed pump regulator Pressure filter Safety valve Restrictor Check valve HP Venturi IMV HPP Accumulator Engine driveshaft Injector HPC Pressure sensor Manifold Overflow valve Flow Cooler CONTROL High Pressure Pump CONTROL INJECTOR PUMP SOFTWARE INJECTOR SOFTWARE Fuel system management Injection Angle Fuel pressure Fuel quantity

External input/output flow

Material flow Signal flow Energy flow FUNCTION TECHNICAL SOLUTION

Intake Air Exhaust Air

Combustion chamber Electricity Camshaft Impeller mech. force MVD DRIVE THE MOTOR Supply electricity Electricity Electricity MOTOR ALTERNATOR

(40)

Hot fuel Hot fuel Hot fuel Fuel Fuel Air

Returned fuel Water Returned fuel R etu rne d fu el Air Air Fu e l m ech. f or ce mech. force mech. force mech. force Fuel h. force h . fo rc e h. force h. force Torque Torque Torque Torque Fuel Fuel Fuel Fu e l mech. force mech. force STORE FUEL PUMP FUEL Inlet tank/ hot fuel SEPARATE FUEL & WATER Cool ECU unit SUCK FUEL DRIVE FEED PUMP Regulate internal pressure PUMP FUEL Continuously air/fuel bleeding MAINTAIN FILTER PRESSURE FILTRATE MICROPARTICLES Import human force Actuate hand pump SELF DRAINING Fuel Fuel Fuel CONTROL FUEL QUANTITY SUCK FUEL LEKEAGE PUMP FUEL TO ACCUMULATOR TRANSMIT TORQUE DRIVE HPP STORE FUEL MEASURE PRESSURE PUMP FUEL TO INJECTORS PREVENT OVERPRESSURE PUMP FUEL TO CYLINDER Fuel Fu el Fuel Fuel Fuel Fuel Fuel Fuel Fuel Fuel mech. force mech. force mech. force REGULATE HOT FUEL R etu rne d fu el W a te r ACCUMULATE

HOT FUEL MAINTAIN PRESSURE

OVERFLOW COOLING Fuel leakage Returned fuel Fu el lea ka ge Hot fuel Hot fuel

Hot fuel returned

H o t fue l r e tur n Hot fuel mech. force mech. force Tank Hand pump TRV LP Venturi Suction filter ECU Cooler Feed pump Feed pump Feed pump regulator Pressure filter Safety valve Restrictor Check valve HP Venturi IMV HPP Accumulator Engine driveshaft Injector HPC Pressure sensor Manifold Overflow valve Flow Cooler CONTROL High Pressure Pump CONTROL INJECTOR PUMP SOFTWARE INJECTOR SOFTWARE Fuel system management Injection Angle Fuel pressure Fuel quantity

Intake Air Exhaust Air

Combustion chamber Electricity Camshaft Impeller MVD DRIVE THE MOTOR Supply electricity Electricity Electricity MOTOR ALTERNATOR Module 5 Module 4 Module 3 Module 2 Module 1 Module 8 Module 6 Module 7 Module 1 Actuate handpump Module 2 Suck fuel Module 3 Transmit mechanical force Module 4 Transmit torque Module 5 Supply energy Module 6

Pump fuel to cylinders

Module 7

Return hot fuel

Module 6

Return material surplus Figure 25 – Dominant flow modules marked with colored blocks

(41)

Hot fuel Hot fuel Hot fuel Fuel Fuel Air

Returned fuel Water Returned fuel R e tu rne d fu e l Air Air Fu el m ech. f or ce mech. force mech. force mech. force Fuel h. force h . fo rc e h. force h. force Torque Torque Torque Torque Fuel Fuel Fuel Fu el mech. force mech. force STORE FUEL PUMP FUEL Inlet tank/ hot fuel SEPARATE FUEL & WATER Cool ECU unit SUCK FUEL DRIVE FEED PUMP Regulate internal pressure PUMP FUEL Continuously air/fuel bleeding MAINTAIN FILTER PRESSURE FILTRATE MICROPARTICLES Import human force Actuate hand pump SELF DRAINING Fuel Fuel Fuel CONTROL FUEL QUANTITY SUCK FUEL LEKEAGE PUMP FUEL TO ACCUMULATOR TRANSMIT TORQUE DRIVE HPP STORE FUEL MEASURE PRESSURE PUMP FUEL TO INJECTORS PREVENT OVERPRESSURE PUMP FUEL TO CYLINDER Fuel Fu e l Fuel Fuel Fuel Fuel Fuel Fuel Fuel Fuel mech. force mech. force mech. force REGULATE HOT FUEL R e tu rne d fu e l W a te r ACCUMULATE

HOT FUEL MAINTAIN PRESSURE

OVERFLOW COOLING Fuel leakage Returned fuel Fu el lea ka ge Hot fuel Hot fuel

Hot fuel returned

H o t fue l r e tur n Hot fuel mech. force mech. force Tank Hand pump TRV LP Venturi Suction filter ECU Cooler Feed pump Feed pump Feed pump regulator Pressure filter Safety valve Restrictor Check valve HP Venturi IMV HPP Accumulator Engine driveshaft Injector HPC Pressure sensor Manifold Overflow valve Flow Cooler CONTROL High Pressure Pump CONTROL INJECTOR PUMP SOFTWARE INJECTOR SOFTWARE Fuel system management Injection Angle Fuel pressure Fuel quantity

Intake Air Exhaust Air

Combustion chamber Electricity Camshaft Impeller MVD DRIVE THE MOTOR Supply electricity Electricity Electricity MOTOR ALTERNATOR M o d u le 3 Module 1 Module 7 Module 5 Module 6 Mo d u le 2 Module 8 Mo d u le 4 Module 9 Module 1.2 Module 1.1 Module 1

Pump filtered fuel

Submodule 1.1 Leakage fuel Submodule 1.2 Pump HP fuel Module 2 Filter pressure Module 3 Bleeding fuel Module 4

Signal conversion & transmission

Module 5

Measure pressure

Module 6

Pump fuel to injectors

Module 7 Prevent overpressure Module 8 Internal cooling Module 9 Maintain pressure

References

Related documents

Figure 16: The pump trip simulations in Fluent and Relap5 are compared for (a) pump head, (b) impeller moment, (c) volumetric flow rate and (d) radial velocity of the impeller....

Major factors that may lead to a material difference between Couche-Tard’s actual results and the projections or expectations set forth in the forward-looking statements include

Återbetalningstiden beräknades med payback-metoden, där kostnaden i ekvationen försummades med antagandet att driftkostnaden för den befintliga pumpen och uppdateringen samt

(6) and (7) where increasing in the required power exists with increasing of speed, that is clear in Fig. 39 where the maximum power when is at the highest speed which is

Using Figure 22, which was provided by MWI, the calculated head of about 40 feet was used, which is from the intake in Boysen Reservoir up to the outlet through the dam into

flow condi tions at the latoratory where the pump tests were to be perfo~med. The velocity pr ofiles taken at the Engineering Research Center of Colorado.. For

För att möjliggöra analys av blandningen såväl före som efter reaktorn förgrenas ledningen så att en gren går till adsorbentbehållaren (reaktorn) och den andra till

It is possible to obtain an accurate estimate of the pressure and flow given the speed and the current consumption of an ideal pump but in reality there are many more parameters