elaboration K. Fur ut a & S. Kondo Department of Quantum Engineering and Systems

Size: px

Start display at page:

Download "elaboration K. Fur ut a & S. Kondo Department of Quantum Engineering and Systems"

Cora Baker
5 years ago
Views:

1 Support tool for design requirement elaboration K. Fur ut a & S. Kondo Department of Quantum Engineering and Systems Bunkyo-ku, Tokyo 113, Japan Abstract Specifying sufficient and consistent design requirements is an important task in design, because they guide every design activity. This paper discusses how computers can support designers in eliciting and representing design requirements formally. A prototype system of support tool for design requirement elaboration has been developed based on the cognitive work space that is characterized by abstraction and structure hierarchies. The system provides moderate supporting functions of knowledge-based requirement elaboration, requirement classification and assessment of contentment status of requirements. Introduction Our group has been studying how AI technologies can intelligently support engineering design, in particular nuclear reactor design (Furuta & Kondo[l]). As a basis of this study, we consider design process as explorative abduction, where structurization of the problem space as well as search in the structured space is repeated till some solution is finally obtained. In this process, requirements for designing artifact guide design activities towards solution. Design requirements, however, will be incomplete or inconsistent at the beginning, and they become complete and consistent finally at the moment of solution. It is a remarkable difference of design from ordinary search in AI, where the goal is definite and fixed from the beginning. In the early stage of design, design requirements are expressed usually in abstract, ambiguous and conceptual terms. Moreover, the requirements may be incomplete or inconsistent. Design requirement elaboration is the task of eliciting necessary design requirements and then giving formal representation to

2 578 Artificial Intelligence in Engineering them as constraints. This task is so important in design that some engineers dare say that design is almost over when design requirements have been elaborated. Since design support systems, which are mostly based on formal logic of numerical or symbolic operation, cannot deal with early design requirements as they are, designers have been responsible for design requirement elaboration. It is not an easy task for designers to define a set of constraints representing sufficient and consistent design requirements without any help. The purpose of this paper is to present a method of support for such a task using current computer technologies. The support tool for design elaboration in this study is not to be used alone but cooperatively with some design system that has the capability of constraint satisfaction. The support tool passes constraints representing design requirements to the design system, and constraint satisfaction is carried out by the latter system. Other constraints of domain-specific design knowledge are also used in the constraint satisfaction, and the results are returned to the support tool, which shows the degree of requirement achievement to designers. Supporting functions Cognitive work space Physical systems have been represented often by the abstraction hierarchy, where system functions are related to more abstract functions in the upper level and more concrete ones in the lower. The upper and the lower level functions imply the goals and the means of the present level, respectively. Another aspect prevalent in engineering is the structure hierarchy, which represents whole-parts relation of physical systems. From the observation of behavior of system designers at work, Rassmussen pointed out that a two-dimensional space of abstraction and structure hierarchies is used in their cognitive process (Rasmussen[2]). We adopt such a cognitive work space for the framework to guide designers in design requirement elaboration. In this framework, design requirements are organized as a design requirement graph, where each node represents a unit chunk of requirement description and a unidirectional link represents means-end relation between adjacent abstraction levels. Another graph is used to show the structure hierarchy of the system. Nodes in both graphs are inter-linked by the relation which requirement is realized by which part of the system. Figure 1 shows the conceptual view of a physical system organized by the two graphs. The support tool for design requirement elaboration provides editing functions of these two types of graphs. At the beginning, the design requirement graph has a few nodes just below the top level, which nodes show purpose level requirements for the system. As designers elaborate design requirements, the graph grows downward till concrete requirements are obtained as constraints. Designer will relate, unrelate requirements, or go back to a higher level to expand another branch of the

3 Artificial Intelligence in Engineering 579 graph. He/she may jump down to a lower level and fill up the gap afterward. In accordance with the growth of the design requirement graph, the system structure will be specified. On the contrary, decisions on the system structure will yield new design requirements. In design requirement elaboration, however, specification of the system structure is a subsidiary task and its completion can be left for the next stage of design, i.e., constraint satisfaction. Figure 1. Conceptual view of the cognitive work space of system design. Automatic requirement elaboration and classification Designers, who are expected to show much more creativity than computers, are primarily responsible for design requirement elaboration. In many engineering domains, however, there exist typical patterns of design requirements. In such a case, computers can elaborate design requirements on behalf of designers by applying the domain-specific knowledge^ Such support will be effective not only for the reduction of designer's workload but also for the prevention of overlooking relevant requirements. It is also possible to judge automatically whether or not requirements have become concrete enough that they can be processed by a formal design system. Design requirements can be classified by their description patterns, and some subsidiary constraints may be necessary for particular types of constraints. For example, two measures of designer's preference are required for multiobjective optimization or satisfying: aspiration levels and ideal levels of objective parameters, details of which will be described in the next subsection. Nodes for such subsidiary constraints are added automatically to the requirement graph, having checked the types of constraints.

580 Artificial Intelligence in Engineering Assessment of contentment status Another supporting function provided by the support tool is assessing contentment status of design requirements.

