1. INTRODUCTION
Commercial vehicles, such as trucks, are complex products designed for a large range of customers and uses. Because reliability is an important decision factor when buying a truck (Gnamm et al., Reference Gnamm, Lundgren, Stricker and Nilvall2012), it is also an essential property for manufacturers to understand and model accurately. A customer's view of reliability is holistic: if any one part causes the truck to malfunction, it does not matter that all the others are still working. Therefore, knowledge of component reliability is insufficient; we need to model the system reliability.
In keeping with the customer's view, we also notice that reliability problems are related not only to hardware failures but also to all types of unwanted effects. Reliability is “the ability of an item to perform a required function under given conditions for a given time interval” [IEC60050 (191)]. In addition to technical functions related to goods transportation and road safety, a truck also has functions related to the driver: interactive functions, for example, climate comfort and ergonomics. According to the definition, if any of these functions cannot be performed satisfactorily, the truck is unreliable; in other words, a failure has occurred.
If the user feels, or experiences, that his or her expectations are not fulfilled, for example, if the cab feels too cold, this is a failure that is a subjective experience, a failure that occurs in the interaction between the technical system and the user, that is, in the human–machine interface. Another user might not experience a failure, although the technical system behaves identically. The subjective nature of this failure does not make it unimportant, because failures of interactive functions not only affect customer satisfaction but also directly reduce availability. Some of them are severe enough to require a visit to the repair workshop. Some of them are minor annoyances that lead to prolonged workshop visits, because additional efforts are needed. Because interactive failures also reduce the availability, an accurate reliability model should include both technical and interactive failures.
Several researchers have pointed out the importance of performing reliability assessments during the early stages of the development process (Grantham Lough et al. Reference Grantham Lough, Stone and Tumer2008; Mutha et al. Reference Mutha, Jensen, Tumer and Smidts2013; Rahimi & Rausand Reference Rahimi and Rausand2013). Before system reliability tests can be performed, data from component or subsystem reliability tests are available, as well as data from functional tests. The best possible reliability estimate is that which takes all available information into account. Early reliability estimates can support project planning decisions concerning resource allocation or possible iterations in the development process. These reflections point out the need for a reliability model that includes all failures experienced by the customer. The starting point for this should be a system model with the requirements listed in Table 1.
Requirements on system model
The research questions addressed by this paper are as follows: how can we model system reliability in order to include technical failures, that is, mechanical, electrical, and software failures, as well as interactive failures, that is, objective as well as subjectively experienced failures; and what aspects of the system does our model have to treat?
The remainder of this paper is structured as follows: in Section 2 we review product and reliability representations that are relevant for our stated purpose. Section 3 describes a proposed methodology, which is then exemplified with a limited case study in Section 4. Section 5 presents a discussion, and the paper ends with conclusions in Section 6 and a plan for future work in Section 7.
2. MODELS OF PRODUCT, RELIABILITY, AND FAILURE
This section will first present methods for system modeling, different ways to describe connections between customer requirements, product function, system structure, and possible failure modes of the product. The methodology presented in the next section is based on these contributions. We will further present other methods for improving reliability based on detailed knowledge of the system. The section ends with a discussion of failures of interactive functions.
A structured product development process begins by establishing system requirements and transforming those into functional requirements. These guide the choice of principal solutions that are function carriers. The principal solutions are further optimized for a detailed component structure.
The development from function to principal solution can be assisted by a structured and iterative method, such as function–means decomposition (Andreasen, Reference Andreasen1980). Function–means decomposition will result in a function–means tree (Andreasen Reference Andreasen1980), which is conceptually shown in Figure 1. The function–means tree can serve as a basis for a system architecture representation.
Example of a function–means tree.
A widely used product representation is the component design structure matrix (component DSM; Steward, Reference Steward1981), which is an intradomain square matrix with product components as rows and columns, and the off-diagonal terms representing type and/or strength of interactions between pairs of components. DSM techniques have since been expanded toward also modeling relations between different domains, with domain-mapping matrices and multidomain matrices; see, for example, Eppinger and Browning (Reference Eppinger and Browning2012). Sellgren and Andersson (Reference Sellgren and Andersson2005) proposed an extension of the component DSM representation, referred to as an eDSM, which also includes feature objects representing human organs, aspects of an active environment, as well as interactions between these domain objects. Figure 2 shows an example of such an eDSM. The labels in the figure indicate functional surfaces (fsi) and technical (ti), ergonomic (ei), and communicative (ci) interfaces. Sellgren and Andersson's matrix in Figure 2 can be viewed as a multidomain matrix with three domains: technical, human, and environmental.
Example of extended design structure matrix, with component, human, and environmental subsystems included for a bottle opener case from Sellgren and Andersson (Reference Sellgren and Andersson2005).
A matrix-based product representation with a different perspective is the module indication matrix (MIM) that relates components to module drivers (Erixon, Reference Erixon1998). The columns of the MIM are module drivers, and the rows are components. The module drivers are customer requirements, but also requirements from other stakeholders, from supplier to aftermarket. These requirements drive, or supply the reasons for, the choice of partitioning of the product into modules. The module drivers are analogue to customer requirements in quality function deployment (QFD), and in the customer–function matrix in the system representation proposed by Sellgren and Andersson (Reference Sellgren and Andersson2005). Figure 3 shows the same gas burner case with two different representations: a MIM and a component DSM.
Example of (left) a module identification matrix and (right) a component design structure matrix of a gas burner from Borjesson and Hölttä-Otto (Reference Borjesson and Hölttä-Otto2013).
In structured design methodologies, functions are usually expressed as solution-independent verb–noun pairs. Several taxonomies have been proposed, for example, by Hirtz et al. (Reference Hirtz, Stone and McAdams2002), who aim to describe every function that a mechanical product can perform, and refer to their taxonomy as a functional basis, spanning the entire space of possible functions. They point out that clear communication and repeatability are supported by using standardized terms.
There are several examples of matrix-based reliability models. One of the earlier is the failure–experience matrix proposed by Collins et al. (Reference Collins, Hagan and Bratt1976). They use a three-dimensional matrix to represent connections between components, mechanical functions, and known corrective actions, thereby enabling improvements of new products with experiences from past failures. More recently, Grantham Lough et al. (Reference Grantham Lough, Stone and Tumer2008) developed a method for risk estimation based on past experience of failures, the risk in early design (RED) method. The system architecture information is encoded in a function–component matrix and the past failure data in a component–failure matrix. These are combined to estimate the risk to the new design. This method is further developed by Krus and Grantham Lough (Reference Krus and Grantham Lough2009), where failure propagation is added to the risk assessment. This puts the focus on the interfaces between components, where the propagations take place. Failure propagation through interfaces in complex systems has also been studied by Mutha et al. (Reference Mutha, Jensen, Tumer and Smidts2013), who take both hardware and software failures into account. A DSM-based method to improve the systems engineering process is proposed by Eppinger et al. (Reference Eppinger, Joglekar, Olechowski and Teo2014). The method examines the test coverage, that is, how many interfaces in the system that are tested and at what stage of the product development process. They show how this method can inform the system architecture design with respect to design for testability and reliability.
QFD is a methodology that connects customer requirements to parts characteristics (Katz, Reference Katz, Griffin and Somermeyer2007). Requirements on technical performance are included, as well as aesthetic and ergonomic requirements. Some methods for reliability analysis use QFD as a base. Braglia et al. (Reference Braglia, Fantoni and Frosolinir2007) propose a methodology called “the house of reliability” with the purpose of prioritizing possible failure causes according to their respective importance for the customer. Customer requirements, both technical and interactive, are analyzed for possible failure causes, but failures of interactive functions are not used directly. A literature review by Al-Mashari et al. (Reference Al-Mashari, Zairi and Ginn2005) shows that QFD has been linked with other risk assessment methods, for example, failure mode and effects analysis.
Ouden et al. (Reference Ouden, Yuan, Sonnemans and Brombacher2006) have studied customer satisfaction with consumer electronics products and found that a significant proportion of the complaints were caused by nontechnical failures. They also emphasize the need to broaden the concept of product reliability to include these failures. In a case from the automotive industry, Qatu et al. (Reference Qatu, King, Wheeler and Shubailat2011) claim that more than one-fourth of all warranty claims were connected to noise and vibration. Certainly many of these problems could be found to have technical failure root causes, but their effects are perceived as interactive failures. Failures of interactive functions, sometimes called soft failures, or nontechnical failures, have been investigated from several angles, often connected to the consumer electronics industry. Bly et al. (Reference Bly, Schilit, McDonald, Rosario and Saint-Hilaire2006) studied customer dissatisfaction from computer networks in the home. They found that in addition to problems due to broken hardware or broken software, problems occur due to “broken expectations.” This term is defined as a mismatch between customer expectation and product capabilities. Brombacher et al. (Reference Brombacher, Sander, Sonnemans and Rouvroye2005) proposed a classification scheme for soft failures, with the purpose of making it easier for manufacturers to use field feedback data for product improvement. Kim (Reference Kim2014) examined the connection between dissatisfaction and user characteristics, such as age, gender, and culture. These studies consider interactive reliability problems, but without a system outlook. Brombacher et al. (Reference Brombacher, Sander, Sonnemans and Rouvroye2005) stated: “Many traditional reliability models assume that a product consists of components and that a failure happens when a (physical) gradual or instantaneous change occurs in a component.” These models are not equipped to handle test data for interactive functional tests. Belsus et al. (Reference Belsus, Sankar and Sharma2010) studied system reliability of commercial vehicles. They made a distinction between failures and customer complaints, which can be interpreted as roughly the same as technical and interactive failures, and maintained that both categories must be included in reliability estimation, because both affect product availability.
The system architecture models reviewed build the basis for our model, but they lack the direct inclusion of interactive failure modes. The research on soft reliability supports the importance of this aspect. We find that the reviewed reliability methods do not consider failure of interactive functions, whereas QFD and the research on soft failures consider each function in itself, but not the complete system. We have found no reference combining system reliability and soft reliability. Our proposed methodology, which is the result of these considerations, is presented in the next section.
3. THE PROPOSED METHODOLOGY
3.1. Representation of systems architecture
The proposed methodology is a top-down reliability assessment approach, based on a complete systems architecture representation. The system representation encodes information that can enable reliability assessment of both technical and interactive reliability issues. Figure 4 schematically shows how information about customer requirements on functionality and structural information about component relations meet in the function–means matrix (FMM). The FMM specifies which technical, human, and environmental features we need information about in order to assess the performance of each function, and finally the reliability of the entire system.
System architecture model.
The matrix-based system model in Figure 4 was proposed in (Sellgren & Andersson, Reference Sellgren and Andersson2005). For scalability reasons, the chosen systems representation is matrix based. The aim of their work has been to represent the relations between the customer, functional, and implementation domains. Because of the importance of aesthetic and ergonomic properties of a product on the human–artifact interaction, they are included in the model, and referred to as interactive properties. The relations are described in the three matrices, customer–function matrix (CFM), FMM, and eDSM.
The rows of the CFM represent customer requirements. These are split into three types: end user, corporate, and regulatory requirements. End user requirements are the end user's expectations of the product. Examples of corporate requirements include brand name issues as well as architectural, standardization, and manufacturing issues. Regulatory requirements can be third-party interests, or are imposed by laws.
The columns of the CFM (and of the FMM) represent the required functions of the product. The functions are described in the functional basis, as proposed by Hirtz et al. (Reference Hirtz, Stone and McAdams2002), and divided into technical and interactive functional requirements. Technical functions are internal product functions, while interactive functions are human–product interactions. A basic functional requirement may be fully or partially related to one or several customer requirements. These relations are represented in the CFM.
The eDSM relates different parts of the technical system to human and environmental features. The standard technical DSM is extended with submatrices representing the active environment, the human, and the interactions between these domains. The three subdomains are shown in Figure 4 in yellow (technical system), green (human), and blue (environment). Each entry in the eDSM represents an interface, either internally in the technical system or externally to a human or environmental feature.
The FMM matrix relates the objects represented by the eDSM to the functional requirements and is a traceability mechanism that enables cause (customer requirement) and effect (implementation) studies. In DSM terms, the FMM is a domain-mapping matrix, mapping the relation between components and functions. The FMM makes the architectural representations complete, by joining the abstract purpose (the functions) to the concrete constituents of the physical system. It should be noted that there is a many-to-many relation between the functional domain represented by the FR vector and the physical domain represented by the eDSM matrix. Because the model will be used to assess the reliability of the product, all influences of a component or human or environmental feature on a function should be displayed in the FMM. Eppinger et al. (Reference Eppinger, Joglekar, Olechowski and Teo2014) specify five types of interactions: structural and spatial interactions, as well as transfer of energy, information, or materials. All types of interactions must also be displayed in the eDSM.
Customer requirements and the translation of these into functional requirements are out of scope of this paper. We describe briefly the procedure for generating the FMM and eDSM matrices:
1. Create the FR vector from functional requirements either specific to the current development project or generic for all products.
2. Generate the eDSM with the basic human, environmental, and technical submatrices.
Create the basic structure of the eDSM matrix. Expand the technical eDSM submatrix with principal components. The level of detail of the components should match the level of detail of available test data. There is no need to subdivide components that have always been tested together. If new, more detailed, information is obtained, the eDSM can be expanded later, one of the advantages of the matrix-based model.
3. Define the boundary of the studied technical system, which separates it from the environment. Expand the eDSM with relevant features of the environment. Relevant features are those that contribute to (or impede) the performance of a function.
4. Expand the eDSM with relevant features of the human. Relevant features are those that interact with the technical system when a function is performed.
5. Relate the eDSM matrix to the functional requirements. Create the FMM matrix.
Building this model is an iterative process. As more detailed information is found through more testing, components can be subdivided in greater detail, the number of base functions increased, and the rows and columns of the eDSM expanded accordingly.
3.2. Representation of reliability
This section will describe how the system model presented above can be used to investigate factors that influence reliability and organize reliability data. Further on, we will show how this information is used to qualitatively assess reliability.
Our aim is to represent a technical system that interacts with a human operator and/or user. The main objective is to estimate the reliability of the system, or the expected number of failures. A failure does not necessarily mean a complete lack of functionality, but rather that a failure occurs if the function is not performed satisfactorily, that is, according to all requirements. Thus, reliability is determined by the performance requirements of a function and the system properties that contribute to the performance of the function. We use the terms demand and capacity, as used in Davis (Reference Davis2006). The demand is the requirement on the system, which means that both the physical loads and the user needs and expectations are demands that the system must have the capacity to meet. Thus, the demand is a functional attribute, and the capacity is an attribute of the physical system.
The FMM can be seen as a link between system architecture and reliability (Fig. 4). Each input in the FMM denotes a relation between a function and a component. Because each input in the FMM thus represents a meeting between demand and capacity, it also represents a possible failure mode. Thus, the FMM illustrates all known failure modes (corresponding to all known function–component relations) and provides input to the reliability assessment. In this paper a failure mode is defined as the “effect by which a failure is observed on the failed item” [EN-ISO 14224:2006 (E)]. This definition is well suited for failures of interactive functions, where a physical root cause is not always known, but the failure can always be observed or experienced.
The FMM can also be used to collect failure data, in the way described by Collins et al. (Reference Collins, Hagan and Bratt1976) and Grantham Lough et al. (Reference Grantham Lough, Stone and Tumer2008), but with interactive failure modes included. The failure modes that have been frequent in the past are the ones to focus on for new designs. The failure modes that are likely to contribute the most to the number of failures are the ones where accuracy in the input data is most important. Conversely, unusual failure modes contribute little, and rather sketchy information will suffice. A large uncertainty in a small contribution to the total number of failures will only contribute a little to the total uncertainty, whereas the uncertainty in common failure modes will contribute a great deal to the total uncertainty, due to error propagation (Ku, Reference Ku1966).
When treating the parameters influencing demand and capacity, it is important to keep in mind that these parameters are described not only by their nominal values but also by their variations. Modular architectures allow a great deal of variation in the configured products of a product family. Both the driver influence and the active environment will also vary between different customers and between different operations. The capacity of the system also exhibits variation. It depends on the variation of geometry, material properties, and surface properties between individual components, but is also affected by the assembly process. Mistakes or variability in the assembly process can considerably diminish the effective strength of a component.
This variability is often referred to as noise factors, which affect the demands on the system or its capacity. Davis (Reference Davis2006) divides these into five groups: capacity noises: variation of part characteristics due to production conditions, or that occurs over time in the field; and demand noises: customer duty cycles, external environmental conditions, and internal environmental conditions.
We have slightly changed these categories. We need to include human interactions explicitly, and also prepare the model for component and functional test data. Component tests often simultaneously vary the capacity noise factors. If the variation in a test result is due to a combination of both noise factors, the data cannot tell the difference between the two effects. For this reason, they have been combined to variation in parts or functions characteristics. Effects of assembly, however, are seldom the same in component tests and system tests. Therefore, variation in assembly is a separate noise factor. These two are capacity noises. The demand noises are variation in environment, variation in configuration, and variation in human operator/user behavior or perception (see Fig. 5).
Graph showing the influences on reliability.
The information about the interactions modeled in the system matrices can be used to understand how noise factors influence the probability of failure of each failure mode. We illustrate this in a graph like in Figure 5, where the ellipses represent noise factors from the system model and the arrows symbolize influence, that is, a causal relation. The FMM holds information about which human and environmental features must be considered for each function. The eDSM can be used to find load paths in the structure and interactions between components. This information is useful for estimating how much the configuration changes if one or several components are replaced by a different version. This will be described further in the case study in the next section.
4. A CASE STUDY
To describe and to verify our proposed methodology, we will present two truck cab cases. The purpose is to verify that the system model supports reliability assessments based on data about both technical and interactive functions. One technical and one interactive function have been chosen for the example, in order to verify that the model can be used to analyze both hardware failure (i.e., a failure of a carrier of a technical function) and failure of interactive functions. The case study will demonstrate the system representation for the two functions and how the information is used to understand how system components and failure modes are related. As a final point, we can analyze the factors in the extended system description that affect the reliability of the system.
Our context is a full-scale truck driven on a well-defined test track. The test consists of a prescribed number of maneuvers and obstacles on the test track combined with driving on public roads. Our focused technical system is the truck cab. The cab suspension is included in the system, and the rest of the truck is considered part of the active environment. The reliability estimate is based on test data from component and functional testing. Real test data is proprietary information, which we cannot publish, but the example test data has the same format. Example test data is presented for each case.
The first failure mode is a fracture in the storage compartment above the passenger seat, marked in Figure 6. This is a failure of an internal technical function of the storage compartment, with the purpose of supporting and connecting the subcomponents of the storage compartment. The second failure mode is unpleasant vibrations experienced by the driver. This is a failure of an interactive function with the purpose of providing a comfortable vibration environment for the driver. In the functional basis, this function is described as inhibit mechanical (vibrational) energy (IME).
The storage compartment above the passenger seat. (Photo courtesy of Scania.)
The system architecture matrices that will be detailed in the example are restricted to only components and functions related to the storage compartment and the interactive IME function. The yellow, green, and blue backgrounds in the matrices indicate the technical, human, and environmental subsystems, respectively (cf. colors in Fig. 4).
4.1. Storage compartment
The storage compartment implements and contributes to several functions, both technical and interactive (see the FMM in Fig. 7). The functions are derived from customer requirements, such as the need for good storage for the driver, and the manufacturer's desire to give a high-quality impression. The interactive functions have inputs in the submatrix for the human. Note that the objects stored in the compartment are part of the environment, although they are spatially inside the system. The internal technical functions of the storage compartment have been condensed into one column, which also means that all internal failure modes of the storage compartment are condensed into one at this level of detail. This is the function studied in the case. As stated above, the demand (load) that causes failure of this function is mainly caused by vibrations, but there is no input in the FMM connecting the vibrations in the frame to the internal technical functions of the storage compartment, because the frame and the storage compartment are not directly related. The relation is shown by the eDSM.
Function–means matrix for the storage compartment.
As can be seen in the eDSM, shown in Figure 8, the storage compartment interacts with the front wall and the roof, as well as with features of the driver. The eDSM shows the load paths from outside the system, from the road and the engine, marked by arrows. The vibrations in the frame enter the system via the cab suspension, and continue through the front wall to the storage compartment, or through the floor, rear wall, and roof to the storage compartment. The load paths found in the eDSM show which components must be considered when determining if the configuration transmits vibrations to a high or low degree.
Extended design structure matrix for the storage compartment.
According to the eDSM, the storage compartment is influenced by the technical, human, and environmental systems. The information available of the failure mode is shown in Table 2. The influence of these factors on the reliability of the storage compartment is analyzed using the graph presented in Figure 9.
Influences on the probability of failure of the storage compartment.
Example test data for technical function
In our example, we have information that the driver is careful and responsible (not adding to the load on the storage compartment by careless behavior), and that the configuration used in the test does not transmit vibrations in an unusually high or low degree (normal level). This information is combined with the environmental circumstances caused by the test method; the vibration level on the test track is high. Moreover, the test method specifies the storage compartment be loaded to maximum allowed weight. As a result, our estimate is that the load on the storage compartment is high.
The information on the strength of the storage compartment is compiled from the strength of all identical storage compartments and the quality of the assembly process. The nominal strength of the storage compartment has been tested successfully in a component test with a load corresponding to high vibration levels. A successful test corresponds to low probability of failure. The assembly of a complete cab can be expected to show greater variation than in component tests, which leads to a higher risk of failures caused by an assembly error. Consequently, the strength of the storage may be too low for a high vibration level (capacity in Fig. 9).
Finally, we combine the information about the demand on and the capacity of the storage compartment. In the known situation with high demand and sufficient capacity, the failure probability is low:
$$ \eqalign{P(\rm{failure} \vert \hbox{high demand, OK capacity}) \cr & = P(high \; demand \gt OK \; capacity) \cr & = \hbox{low probability.}}$$The risk of an assembly error reduces the capacity somewhat. The demand remains high, and the resulting failure probability is
$$\eqalign{P(\rm{failure} \vert \hbox{high demand}, \; {\rm OK}^{-} \; \rm{capacity}) \cr & = P(\hbox{high demand} \gt \rm{OK}^{-} \rm{capacity}) \gt \hbox{low probability.}}$$We see that the failure probability of the storage compartment is slightly elevated.
4.2. The function IME
The interactive IME function is derived from customer requirements for a good working environment for the driver. Several components contribute to the implementation of the IME function, and several different failure modes are specified (see the FMM in Fig.10). Only the IME function in the first column is studied in the case; the functions in the other columns are an illustration of some other functions performed by the same components. In this case, the vibrations in the frame affect the IME function directly, as shown in the FMM. The eDSM is still useful for studying load paths and configuration influence.
Function–means matrix for the inhibit mechanical (vibrational) energy function.
The components chosen to implement the IME function interact with each other, with the environment and with aspects of the driver that experiences vibrations. These interactions are described in the eDSM (see Fig. 11). The eDSM shows the path of influence from the environment (the vibrations in the truck frame), through the cab suspension, the floor, and the seat, to the human that experiences the behavior of the system, marked by arrows. Note once more that several load paths are possible, for example, the loop from the cab suspension to the antiroll bar and back again, which dampens rolling motion, and thus contributes to the IME function.
Extended design structure matrix for components implementing the inhibit mechanical (vibrational) energy function.
The factors influencing the IME function can be found in the FMM, for example, that vibration in the frame is the relevant environmental feature. Further information regarding load paths and surrounding components is supplied by the eDSM. The information available about the failure mode is shown in Table 3. The influence of these factors on the reliability of the IME function is analyzed using the graph in Figure 12.
Influences on the probability of failure of the inhibit mechanical (vibrational) energy function.
Example test data for interactive function
In our example, we have information that the driver is experienced and has high demands on vibrational comfort, and that the configuration used in the test is high end, which leads to high expectations, and thus high demands. In the example test method, however, the IME function can only be evaluated during the public road parts of the test, where the road conditions are good and the vibration level low. The influence from the environment thus balances the demanding driver influence and configuration, and we estimate normal demands on the function.
The information about the capacity of the system of performing the IME function is influenced by the nominal properties and the assembly quality. The IME function has been tested successfully in a functional test with high requirements performed on a prototype vehicle. A successful test corresponds to a low failure probability. Less variation can be expected in series assembly than in prototype assembly, which means lower risk of an assembly error in a commercial truck than in a prototype truck. Consequently, the system properties may be better than necessary for high demands (see Fig. 12).
Finally, we combine the information about the demand and the capacity. As above, the known situation of high demand and sufficient capacity corresponds to a low failure probability. From Figure 12, the demand is normal (lower than high) and the reduced risk of an assembly error improves the capacity a bit.
$$\eqalign{P\left( {{\rm failure \vert normal\; demand},{\rm OK}^ + {\rm capacity}} \right)\hskip 9pc \cr & \hskip -20.1pc = P\left( {{\rm normal\; demand} \gt {\rm OK}^ + {\rm \; capacity}} \right) \lt {\rm low\; probability.}}$$We see that the failure probability of the IME function is very low.
5. DISCUSSION
The proposed system model is similar to the matrices associated with QFD (Katz, Reference Katz, Griffin and Somermeyer2007). The QFD matrix connecting product characteristics to parts characteristics has approximately the same purpose as the FMM in this work. The product characteristics are measureable quantities that the product must fulfill in order to satisfy the customer, and correspond to the functional requirements of the system model in Section 3. Because function is explicitly mentioned in the definition of reliability, we prefer to express failure modes in terms of functions. Moreover, QFD matrices do not include human and environmental features.
A comparison of the proposed methodology and the RED method (Grantham Lough et al., Reference Grantham Lough, Stone and Tumer2008) shows a difference in the treatment of failures of interactive functions. Suppose a failure is reported in a functional test, or a field test, with the description: “The ride comfort is bad, very hard and shocky on rough roads.” This report cannot attribute the failure to any single component. The information is too vague to be used in methods linking functional failure to components, like the RED method (Grantham Lough et al., Reference Grantham Lough, Stone and Tumer2008). Despite the lack of details in the report, it is still a clear indication that something is wrong with the ride comfort (IME function). This failure report cannot help a designer improve the product without further investigation. It can, however, help a reliability analyst make a better estimate of system reliability, from the complete vehicle point of view shared with the customer, but only if the system model permits it.
Interactive failures are often the result of an underlying technical failure, but when they are detected, the root cause may not be known. In complicated cases, when the reason for failure is due to a combination of components, which may all individually be inside nominal limits of functionality, the root cause may never be found. The IME function in the case study is a good example of this. Unpleasant vibrations are among the most difficult problems to diagnose and solve that workshops ever encounter. If physical failure data for components is used to estimate the reliability of interactive functions, it may be overestimated, because the combination effects are lost. In summary, if all the available information is used to assess the system reliability, the estimate will improve.
The system model in the proposed methodology could become very large for a complex system, and there is no automatic way to generate it. This difficulty could be partially overcome by using a coarse model to begin with and expanding it in more detail as needed. It is a matter for further investigation if the necessary level of detail can be reached before the model becomes too unwieldy, or what that necessary level of detail is.
6. CONCLUSIONS
By expanding our system model to include human and environmental features, the interfaces where functions are performed are made explicit, and both technical and interactive functions are included in the system model. This is the key to allowing the customer's full perception of the product to be represented. We list the requirements on our model again in Table 4, and how they were realized. The impact of configuration cannot be fully evaluated. The FMM and eDSM supply information about the components that affect function performance, but not the relative importance of components. A measure of “distance” between two configurations would be useful in order to estimate how much function performance can be expected to change between two configurations.
Fulfillment of requirements on system model
In order to show all interactions where the functions of the product are performed, the system model is expanded to include human and environmental features. The eDSM shows interactions between all features of the system; the FMM shows which features perform (or fail to perform) each function. The system model supplies valuable information indicating which noise factors influence reliability. The case study describes how this information can be found in the system model and used in a reliability assessment. If these connections were not present in the system model, the information about which features of the environment influence each function, for example, would have to be found elsewhere.
The main contribution of this paper is to show how the proposed system model can support reliability assessments, where both technical and interactive functions are taken into account. We have shown how this system representation allows information about failures of interactive functions to improve the system reliability estimates in comparison to models lacking interactive functions. The system representation also holds information about what external and internal factors must be taken into account in reliability assessments.
7. FUTURE WORK
This paper investigates how interactions in the system representation are connected to qualitative reliability assessments. The next step is planned to focus on quantitative analyses, where component and functional test data are used to estimate failure probabilities. The level of detail required to enable efficient reliability related analyses must be addressed in next phase of the presented research.
To enable quantitative analysis of product reliability, a great deal of effort will be needed to evaluate the accuracy of different types of test data. Expressing the probability of failure in terms of demand and capacity allow technical and interactive failures to be analyzed in a consistent manner, because they are affected by the same noise factors (configuration, human operator/user, and environment). The similarity in the handling of different types of failure modes can allow the same methods of evaluation to be used, which will reduce the complexity, and thus the amount of human effort. Furthermore, the inclusion of software failures and propagation of failures between software and hardware is interesting, and should be addressed in future research.
There are important questions to answer in future research tasks. How can component test data be represented and related to the presented systems model? How does the component or function test load (demand) correspond to the system test load? What is the accuracy of the data? What is the variance of the data? How should the variance be represented in the model? How can informal, experience-based knowledge be captured, codified, and included in the analyses? How can components and functions with incomplete or no test data be included in a quantitative analysis? How can dependencies between failure modes be handled? How do operating conditions influence component reliability and product function? How should software failures and propagation of failures between software and hardware be handled efficiently?
Julia Lindén is a Senior Engineer of load analysis and reliability at Scania. She is currently studying for a PhD at the Machine Design Department at KTH Royal Institute of Technology. Her research interest is in complete vehicle reliability.
Ulf Sellgren is an Associate Professor in machine design at KTH Royal Institute of Technology. He received his PhD on methods and tools for model-based and simulation-driven design. His research focuses on systems engineering, modeling, and simulation of complex processes and systems.
Anders Söderberg is an Assistant Professor in the Department of Machine Design at KTH Royal Institute of Technology. He earned his MS in mechanical engineering and his PhD in machine design from KTH Royal Institute of Technology. His current research in simulation-driven design focuses on modeling and simulation of the interactions in mechanical interfaces.
