With the two following partial areas of Design Science (Sections 7.3 and 7.4) we transfer our considerations away from the theory (descriptive statements, see Sections 7.1 and 7.2) to the area of the prescriptive statements which are closely related to engineering practice (compare figure 5--2 upper "northern" half). The prescriptive areas (together called prescriptive design-technical knowledge) should contain the practical knowledge which should give answers directly and quickly to those immediate questions asked by designers in all situations when designing. In analogy to the theory, the prescriptive technical knowledge is treated in his two partial areas:

1. in the branch knowledge (knowledge about more specific technical systems), and
2. in the design process knowledge (knowledge about designing).

Designers, whilst they are creating, repeatedly ask questions such as:

• what is the problem, how is it formulated, what does it mean?
• "how" (what process and procedure), and
• "with what" (means) can I solve a problem?

The multiplicity and variety of the problems encountered corresponds to the breadth of the possible design activities (compare figure 7--12). Therefore the necessary technical knowledge should not only be available, but also quickly findable, and should answer the questions directly (both in object and in process knowledge) as they emerge in designing. Especially in realizing the individual TS-requirements (which later appear as the properties of the realized technical systems) all influencing factors must be known, and their relationships must be available, if possible in quantified form.

Questions:

1. Which forms of branch (domain) knowledge are favorable for designers or for computers?
2. From where does the prescriptive branch knowledge originate?

Such a knowledge system as an independent area exists only in attempts and fragments. The knowledge which designers need today and will also need in future, once found, remained in earlier times scattered in some relevant sciences. In additional it was in most cases only vaguely formulated and, as merely personal "experiences" of individual designers, not integrated into a system. The retrieval or transfer of knowledge into other specialties was therefore extremely complicated. Experience was the main source of knowledge. Only later, about the 1920's, engineering sciences became the dominating source of this knowledge (figure 7--19, path 1).

This meant for designers that they (i.e. each designer, mainly for themselves and partially from their colleagues) had to derive their concrete specific knowledge for their own specialty from the general knowledge. Where no engineering sciences had emerged, the search for technical knowledge was possibly extended to the natural and "pure" sciences (physics, chemistry, biology) and in further areas. The "field of search" of designers consisted therefore -- and still consists -- of the two hierarchical knowledge levels shown in figure 7--19 (path 2) in columns 1 and 2, and of course also experience knowledge (column 4) and standards (column 3). It should also be mentioned that some TS-features or TS-properties (figures 7--4 and 7--5) could not be associated with an existing knowledge area. This is explained in the following on some examples.

Approximately in the 1940's this disadvantage came clearly to light. It was discovered that too large a transfer of knowledge for designers was to be overcome, so that information from the engineering sciences could be utilized in engineering design. The area of realization of technical systems which showed the necessary future direction, when the discipline "design for manufacture" was formulated (compare [48,49,80,81]). The basis for this partial area of prescriptive branch knowledge actually emerged in this way, and is situated in column 6, figure 7--19 (compare figure 7--4). For design practice, this knowledge system should serve as a substantial reservoir of necessary knowledge (path 3).

Question:
What is the structure of branch knowledge?

The structural elements of branch knowledge should be adapted within the objectives (goals), on the one hand to the situations in the design process (see design situation, Section 7.2.2.3.5), on the other hand to the kind of operand (type of technical system to be designed, the different aspects of the technical systems), as they have already been explored in the Theory of Technical Systems (Section 7.1 and [214,219]).

The knowledge about the origin, development in time, and taxonomy of technical systems remains fairly constant, regardless in which design phase we ask about them. Therefore they can form independent areas, which fully agree with the corresponding partial areas of the Theory of Technical Systems. The essential difference exists merely in the kind of knowledge, whether descriptive or prescriptive.