4 580 Artificial Intelligence in Engineering Assessment of contentment status Another supporting function provided by the support tool is assessing contentment status of design requirements. This function helps designers to grasp in which part design activity is over and in which part it is still continued, and to plan design activities in the future. In case some requirements are violated, it is possible to know which requirement is conflicting or too demanding, and needs reconsideration. Design requirements can be classified into two primary types, and the meaning of contentment is somewhat different between the two. One of them is hard requirements, which are usually regulatory. Hard requirements must be satisfied for the realization of design objects. The other type is soft requirements. Soft requirements work as the criteria to chose attractive solution out of several alternatives, and they can be represented basically as some kind of optimization or satisficing such as "higher the better," etc. The contentment status of a hard requirement can be defined by a binary logic: acceptable or unacceptable. That of a soft requirement cannot be defined in the same manner due to its ambiguous nature of satisfaction. Since most of soft requirements are negotiable and conflicting each other, tradeoff is often necessary between different soft requirements. To define the contentment status of soft requirements, two measures of designer's preference are used in this study: aspiration level and ideal level. In case of maximizing some parameter, for example, the aspiration level is the value below which the case is unacceptable. A value above the aspiration level is acceptable, but humans usually prefer a value as high as possible. Considering such feature of human desire, we represent the contentment status in such a situation with a parameter calculated as follows: (obtained value) - (aspiration level) T = ;. (ideal level) - (aspiration level) A similar formalization is used for multiobjective programming called satisficing trade-off method (Nakayama[3]). In accordance with the above definition, we assign a value of+1 to the acceptable state of hard requirements. In addition, we assign -1 to the unacceptable state of both hard and soft requirements. The contentment status of any design requirement can be represented by a single measure from the above definition. The support tool calculates this measure after the results of constraint satisfaction have been returened from a formal design system. The contentment measure for a node in the abstract level is calculated from those in more concrete levels. The aggregation rule of the fuzzy set theory is applied to the calculation: minimum operation for conjunction and maximum operation for disjunction.

Artificial Intelligence in Engineering 581 Prototype system System architecture A prototype system of the support tool for design requirement elaboration has been implemented on a UNIX workstation.

5 Artificial Intelligence in Engineering 581 Prototype system System architecture A prototype system of the support tool for design requirement elaboration has been implemented on a UNIX workstation. The X window system with the Motif widget set is used for the user interface. The prototype system consists of the following submodules. Design Description Document is a working memory, where the design requirement graph, the structure graph and other knowledge emerged in the elaboration process are recorded. Design requirements are represented as frames that have slots containing label, substance, description, type and contentment measure of requirements. The substance is represented by predicates, while any comment of natural language can be written in the description slot. Automatic conversion of comment into predicates has not yet been implemented, though it is desirable. Knowledge Base consists of three types of knowledge to support design requirement elaboration. Requirement elaboration rules are the production rules that are used to expand and modify the design requirement graph automatically. Requirement classification rules are used to identify the type of design requirement such as predicate, equation, inequation, optimization, etc. from the symbolic pattern in the substance slot of a requirement frame. An object class library defines design objects that are well known in the domain. In the library, object classes are organized by is-a and has-part relations. Inference Engines consist of a production engine, a requirement classifier, an object generator, and a requirement evaluator. The production engine applies the requirement elaboration rules. If the substance slot of any requirement is evaluated, the requirement classifier identifies its type and writes the result into the type slot. The object generator creates an instance of object that has newly appeared in the design description document. The requirement evaluator calculates the measure of requirement contentment, and writes the result into the contentment slot. These engines are controlled by the blackboard model of control to support the designer cooperatively. Running example In nuclear reactor design, there are many prescriptive requirements, in particular for safety. The details of them are not fixed for reactors of advanced types under development, and additional requirements may be necessary depending on new features. For example, the basic philosophy of safety design for fast breeder reactors is almost the same as that for light water reactors, which are the most prevalent reactor type at present. Special concerns, however, for the chemical reactivity of sodium have to be taken into account. Advanced reactor design is, therefore, a good field to apply computer supported design requirement

