UseCase: Drools in Engineering

[incunabulum]

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

[Mark Proctor]

Michael Zimmermann wrote:

> 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...
>  

Drools trunk now hows JAXB model suport, where it can generate the model
from an XSD and bind with JAXB. We also support smooks data binding.
> 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.
>  
This is something I'd like to see happen too, just haven't had the time
to research it yet.

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

_______________________________________________
rules-users mailing list
rules-users@...
https://lists.jboss.org/mailman/listinfo/rules-users

[Edson Tirelli-3]

   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@...>

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

--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com

_______________________________________________
rules-users mailing list
rules-users@...
https://lists.jboss.org/mailman/listinfo/rules-users

[Edson Tirelli-3]

   Ops, someone was faster than me! :) Glad to see it in the blog!

   Edson

2008/9/17 Edson Tirelli <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@...>

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

[Mark Proctor]

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@...>

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

--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com

_______________________________________________
rules-users mailing list
rules-users@...
https://lists.jboss.org/mailman/listinfo/rules-users
  

_______________________________________________
rules-users mailing list
rules-users@...
https://lists.jboss.org/mailman/listinfo/rules-users