The knowledge about the nature, effects, modes of action and structuring of the technical systems are in contrast specific to and dependent on the branch (domain) or specialty, working stage and the kind of design activity. Substantially different information is required for the synthesis of the total system when conceptualizing, than in the layout stage, and again different sets of information for evaluating the proposed or realized systems.

Following these insights, this branch (object, domain) knowledge should be categorized primarily from the kind of design activity (design process knowledge), and then from the procedural stage. The assignment of the relevant branch knowledge to the individual design activities can be accomplished in very differentiated ways, according to the importance of individual characteristics for the concrete situation. We must first find out which characteristics exert the decisive influence on the categorization (order) of the knowledge; only afterwards can the primary ordering characteristics be used. If for example the form (shape) of components is to be established, then it is obvious that (beside the function) the production processes are the prime influence on the form. Therefore the production processes can be chosen as key indicator for the categorization (ordering) of the knowledge about form.

But also the choice of the design activities as key indicator for the categorization is not free of problems. This has already been demonstrated in the treatment the design situation (Section 7.2.2.3.5). The design activity may neither be set too broadly (compare figure 7--12, plane 1, design stages), nor too narrowly (figure 7--12, planes 4, elementary activities, and 5, operations). Thus we come selectively to the predominant planes 2 (design operations) and 3 (basic operations, problem solving thinking and actions) as main categorizing feature for the design activities.

In the area of the operand (the system to be designed), the first key characteristic is the branch of industry (the functions of the relevant TS-group, therefore for example turbines, machine tools) in which several more hierarchical planes can be distinguished. Following this, the second key indicator is the level of originality of the system. We could add the complexity level between these two, and with it form a special group of "elements" (this coincides for practical purposes with the conventional machine elements).

The design situation offers a further possibility for defining categories. The possible arrangements of design situations and the associated structural elements of the branch knowledge are obvious from figure 7--20.

If the branch knowledge is independent of design operations, then an aspect of the operand can become the key indicator for categorization. The area (B) from figure 7--20 contains such cases. So the certain elements of branch knowledge can be derived with the help of the general theory of origination (life cycle, figure 7--8), for example in the framework of a certain specialty (industrial branch), further for different levels of originality, and still further for different kinds of production (mass, large or small batch-series, and single-piece "one-of-a-kind" production).

An important categorization of technical systems develops also from the degree of complexity. Plant, machines, assembly groups, and individual components cover the four levels for machine systems (compare Section 8.1), whereby each level displays several particular characteristics. Especially the latter two levels contain constructional units which are generally applicable across many specialties (branches). For this case it would not be favorable to categorize the branch knowledge about constructional units according to design activities. A better categorizing feature is the order derived from TS-organs. For that reason, elements of the branch knowledge are arranged according to elementary organs or organisms (such as connections, transmissions) and can contain the complete knowledge about these specific constructional units. The design situation which is applicable for such elements of the branch knowledge can be described as follows:

• an organ structure (solution concept) has been established for the system to be designed, and the component structure should now be established.

The knowledge in this area can also be processed in a rather general fashion, for instance in the way in which it is used in books about machine elements, or published for a certain branch and a particular manufacturer, in the concrete form of an industrial guideline or even a standard.

The current considerations about the structure of branch knowledge prove clearly that no generally valid solution of this problem can be recommended. Some fairly clear classes of the elements have emerged, but they do not cover the whole content of the area. We can therefore expect a mixed solution for engineering practice. And the main reason is that guidance does not come from a total conception. It is directed by a successive process (origination of individual areas one after another), which is intimately connected with other areas, especially with that of the construction of knowledge-based systems (expert systems).

Question:
Which forms of the branch knowledge are favorable for application in the design process (when designing)?

Establishing the most favorable form of branch knowledge is the main requirement for its effective application. The knowledge should always bring a direct answer to the immediate question, whether it is asked by designers or by the computer. The series of design questions is formulated not only by the procedure, but also by the design activities (see figure 7--12).

