About the Know-how Apps Logic Engine

This topic explains how the KML engine works.

The Know-how Apps Logic editor can be seen as the "Buildtime" part of the KML solution. It describes static logics that will apply to all instances of a Concept. The "Runtime" part, aiming at applying these logics to the generated Objects, is the KML Engine. It is used when instantiating a KML Concept or Template. When instantiating a Concept using the standard command, the user triggers the engine which will always try to evaluate as much as it can. When stuck, it will detect what attributes are blocking further evaluation, ask you to valuate them manually and then go back to evaluation.

This page discusses:

Evaluators
Attributes Evaluation
Paths Evaluation
Objects Evaluation
Automatic Import of Features

Evaluators

To write efficient KML Libraries, it is mandatory to understand the evaluation mechanisms. The first step is to declare your Concepts and their structures (attributes/children). You can then define evaluators to specify how the Concepts you have declared will lead to the creation of objects. There are different kinds of evaluators:

External Rules

External rules are EKL functions defined at the library level. Their signatures will indicate what attributes they are an evaluator for.

Suppose you have defined a rule in your Library:

Add (a : Integer, b : Integer, c : Out Integer)
{
          c = a + b
}

Suppose you define the following Concept:

Concept MyAdditionnor : BaseConcept
{
               Object : VoidType;
               Attributes
               {
                        Inputs
                        {
                                Integer a;
                                Integer b;
                         }
                         Outputs
                         {
                                 Integer c;
                         }
                }
                Rules
                {
                          External Rules
                          {
                                  Add(a,b,c);
                           }      
                }
}

In this Library, the External Rule Add is seen as an evaluator for c and it requires a and b to be valuated and to be executed.

Local Rules

Local Rules are local to a Concept, they are analyzed to determine for which Attributes they are an evaluator.

Concept Factorial : BaseConcept
{
        Object : VoidType;
        Attributes
        {
                 Inputs
                 {
                         Integer n;
                 }
                 Outputs
                 {
                         Integer result;
                         Integer iterations;
                 }
         }
         Rules
         {
                  Rule
                  {
                          let i = 0
                          result = n
																										for i while i < n
                          {
                           result = result * n-1-i
                          }
                           iterations = i
                  }
         }
}

The local rule defined above is detected as an evaluator for result and iterations requiring n to be valuated to run.

Formulas

Formulas are local to an attribute in a concept.

Concept LogicalOr: BaseConcept
{
        Attributes
        {
                Inputs
                {
                        Boolean val1;
                        Boolean val2;
                }
                Outputs
                {
                         Boolean outVal = val1 OR val2;
                }
         }
}

This formula is detected as an evaluator for outVal requiring val1 and val2 to be valuated to run.

Constructors

Constructors are an alternative to a call to new() to instantiate a KML Concept child. They allow explicit evaluation of the attributes of the Concept whereas the inputs are given using the order in which the attributes were declared, when calling new.

Concept Bottle: BaseConcept
{
        Attributes
        {
                 Inputs
                 {
                        Length BottleHeight;
                 }
        }
        Children
        {
                  BottleBody body = {
                           Height = BottleHeight;
                           Diameter = 5cm;
                   }
         }
}

The constructor is an evaluator for the body child using BottleHeight as input.

Attributes Evaluation

When evaluating an Attribute the Engine works in a demand-driven manner, the Engine evaluates recursively Attributes until it can evaluate the one for which the value was required first.

Paths Evaluation

When dealing with Paths, the KML Engine evaluates the encountered elements one by one.

Suppose your Path is A\B\C\D called on Object "obj": The engine first asks for the value of the Child A on the Object obj (leading to an evaluation if A is not evaluated): It returns an object aChild. Then it asks for the value of the Child B on the object aChild (leading to an evaluation if B is not evaluated): It returns an object bChild.

Objects Evaluation

From the engine point of view, the goal is to completely evaluate all the created KML Objects. An object is considered as fully evaluated once its Attributes (including the concrete Object) and the Children are evaluated. A child is considered as fully evaluated if the object it references is fully evaluated. The engine will also consider any attribute or child explicitly set to NULL as evaluated.

When instantiating a KML Concept using the standard instantiation command, most of the evaluation is automatically done by the KML Engine. In some cases (in a rule), you may need to instantiate a KML Object and have it fully evaluated, this can be done by calling the Finalize method. This method calls the engine for full evaluation of the given object. Note that the method may not be able to fully evaluate the object if all the logical inputs are not valuated when it is called.

Note that you can use the new(typeName : String, instanceName : String, father : Object, [variable args]) function available in EKL to instantiate types implementing the Knowledge instantiation protocol. This function is widely used in a KML Library to instantiate Concepts, PLM Components or even Features. The Finalize() method is Specific to KML objects and calls the Evaluation of the Object.

When calling new for a KML Concept, several specific mechanisms are available:

Concept MyConceptWithInputs : BaseConcept
{
        Attributes
{
        Inputs
        {
               Integer a;
               Integer b;
}
Outputs
{
         Integer c = a+b
        }
}}

In this case, you can evaluate an object of type MyConceptWithInputs in one line using this mechanism:

let myObject(MyConceptWithInputs)
[…]
myObject = new(“MyConceptWithInputs”,”MyObjectName”,MyObjectOwner,5,10)

The new function will automatically valuate "a" with value 5 and "b" with value 10. The inputs order is identical to the declaration order.

Concept ConceptA: BaseConcept 
{
        Attributes
        {
                Inputs
                {
                         Integer attrA;
                         String attrB;
                }
         }
}

Concept ConceptB: ConceptA
{
        Attributes
        { 
                  Inputs
                  {
                        Angle attrC;
                  }
         }
}

In the above example, ConceptB has attrC as input but it also inherits attrA and attrB from its parent ConceptA. When calling new, if you want to value the inputs, enter the inputs of the father Concept, then the inputs from the instantiated Concept:

ConceptB myB = new(“ConceptB”,”myB”,myOwner,
1, /* attrA */
”stringForAttrB”, /* attrB */
90deg) /* attrC */

It will also detect that all inputs are evaluated for myObject and finalize it. This means that at the end of this statement myObject\c will have value 15.

Note: New functions have been added to enrich the Knowledge language.

Automatic Import of Features

This section discusses the import of features.

Suppose you define a Triangle Concept:

Concept KMLTriangle : BaseConcept
{
          Object : VPMRepReference;
          Inputs
          {
                    Point A;
                    Point B;
                    Point C;
          }
          [...]
}

To support this scenario, whenever the inputs of a concept are geometrical features and the concept’s object is a 3D Shape, the geometry will be automatically imported into the 3D Shape of the concept so that it can be used locally. The import is not performed if the selected object is already in the current object’s representation.