[rules-users] UseCase: Drools in Engineering
Mark Proctor
mproctor at codehaus.org
Wed Sep 17 17:54:04 EDT 2008
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 <list at incunabulum.de
> <mailto: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 <mailto: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 <http://www.jboss.com>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20080917/f6e13445/attachment.html
More information about the rules-users
mailing list