Fortunately the diversity of the possible questions does not lead on the equal diversity of forms. These appear by chance only in some classes. We can therefore cover and position the total area from some few classes of questions. The most important and frequent forms are discussed here.

A) Class "Which are .... ?"

Many design steps ask about solutions of a certain problem, e.g.: which demands or requirements, which action principles, which organs, etc., fulfill this function?

For given boundary conditions, the branch knowledge should therefore place all solution possibilities at the disposal of the designer or computer. We can differentiate several levels of such knowledge material for delivery to designers, for example:

• enumeration (a simple enumeration without further statements);
• enumeration with statements of the conditions;
• enumeration along with further documentation, e.g., formulae;
• enumeration with the properties of a solution for evaluation and comparison.

Such knowledge is stored, for example, in design catalogs [257,376] and in guidance sheets, which use mostly tabular form. They are usually compiled in three or four parts: categorizing (classification), presentation, extension (reference), and possibly an appendix (according to Roth [376]). Further details are shown in figure 7--21, where some examples illustrate the possibilities of this knowledge system. The successful application of design catalogs is predicated on the systematic order of the categorizing arrangement. Often it is not the concrete solutions, but the classes of knowledge, which bring further important inspiration. A complete enumeration of the classes is more easily possible than a complete enumeration of the solutions (examples: classes of properties, or mechanical, hydraulic, electric amplifiers).

It would be conceivable to store such knowledge in knowledge-based systems, so that the necessary information (including advice) is accessible from the computer. Advice could also contain heuristic instructions for the selection of values for properties, e.g., as rules. A part of these instructions are already available within the design catalogs, but the extent could be expanded much further.

B) Class "how should form-giving be performed?" (or any other branch activity)

Especially during form-giving (of components and assembly groups), the most frequent questions refer to design properties. How should form-giving be performed, or dimensioning (establishing sizes), choosing raw materials and determining surface quality, so that the given demands (function, strength, friendliness for production, transport, storage or operation, etc.) are fulfilled? The instructions and information for this kind of question are recorded as branch knowledge in the disciplines usually known as "Design for ..." classes (see figure 7--5, part 3), for the individual properties of technical systems (e.g., design for manufacture and assembly [48,49,80,81], ergonomics [27], maintenance, and others, compare figures 7--4 and 7--5). We could use the expression "property-friendly designing," since operability or transport friendliness can be included in the TS-properties, and can be classified into the normal set of properties.

Using the example of the metal casting process (figure 7--22), the large difference in content and form of the information is made clear between manufacturing technology (in section A of this enumeration) and the information for casting-friendly design (section C). Designers (or computers) get a direct indication about how the forms (shapes) and dimensions (sizes) should be established, so that a casting (metal cast component) suitable for modeling (casting patternmaking), forming (in sand or other form material), casting (pouring), fettling and machining can exist. The prevailing knowledge form in this area consists of "rules" as text and pictures (either examples of good practice, or good and bad for comparison), as well as diagrams or equations.

C) Class "One should do it this way"

Often no large difference exists between the prescriptive and normative statements, unless the obligatory nature and depth of treatment for the instruction are different. As a further pattern of the form of branch knowledge, the instructions for establishing the design properties of a certain technical system can be considered (figure 7--23). These are usually related to a set of scientific theories of the relevant phenomena, and suitable heuristics and experience values. The individual properties -- form, dimension, raw material or surface processing -- can be recommended (guidelines -- prescriptive statements) or prescribed (standard -- normative statements).

These three classes of branch knowledge and the examples of the appropriate forms do not exhaust the possibilities. In connection with the contents, we will always find new forms which present the branch knowledge more completely and make retrieval and use still more effective. The other element, the computer, will make further demands, and enrich the offering through its abilities, independently of whether the knowledge serves designers, or is installed in a knowledge-based system.

Question:
From where does the branch knowledge originate?

