The definition of warranty varies depending on the nature of product being used by the consumer. For a product as intangible as an insurance policy, warranty may be defined as percentage of eligible claims settled by the insurance company in given time-period. However, manufacturing companies produce tangible products. In such scenarios warranty is almost always defined either in terms of time or in terms of in service load cycles product is expected to survive. Both parameters are often related to each other depending on the frequency of use. Moreover, in service load values varies a lot from one geography to the other as well as from one user to the other. Have you ever come across a car that is always driven on roads of a constant surface quality? Have you ever seen two drivers who maneuver their cars in a perfect identical fashion? If not, there is a statistical aspect to be considered as well. Nevertheless, customer do not realize how difficult it could be to define a warranty of a physical product. They treat it as a simple number on warranty card and if the product fails before the warranty expiry period, they feel cheated and their response is often something like this:

It is true that several critical parameters should be considered to define warranty of a physical product with precision. Many of such parameters are either very difficult to measure in house or to collect from external resources due to their seasonal, spatial or statistical nature. Thus, it is impossible to narrow down warranty failure instances to absolute zero. However, it is possible to reduce cost and unpleasant experience associated with such instances by reducing their frequency.

In case of a physical engineering product, often used in transportation, aviation or healthcare industry, virtual testing for durability is an effective method of containing warranty costs. Here we are talking about using finite element analysis approach using FEA codes such as Abaqus in combination with durability codes such as fe-safe.

In any given fatigue analysis workflow, a structural FEA solver as well as fatigue solver are present. The output from FEA solver serves as one of the input for fatigue solver. The FEA simulation is carried out either by applying a unit load or the entire variable load depending on the nature of problem. The minimum needed output may be either principal stresses or combination of principal stresses, principal strains and temperatures depending on the physics of the problem. The second input for fatigue solver is the in-service load data files and it may be optional in certain cases. These are real time digital files that capture fluctuation of loads in different directions over a given time. They are created using data acquisition techniques and are compatible with well-known fatigue solvers such as fe-safe. Once they are entered in the workflow, they serve as a multiplier to respective unit load data set to generate a 3D stress cycle. Both uniaxial and multi axial load scenarios are supported along with multiple block loadings.

The third input is the fatigue material properties. This could be either a stress-life curve or strain-life curve depending on physics of the problem any type of fatigue algorithm used. A good news is that fe-safe has a well-defined material databank of commonly used metals and alloys. If needed, this material data can be customized.

Once these three inputs are defined, fatigue problem definition is complete and solver is executed to provide the output in desired forms: cumulative damage, damage per block, cumulative life in terms of hours/days/load cycles etc. The numeric values are all printed in text files while a fatigue contour can be seen in a binary file compatible with most FE post processors.

An advanced fatigue workflow could be one involving fatigue optimization. In this workflow, it is possible to define fatigue as one of design response that could be minimized using shape optimization code such as Tosca. It is further possible to incorporate various types of manufacturing constraints in such an optimization.

Though a fatigue simulation workflow is well defined, it is not easy to execute. It is still beneficial to adopt this methodology because physical testing is often time consuming and manual hand calculations are not valid for complex loading cycles. If customers understand the complexity involved, they may be able to accommodate margin of errors in product warranty cards.