6 582 Artificial Intelligence in Engineering elaboration; we will show the function of the prototype system using an example of fast breeder reactor design. In this example, the designer started design requirement elaboration by making the top goal of design in the abstraction hierarchy space. The top goal was a general assertion of design(fast_breeder_reactor). Since the support tool found fast_breeder_reactor in the object class library as a subclass of breederjeactor^ an instance of fast breeder reactor and its subcomponents were created in the structure hierarchy space. The requirements known for nuclear reactor, breeder_reactor and fast breeder reactor were then generated automatically. The requirements for mission, reactivity and safety are common to every reactor type, while that for breeding is specific to breeder reactors. Their lower level requirements were also generated, but they were not yet elaborated completely. iriticality lability / jfueljei' rtnormall - ' IheaTremovaJ <^ - [critical^ * '»fety_in_shutdown (...,..._...., :_., iahtjtdo^itcodling, ^ r Iclad mission of fast_breeder_rea:tor is power_productiorv. Constraint: [ predicate Contentment: [unsatisfied 1^006: 3afety_protectlon_ay3ten> ' 007:'blanket I Figure 2. An example of display in specifying the mission. Since any reactor must have some mission like power production, isotope generation, academic research and so on, the frame for mission requirement was generated by the system. Its substance slot, however, had been empty, and the designer set the mission of the reactor as power production next. Figure 2 shows the display of the system in specifying the misssion, where the requirement graph is shown in the upper half portion of the base window and

Artificial Intelligence in Engineering 583 the structure graph in the lower. The structure of the requirement frame is also shown in the subwindow.

7 Artificial Intelligence in Engineering 583 the structure graph in the lower. The structure of the requirement frame is also shown in the subwindow. The support tool then added the requirement frames related to power production. The new frames were for specifying reactor output power, and for economic requirements: capital cost and running cost The detailed specs of the reactor subcomponents were not determined at this moment. The designer can elaborate the design requirements by replacing more specific classes for the general subcomponents. The designer, for example, decided to use control_rods as the reactivity_controljievice from the alternatives presented by the support tool. No check rules of selection will be applied here on any choice of the designer, though it is not conventional to use burnable_poison or chemical shim for fast reactors. It is because the possibility of using an unusual option is not negligible for some special mission or in some genious idea. After controljods had been chosen, the support tool added general requirements for control rods such as the minimum rod worth required to control the reactor and the safety criterion of one rod stuck margin. The designer need not necessarily follow suggestions from the system, but he/she can define new concepts. He/she is also allowed to supplement or modify the requirement graph expanded automatically by the support tool. It is better to think that the support tool of this study is basically a structure editor with which the designer can build the cognitive work space as he/she wishes, and the other supporting functions are add-ons to help the designer modestly. Design requirements generated by the elaboration process are concrete enough that they can be processed by a design system based on symbolic or numerical methods. Related works Semantic network tools have been used not only for knowledge representation but also for computer support of creative thinking, concept generation or learning. In these approaches, graphical representation of concept relations and some computational support are expected to stimulate the user and to enhance the organization of knowledge (e.g. Jonassen[4]). Esselman [5] argued about the framework for computer aided systems design, and proposed a three-dimensional requirements matrix to describe how system requirements are to be developed. This matrix is organized by the view points of components, systems and functional tasks. The former two are particular levels in the structure hierarchy, and the last one is almost the same as the abstraction hierarchy. The reason why the two particular levels of structure have been chosen is that they dominantly important in plant engineering in which he is particularly interested in. It is, however, more general to use the single concept of structure hierarchy in stead of components and systems. Foster, et al. [6], developed a Design Brief Expansion Tool, which is equipped with a Hyper Text system and a parsing engine based on a semantically annoted grammar. This tool generates an extended design

8 specification that can be used by a design system support tool; the aim of their tool is similar to ours. Conclusion Designers can hardly present design requirements using a definite and symbolic formalism in the early stage of design, and it is expected that modern computer technologies can support this task as well as the satisfaction of them. For such a design support tool, it is important to choose a proper functional level; an excessively formal and functional system will restrict human creativity, while an excessively plain and silent system will be ineffective. We proposed to organize the working space of design requirement elaboration by abstraction and structure hierarchies, and developed a prototype system of the support tool for design requirement elaboration. The prototype is basically a structure editor with which the designer can build and modify the design requirement graph and the structure graph of a designing object. The system also provides knowledgebased supporting functions: automatic elaboration and classification of requirements, and assessment of contentment status of requirements. The contentment status is assessed considering the difference between hard and soft design requirements. The function of the prototype was shown with a running example of nuclear reactor design. References 1. Furuta, K. & Kondo, S. Framework for Al-based nuclear reactor design support system, J. Nuclear Science and Technology, 1992, 29, Rasmussen, J. Abstraction hierarchy, Chapter 4, Information Processing and Human-Machine Interaction, pp 13-24, Elsevier, Amsterdam, Nakayama, H. Proposal of satisfying trade-off method for multiobjective programming, J. Soc. Instrumentation and Control Engineers, 1984, 20, (Japanese). 4. Jonassen, D.H. (ed). Semantic networking as cognitive tools, Part 2, Cognitive Tools for Learning, NATO ASI Series Vol. F 81, pp , Springer-Verlag, Berlin and New York, Esselman, W.H. Framework for computer-aided systems design, Nuclear T^cAWogy, 1992, 97, Foster, J., et al. Design brief expansion tool, pp , Proc. 6th Int. Conf. Applications of Artificial Intelligence in Engineering, Oxford, UK, 1990, Elsevier, Amsterdam, 1990.

Changing and Transforming a Story in a Framework of an Automatic Narrative Generation Game

Changing and Transforming a Story in a Framework of an Automatic Narrative Generation Game Changing and Transforming a in a Framework of an Automatic Narrative Generation Game Jumpei Ono Graduate School of Software Informatics, Iwate Prefectural University Takizawa, Iwate, 020-0693, Japan Takashi