One of the largest problems in planning the branch knowledge lies in the acquisition of the sources. As shown in figure 7--19 (the lowest comments), all kinds of knowledge sources must be used so that a complete system of design knowledge is realized. The hope to be able to solve the problem of generating a branch knowledge system only from the available literature, is a pure illusion. A very extensive source of knowledge that does not appear in the published literature consists of experiences -- a very individualized system -- and some of it is proprietary, subject to security precautions by an individual enterprise.

Especially two problems arise. One relates to the difficulty of formulating personal experiences (subjective knowledge) and to find important dependencies and laws. The second problem is in some ways the consequence of the first, that often vague (fuzzy) knowledge must be processed. These are in particular transient entry problems.

It is further necessary to transfer the available branch knowledge between specialties. Designers should direct their particular attention to published research, and fault events (e.g. [346,448]), in own and other specialties, and to draw consequences and derive guidelines for their own work from such sources. All data and statements should be subjected to tests for correctness, with regard for continuity, reliability of the source, verifiability of the statements, agreement of the data in transitions between sources, etc. That these tasks are too demanding for individual designers is evident. More reliable information is accessible in part from different organizations, e.g., from ESDU [6,7].

In generating the branch knowledge, the situation has changed in essence. Through the new expertise and laws in the areas of theory, especially the Theory of Technical Systems, a positive influence has been found; the right direction of development from the theory to the guidelines is made possible.

The branch knowledge is by nature a concrete form of knowledge. Its dissemination is therefore to be expected in the branches of industry (fields of use) and even more in the individual enterprises. The "know-how" can assume clear and unique forms from the completely defined elements of the design process (compare figure 7--23).

There are also areas which can contain concrete references, and can serve a broad consumer circle with rather limited "specialties," although they were developed on a general plane. As example we can consider the areas of "design for properties," as described in Section 7.3.3, especially figure 7--5, parts 2 and 3. Figure 7--22 illustrates how the indications obtained from knowledge of manufacturing technology, as rules or form recommendations (part C), have an extensive validity, and represent a very concrete form of knowledge when the special additions for the enterprise are made.

If they think about their demands for technical knowledge, branch (domain, object) knowledge appears to all designers as something self-evident. Yet only a fraction of this knowledge was available before the introduction of methodical (systematic) designing. The general difficulty in constructing and maintaining these knowledge systems hinders their broader application; and it is a fact that experienced designers are generally not convinced of the benefits likely from constructing these systems. The application of a system of branch knowledge could, beside other consequences (discussed in this section), also substantially shorten the expected "maturity time" of designers.

Practically, an essential change is to be expected, in our opinion, only when the knowledge-based computer systems demand a storage of knowledge, and "discover" that the branch knowledge is an essential element of the necessary designers" knowledge.

The second partial area of technical (prescriptive) knowledge -- knowledge about design processes -- deals with the transformation according to figure 7--10. The Theory of Design Processes was treated in Section 7.2, and questions relevant for the theory were asked. In contrast, these questions for a designer in engineering practice assume a different, more concrete form. According to the functions and rank of the individual designers, the emphasis of the work and the formulation of the questions can be found in different places. On average, the following question formulations are frequently repeated:

1. How should designers proceed for a concrete design task?
2. Which method should designers choose (reference Section 7.2) for solving a certain problem (under the given conditions), or how should they behave?
3. Which working means can they use in a certain design situation?
4. Which branch (domain) information is needed for particular design situations, and where can it be found? (Coordinating with branch knowledge)
5. How should certain design tasks be led (managed) and organized?
6. How can evaluations (of proposed TS) be better performed?
7. How can the work of designers be improved?

Compared to the questions in the theory, the difference is clear. We do not ask about a systematic treatment of a knowledge area, but for a recommendation about how a problem can be solved in a certain situation (or certain class of situations), or how one can behave and which measures should be used. Such a designated task for a knowledge system is difficult in comparison to the theory, especially because of the very large number of possible situations (if all variations are to be considered).

