Configueres was developed as a result of a change in the product development process at ASML. The change took place in the period 2015 – 2020 and boils down to doing things in parallel rather than sequentially.
Practical transport issues triggered the development teams to change their ways of working. The physical modules that were transported in crates suited for the Boeing 777 did not fit anymore. In addition some of the physical modules were too heavy for the customer’s factory elevators. In other words: a few of the product’s physical characteristics (also known as product properties like mass and volume) were not under sufficient control during product development.
Just to get an impression of the size of the aluminum frames for one of the three parts of the machine. You can image that there is a need to know, already in the first stages of the design process, to see how the physical modules can be packaged and transported (using different means of transport).
Instead of developing components (or rather Building Blocks) purely from a functional point of view; budgets for the product’s mass, volume and cycle time were made, based upon the knowledge that was gathered throughout the years from earlier machine types. These budgets were managed by the so-called Production Module owners; engineers that were primarily responsible for ensuring that the physical characteristics meet the requirements from service, packaging and transport during the development phases. In the past this was done after the functional building blocks were designed.
In terms of modeling the system: from a functional-driven product development, resulting in a 150% list of building blocks that is taken as the starting point for integration/ assembly and testing; a shift was made to a parallel development of both the function-driven development of the building blocks and the physical architecture that is driven by the physical properties such as mass, volume and cycle time.
The approach soon made clear that although the functional and physical breakdowns were driving the development of the Building Blocks, not all building blocks were the logical outcome of the functional breakdown. One of the examples that we came across in many industrial developments was the electronics cabinet, Ecab for short.
During development a number of subsystems (functional elements) implemented functionality into electronics hardware, PLC’s, PCB, and more. It was the electronics department (also called the electronics discipline or competence group) that organizes and optimizes the building blocks from the subsystems into a consistent and coherent whole (the electronics cabinet).
It not only enabled the electronics department to determine the interfaces (requirement for the building blocks), but also the quality of the components used, the organization of the PCB’s across the racks in the cabinet, safety measures (ventilation, smoke detection). The same holds for the other competence groups.
For this reason the model that is created also shows the building blocks and their relation to one or more competence groups.
As Derek Cabrera would say: it is a different perspective from which you look at the elements.
It is important to know that all elements to the left of the thick dark line in the middle of the diagram, are the responsibility of the developers (systems engineers, systems architects, mechanical-, electrical- and software engineers (and all other relevant engineering disciplines that have a role in the product development.
The thick dark line in the middle also symbolizes the interface between product development (engineering) and manufacturing (and logistics).
All model elements from the left up to the line in the middle are fully supported in Configueres. The outcome of Configueres is the handover from product development to manufacturing. You could call this the Design Bill of Material (D-BoM). Of course the D-BoM is not the only deliverable that is needed as a handover from product development. All technical product documentation is also part of it.
Credits
