| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3.1 | Project Selling Risk Advisor | YIPPEE::FITZGIBBON | Joe Fitzgibbon EAITC Valbonne | Tue Sep 13 1988 17:21 | 138 |
|
A SWAS Projects Expert Selling Assistant
Product Acronym : RAD.
Product Name : Risk ADvisor.
Version : V1.0
Portfolio : SWAS.
Produced by : European A.I. Technology Centre,
Valbonne.
Current Status : Field Test in France and Germany,
moves into Operational use are
planned during FY89 for the
rest of Europe.
Goal.
Provide SWAS Project Selling "support expertise" on the desktop
of every Field Office in Europe thus supporting goals of;-
o Increased revenue on SWAS Project Sales.
o Improved focus of Selling activities in the Field
Offices.
o Provide effective decision support summary
information to District Management teams.
o Pro-active support for the approved "Selling
processes and Business strategic directions" as defined
by Management.
o Subsidiary/Country level facility to modify/enhance
the Knowledge Base thus enabling ease of adaption to
Business needs and evolution.
Description.
The Risk ADvisor (RAD) is a Decision Support Expert
System (DSES), produced by the European Artificial
Intelligence Technology Centre located in Valbonne
(France), for use in the European SWAS/SALES offices.
The purpose of this DSES is to provide an "on-line
expert assistant" to a SALES/SWAS person responsible
for the selling of SWAS projects to external (Non DEC)
Customers.
Output from RAD provides detailed Decision Support
information to the SALES/SWAS person AND Summary
information to the SWAS/SALES District management
team. In this fashion it supports the goal of
effective focus of available SWAS/SALES resources
around strategic business objectives.
The contents of the Knowledge Base represent the
combined inputs of three major European Subsidiaries
- France, Germany and UK. Once implemented the
Knowledge Base can be tailored to suit a particular
country style of operation and/or legal requirements;
this tailoring activity could also include textual
information/messages in local language.
The ongoing maintenance of the Knowledge Base, changes
to business practices and/or legal requirements are
managed by a responsible person in the Country level
operation, i.e. the Knowledge Base can be maintained
by a trained "Knowledge Base Administrator" (KBA)
without the need for intervention on the part of a
Technical Group. Approved changes to the Knowledge
Base, as made by the KBA, can be distributed via the
network (EASYNET) to SWAS/SALES field offices.
This Expert System makes use of the standard range of
DEC terminal equipment (VT100 upwards) and of the
normal VAX range of machines. The Knowledge Base
Administrators (KBA) facility (typically one per
country) requires VAXstation facilities.
Status as of - July 1988.
The expert system has received provisional acceptance
with final acceptance scheduled for October 1988, at
which point in time it will be moved into operational
use in SWAS/SALES offices in Europe. Current installations
are in France and Germany - which are the Field Test sites.
Documentation.
Installation and User Guide (Draft copy only. - final
copies available end of FY89/Q1)
Product Requirement Specs.
Project Development Plan.
Pre-Requisite Hardware
Knowledge Base Editor :- VS2000 upwards.
End-user Interface :- VAX Range of Machines with VT series
terminals.
Pre-requisite Software
VAX/VMS V4.6 Upwards.
EASE (Expert System Building Tool).
3.3.7 CURRENT STATUS.
OPERATIONAL.
|
| 3.2 | Benchmark Advisor | YIPPEE::FITZGIBBON | Joe Fitzgibbon EAITC Valbonne | Tue Sep 13 1988 17:21 | 141 |
|
A Benchmark Advisor Expert System
Product Acronym : BEAD
Product Name : BENCHMARK ADVISOR
Version : Internal Field Test V1.0.
Portfolio : European SWAS.
Produced by : European A.I. Technology Centre,
Valbonne.
Current Status : Internal Field Test.
Goal.
Sales and Technical expertise implemented in the
form of a "Desk-top" Expert System and made generally
available in Field Offices. This expertise will enable
SALES/SWAS Field Office staff to,-
o Respond in a consistent fashion to Customer
benchmark requests.
o Ensure that ALL the necessary information is
collected and presented to the benchmarking team.
Description.
The Benchmark Advisor system will support the
"process" which is currently in place to manage
benchmarking activity from the point where the request
is made by the customer through to the presentation
of the results to the customer. There are three
(3) fairly distinct phases to this process and the
BENCHMARK ADVISOR makes a contribution to each phase.
It is noted that Sales Account Management plays a
major role in the process and related expertise must
be incorporated into the system along with technical
benchmarking expertise.
Each phase of the Benchmarking Process is discussed
below and the contribution of the associated Benchmark
Advisor Module described in this context.
Screening activity.
-------------------
The sales situation surfaces the need for a Benchmark.
It is recognized that the motivation for such a
request is not always technical, but can be caused
by a number of sales / Account Mgt factors - some of
which can be addressed to the point where the request
for a benchmark is avoided or withdrawn. The SCREENING
activity acts as an expert assistant to sales account
management in this regard. It will also provide
assistance to the SWAS/SALES team in deciding if the
benchmark request should, in the final analysis, be
accepted or rejected (e.g. on the basis of the request
being symptomatic of some account problem which is
unrelated to system performance issues).
Technical Advice activity.
--------------------------
Following the decision by the SALES/SWAS team to
proceed with a benchmark - the request is passed to
a SWAS specialist for technical evaluation and project
planning. If a reference benchmark can be identified
during this exercise, it is possible that the customer
will accept these results and the benchmark exercise
can be avoided. It is always recommended that this
strategy always be considered as the first item of
the technical evaluation. If a reference cannot be
obtained, the technical evaluation should continue -
sizing the complexity of the benchmark, recommending
the technical approach and estimating manpower, time
and associated costs. The resulting report should
be used by the sales/SWAS team in deciding whether
to accept the benchmark or reject it on the basis
of low probability of success due to technical or
manpower reasons. The Benchmark Advisor TECHNICAL
ADVICE activity assists the SWAS specialist with the
above analysis, and provides Decision Support details
which will assist management with GO/NO-GO decisions
relating to the benchmark request.
Operational Guidelines.
-----------------------
Is concerned with setting up and the correct running
of the Benchmark, and the presentation of results
to the customer. This activity will highlight good
operational practices and will NOT be concerned with
providing Project Management support for the Benchmark
activity.
Current Status.
The current Internal Field Test V1.0 of the software has
been released to the E/ACT (Valbonne) Benchmarking Team
for Field Test implementation and administration.
Documentation.
Draft User Guide will be available October 1988.
Project Proposal.
Product Requirement Specs.
Project Development Plan.
Pre-Requisite Hardware
Knowledge Editor :- Vaxstation VS2000 upwards.
Desk-top end-user :- VT series terminals (N.B. Not PCs)
Pre-requisite Software
VAX/VMS V4.6 Upwards.
EASE (Expert System Building Tool).
|
| 3.3 | Network Diagnostics Assistant | YIPPEE::FITZGIBBON | Joe Fitzgibbon EAITC Valbonne | Tue Sep 13 1988 17:22 | 91 |
|
Network Diagnostics Assistant Expert System.
Product Acronym : NDA.
Product Name : Network Diagnostics Assistant.
Version : Prototype V1.1.
Portfolio : No Sponsor.
Produced by : European A.I. Technology Centre,
Valbonne.
Current Status : On indefinite hold due to Budget
cuts.
Goal.
o Enhance the DECNET knowledge of the Support Centre
Specialists.
o Provide an option for automatic fault diagnosis
and, when practical, corrective action.
o A basis for an "Intelligent Network Management"
tool.
o Preservation and distribution of DECNET diagnostic
expertise.
Description.
The current version conducts a dialogue with a
Specialist in order to determine the cause behind a
DECNET error as reported by VMS. Once the cause is
isolated the Expert System will provide the Specialist
with detailed guidelines indicating how the problem
can be resolved. The Prototype Expert System also
allows the Specialist to examine the reasoning path
taken by the Expert System.
The Expert System architecture demonstrated by the
Prototype can be interfaced to the Management layer of
DECNET, thus enabling the Expert System to directly
monitor and test the network configuration and
eventually make recommendations to the Specialist
on how to overcome the problems. It would also be
possible to allow the Expert System to intervene
directly, with or without a Specialists consent - as
the case may indicate, in order to effect corrective
adjustments to the network.
Predictive maintenance would also be practical,
particularly if a version of the Expert System was
installed on a DEC Service Module connected to a
Customer configuration.
Current Status.
This software is installed in three Field test
sites, Valbonne High Volume Group (Remote Diagnostic
Services), the Paris TSC and Valbonne Area 51 Network
management.
N.B. All activity has been suspended, - indefinitely,
- due to to FY89 Budget cuts!
The current prototype is on demo on the Telecoms Booth
of DECworld 88, and has also been demostrated on the
DEC booth at the Annual AAAI Conference in USA.
Pre-requisite Hardware.
VS range of Machines.
Pre-requisite Software.
VAX/VMS V4.7 upwards.
NEXPERT (Prototype only).
|
| 3.4 | Expert System Building Tool | YIPPEE::FITZGIBBON | Joe Fitzgibbon EAITC Valbonne | Tue Sep 13 1988 17:22 | 175 |
|
Decision Support Expert System Building Tool.
Product Acronym : EASE.
Product Name : Expert Advisor ShEll.
Version : V1.0.
Portfolio : European SWAS.
Produced by : European A.I. Technology Centre,
Valbonne.
Current Status : Operational.
Goal.
EASE was developed as Expert System Building Tool for
the SWAS funded project activities with the following
goals.-
o Provide a common set of software for use by
the SWAS Projects, thus reducing Engineering
development and maintenance costs.
o Support a need for maintenance and enhancement
of the Knowledge Base by Country level Business
Experts.
o Support integration into the VMS environment.
o make available a tool for use by SWAS and IS
Specialists for Expert System applications -
thus developing a Technology capability in those
functions.
o Support the distribution of Knowledge Base updates,
via the Network, to Field Office users of the
Expert System application.
Description
EASE is a tool designed to support the ease of
construction of Advisory Expert Systems for use in
the Business Decision Support space. These are Expert
System applications which provide on-line expertise
in a specific Business process, the current examples
being,-
o the Risk Advisor (RAD) which supports the "expert
selling" of SWAS Projects.
o the Benchmark Advisor (BEAD) which provides Sales
and technical expertise support to Field Office
staff who are expected to respond to Cusomter
requests for Benchmark activity.
o the Forecasting of "real Customer demand" for
Terminal Products.
Functional Overview.
The tool consists of two subsystems: A Workstation
based Knowledge Base editor which permits the building
and continued maintenance of a object-oriented
Knowledge Base system, and secondly a "End-user"
run-time environment, which uses the Knowledge Based
System constructed by the editor.
The "End-user" run-time environment has a simple
interface which allows the user to respond to
questions, and then inspect recommendations which
arise from the responses. Because of the architecture
of the system, the user may volunteer data as they
become available, and modify values as required. The
user may also find the collection of questions which
are causing a recommendation to be "true" be simply
causing the system to search back through the methods
in the network. Context sensitive help is available
at all stages, and "on-demand" printed output provides
management team Decision Support details and working
copy for the "end-user".
The EASE tool also provides facilities to allow a
trained User to maintain the Knowledge Base, i.e.
update the Knowledge Base to reflect changes in
Country Business practices, legal requirements, etc.
This same facility enables text to be modified to suit
local language needs. Updates to the Knowledge base
can be subsequently distributed, via the Network, to
the "End-users" of the Expert System application. The
existence of this facility enables maintenance of the
Knowledge Base to be placed in the hands of a Country
level User/Administrator, rather than depending on
some centrally located Technical Group to provide the
updates.
The Knowledge Editor also supports "embedded documentation"
(for Knowledge Base maintenance purposes) and on-line
Help file generation for the end-user expert system
application.
Technical Overview.
An application produced by EASE consists of a set
of objects linked together by "methods". "Methods"
describe how the values of the object are derived
from other objects in the system. These methods can be
calculations or logical expressions, or a combination
of both. Alternatively, values may be acquired from
the user by prompting or via calls to procedural
language routines (e.g. PASCAL or BASIC).
The editor permits the definition of objects which
will constitute the final system, and the definition
the methods in a form of data-flow language. These
definitions form a network of objects, which can
be viewed and expanded, thus making the incremental
addition, or modification of knowledge very simple.
The editor runs on a Vaxstation, making full use
of the multiple-window capabilities. The resulting
knowledge base is then employed by the run-time
system.
The architecture is open-ended, allowing Country
programmer written procedures to be inserted into
the system, - for example to perform database access
etc. Such procedures are linked as a shareable image
with "run-time linking" being performed by the Shell
software (i.e. It is not necessary to re-link the
run-time environment).
Documentation
Currently Available :
Draft copies (finished copies will be available in
October 1988) of the EASE Reference Manual.
EASE Technical Architecture
Prerequisite Hardware
For the Knowledge Editor :- Vaxstation 2000 upwards.
For the Run-Time :- VAX or microVAX, VT100 or later
Pre-requisite Software
VAX/VMS Version 4.5 or later.
QUINTUS or C-PROLOG.
VAX-C
SMG
Current Status.
Operational: - available for internal use.
|
| 3.5 | Call/Text Screening Expert. | YIPPEE::FITZGIBBON | Joe Fitzgibbon EAITC Valbonne | Tue Sep 13 1988 17:23 | 111 |
|
A Calls Screening Assistant for the TSC's.
Product Acronym : CSA.
Product Name : Call Screening Assistant.
Version : V1.0.
Portfolio : European Field Service.
Produced by : European A.I. Technology Group,
Valbonne.
Current Status : OPERATIONAL in Paris/TSC since
January 1988.
Goal.
Enhance the VAX Products knowledge of a Response
Specialist (i.e. the Telephone Operator) in the
Telephone Support Centres (TSCs) and enable them
to accurately route a Customer Call to the Support
Specialist with the appropriate set of expertise.
Description.
CSA is an Expert System which analyses and understands
a problem description which has been recorded on the
Call Handling application (CHAMP/TSC) by the Response
Specialist. The problem description is a free form
textual description, e.g. "How do I install GKS on a
VSII?".
The analysis results in the identification of the
Class of Specialist - or a Service Unit identity -
which has the expertise required to resolve the
problem. This identification permits accuracy of
onward routing of the Call to the Specialist, or Unit
location.
This Expert System has been embedded as a set of
callable routines into a existing, third generation,
product (CHAMP/TSC at the PARIS/TSC) with no
unacceptable performance overheads.
The facility includes a interface for use by a "User
Expert" who may,-
o set-up and modify the Knowledge Base to suit
the Call handling organisation within a
Country/District.
o verify the correct functioning of the facility, and
make any necessary adjustments.
o adapt the facility to handle the different national
languages.
o update the Knowledge Base to included new products,
or to adjust to organisation changes.
Current Status.
This product has been installed at the Paris TSC in
January 1988 and is since in daily operational use
with a typical call rate of 200 call per-day being
handle by an average of seven Telephone response
specialists (i.e. non-technical personnel). The
success rate is better than 87% of recorded calls
being correctly screened, the remaining calls normally
being outside of the scope defined for the expert
system.
The degree of user satisfaction with the product is
very high.
A version of this software, known as TSA, has been
made available, as a set of callable routines with
supporting documentation, for internal use elsewhere
within DIGITAL.
Documentation.
User Guide, Programmer Guide and Installation Guide.
(in VAX DOCUMENT format.)
Pre-requisite Hardware.
VAX Range of machines (Including VS).
Pre-requisite Software.
VAX/VMS V4.5 upwards.
PASCAL, SMG, SCAN.
|
| 3.6 | Computer Resources Capacity Planning ES. | YIPPEE::FITZGIBBON | Joe Fitzgibbon EAITC Valbonne | Wed Sep 14 1988 13:05 | 12 |
|
Capacity Planning Project start-up.
The European AITC has satrted a project for the development of a
Computer resources capacity Planning ES in co-operation with the
USA and GIA.
For more info hit SELECT to have the Capacity_planning conference
added to your list.
Joe.
|
| 3.7 | Mail Filter for ALL-IN-1 | YIPPEE::FITZGIBBON | Joe Fitzgibbon EAITC Valbonne | Fri Sep 16 1988 15:48 | 53 |
|
Project Name : Mail Skimmer
Project Status : Prototype (pre-phase 0)
Description:-
Production of a Prototype Mail Skimmer which can quickly be integrated
into ALL-IN-1 in order to obtain a better understanding of the User
Needs.
This is a joint venture between ESDC Galway (Pat Phelan and Niamh
Scannell), NSTC Valbonne(Tony Redmond), IOSG UK (Dave Matthews) and
European AI Technology Centre Valbonne (Serge Himbaut).
Details of the prototype can be had from Joe (YIPPEE::) Fitzgibbon.
Current status:-
Objective is to meet short term deliverables aimed at demonstrating the
possibilities, and providing a mechanism by which a better understanding
of user needs can be obtained.
ALL-IN-1 Interface:-
The details of this interface have been agreed between
Tony Redmond, Niamh Scannell and Serge Himbaut. The style
of this interface (i.e. the structure of the interface files
created and maintained by AI1) are a compromise between
percevied information needs of the Mail Sorter software and the
constraints imposed by the AI1 forms package.
It is understood that this interface mechanism can be improved
with later versions of AI1.
Mail Sorter:-
Module organisation has been defined. Niamh has been busy with
specification of Rules whilst Serge has started the production
of the prototype code in PASCAL.
Forecast:-
Progress is on target for the Mail Sorter software to be
made available to Tony for integration into AI1 on 18th
May.
Regards,
Joe.
|
| 3.8 | KBO's Project DFA | KBOV01::CAOXUAN | | Thu Jan 19 1989 12:37 | 243 |
|
Project: Expert system for Design for Assembly (DFA)
Location: KBO Kaufbeuren /Germany
Project Manager: Mach Caoxuan (KBOMFG::CAOXUAN)
Project Team : University Munich
University Darmstadt
( University Munich)
ABSTRACT:
Improving product designs for assemblability is an improtant goal of
manufacturing and should result in lower manufacturing cost.
In cooperation with Universities the KBO-AMT group has been working
in the area of DFA methodologies and applications, and in the development
expert systems for Design for manufacturability.
The subject of this report is to give a comprehensive overview of the work
on DFA project that has been performed during the FY88.
1. Introduction:
DFA is a technique to design products with ease of assembly in mind. By
applying DFA a product can be systematically designed to minimise the
technological and financial efforts required for assembly while remaining
within the constraints of tje product's functionality.
DFA procedures have traditionally relied on the use of a few general guidelines
to aid the designer in the two major areas of the subject: product assembly
and component feeding and orientating. Systems and Tools have been developed
that enable designers to measure the ease or difficulty with which components
can be handled and assembled. The main problem in using all these tools is
either thar their lack entirely in dealing with assembly problem, or that
their application is tedious, cost intensive and extremly time-consuming.
Moreover, the application of these tools does not guarantee success in every
case because most of the knowledge on DFA exist only as experience which
brings irreproducible results.
Contrary to these systems and tools, the design process with KBO-AMT's DFA
Expert System starts at the conceptual design stage where the structure of the
product as the whole is considered. Upon completion of the analysis and design
of the product structure, the system considers the invidual parts, insertion
and assembly processes .
In cooperation with University Munich (IFI) and Technische Hochschule
Darmstadt (EMK) the project was started in FY86. In the first project phase
EMK examined systematically the state of the art in design rules and pratical
knowledge available for designing products with high assemblability. The result
of this work is a Design for Assembly Catalogue. On the basis of this catalogue
a prototype for Product Structure Analysis in view of assembly were provided
by IFI.
Currently we are working on the development the second prototype called
" Expert System for Handling Analysis" . Besides a graphical DFA Examples
Library is also on development.
2. Objectives:
2.1 Tool for calculation of parts handling charactersitics
An important portion of all assembly operations ist the handling
(i.e. gripping, transportation, orientating, etc.) of assembly parts
Therefore handling oriented design as an integral part
of DFA is an essential precondition for an economic automation
of the assembly process .
The handling oriented design requires a detailed analysis of the
parts characteristics. Design rules can help to detect weak points
and to optimise the part with regard to its handling functions
Most of these design rules are closely related to the parts geometry.
Therefore to assess the "handlability" using an expert system it will
be necessary to decribe the parts shape to the system. To do this
entirely by means of an interactive dialogue will fail because of the
huge amount of data.
At Institute EMK an interfacing module for calculation of geometry
parameters is beeing developed, which will take over data from CAD
and make them "understandable" for the design rules within the
expert system .
2.2 Development a expert system for "design for assembly"
The aim of this period was to find out whether the knowledge on design for
assembly can be applied in a mechanized way utilizing artificial intelligence
techniques. This task should be carried out by analyzing and refining the
knowledge and developing a proper representation formalism for it.
2.2.1 Knowledge Acquisition
The first attempts to formalize the "catalog-knowledge" have shown that it
is based on a huge amount of implicit domain knowledge resp. fundamental
physical laws. The statements in the catalog had to be clarified and the
implicit knowledge made explicit. This task has been carried out in
collaboration with EMK and KBO-AMTduring intensive discussions and case
studies of several products.
To simplify the knowledge acquisition we are now working on the development
a object oriented representation system, which enables the DFA Expert
describing his domain knowledge hierarchically and expert system suitable.
2.2.2 Development of the Knowledge Representation Formalisms
Today knowledge representation is still an active area of research and there
exists no general approach suitable for every problem domain. So IFI had
to start with the development of an appropriate system. The basic idea is to
model physical or technical systems by components and aggregation of
components.
This approach has the advantage to be cognitive adequate and psychological
intuitive as it is based on the ideas engeneers have from systems they deal
with. Implementing this ideas we took an object-oriented approach with
hierarchical structures and inheritance mechanisms which combine different
ideas from already existing systems. The elements of this underlaying
knowledge representation are classes, attributes and instances.
Since the development of Smalltalk-80, LOOPS or Flavors, object-oriented
systems have become very popular and the notion of classes and instances
is well known. Classes are used to describe a set of similar objects, thus
defining the structure and behaviour of the objects, while instances of a
class represent the objects or individuals themselfs and hold the actual
information. The advantages are obvious. Insted of storing information
as an unstructured collection of facts (like in pure logic), all relevant
data can be grouped around conceptual entities.
Classes describe their instances by providing attributes for each property.
To reduce the amount of description a powerfull inheritance mechanism can be
used to specify that some objects are almost like other objects exept for
the differencies explicitly stated.
The so far described formalism for knowledge representation privides only a
basic layer upon which more sophisticated structures can be constructed.
4 main structures seem to be necessary to build up a knowledge base in a
technical domain:
- Components: are elementary objects of the real world; they are the basic
elements of our domain, e.g. assembly parts.
To describe a component it is necessary to specify its function
its interaction with other parts and its task in some greater
context.
- Aggregates: are composed objects, like assemblies or subassemblies.
In addition to the previous mentioned attributes for components
an aggregate must name the components of which it consits
and describe how they are connected.
- Concepts: are objects of the non-material world, e.g. methods or technical
terms. They can be described by specifying the involved objects
and the constraints they underlay. By defining subconcepts a
structured concept description on several levels of abstraction
is possible.
- Constraints: express relations between physical objects or properties,
e.g. physical laws.
To specify a constraint it will be necessary to state the
involved physical objects and the concept for which this
relations will hold.
Beside the taxonomical knowledge represented using the object oriented
mechanisms there exist a lot of heuristic or procedural knowledge.
Commonly used formalisms for representing this kind of knowledge are
the so called "rules" or "production rules".
A rule is a construct of the form
if <condition> then <action>
whereas <condition> is a description of a situation and <action> is a
conclusion or action to be performed if the situation occurs during the
reasoning process.
2.2.3 Prototype Expert System
Corresponding to the demands of the knowledge representation
formalisms a prototype expert system architecture has been developed
and its components implemented.
Because of the two explicitly distinguished kinds of knowledge -
taxonomical and heuristic - extra knowledge bases and reasoning tools for
both of them are necessary.
Knowledge Base(s)
The procedural part of the domain knowledge is beeing represented as rules
and facts - utilizing the self defined production rule format as well as
pure prolog rules.
The taxonomic or declarative knowledge is being represented as objects in
a class hierarchy. There are general descriptions for aggregates and
components (eg. screws, nuts, physical components in general, ...) as well
as concepts (eg. connection methods, ...) from which concrete instances
can be created.
For the maintenance of the class hierarchy and the instance-base an
object oriented knowledge representation system with multiple inheritance
mechanisms has been implemented. It offers various capabilities for
defining the class structure, the attributes and for creating instances.
In order to allow rule application upon objects there also exist some
attribute access functions.
Inference Engine
Rules can be interpreted using the standard prolog interpreter or the
production rule interpreter, which also utilizes a backward chaining
inference strategy. For the production rule interpreter a very simple
explanation facility has been implemented to allow "why"-questions upon
parameter requests of the interpreter.
The Concept Evaluator serves for evaluating resp. acquireing information
of the product descriptions according to the formation of concepts in the
class definitions. This component has not yet been implemented, so the
user has to give a complete product descripion in the beginning of the
consultation.
Product Description
The complete description of the product to be analysed is beeing represented
as a network of instances of the general class descriptions in the objects
knowledge base.
Intermediate Results
Facts inferred during the reasoning process which serve for further
inferences and explanation.
User Interface
Procedures for creating, changing, inspecting and saving the knowledge base
and product descriptions as well as communicating with the rule interpreter.
|