In order to keep the knowledge system within concrete boundaries, we must not only deal with the knowledge about classes of situations. We must be more specific, and deal only with selected, characteristic classes. In this case the restriction is not too difficult, because analysis shows that the individual questions are not asked with equal frequency. This insight serves now as starting position for considerations on the structure of the knowledge about design processes.

The required technical system is only rarely treated as a system to be newly designed, in which case the problem then consists of designing without an available model (precedent). The product is (in the ideal case of a design process) continuously more concretely defined. It experiences therefore a development in a crudely linear progression [310], from the given task to the concrete description of the system ready for the manufacture, see figure 7--24, part 1. Deviations from linearity are necessary because of iteration, recursiveness, and the need to work on one section (or a few) of the problem at a time. Further problems can occur which can be solved through a similar, crudely linear procedure. This is valid even if a design problem is decomposed into smaller partial problems, and during all the necessary iterations, recursions and revisions.

This scheme indicates that it should be natural for designers to incorporate information about manufacturing into the documents for designed systems. Concurrent (or simultaneous) engineering is supported by systematic work, especially because of the need for iteration and recursiveness to optimize a proposed system. This assumes that sufficient will and encouragement to cooperate is shown by personnel in other specialties and management.

According to the presented scheme (see figure 7--13) this solution path should traverse a series of different modeling forms which bring a flowing, continuously more concrete description of the technical system (TS). The crudely linear procedures are supported by numerous shorter cycles of detail problem solving (see figure 7--12, level 3: basic operations): The partial task is defined, information is procured, different solution possibilities are established, explored (analyzed), evaluated, selected, verified, improved, represented, then re-introduced into the main current of the solution procedure and documentation, communicated, etc.

The predominant number of cases of designing deals with alterations, changes, adjustments, variations, adaptations, etc.: A solution already exists, it should be adjusted or improved in one or another aspect of the designated task. Here too we need to initially designate and clarify a task. Then a more concrete structure can be taken over, either from an existing TS-model (see figure 7--3) as a break or jump in the crudely linear procedures, or obtained by abstracting from an already designed model, see figure 7--24, part 2. Following such a step, we can again follow the procedural model (see figure 7--13) to establish the revised manufacturing documentation. Through abstracting and subsequent concretizing a reversing loop through the structure models is traversed.

For alterations in the constructional details (configuration and/or parametrization) and their assembly, i.e. changing only the component structure, the reversing loop through abstraction from a model is short (or a break or jump from the task designation very long). If larger regions of the component structure are to be changed, especially when newly developed components or organisms are available, the reversing loop can be extended in time, and reach higher into abstractions of the structure. Still longer time and higher abstraction in the loop is needed if changes are demanded in the organ structure, e.g., if the functions of the technical system should be solved electronically instead of mechanically (e.g., for regulation and control, up to automation). Changes can even occur in the function structure or in the chosen technology, whereby the reversing loop for some regions becomes still longer and higher. Under this last condition, the design path can probably be made more rational by adopting or newly developing a higher, more abstract structure (small jump or break in a "novel" process), rather than by abstracting. The case for concurrent engineering is again shown.

If our question catalog to Section 7.4 is used as basis for the inquiry about a structure, the possibility to organize the questions in three classes arises, namely:

1. questions of methodical character, asking about available and suitable methods and behaviors (e.g., questions 1, 2);
2. questions about relationships in the design process, about its characterization, evaluation, and especially about operators of the design process (e.g., questions 3, 5);
3. special questions, which are tied to a certain situation (e.g., questions 6, 7).

The class (1) can be described as a range of problems that is interesting for many designer (and computer programmers). Questions are frequently asked regarding this range of problems. Answers are available in two basic forms, see figure 7--25. The first form contains listings of available methods, usually with descriptions of the procedures for operating them [98,228,239], typified by the upper section of figure 7--25. The second form relates possible and preferred usage of a method to the stages of designing, as indicated in the lower section of figure 7--25. As may be seen, the answers, i.e. the desired knowledge, can be organized fairly reliably using the design activities as classes. (This knowledge approaches that of the branch knowledge -- compare figure 7--20).

