Already published it for him :) Michael if you think you'll end up
wanting to publish a number of blogs we can add you as a guest writer.
Mark
Edson Tirelli wrote:
Michael,
Really interesting use case.
Thank you for sharing!!
In case you are interested in publishing an article on the Drools
blog as a guest writer, it would be more than welcome!
I completely agree with your suggestions on improvements. We just
need to find the time to work on them!
Cheers,
Edson
2008/9/17 Michael Zimmermann <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
HI Edson,
while discussing custom operators in drools trunk, you pocked me
repeatedly to write something about how we use drools in a research
project in the field of engineering. Here you go... may be it is also
helpful or at least interesting for the other readers on this list :-)
The Scope: Naval Engineering,
In naval engineering vessels consists of thousands of parts (read: way
more than an aircraft has today). Focusing on the steel structure,
most
of these parts are 2-dimensional plates of a certain size, thickness,
grade and contour. For most fields of applications detailed
regulations
from classification societies etc. exist.
Currently, the design of such objects is done using specialized CAD
systems. Here the following issues are present in all cad systems and
the design process today:
- design time is 6 - 18 months (and not 10 - 15 years as for an
air plane)
- this means concurrent design, i. e. different people are working on
parts or features that are closely related (strength, fatigue, cost,
functional aspects or just being in the same room) on different levels
of granularity (changing the hull 6 weeks before building happens!)
- and no connection between design intent (specification on paper),
design conditions (regulations, by the customer, results of
calculations) and design solution chosen.
Result:
- We just have the geometrical data, nothing more in the CAD-model
- No automatic checks if a certain component is changed; no automatic
tests if a chosen design solutions really satisfies the conditions at
lowest cost today
- Therefore, changes (which you can't avoid) are cost intensive and
error prone. Also, no one really knows why a certain solutions was
chosen
Enter Logic & Drools
The objective of our research is to make the design process context
aware. Example: If I design a "door" in a watertight "wall" the cad
system should check whether the selected door is a watertight model.
So, using one of the most popular commercial cad systems for naval
engineering the approach is to define the standards (currently
paper-based) electronically using DROOLS. Also, context-information
like watertight, stress level=x ... is added to the model and
reused in
the design process. For standard design tasks (in a part of the
field of
detailed steel structural design) we use drools to completely automate
the design process, i. e.
- find a design problem in the model
- select a suitable solution adhering to all known boundary conditions
- design the solution
- and assign a assurance level for the solution (how good is it?)
Lessons Learnt from an Engineering POV
1) Extracting the knowledge is hard
2) Formulating it logically sound even harder (even official
regulations
are vague on a regular basis)
3) Defining the context a solution is valid for is even more
difficult.
4) Current CAD systems in naval engineering are not really capable to
store meta information and to interface with other applications.
Lessons Learnt from a Drools POV
1) Drools is quite a nice system :-)
2) With DSL even engineers can use it (once they are trained how to
"Think Rules". And that is next to impossible)
3) What's missing is some solution to easily define classes, class
hierarchies and (!) instance data. We use OWL for now. eCore might be
usable yet is terrible from a UI usability perspective
4) Not drools is the problem but getting the data in and out!
4a) The Smooks binding could be a godsend for this
4b) Fact templates sound really promising if you think dynamically
generated classes via web services...
What's missing in Drools?
- An OWL/RDF binding would be really great (we use OWL to define,
edit,
store our standards. But encountered the clash of open world logic
(DL)
and closed world logic (CS) more than once.) I know there is quite a
large interest for such a solution in the Ontology user base.
- Better support for constraint programming (what we do here and
there)
for simple primitive cases (read: selection processes) would help.
Drools solver is overkill; drools rules can not handle this if you
think
optional constraints. The custom operator "== (open world style)" we
talked about helps, though.
Well, it has gotten longer than I expected yet only skimmed the
surface
of our approach, I think. Hopefully not to long :-)
cu, Michael
_______________________________________________
rules-users mailing list
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com <http://www.jboss.com>
------------------------------------------------------------------------
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
