Ops, someone was faster than me! :) Glad to see it in the blog! Edson
2008/9/17 Edson Tirelli <[EMAIL PROTECTED]> > > 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]> > > 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] >> https://lists.jboss.org/mailman/listinfo/rules-users >> > > > > -- > Edson Tirelli > JBoss Drools Core Development > JBoss, a division of Red Hat @ www.jboss.com > -- Edson Tirelli JBoss Drools Core Development JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
