Development of the system concept: functional analysis and modular synthesis

The main decisions on the system arrangement are called the system concept. Usually, the system concept evolves with details until the description accuracy of the system is sufficient for its manufacturing on a production platform. Remember that the system concept is "alive"; it changes during the system development, and the system is constantly modified even after its operation has begun.

The essence of the system concept lies in the description of the fusion of the functional ("how it works") and constructive ("what it is made of") breakdown, considering spatial layout and the resulting total cost of ownership (and remember that another addition to the system concept will be the breakdown description).

In literature, various breakdowns are often simply termed as "structure," but it should be noted that this is precisely a hierarchy based on some type of breakdown: the relationships of structure elements are usually a hierarchy of "part-whole" relations (is_part_of, composition), functional, constructive objects, placements, costs, and similar objects (not only the main types are used in projects!). All other relations (specializations, classifications, temporal precedence, interactions, etc.) are not considered in this "structural" breakdown. If the hierarchy is shown as a breakdown, then the structure of the object-system being broken down is a structure of parts-wholes! And these different types of parts-wholes do not depict objects for physical disassembly-assembly but simply indicate the separation of parts in a physical system by different types of attention. Though product/constructive parts (affordances) are about more than just highlighting attention during their interaction; it is also about actual disassembly-assembly, involving design time and assembly time.

Here is a figure from the IEC 81346-1 standard, and this standard took this figure from the earlier standard IEC 1392/09. This is the basic work scheme for creating the system concept (and it is also the fundamental scheme of inventiveness). The layout and cost are not considered here, but in real work, they are also inevitably present, along with variations of other specific breakdowns for different projects. But the main point here is the transition from functional decomposition to modular/product composition, from analysis to synthesis.

Let's consider the target system, which initially is viewed as a functional object A (function/behavior or functional/role part of the system - this is largely irrelevant here and depends on the modeling agreements made. You may refer to behavior as "nail driving" or the functional/role part as "nail driver"). The IEC 81346 standard deals with functional parts of the system/role objects, not their behavior/functions. To realize is to bring the "logical" object-functional role into the physical reality of constructive modules (role executors). In simple terms, a "nail driving" function or "nail driver" is assigned to a hammer, microscope, or stone. This is the basis of inventive activity: for the same function, one can select numerous different constructive/physical objects from the surrounding world (affordances) that offer the desired behavior.

The first step in contemplating a future system is functional decomposition: functions and/or functional parts are broken down into smaller entities (on the figure, these are B and the other four), and attempts are made to select products/modules for them that can perform the functions of these functional parts.

Bear in mind that the system functions are formulated in the language of subsystem project roles, while services are articulated in the language of system project roles. The hammer’s service is "to strike an object." This service is perfect for the function "driving nails." Inventiveness here lies in recognizing that not only a hammer but also a microscope both provide the service "to strike an object,” and even a "stone" can offer such a service. When lacking a hammer, one may choose a stone, for instance (because a microscope might be large and inconvenient, while a stone can be easily selected for its size and shape – considerations vary, not solely based on the stone's low cost).

From the figure in the IEC 81346 standard, it is observed that at the initial decomposition step, it is only possible to find products/modules with suitable services for two subfunctions out of five (shown as subsystems: it is evident which function they perform in the suprasystem with the functional name A and what modules they will be made of), only two out of five first-level cubes with yellow color (functional parts) have a constructive module/product matched with them (shown in blue on the same cubes). Moving on to the next step, this is achieved for all subfunctions, including subfunctions under B. This part of functional decomposition is sometimes called functional analysis. Analysis (involving separation into parts, decomposition) is normal, as long as one remembers its subordinate role to synthesis (assembly from parts). Analysis is only bad if it exists by itself, separated from synthesis without serving synthesis goals. The figure from the IEC 81346 standard exactly demonstrates how analysis/decomposition supports synthesis/assembly.

Next, from all modules, using their interfaces for connection, the target module-system is assembled/synthesized, the final product that will perform the initially stated function. For the assembly module B' in the figure, implementing functional part B, this is achieved in just two steps - first, two intermediate modules are assembled, and only then are they combined. At the next step, module B' is included in the composition of module A', which implements the originally envisioned function A. From this moment on, the function and service are aligned, the functional part and the constructive part/module coincide. This part of system design as composing the whole system (module/product/item) from its constructive parts is called modular synthesis.

The system concept may sometimes be evident, but sometimes it includes inventiveness (working with affordances, "objects from the surrounding world suitable for performing the required function as parts of the design"). In TRIZ, it is essential that a small number of construction elements will perform a large number of functions (i.e., the degree of system idealness increases: an ideal system is one where its functions are fulfilled, but it has no construction, no material embodiment, zero modules/affordances in the system, without the need to manufacture anything). So in TRIZ, the relationship between functional and constructive elements is inherently not 1:1 (as in the case of scissors and a samovar). Always remember that modular synthesis is inventive activity: it is desirable to learn how to attach many functions to one module, reducing the number of modules in the system.

In inventive activity, we solve a multi-level optimization problem, resolving conflicts between interests, which may arise regarding different system levels.

John Doyle and colleagues indicated that there are always contradictions in nature (with a particular emphasis on the contradiction between speed and accuracy: there are fast inaccurate parts of a system and slow accurate parts), and this contradiction can be resolved by using multiscalar constructions with multi-level feedback, which cannot be resolved within the same level. Therefore, if one needs to create a fast and accurate system, it necessarily becomes complex - there is a lot of inventive work involved, but this work is supported by mathematics developed by them.

Usually, from the available or easily manufacturable modules/products, it is difficult to find those which in construction realize all the necessary functional parts with their functions. Thus, it is necessary to change the way processes in the system are broken down into functions of certain functional parts (which is equivalent to proposing an alternative way of the device's operation, a different principle of operation). Then, to realize other functions, one can select other, more accessible modules.

Modules/products/items have to be developed and manufactured if they cannot be readily purchased. Buying - is the simplest way of manufacturing modules! In IEC 81346-1:2022, even suggest calling a "product" a "component" if its purchase is envisaged, as such a situation is very common. Terminology can vary significantly; in other literature, a functional part might be called a component, the constructive part would be referred to as "component part," and the item being purchased will be named as a "procurement item."