An Integrated Operational Knowledge Base (System of Operators) and the Innovation Workbench System Software

 Boris Zlotin and Alla Zusman
September 22, 1992
Kishinev, Moldova

Translation and comments by Alla Zusman
August, 1998
1998 Ideation International Inc.
May 1, 1999

Definition:

Operator – a transformation as denoted by a TRIZ principle, method, standard solution, or utilization of an effect (physical, chemical, geometrical, even psychological, etc.).

Prerequisites and Requirements

Prerequisites

An attempt was made to create an integrated TRIZ knowledge base that combined all existing TRIZ knowledge base tools. This constituted a logical step in the evolution of TRIZ, and was primarily a response to the following:

The IM software family was created on the basis of TRIZ as it was developed for manual use. This was the right direction to begin with, however, eventually a machine should work like a machine rather than simply mimicking human methods. To promote this change in approach it was necessary to reconsider the theoretical base of TRIZ.

The first step in this direction was the development of ARIZ-SMVA, with the understanding that this version of ARIZ is a process of developing multiple models for a given problem rather than a single model (as with ARIZ-85). The following models were identified:

Each of the above models is associated with a tool or set of tools. For example, the Innovation Principles work with Technical Contradictions; the Separation Principles with Physical Contradictions; the Standard Solutions with Substance-Field models, etc. It is obvious, however, that it would be much more convenient if there were an integrated tool that could serve all of the above-mentioned models.

Historically, various TRIZ knowledge-base tools such as the Innovation Principles, the Separation Principles, Effects, and others were developed as independent tools. Later, the expectation existed that these tools would eventually be replaced or absorbed by a more advanced and effective tool such as a complete System of Standard Solutions. This expectation was based on the assumption that a problem solver will always prefer to obtain a single, high-level solution rather than a set of solutions that includes those at lower levels (it was known that the Principles provided solutions of lower level than the Standard Solutions). As a result, over the next 5 to 6 years TRIZ schools practically stopped teaching – as well as using – the Innovation Principles altogether, and instead provided only brief information about this tool.

Later, it became apparent that excluding the Innovation Principles from a practitioner’s "toolbox" had a negative impact on his practical problem-solving abilities. This was primarily due to the fact that the Principles had capabilities that the Standard Solutions didn’t have and hadn’t gained, despite expectations to the contrary. For example:

In addition, the local ideality approach made a set of potential solutions preferable, as it allows one to choose the solution concept that has the highest local ideality. Given this, it is senseless to abandon ideas that can be obtained via numerous tools. On the other hand, reinstating all the Principles resulted in duplication, because in many cases similar recommendations were included in different tools.

 

Requirements for a System of Operators

All of the problems mentioned above can be resolved through the development of an integrated operational knowledge-base tool (a System of Operators) that includes all recommendations contained in the Principles, Standard Solutions, Utilization of Resources, etc. This System should work with any problem model known in TRIZ: Technical Contradictions, Physical Contradictions, Substance-Field models, etc.

Working with the Contradiction Table, it was found that selecting Principles based on a pair of contradictory characteristics limits the tool’s capabilities. In fact, with TC modeling, two characteristics (parameters) are "connected" via a specific means of eliminating a drawback. For example, one way to improve productivity might cause an increase in weight, while another way might result in decreased reliability – that is, lead to a different TC. Given this, we can assume that besides the traditional methods of eliminating a TC there might be others as well. For example, if our TC contains the pair "productivity – reliability," the following might also be considered:

In order for these methods of withdrawing a TC to be utilized, the option must be provided for selecting Principles (Operators) separately for each applicable characteristic (in addition to the "usual" way; i.e., through the Contradiction table).

It is also interesting to note that the original Principles were much more specific than the Principles used today. Many of the Principles were adapted to the specific characteristics they were intended to deal with. For example, the Principle "Segmentation" for the purpose of weight reduction differed from the "Segmentation" used to reduce dimension. Later, Altshuller withdrew such specifics from the Principles, apparently for the sake of the universality and convenience of the Contradiction Table. However, this "detailization" can now be reconsidered in light of the possibility of utilizing PC.

Besides "picking up" (selecting for use) an Operator based on a particular characteristic, it would be useful to do this based on the type of drawback involved or on a desired function. Providing such "entrances" to the System of Operators requires that the Operators be classified according to their application.

