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