The knowledge in class (2) is predominantly of interest for a smaller group of personnel -- the leading designers (e.g., project leaders as part of the management hierarchy). This knowledge is seldom called for, and is for certain special situations, i.e. not for day-to-day use.

Apart from these, now and then particular singular situations emerge, which display little similarity with other situations. General knowledge for such cases does not suffice, it is necessary to obtain special knowledge for these situations.

From this analysis, we adopt the three classes (1), (2) and (3) as fundamental structural elements, and the characteristics of design activity are used as ordering features of class (1).

The analysis has also drawn attention to the frequency of application of the knowledge. From the viewpoint of effectiveness it is not rewarding to plan the construction of the information systems for rarely asked questions and seldom encountered situations.

The importance of the form in which the knowledge is presented has been emphasized repeatedly. For the knowledge about design processes, the following forms are beneficial:

1. Catalogs -- the design catalogs that were described in the area of branch knowledge (compare figure 7--21), can also present the knowledge about processes, in the form of operation catalogs (e.g., methods catalogs, or descriptions [98,228,239]). They contain predominantly the procedure, or its steps and rules, as well as the conditions of application and criteria for employment. In contrast to object catalogs they contain no extension part.
2. Models -- it is recommended, and confirmed by experience, that the procedure and other methodical indications should be presented in the form of models, not only by text. The engineer understands and "reads" diagrams considerably more easily than text (or than mathematical relationships) and retains graphical elements and relationships better in memory than words (compare figure 7--13).
3. Tables, decision table -- the representation of complicated relationships or combination possibilities can be clearly recorded in form of a table or matrix. Therefore this form is often utilized (compare morphological matrix, or "house of quality" in the QFD-method). A particular form of table is the decision table (logic states table), which is used for pre-determination of decision procedures, but also for the preparation of the logic flow for computer programs. The development of decision tables can be different, however they must contain rules and measures following the pattern "if -- then."

The four main areas of Design Science (as outlined in the previous sections of this chapter) with their knowledge in each level of concretization of technical systems cover the needs (and applications) of knowledge for designing. In certain conditions it can be useful to raise one or several partial area of these four main areas to a further quasi main area. In this fashion a partial area can be pragmatically categorized into the highest hierarchical level because of its immediate importance, timely relevance or because of the demands for knowledge from several main areas. As an example, "CAD-knowledge" is presented in the following paragraphs.

This partial area of Design Science is discussed in more depth for pragmatic reasons, because of the importance of computer application and of the novelty of the range of problems. To present the range of problems as clearly as possible, the descriptive (theory) and prescriptive statements are combined into a unit. But the emphasis of the useful knowledge for designers lies clearly in the prescriptive area. The knowledge in this area must always be presented to the users, and no fundamental theory is expected. The theory is treated mainly in computer (information) science and is adopted as necessary from there.

To be absolutely clear, we repeat here that this range of problems forms a part of the Theory of Design Processes. In this part, the working means (and therefore the computer) represent an operator of the design process (see figure 7--10--C).

Terminologically, despite all definitions, confusion rules in this area. The English abbreviations were formulated from completely different viewpoints than ones related to Design Science, and also their interpretation is not uniform. So for example, according to the perceptions of some branch experts the abbreviation CAD may cover applications in the whole design process ("computer aided design"), for others it only covers drawing ("computer aided drafting"). There are also other branch experts for whom designing does not need calculations; thus CAE ("computer aided engineering") would not belong to CAD ("design" or "drafting"), but this is not our conviction. Historically and pragmatically CAD/CAE-systems were written, prepared and developed particularly by computer programmers using techniques that at the time were "feasible" -- with only little regard to the needs and modes of operation of the engineering designers who were expected to use these program systems.