Keeping in mind the utilization of computers as a goal, a complete redesign of all existing Operators (Principles, Standard Solutions, etc.), making them much more detailed and specific, can be achieved. This work has already been started by Lev Pevzner and may prove to be extremely powerful. Such "detailization" can be accomplished in two ways: through segmentation of the existing Operators (from the top down); and through the generalization of illustrations associated with each Operator (from the bottom up)

In conclusion, the following main requirements for a new TRIZ knowledge-base tool can be formulated:

 

Requirements for Illustrations (Examples)

An Operator’s recommendation should be illustrated via descriptions of practical applications. Since most TRIZ recommendations are fairly general, these illustrations might be far removed from the specific area in which the user’s problem lies – this can result in a negative impression about TRIZ in general and about IM’s software. Making the Operators more specific affords the opportunity of supplementing each Operator with appropriate illustrations.

In the IM software family, the illustrations are installed in a specific product. In our opinion, it would be much better to allow for the same illustration to be used for various Operators (when appropriate). On the other hand, the situation wherein the user arrives at the same illustration several times develops the negative impression of a limited knowledge base. We have a contradiction: An illustration should serve multiple Operators to increase its problem-solving power, and should serve one Operator only to avoid the impression of limited capabilities. One way to resolve this contradiction is to avoid similar illustrations appearing during demonstration of the software product. For example, the same illustration shouldn’t be the first one listed for more than one Operator.

Illustrations should be simple, easy to understand, and convincing. For these reasons they should be free from unimportant details that can negatively influence "analogic thinking."

 

Structure of the System of Operators

Basic characteristics of Operators

The work began in September of 1991 as a logical continuation (following ARIZ-SMVA) of the computerization of TRIZ. A general list that included all Operators derived from the existing Principles, Standard Solutions, Lines of Evolution, etc. was developed. After excluding instances of duplication, a preliminary classification of the Operators was done. This resulted in the understanding that the "database" of Operators should be divided into three groups, based on the level of universality, as follows:

 

Operator Blocks

Operators are used in blocks (i.e., sets), which are created by selecting the appropriate "higher-level" Operator from a more general list. Accordingly, some Operators may be included in various blocks. The following types of blocks have been identified:

Universal Operator Blocks

Universal Operators contain recommendations for system transformation irrelevant to the type of drawback or contradiction to be resolved. The effectiveness of an Operator depends on how clearly the user comprehends the way to implement the recommendation. If this is not clear, it is necessary to specify the problem in more detail and apply specialized Operators. The following Universal Operator Blocks have been identified:

Specialized Operator Blocks

Specialized blocks address specific types of problems related to a particular function to be performed or drawback to be eliminated. For convenience, all characteristics are divided into two groups: useful (such as accuracy or convenience) and harmful (weight, complexity, etc.). The following Specialized Blocks have been identified:

Weight Reliability
Overall dimension Speed of action
Energy consumption Mechanical strength
Complexity Composition stability
Time wasted Convenience
Energy wasted Productivity
Local (selective) mode
Manufacturing accuracy
Dispensing accuracy
Shape
Universality
Degree of automation
Degree of adaptation

Auxiliary Operator Blocks

Auxiliary blocks are intended to help improve a solution in terms of ideality and feasibility, and include the following:

Block-Lines

Block-lines help the user to further develop a solution that has been found. These include:

Applying substances, fields, effects

These blocks should include information related to the selection of fields, substances, and physical and other effects.

Purposeful (general) blocks

General blocks help identify the "type" of the specific problem being addressed and offer recommendations for finding solutions. The following general blocks have been identified:

Altogether, the System of Operators is structured in the form of a list/block: i.e., all Operators are placed in a single list, and various blocks are built for various purposes.

 

Illustrations

Similar to the Operators, the illustrations form their own list. Each potential illustration gets its specification including indications of Operators it can relate to (appropriate software addresses are posted). As usual, one illustration can serve two-three Operators.

The System of Operators as part of the knowledge base incorporated into the Innovation Workbench ™ (IWB) System software prototype

The structure of the System of Operators became fairly complex due to the numerous relationships (links) existing between the Operators. For example, if a user is working to improve dispensing accuracy, one of the Operators from this block recommends the addition of an easily-dispensed substance; then, to further develop the solution, a block for eliminating a substance is presented; one of these Operators recommends removing the introduced substance immediately after it has fulfilled its function; and so on. As a result, the Operator blocks form a net having a complex, reticular structure that is practically impossible to draw on a piece of paper (and would be unusable in any case). This type of structure was implemented with the help of hypertext, in the form of a branched system of menus consisting of menus of two types: a choice menu from which the user selects an appropriate Operator or Operator block (this constitutes part of the process of problem clarification), and an exploration menu whereby the user works with the recommended Operators one-by-one to develop a solution(s).

