[rules-users] UseCase: Drools in Engineering

[Edson Tirelli]

   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 <list at incunabulum.de>

> 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
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>



-- 
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20080917/b23f386e/attachment.html