1. Using OWL 2 For Product Modeling David Leal Caesar Systems April 2009 Henson Graves Lockheed Martin Aeronautics

2. Why Use OWL For Product Modeling  There are several good standards based product modeling languages  SysML - does not have a formal semantics  ISO 10303 – does not have a formal semantics  ISO 15926-2 – uses set theory semantics, but with only limited definition constructions  OWL is a general purpose modeling language  Has a formal mathematical semantics  Provide class definition constructions  Has well developed automated reasoning tools

3. Formal Semantics Is Needed To  Communicate product descriptions without the intermediary of a subject matter expert  Provide framework for answering questions and justifying results  Are requirements consistent?  Does the design satisfy the requirements?  Can the design be implemented?  Does design satisfy evaluation criteria?  Provides a framework for analysis and justification of conclusions  Particular important when multiple languages are used

4. We Are Using OWL To Represent Product Models and Reasoners To Verify Model Relationships  Formal definitions have been created for:  A conceptual design specification;  A detailed design which specializes the specification;  An individual which is a realisation of a design.  An OWL reasoner (Pellet) has been used to infer that:  the detailed design specializes the conceptual design;  an individual assembly is an implementation of a design.  We have also manually proved properties of the design which ensure that the implementations have the same parts structure. This result requires a particular, but not contrived, approach to recording a formal definition.

5. We Started With The Informal Design Concept Of a Widget  It consists of a widget base plate and two widget brackets.  Each widget bracket is connected to the base plate.  One widget bracket has a position which is a member of “Widget Left Bracket Position With Tolerance”.  The other widget bracket has a position which is a member of “Widget Right Bracket Position With Tolerance”. Widget Concept A thing is a widget, if and only if: These necessary and sufficient conditions can be stated formally.

6. We Can View The Widget Design Concept As a Graph Widget WidgetLeftBracketWidgetRightBracket WidgetBasePlateConenctedToBrackets one-to-one hasPart / partOf function one-to-one connectedTo function WidgetBasePlate WidgetBracket some right bracket position some left bracket position subclassOf

7. OWL Provides Constructions To Express Class Definitions  Sufficient, as well as, necessary conditions for describing classes  For example  to specify that if something is a bracket, is connected to the BasePlate Has a position on the left side  Then it is a left bracket LeftBracket

8. The Concept Can Be Represented In OWL As a Knowledge Base (KB) ( hasPart exactly 1 WidgetLeftBracket) and ( hasPart exactly 1 WidgetRightBracket) and ( hasPart exactly 1 WidgetBasePlateConnectedToBrackets) Widget = WidgetBracket and ( connectedTo exactly 1 WidgetBasePlate) and ( hasPosition some WidgetLeftBracketPositionWithTolerance) WidgetLeftBracket = WidgetBasePlate and ( connectedTo exactly 1 WidgetLeftBracket) and ( connectedTo exactly 1 WidgetRightBracket) WidgetBasePlateConnectedToBrackets = etc.

9. OWL Has Much Of The Expressiveness Needed For Modeling Products Constructions Names a, b, p312 A, B, C classes R, P, Q roles X, Y, Z data types k number Class constructions A AND B, A OR B, Not A R some A R exactly k A R any A R Q Value k Role constructions RoP Trans(R) Properties A SubClassOf B R SubClassOf Q A EQ B p3 : A (a,b) : R Card (A) = k Function (R) The syntax is a modified Manchester Syntax for OWL 2

10. A Widget Assembly  It consists of the parts WB-2345, WB-2346 and WBP-3456.  WBP-3456 is connected to WB-2345 and Wb2346.  WB-2345 has some right position.  WB-2346 has some left position. An individual widget The thing with serial W-123 is as follows: These facts can be stated formally.

11. Does The Assembly Realize The Design?  WB-2345 and WB-2346 are instances of WidgetBasePlateConnectedToBrackets.  WBP-3456 is an instance of WidgetBasePlateConnectedToBrackets.  Position LBP-123 is within WidgetLeftBracket.  Position RBP-123 is within WidgetRightBracket. An individual widget It is known that: Can it be inferred that W-123 is a member of Widget? Yes, validated by the Pellet reasoner

12. For The Widget KB To Serve As a Detailed Design We Need We can manually verify that Any implementation (model) of Widget KB has exactly 3 individual parts and has a connected, directed graph structure Since we know what the implementations look like, we can answer the questions as well as summing the weights, etc.

13. However Representing Detailed Designs Stretches OWL Capability  A detailed design serves as a template for implementations  Used to calculate weight, center of gravity, stress loads, etc  For an OWL design KB to serve as a detailed design it needs to  determine the parts required, connectivity, positioning of parts, design instruction sequence  Rule out non-intended implementations, E.g., extra parts and connections  In general we believe that OWL needs some additional class and role properties  E.g., an edge property for roles, that guarantees roles can be used to form a directed graph

14. The Approach Of Using Edge Relations Is Similar To Description Graph Extension For OWL 2 Design Diagram Vehicle Engine Fuel System Frame PumpTank[1] Tank[2] Atomic classes: Vehicle, Engine, Frame, FuelSystem, Tank[1], Tank[2], Pump, … Atomic relations: haspart, is-connected-to FuelSystem-haspart-Tank, FuelSystem-connectedto-Pump Axioms: Vehicle SubClassof haspart some Engine Engine is-connected-to FuelSystem Engine is-connected-to Tank Design KB Which has also been used to rule out unintended interpretations

15.  A graphical syntax (use SysML block diagram)  Additional role properties  E.g., Edge(R)  Function terms calculus  E.g., represent weight (widget) = sum weights of parts  Behavior representation  E.g., state change Enhancement To OWL Needed For Product Modeling Include The objective is to find an extension to OWL that allows us to specify structural graphs without destroying the computational complexity properties of OWL

16. Conclusions  Need unification of current PMLs since none have all features needed  Strong case for PML with mathematical semantics  Experience with OWL indicates  Has learning curve  Extensions needed