Wednesday, September 17, 2008

Improving the Naval engineering process using Drools ( Michael Zimmermann )

Michael Zimmermann, from Rostock University, has emailed us an overview with findings for his Phd thesis on helping to improve the navel engineering process using Drools. The thesis title is "Knowledge based design patterns for detailed steel structural design".

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!).
  • 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!
    1. The Smooks binding could be a godsend for this
    2. 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.
University of Rostock, http://www.uni-rostock.de
Chair of Naval Architecture, http://www.schiffbauforschung.de
Contact: michael.zimmermann at uni-rostock.de

8 comments:

  1. I'm curious to hear some example of open world vs closed world logic. I've encountered similar issues in financial software.

    Eclipse eCore the specification is decent, but the UI is rather ugly and user unfriendly. Back when I worked for IBM Ascential, we had a product called metadata server that used UML -> ecore -> tables + classes approach. In many ways, it provided ontology capabilities with lots of other features like build in versioning, model analysis, change impact analysis and data migration.

    ReplyDelete
  2. "Better support for constraint programming"
    Drools solver's heuristic solving (tabu search, ...) is indeed overkill in such cases, but Drools (Solver) should also support deterministic solving.

    In any case, the "score calculation constraint rules" should be standardized, independently of the solving type, so they can be reused.

    In the ITC2007 examples I've done deterministic solving before starting heuristic solving, based on the same score constraint rules drl, which saved me a lot of time. Unfortunately I haven't taught about or worked on extracting a deterministic solver... yet. Idea's and code are welcome :)

    ReplyDelete
  3. @woofel: Have a look a the following rule:

    rule "MyRule"
    when
    SomePart( $hasFeature : feature)
    OtherPart (requiresFeature == $hasFeature)
    then
    ....
    end

    So, under closed world conditions this rule only fires iff there is a feature definition in SomePart that is identical with the requiresFeature of OtherPart.

    In our case, what we needed was something like: fire rule iff either there is no feature definition or there is a feature definition on SomePart that is identical with requiresFeature of OtherPart

    With such an approach optional constraints can be handled more easily.

    And yes, I know that does not follow the open world assumption 100% as the following case does not fire the rule: iff there is a feature definition on SomePart that is not (!) identical with requiresFeature of OtherPart. But as we make heavy use of functional properties and do not assume, that two different objects can be identical, this was never required.

    Regarding your comments about eCore, I fully agree. The Ascential metadata server sounds interesting, though.

    @Geoffrey, are you willing to share the score constraint rules? Our implementation shows it's age and the multiple development stages

    ReplyDelete
  4. thanks for providing an example. That makes sense to me. You probably considered this, but just in case for the sake of discussion.

    One approach to solving this is to use a high level rule language and compile iff either there is no feature definition or there is a feature definition on SomePart that is identical with requiresFeature of OtherPart that down to 2 rules. Clearly, that doesn't begin to address Open World assumptions, but it "simulates" the functionality.

    I've explored this topic a bit in the past with the ruleml guys. Proper support for open world assumptions is quite complex on every level. I know Mindbox CBR provides this type of functionality in the past and there are existing deployments.

    On an academic point, even if we can capture the domain in a knowledgebase, it still doesn't solve the open world issue. I'm sure others will disagree, but classic prolog backward chaining is better suited to open world assumption problems.

    Simulating it in a Rete rule engine only goes so far.

    ReplyDelete
  5. @woofel, I agree that proper open world support is a pretty complex topic. In our case, due to the basic assumptions inherent in our data model, two objects are never identical. This reduces the problem quite a bit :)

    Regarding "meta rule" systems and a compiled real rule base: this might be an option yet we wanted to keep complexity down a bit so that engineers with training can handle it. Also, we are aware, that testing independent multiple facts or conditions in a single rule does violate some principles of rule design yet make the rule design easier.

    Regarding prolog backward chaining: Yes, for this case it would make more sense. Yet, as only some of the rules are of this type, we would either deal with two different rule systems or some prolog style system for everything. Here, again, usability by non prolog experts would be next to impossible. And imho prolog is something not easy to grasp.

    ReplyDelete
  6. I agree. Understanding and using prolog backward chaining effectively does come with a gigantic learning curve. For a real project with deadlines, it's impractical.

    the high level rule approach does add complexity, so it's definitely not a general purpose solution. Having done it a few times, it's not a trivial exercise. The initial cost of creating the high level rule language and rule compiler is high, but once it's in place, it can reduce the learning curve for the end user.

    ReplyDelete
  7. "@Geoffrey, are you willing to share the score constraint rules? Our implementation shows it's age and the multiple development stages"

    My score rules are part of the examples of drools solver and are included in the drools source zip.
    Here are some direct links:

    http://fisheye.jboss.org/browse/JBossRules/trunk/drools-solver/drools-solver-examples/src/main/resources/org/drools/solver/examples/itc2007/examination/solver/examinationScoreRules.drl?r=trunk

    http://fisheye.jboss.org/browse/JBossRules/trunk/drools-solver/drools-solver-examples/src/main/resources/org/drools/solver/examples/itc2007/curriculumcourse/solver/curriculumCourseScoreRules.drl?r=trunk

    I'd love to discuss some ideas on standardization of score calculation. What would you change those score drl's?

    I 'll probably introduce an immutable Score object and maybe remove or limit the responsibility of the ScoreCalculator soon. That will enable some new features.

    ReplyDelete
  8. Geoffrey, our implementation is at least 2 years old and therefore from the "before drools-solver"-time. And it is grown over time, therefore in dire need of an overhaul.

    I will study your drls next week or so and come back to you if I have any idas.

    ReplyDelete