Proceedings of the 8th International Conference on Intellectual ...

Marko Anzelak et al.
72% recognise <strong>the</strong> benefits <strong>of</strong> simply using a commercially available drawing management
system.
These results produced <strong>the</strong> following key questions:
Which drawings exist? A design engineer knows his or her own drawings, but may only know a
few <strong>of</strong> those created by colleagues. If an organisation is subdivided into design groups, <strong>the</strong> same
also applies to <strong>the</strong> group level, though <strong>the</strong>re is less knowledge <strong>of</strong> drawings outside <strong>the</strong> group than
is <strong>the</strong> case for individuals − this is because queries and issues can be resolved within <strong>the</strong> group.
To gain an overview <strong>of</strong> all <strong>the</strong> drawings within one organisation, appropriate search options must
be available, as <strong>the</strong>re is not sufficient time to manually search through all <strong>the</strong> drawings. Therefore,
<strong>the</strong> option to search for a drawing by keyword or by defined pattern must be made available.
How do I find a solution to an issue I have with a drawing? A design <strong>of</strong>ten gives rise to similar
questions about <strong>the</strong> best way to solve a problem. In many cases it is only possible to assess <strong>the</strong>
best possible solution to a problem in retrospect, once a prototype has been constructed based
on <strong>the</strong> drawing. The problems can also be similar across different departments, even if <strong>the</strong>
departments’ work focuses on entirely different areas. Never<strong>the</strong>less, <strong>the</strong> design for a rotating
mechanism, for example, will still be similar. The design engineer entrusted with <strong>the</strong> task <strong>of</strong>
designing a rotating mechanism now has to consider which drawings include this kind <strong>of</strong> element.
A rotating mechanism consists <strong>of</strong> several elements, and is <strong>the</strong>refore not considered as a single
part, but as a component group. A component group is usually viewed as physically linked
components, and only rarely represents a number <strong>of</strong> logically linked components. Consequently,
<strong>the</strong> content <strong>of</strong> <strong>the</strong> drawing must be described in a certain way in order to facilitate a
corresponding search.
What is <strong>the</strong> most efficient way to design a new drawing? No one wishes to reinvent <strong>the</strong> wheel,
especially when an appropriate solution already exists. The fastest route leads via existing
drawings and <strong>the</strong>ir underlying design ideas. Unfortunately, <strong>the</strong>se can hardly ever be deduced
from <strong>the</strong> title <strong>of</strong> <strong>the</strong> drawing. In order to be able to search using <strong>the</strong>se criteria, this information
must somehow be stored toge<strong>the</strong>r with <strong>the</strong> drawing. Attaching keywords to <strong>the</strong> function or
purpose <strong>of</strong> a drawing can be done in a structured manner, however a design idea can surely only
be formulated in free text. This type <strong>of</strong> text is problematic for search functions, and would have to
be supported with a semantic search function.
Which types <strong>of</strong> documentation are relevant for my drawing? There are production rules,
operational rules, procedural instructions and fur<strong>the</strong>r guidelines. Which documents are relevant
for <strong>the</strong> new drawing? Have <strong>the</strong> guidelines changed, and is my knowledge up to date?
Who else has encountered a similar problem and managed to find a solution? There are usually
several ways to solve a problem. In order to avoid having to try every single option, it would be
helpful if one could ask someone who has solved this type <strong>of</strong> problem in <strong>the</strong> past. This leads to
<strong>the</strong> question <strong>of</strong> how to find such a person. It is virtually impossible that a person will provide a
comprehensive description <strong>of</strong> all his or her knowledge, so that this information can be searched
for. It should be easier to find a way using <strong>the</strong> created drawings. The designer <strong>of</strong> a new drawing is
required to expend more effort in describing <strong>the</strong> drawing, but <strong>the</strong> overall time consumption will be
lower.
Using this as a starting point, we defined relevant objectives and divided <strong>the</strong> implementation into two
phases.
4. Design engineers objectives
The main objective <strong>of</strong> <strong>the</strong> construction element database is to support <strong>the</strong> design engineers in <strong>the</strong>ir
daily work. This is achieved, firstly, by ensuring that <strong>the</strong> knowledge about existing drawings increases
and secondly, by improving <strong>the</strong> quality <strong>of</strong> <strong>the</strong> information about <strong>the</strong> drawings. Thirdly, <strong>the</strong> design <strong>of</strong>
new drawings, which are based on existing drawings, will be accelerated, and fourthly, all required
documents would be available at a glance. Finally, communication between <strong>the</strong> design engineers is
facilitated.
In order to meet <strong>the</strong>se objectives we decided to implement <strong>the</strong> construction element database with
our own s<strong>of</strong>tware, as <strong>the</strong> ERP proved not to be flexible enough, its operation proved too complicated
and <strong>the</strong> permission management may have prevented access. It is intended that <strong>the</strong> designer has one
access point, from which he or she can quickly retrieve all information about <strong>the</strong> drawings as well as
<strong>the</strong> drawings <strong>the</strong>mselves.
47