The choice menu allows for the selection of:

 

The purpose of the work

Numbers related to the IWB software prototype (as of April 1992)

Operators blocks: 39
Operators: approx. 200 (approx. 400 in the recent version, IWB 2.2)
Illustrations: approx. 300 (approx. 1,300)
Links: approx. 1,500 (over 14,500)
Screens: approx. 800 (over 4,000)
Amount of information: approx. 500KB (over 2MB)

Basic Advantages of the IWB prototype

The menu system allows the user to clarify the problem without building a TRIZ model. This simplifies the work for those user’s who do not have special (TRIZ) training.

Unlike the usual practice of applying 2 to 4 single recommendations while working with the Principles or Standard Solutions, the System of Operators offers "chains" of recommendations that can include up to 20 Operators in one chain, substantially increasing the tools problem-solving power.

Conclusion

The IWB prototype was demonstrated in April-September 1992 in Moscow, to around 30 TRIZ specialists from Moscow and St. Petersburg (Russia), Panevegis (Lithania), Minsk (Belorussia) and Petrozavodsk (Russia), twice. During these demonstrations, as well as during the seminar for TRIZ specialists conducted by the authors in September, more than 100 people from 27 former Soviet Union cities became familiar with the system.

The overall reaction was positive, especially for the theoretical advances. With regard to the software implementation, constructive criticism was received. Today, our work with the prototype continues. When it is finished, we intend to offer it to selected TRIZ schools and specialists for testing, and to be included as a supporting tool for TRIZ consultants.

 

Acknowledgements

We are grateful to our colleagues Igor Vikentiev, Simon Litvin, Alexander Lubomirskiy, Lev Pevzner, Michael Rubin, Igor Kholkin, Nikolai Khomenko, and Alexander Chistov, as well as organizations ImLab and LenNilim for useful discussions and suggestions. We would appreciate any comments related to this paper.

1998 Ideation International Inc.
May 1, 1999

 

 

ENDNOTES:

  1. This paper was originally prepared in 1992 for publication in the Journal of TRIZ, in an issue devoted to the Kishinev School. It was pulled from publication due to the proprietary nature of the material and because a patent was pending related to the Innovation WorkBench System™.
  2. Later, for the purpose of simplifying the structure of the TRIZ knowledge base, the "effects" were excluded from the System of Operators. [Translator’s note.]
  3. It is an interesting and well-known fact that the first attempts to automate a process usually involve imitating the human way, and that these attempts are never successful. (An example is the first sewing machine, which had artificial "arms.") Real success was usually associated with the development of a new technology – one suitable for automation. [Translator’s note.]
  4. Boris Zlotin and Alla Zusman, "Problems of ARIZ Enhancement" (in Russian), Journal of TRIZ 3, no. 1 (1992). [Translator’s note: See the English translation on the scientific channel of our web site, www.ideationtriz.com.
  5. G. Altshuller et al., The Search for New Ideas: From Insight to Methodology (Kishinev: Kartya Moldovenyaska Publishing House, 1989).
  6. Zlotin and Zusman, "Problems of ARIZ Enhancement."
  7. G. Altshuller, Basics of the Method of Inventing (Voroneg: Central Chernosem Publishing House, 1964).
  8. Lev Pevzner, "A Concept for Development of Micro-Standards for Solving Problems with the Help of a Computer" (in Russian), Journal of TRIZ 1, no. 2 (1990): p.44.
  9. Boris Zlotin and Alla Zusman, "Basic Problems Related to the Development of TRIZ-Based Software" (in Russian), Journal of TRIZ, V4, no. 1 (1994).
  10. Later renamed as "General." [Translator’s note.]
  11. Later placed in the Innovation Guide. [Translator’s note.]
  12. These references form so-called "associative chains," which model the way experienced TRIZ Specialists solve problems.
  13. Boris Zlotin and Alla Zusman, "Basic Problems Related to the Development of TRIZ-Based Software" (in Russian), Journal of TRIZ, V4, no. 1 (1994).
  14. A secondary problem (drawback) results from applying a known way to eliminate the initial drawback. [Translator’s note.]
  15. Later, Substance-Field models were replaced by a verbal problem description.
  16. Pure text information (text file).