Optionally
AIPS-2015
- AIPS. Stage 1.
- AIPS. Stage 2.
- AIPS. Stage 3.
Functional model
Causal model
Hierarchical process model
Analogies
Useful technical system
Principles of resolving technical contradictions
- Principle 1. Segmentation Principle
- Principle 2. Separation Principle
- Principle 3. Local Quality Principle
- Principle 4. Symmetry Change Principle
- Principle 5. Merging Principle
- Principle 6. Multifunctionality Principle
- Principle 7. Nesting Principle
- Principle 8. Weight Compensation Principle
- Principle 9. Preliminary Counteraction Principle
- Principle 10. Preliminary Action Principle
- Principle 11. Beforehand Compensation Principle
- Principle 12. Equipotentiality Principle
- Principle 13. The Other Way Around Principle
- Principle 14. Curvature Increase Principle
- Principle 15. Dynamic Parts Principle
- Principle 16. Partial or Excessive Actions Principle
- Principle 17. Dimensionality Change Principle
- Principle 18. Mechanical Vibration
- Principle 19. Periodic Action Principle
- Principle 20. Continuity of Useful Action Principle
- Principle 21. Skipping Principle
- Principle 22. Blessing in Disguise
- Principle 23. Feedback Principle
- Principle 24. Intermediary Principle
- Principle 25. Self-Service Principle
- Principle 26. Copying Principle
- Principle 27. Cheap Disposables
- Principle 28. Mechanical Interaction Substitution
- Principle 29. Pneumatics and Hydraulics
- Principle 30. Flexible Shells and Thin Films
- Principle 31. Porous Materials
- Principle 32. Optical Property Changes
- Principle 33. Homogeneity Principle
- Principle 34. Discarding and Recovering Principle
- Principle 35. Parameter Changes
- Principle 36. Phase Transitions
- Principle 37. Thermal Expansion
- Principle 38. Strong Oxidants
- Principle 39. Inert Atmosphere
- Principle 40. Composite Materials
Standard problem solutions
- Class 1
- Class 2
- Class 3
- Class 4
- Class 5
Lines of development
- 1. Mono-bi-poly of identical objects
- 2. Mono-bi-poly of various objects
- 3. System composition scaling-down
- 4. Segmentation
- 5. Evolution of surface
- 6. Internal structure evolution
- 7. Geometric evolution
- 8. Dynamisation
- 9. Controllability
- 10. Сoordination
Glossary
Literature

Stage 2. Solution of the problem identified

The hill-like diagram illustrates the process of solving an inventive problem most adequately. Its main idea is to transform a real-world problem into a model, to adjust the model at the generalized (abstract) level, and to find a real solution.

Relatively simple problems can be solved using a single model. Several models should be used to solve complex problems.

As a result, the diagram takes the form shown in the following figure and has several “hills” located above each other. The trajectory of transition from the problem to the solution repeats several times with an ever increasing degree of generalization of the models applied.

Our algorithm assumes four iterations of working with four different models of the problem.

Iteration 1. Conditions in the operational area

Step 2.1. Model the “Conditions in the OA” problem

Input: a hypothesis or a formulated problem statement.

Action: single out significant information from the hypothesis or the problem statement.

Output: a formalized problem model.

The formalized problem model describes the conditions which should be created to exclude the cause of the conflict. The operating time and the operational area of the conflict should be determined. A list of resources available should also be prepared.

Step 2.1.1. Transform the problem model into an abstract solution model

Input: a formalized problem model.

Action: transform the problem model into the solution model.

Output: an abstract solution model.

It is possible to move from the problem model to the solution model at this iteration in a number of ways. The most obvious ones include use of engineering experience and similar problems with various methods of activating thinking out of the box applied. It is also possible to apply standard problem solutions developed in the TRIZ.

Step 2.1.2. Create a “portrait” of the resource required for solving the problem

Input: the abstract solution model.

Action: determine the requirements for the resource.

Output: a list of requirements for the resource.

The list of requirements for the resource is a detailed description, a portrait of the resource. The list of the requirements for the resource is prepared at the first iteration and then expanded at each of the following ones.

Step 2.1.3. Find a resource and generate an idea for the solution

Input: the abstract solution model + the list of requirements for the resource.

Action: generate ideas.

Output:

the appropriate concept (-s) of a preliminary solution is available > proceed to step 2.6 (develop the final solution);
no appropriate concept (-s) of a preliminary solution is available > proceed to step 2.2 (develop another problem model).

The abstract solution model describing transformation of the system components in an extremely generalized form is elaborated, filled with the object content. The resources selected are introduced in the description of the abstract model. The resource “portrait” is used to analyse and select the resource. If the resource cannot be applied in its original form, it is possible to use various effects to transform it: physical, chemical, geometric etc.

Iteration 2. “Technical Contradiction” problem model

Step 2.2. Model the “Technical Contradiction” problem

If the solutions obtained upon the first iteration have not satisfied us completely, we proceed to the next problem model, to the parametric one in this case. In the TRIZ, this model is called a technical contradiction (a contradiction among the parameters).

Input: hypotheses, the problem statement, the concepts of the preliminary solution of the first iteration + a formalized model of the problem.

Action: identify the contradictions among the system parameters.

Output: a parametric problem model (technical contradiction)

Step 2.2.1. Transform the problem model into an abstract solution model

It is possible to transform the problem model into the solution problem at this iteration using the techniques to resolve technical contradictions developed in the TRIZ. To simplify their selection, special tables are used, e.g., the table, developed by G. S. Altshuller.

