Abstract

Functional Decomposition is an engineering method where any technical artefact?s functions are divided into manageable lower level functions and inter-connecting architectural relationships are identified. When a function definition is clear, then we know what that artefact is intended to do. Putting this scheme in the center, we started using FuDe at ASML as one of the primary methods that handles complex simulation planning in a structured way. It not only helps out the analyst to clarify and communicate his analysis plan but also helps the design team and the project management on robust product development and accurate capacity planning, respectively. Thanks to the modularity of the FuDe models, engineering teams can also utilize from this method for their large system/multiphysics models, i.e. Digital Prototypes-Twins. This method uses the well know ?p-diagrams? as the baseline, where functional inputs and outputs are classified as Intended or Unintended (non-controllable outside influences or noises) variable sets. This method was first explained by J.M. Juran back in 1993 and later on in 2008 it was introduced into the FMEA process by Automotive Industry Action Group. In 1996, ?Breakdown of Functions? by Pahl & Beitz (1996), explains in more depth that every input or output of a function can only be classified into 3 types of physical quantity, i.e. Energy, Material or Signal; which are ultimately forming our simulation loads (heat, force, acceleration etc), material inputs (cooling water, mass or signals like (control parameters /loops). We use all these content along with a process definition for robust simulation plans. The FuDe process is explained in following steps: Step 0: System Structuring / Hierarchy Layers Step 1: Identifying and naming the Functions Step 2: Identifying Inputs & Outputs of the function Step 3: Identifying the Limits of the Functions and Visualization Step 4: Creating the Input / Output Matrixes Step 5: Creating the Simulation Cases Table Once the FuDe is complete, the team then can choose problems/cases that are most critical and urgent to the success of the product. It is much easier to agree handshake on details once they are laid out with clarity.