Chapter 8
This chapter surveys the state of the art in integrated design environments with respect to their capabilities for using materials information. It addresses the problems of making materials information available to a wide range of different types of software aid for design, selection, analysis and evaluation, for function and for life-cycle issues. Different types of material property are important for different uses of information so it is possible to estimate the relative difficulty of supplying either predictive models or appropriate data to support these different information needs. The chapter concludes that difficulties are inherent and provides a view of the future characterized by steady progress rather than breakthroughs.
The organizational aspects of accumulating and standardizing data and agreeing in the wider community which data interchange interfaces should be developed are, in practice, as important as developing better representation schemes for materials information.
Materials issues present a self-contained package of difficult technical and human problems in a compact form. Thus the difficulties are impossible to dodge by concentrating on some partial but tractable aspect, a tactic often used, perhaps unwittingly, by academics researching other software aids for engineering design [Fin89].
Commercial push
The commercial push to more integrated CAD/CAM systems comes from CAD vendors who attempt to include more materials-based techniques into their packages. There is an interesting parallel with the history of handling geometry input and output for finite element analysis: in the past every package was totally independent, but now the functions of pre-processor, solver and post-processor can be bought separately, and used with other independently produced drawing or solid modelling packages. This expands the market, gives more flexibility to the customer and everyone is happy. The same thing has to be achieved with materials data and materials models which are too many, too large and too complex for every CAD producer to offer a complete package.
Data transfer
Geometrical data is sometimes transferred to a finite element package for analysis of properties under conditions of service, such as analysing the creep of turbine blades over realistic aeroengine duty cycles. At the point of transfer, extensive materials property data libraries are required in the proprietary form required by the finite element simulation package. However there is currently no standard linking format for inelastic materials data between geometric design and property analysis.
Although analysis of in-service component behaviour is possible, the simulation of component failure can be more difficult. For metal fatigue, a stress analysis and knowledge of the fatigue-limit stress can be helpful, but simulating the fatigue of composites requires knowledge of appropriate damage mechanics models and, as in creep in metals, hand-programmed subroutines and extra, non-standard materials information.
Materials properties are also important when designing for the the maintenance and use of equipment: models for the wear of dies and tools can be greatly improved by proper use of relevant material property data [Wri88].
Describing how materials information can be used within future CAD/CAM design environments requires that current systems be surveyed first.
There are two main strands of development: current commercial CAD/CAM and analysis packages [Ric87, Dea90, Sdrc89, , Sta89], and current computer aided software engineering and project support environments [Bro87, Som89, Tho89, Win90]. There is also significant research underway on producing specifically engineering design-oriented databases [Enc90, Cha89, Rum90]. There are also software tools which specifically support the engineering design process as well as individual design activities [ West89 Vid89, Pap90, Fin90].
The overwhelming conclusion is that successful future design environments will comprise a heterogeneous collection of independently produced software agents. These will communicate with each other directly and indirectly, implicitly via the current state of the designed artefact and explicitly by posting messages on several shared 'blackboards'. Only some of the agents will have user interfaces, and some agents will manage sets of other agents.
Design agents
There are six main reasons why a popular approach to developing engineering design environments is to employ a small number of common representations and a large variety of distinct, independent, inter-communicating software agents.
The first reason should mean that constructing design environments using agents involves only a linear scaling of effort with respect to capability, rather than the super-linear effort typical of most software systems (doubly complex systems are much more than doubly difficult to get working [Som89]).
However whether linear scaling of effort actually occurs in practice depends crucially on the representational adequacy of the common core with which the agents communicate (often implemented as a blackboard system). That is why the early chapters concentrating on representations for materials information are so significant.
The hope is that if elements of the central representations can be recombined in many meaningful ways, and if they are at the right level of abstraction, then very large numbers of independent software agents can be constructed and contributed by diverse research groups and commercial organizations. The creation of a market of third-party aids is more than an indication of success, it is almost a definition of success.
What agents communicate
The question is: given a software-based design environment containing many independent agents, what do they say to each other ?
The obvious answer is that they pass along data describing potential artefacts from a number of different points of view. Each agent takes a partially complete design as input and produces some analysis or more detailed layout which it passes on to another agent.
The network of tools implicitly linked by a variety of different input and output data sets can get very complex but the data flow mechanisms always operate in the same direction: from specification to implementation. This type of 'forward' information flow and transformation has been the focus of much important research but few if any have studied the reverse flow.
Feedback flow
One of the very few design environment research projects on formal descriptions of feedback information is the development of SOAR-FORS at the Engineering Design Research Center at Carnegie Mellon University. SOAR-FORS is built on top of and manipulates the existing integrated building design environment (IBDE) and studies which loop should be taken depending on the result of an agent, but not what information should be transmitted along that loop. The number of such loops greatly increases the complexity of the problem..
SOAR is a learning system which requires formalization of messages before it can learn [Lai87, Car90], but such formalization is required before any software tool can help. Formal messages also make many human operations easier in comparison with previous projects which only gave criticisms to users in the form of unstructured text [West89].
Figure 8.1 Artefact descriptions and data flows
Recent researches have provided the basic framework whereby such messages can be transmitted and received, have provided flexibility for their syntax and have taken care of selecting the useful topology of the downstream information flow (FORS) [Pap90] but have contributed little to what they should say or mean.
The general point is that the study of the feedback information is relatively neglected in research in the context of its importance: it is one of the things that makes design distinctive. One (extreme) viewpoint holds that design is just 'iterative analysis' which places all of the distinction between design and engineering science on these feedback links.
Why feedback information is important
The feedback data flow contains the information which the designer takes from the output of a tool (usually an analysis tool) and uses to modify the design. The tool takes input from one problem space and presents it in another, or if it doesn't present it in another, the designer at least reads into it a meaning in another. (If it really is in the same problem space then the problem is one of optimization and not of design.) This is the useful information that a critic or a subdesign agent conveys.
Short-term requirements for most design environment development projects mean that all communication between tools is commonly performed implicitly via an annotated description of the artefact being designed. This has (theoretically) the same expressive power but hides this important matter in a mass of detail. The implicit meaning of information present only as annotations means that it is difficult to write new agents which can make use of it.
Figure 8.2 Feedback as a table of parameters
If information passed back up the design sequence can be formalized, then a wide variety of new designer aids can be developed: navigator tools, training tools, even tools which can make use of databases of design guide-lines (such as a textual databases of design aphorisms or even textbooks [ Fre85, Par89, Pay90]).
As we have seen earlier, the important information in materials selection is present in these feedback messages, so materials information may take a lead in formalizing this type of communication.
Little languages
Many messages will be simple, perhaps consisting of a single list of parameter values, others may require several lists. The elements could be any Common LISP Object System objects but the point is to keep them simple rather than complex, and to keep their structure as well-defined little languages.
The Object Management Group is an industry consortium which is attempting to design an achitecture in which agents may exist. It is also proposing to standardize common types of message structure and formats which agents may use. The group contains representation from the majority of the world's software developers.
The reason that simple languages containing simple components and syntax are preferable is that it is then more likely that other agents can participate, and the simpler the language the easier it is to add agents which can understand it.
Cell Management Language (CML) was developed by Bourne in cooperation with Westinghouse to allow robots to communicate with each other when they interact as units of a manufacturing cell. The language is really a framework that enables entirely new little language translators to be developed quickly so that new or reconfigured robots or machine tools can be integrated into the cell without months of reprogramming [Wri88]. Such a model for communication might serve design agents well.
It is important to realize that successful design environments will contain agents contributed by many different people and organizations, people over whom the original developers will have no control. This is a mark of success, and one could argue that systems that do not permit this will not be successful.
Numbers of tools
Current research systems can assure that the right tools are selected such that they can be used in a sequence which allows the data to flow through successive transformations and to appear at the end in the form required [Vid89, Pap90]. With small numbers of tools this is relatively easy to do manually and the capability is really only required for large tool suites. However if the feedback information is added, it can be seen that even modest numbers of tools have the capability to produce a bewildering variety of possible routes (see Figure 8.1), and for large numbers it is likely that automatic aids will not just be useful, they will be necessary.
Partial designs
One common problem in design is that of evaluating partially completed designs for fitness for purpose. This is the whole purpose of producing trial designs since their functionality cannot be observed directly from the initial specification. This problem is related to feedback messages because often the feedback required is qualitative or semi-quantitative and the (incomplete) design is also semi-quantitative, but analysis tools invariably require complete numerical specification to operate. The classic example is the use of finite-element stress analysis tools for the conceptual design of load-bearing shapes.
If the type of information required from the evaluation at a particular point in the design process were formalized, it seems likely that it would be possible to have automatic management of when to use a detailed tool and when a qualitative, approximate tool would be adequate.
Artefact, process and people
The above description has implicitly assumed that the feedback messages are descriptions of features of, or evaluations of, artefacts. They are artefact-messages. These are useful in themselves, but formalizing them makes it possible to reason about how to manage the design process and thus there will also be strategic and tactical process-messages. Hierarchical decomposition of both artefact and design process has been prototyped in design environments for two-dimensional layouts [Coy89].
The only examples we have now of working multi-agent design systems with sophisticated interpretation of feedback information and commentary messages are human design teams. Thus the research into what constitutes a meaningful message and how it might be expressed should be able to make use of protocol studies of people doing design.
Material critics
One promising hypothesis, which has yet to be tested, is that large quantities of materials information would be more acceptable to practising designers if it could be made painlessly available by watchful software agents 'looking over the shoulder' of the designer working in a software environment [Bam89]. Designers require help with materials selection in the context of a particular design problem. One of the problems with the use of materials databases is that many engineers find it hard to identify the physical principles (and thus the merit indices) which determine materials choice.
The writing of materials information agents designed to operate in conjunction with materials information repositories is likely to be the primary means by which materials engineers will disseminate their knowledge to the rest of the engineering professions over the next few decades.
The history of materials data-intensive agents (databases) is a sorry one, due in no small part to the difficulty of transferring information. Developments of 'formats' and 'protocols' depend on wide acceptance by a number of independent laboratories with widely varying software sophistication. Many attempts have failed even though the technological developments were quite adequate. Thus the difficulty of providing practical materials agents should not be underestimated.
Materials information that would be useful in integrated design environments falls into two classes which require different treatments: well-behaved, stable properties and capricious properties. The differences have been shown in Chapter 3 to be a result of fundamental differences in the physics which determines the observable behaviour .
The well-behaved property information can be described in regular, simply-structured databases and tools using it can be based on straightforward classification. The representations can be simple and many different agents can use the same information. This indicates a potential for unrestricted growth in the number and complexity of agents. The drawback is that using only these properties restricts the designer to elementary mechanics problems.
The materials' process information is far less predictable: the materials' behaviour is highly variable with respect to small changes in composition or external conditions and its management requires both storing large quantities of idiosyncratic data and the use of complex software models of internal mechanisms.
The more superficial process information is theoretically susceptible to standard knowledge acquisition and representation techniques. Unfortunately the requirements for how the information is used in practice imply complete breadth of coverage (in some particular domain) which is expensive and time-consuming. Information derived from current knowledge acquisition techniques is difficult to use in any manner other than that for which the knowledge-based system was originally designed, which restricts the number of agents likely to be developed.
In Chapter 3 promising and less promising directions were identified for the development of software systems for predicting process properties. The problems that fall into the promising category are creep, stress-relaxation, forging, rolling, extrusion, some types of casting, welding, some types of wear, hot isostatic pressing and perhaps (because of the existing large quantity of measured data) some types of machining. Unfortunately, developing a new model for even just a slight variant on one of these processes is a significant piece of research (and usually results in a doctorate for the developer).
There are thousands of such processes so more general techniques which can be used effectively by less highly qualified staff must be developed.
Designed materials
In the late 1980s the idea began to gain acceptance that new materials could be designed, a technique quite distinct from merely designing with new materials [Ebe85]. The former requires that all relevant behaviours are explicitly numerically predictable, the latter merely requires that properties are consistent and can be measured.
The premise is basically flawed since, as we have seen, many material behaviours are intrinsically capricious. The exceptions are where:
Current research attempts to design structural materials from first principles involve large amounts of money with unfortunately few prospects of success because essential characteristics of materials information have been ignored. The difficulty is not one of producing such models for an immediate need but of producing models which are generally useful for a wide range of similar problems without significant extra development effort for each extension.
The slightly obscure classification of materials properties developed in this book is thus not just an academic exercise, it could give useful guidance to planning projects which involve the development of models of materials processes and properties.
We now have all the background necessary to advise how to construct a small materials information system.
First, a systems analysis of the organization and users of the proposed system should be sketched out, including the current data flows and responsibilities for data quality and integrity.
Second, the information it is proposed to store should be analysed in terms of the concepts required and their relationships. Working definitions of these concepts should be written down.
Third, data modelling techniques should be applied to the data to define and document the functional dependencies between the specific fields planned for the database. This will produce a database schema. This should be re-written as a data catalogue in a formal, probably multi-tabular, form along the lines of the IRDS proposal.
Fourth, a data thesaurus should be constructed, using the catalogue and concept analysis previously built, but containing information about relationships between items of data that are entered in the database. This will have to be maintained concurrently with populating the database but will be relatively simple to do if the earlier stages have been done diligently.
Fifth, new software in addition to the database management system, if any, should be written so that the data store communicates with the user interface and with any data manipulation procedures via a simply structured, text-based little language which is communicated via standard operating system mechanisms (temporary files, pipes, Microsoft DDE etc.). This is essential if the system is to be used effectively as a component of larger systems in the future. The little language should have a formally defined grammar.
Sixth, a management system consisting of people and their responsibilities must be established and resourced to maintain the quality of both the data content and the software for a specified lifetime or trial period. This is the requirement which is most critical but too often it is ignored.
Serious materials information systems of all types require continual maintenance even if the data they contain is intended to remain static.
In the area addressed by this chapter it is relatively easy to predict the future, albeit at a coarse level of detail, and the following is an attempt at the next 20 years. What makes such prediction possible is the very slow diffusion of software techniques from the research community into engineering practice. This is an area where a radical change in the software education of materials engineers could make significant difference.
Existing handbooks and data collections will continue to be computerized, reprocessed and further systematized. Research will continue to find more fundamental laws whereby some of the body of knowledge can be parameterized in more compact forms. The data will be increasingly available in normalized form where some incomplete theory is nevertheless able to indicate that, for example, it is the strength/stiffness ratio which is important for some behaviour rather than the absolute stress. Normalized data is generally more well-behaved; it is invariant over a greater number of materials than the raw data.
Database software used to store the information will become more sophisticated, with data dictionaries, schemata and catalogues. Plug-compatible data visualization technology will be used instead of the current situation where nearly every materials databank has its own hand-crafted user interface [Krö87a].
The software used to access this store of data will also become more sophisticated: browsing tools will access thesauri of terms and 1980s principles of user interface design will begin to be applied to the problem of providing context without confusion [Gra86, Wes89, Ben89, Hix89, Lau90].
Extensive concept modelling and data modelling will eventually produce standard interfaces at a level where the interpretation of data as materials information (rather than as numbers and symbols) becomes possible. This will mean that independent agents can at last become useful components of integrated design environments. There do not appear to be any short cuts.
Footnote