Input: a parametric problem model.

Action: transform the problem model into the solution model.

Output: the abstract solution model.

Step 2.2.2. Create the portrait of the resource required for solving the problem

Similar to the first iteration (taking into account the information already accumulated in the list of requirements for the resource)

Step 2.2.3. Find a resource and generate an idea for the solution

Similar to the first iteration, except for the output.

Output:

the appropriate concept (-s) of a preliminary solution is available > proceed to step 2.6 (develop the final solution);
no appropriate concept (-s) of a preliminary solution is available > proceed to step 2.3.1 (develop another problem model).

Iteration 3. “Actions in the Operational Area” problem model

Step 2.3. Model the “Actions in the OA” problem

Input: hypotheses, the problem statement, the concepts of the preliminary solution of the previous iterations.

Action: transform the problem model into the solution model.

Output: a structural model of the problem.

At this step, we try to describe the operational area in more detail. This can be done by various methods: by developing a substance-field model, a SAO model, a stickman model, a component model etc.

Step 2.3.1. Transform the problem model into an abstract solution model

Input: a structural problem model.

Action: transform the problem model into the solution model.

Output: the abstract solution model.

Each model type has its own transformation tools: for the substance-field model, it is more appropriate to apply 76 standard solutions [19], for the SAO model, transformations along the development lines, the structural-analogy method is most suitable to transform the component model etc.

Step 2.3.2. Create the portrait of the resource required for solving the problem

Similar to the first iteration (taking into account the information already accumulated in the list of requirements for the resource).

Step 2.3.3. Find a resource and generate an idea for the solution

Similar to the first iteration, except for the output.

Output:

the appropriate concept (-s) of a preliminary solution is available > proceed to step 2.6 (develop the final solution);
no appropriate concept of a preliminary solution is available > proceed to step 2.4 (develop the “physical contradiction” problem model).

Iteration 4. “Physical Contradiction” problem model

Step 2.4. Model the “Physical Contradiction” problem

Input: concepts of the preliminary solution of previous iterations + a formalized problem model.

Action: identify and formulate a physical contradiction.

Output: a problem model in the form of a physical contradiction.

A physical contradiction is developed upon clarifying the conflict zone within one component of the system. The essence of the physical contradiction is that contradictory (mutually exclusive) requirements are imposed on the same component of the system or on its part.

Step 2.4.1. Transform the “physical contradiction” problem model into an abstract solution model

Input: a problem model in the form of a physical contradiction.

Action: transform the problem model into the solution model.

Output: the abstract solution model.

To have the model of the physical-contradiction solution, it is required to use the techniques for resolving physical contradictions developed in the TRIZ.

Step 2.4.2. Create the portrait of the resource required for solving the problem

Similar to the first iteration (taking into account the information already accumulated in the list of requirements for the resource).

Step 2.4.3. Find a resource and generate an idea for the solution

Similar to the first iteration, except for the output.

Output:

the appropriate concept (-s) of a preliminary solution is available > proceed to step 2.6 (develop the final solution);
no appropriate concept of a preliminary solution is available > proceed to step 2.5 (calculate the missing concepts of preliminary solutions).

Step 2.5. Calculate the missing concepts of preliminary solutions

Input: the concepts of preliminary solutions developed at iterations 2.1-2.4.

Action: extend the scope of preliminary solutions.

Output:

the appropriate concept (-s) of a preliminary solution is available > proceed to step 2.6 (develop the final solution);
no appropriate concept of a preliminary solution is available > proceed to step 1.3 (formulate hypotheses of resolving the conflict).

If all iterations have been completed in solving the problem, a large number of preliminary solutions are accumulated. To analyse the totality of the solutions, expand the search, and generate new ideas, lines of development of technical systems and evolution trees are used.

Step 2.6. Develop the final solution

Input: all concepts of preliminary solutions.

Action: Develop the final solution.

Output: the final solution.

The concepts of preliminary solutions are the working material for the final solution. The most promising concepts should be selected first. The final solution is developed by combining all or some of the preliminary solutions or their positive properties into a single whole. To this end, the method of combining alternative systems can be applied.

How to work with problem models

The AIPS 2015 version provides for the hypotheses processing operator, so it is possible to proceed to the solution part of the algorithm starting with any model. In this case, the main vector of moving along the algorithm – up, to the physical contradiction, to the one-parameter model – is preserved but certain features of applying the models exist. Whatever model is used to enter the solution stage of the algorithm, a preliminary solution intended to improve a certain parameter of the useful system is developed. If the parameter improved satisfies the solver, and no harmful phenomena manifest, then it is possible to develop the final solution. If the solution does not satisfy, an attempt should be made to identify and resolve the physical contradiction using the one-parameter model. In other words, an attempt should be made to proceed to this model upon performing any iteration since it is the resolution of the physical contradiction that gives good ideas for the solution.

It can happen that the idea of a solution improves the required parameter of the system but results in deterioration of one or more of its other parameters. An issue named a technical contradiction in the TRIZ arises. That being said, it is advisable to check whether the solution developed at any iteration contains a technical contradiction. If this is the case, you should proceed with the parametric model of the problem and resolve this contradiction.

Thus, the solution part of the algorithm has two important iterations where the solver’s mental efforts concentrate: the one-parameter model of the problem which resolves the physical contradiction developed and the two-parameter model where it is possible to apply the tools to resolve the technical contradiction (fig. 3.b). The solver can go sequentially from the bottom model to the top model and can constantly refer to the iterations providing for resolving the technical and physical contradictions.