With reference to the structure of CAD-knowledge this sphere can be subdivided from the view of designers -- the computer users -- into the following partial areas:

Basics of Information Science

To understand the fundamentals of information processing and to be able to communicate with the information scientists, designers must master (at least at the level of awareness) the fundamental knowledge of information science.

If we think in this respect about digital computers, we imply for example an understanding of the binary number system and its realization through two conditions of a physical quantity (electric potential, voltage); understanding of information display with bits, codes for symbol display, and the computer-internal display of objects, their kinds of model and so on. Further we must distinguish different kinds of data (e.g., alphanumeric, graphic), files, data administration, data base systems, etc. That the data is entered, stored, processed and delivered to certain data carriers (media), is a further useful element of knowledge.

Basic Knowledge about Hardware and its Functions

Devices and material, all material and physical parts of the computer system which can be touched, are labeled as hardware.

The different devices can be assembled into several different systems (we speak of "architecture" and "configuration"), in which the peripheral devices for input and output, storage and central processing unit serve to process, control and store data.

Basic Knowledge about Software

Under software we understand all programs and data of a data processing system. The program prescribes to the computer a sequence of operations and commands which are to be executed to solve a given problem. This is also valid in general, e.g., independent of whether these commands run in one processor, or two or several parallel processors. Programs can also be stored in and accessed from "firmware."

For writing programs, the solution path must first be described with requirements and boundary conditions (an algorithm). The desired transformation must therefore be algorithmizable, the description can be mathematically formalized.

The program must control and instruct the computer in the real machine language -- binary. This computer-specific language, which transfers the commands to the central processing unit, is not suited for programming, except in particular and restrictive circumstances. For that reason, the higher level languages are used for programming. These are available in a wide diversity, and are suitable for certain specialized areas, e.g., FORTRAN for more mathematical and Pascal for more logical operations, LISP and Prolog for knowledge-based systems, assembler (mnemonic symbol) language or C++ for operating systems and programmable process controllers.

The ordinary user does not normally deal with programming. The current developments point in the direction that program administrators can enter their instructions by word processing, that means without or only indirectly through a programming language. These higher level languages are then translated by the machine into the machine language, with an interpreter directly from the higher level language, or with a compiler which generates a suitable running program in the machine language.

From another point of view we can divide programs into different kinds, for example system programs, user interfaces (shell programs, graphic -- GUI), applications (usable programs), or operating systems. A tendency exists that individual programs (calculation, simulation, search or optimization programs) are combined into program systems which have also stored the necessary knowledge (knowledge-based systems, expert systems) and which address the same database (integration).

With all programs, attention must be paid to transparency of the programming, verifiability, and references to progress and calculation paths. A feature of knowledge-based systems is the separation of procedures (the inference engine) and data (knowledge, rules and so on). Such systems can have additional abilities installed, as for example ability to learn (e.g., neural networks), control of the procedural direction from probabilities, and the possibility of inquiry about how the result was reached.

The branch and company specific data used for the programs refer on one hand to the range of products and all life phases of these products. In contrast to the considerations in the technical knowledge area the questions concern the branch knowledge. On the other hand these data affect procedure knowledge (algorithms) as process knowledge. The program follows the work of the designers and in similar design situations the program asks the same questions as the designers. Consequently the knowledge remains the same in contents, only the form could differ for the computer application. Therefore the statements in the Sections 7.3 and 7.4 are also valid for this area. Once these close relationships are discovered, the view of Design Science as a system is confirmed as correct and profitable.

In figure 7--26, the areas of individual operations and hardware-elements of computer technology (part B) have been brought into a visual relationship with the sphere of the origin and the life of technical systems (part A), as well as with Design Science. We do not intend to describe all the presented processes, but only to present the system (with hardware, software, user etc.) as a whole -- interested readers can find the descriptions for themselves, and can research the relatively complicated system in this way.