Introduction

One type of regular activity within COE is the work of Committees, such as those under the Development Planning Council (DPC). The DPC consists of committees within the following Process Groups: Product Life; Engineering; Ship, Plant, Fluid Systems; Digital Enterprise Infrastructure; Manufacturing; Advanced Planning. Each Process Group coordinates the work of several committees.

The primary DPC objective is to “assure that the CATIA users' needs for enhanced functionality are properly communicated to the Dassault Systemes developers.” There is a mechanism provided to submit Enhancement Requests (ER).

The purpose for this section of the NewsNet is to report on ERs and their status. DPC activity is voluntary and perhaps not as widely appreciated as it ought to be. Perhaps, these regular reports will elevate the attention level.

In this report, Knowledge Based Engineering is detailed as an activity under the Engineering Committee.

Knowledge Based Engineering
Brian Prasad, Ph.D., DPC-KBE Chair

Many companies are embracing Knowledge Based Engineering (KBE) as a path to capture their valuable IPs (intellectual properties), which are often very precious for making their company, more productive, more profitable, more responsive, and stay ahead of competitors in the world marketplace. Many such companies are leveraging the current KBE tools (e.g. DS/Knowledgeware) and KBE functionality of CATIA V5 to accomplish just that. They are capturing their “knowledge” into reusable KBE objects and applications.

Success of many such companies, however, depends not only on “how well engineers have internalize the use of the existing KBE tools” (Knowledgeware) but also “how closely they have aligned their developments to match with what’s being planned for the future in such KBE tools.”

Knowing the available functionalities in such tools helps KBE application developers build workarounds (temporarily) that could eventually be replaced one day by a more efficient tools/methods/processes -- when such capabilities become commonly available (in forthcoming CATIA/KW releases).

In order to better support you in this major KBE strategic pursuit, we would like to take this opportunity to explain the achievements already done in this area and to debrief you about our major enhancements in V5R16 regarding PLM Knowledgeware Solutions.

Enhancements analysis
If I had to summarize at a high level, what I understand of the difficulties that most developers face with their current implementation, I would like to classify those into 3 categories.

• Knowledge language enhancements
• Generative capabilities and relationships management
• Tools to analyze and understand a Knowledge execution

Because of the limited column space, I would be focusing on the first category at this time. In the forthcoming issues of NewsNet, we will be describing the remaining two.

The first category is related to Knowledgeware Language enhancement. I use this term to speak about the rule body language, not the generative scripting capability: with an associated objective of getting rid of some of the “workaround macros” that you ought to develop in order to make your application robust. The term “Robustness” is used here to indicate some of the desirable characteristics/ (programming features) that you ought to have when you are done with building your KBE applications. This is further explained in another News Article. “What Distinguishes KBE from Automation” or http://www.coe.org/newsnet/Jun05/knowledge.cfm#1.

I am very pleased to know that Dassault Systems have listened to our customers. They do agree with us that we need a “High level Generative KBE language.” As we speak today, they are working very hard to integrate this kind of language in a future V5 tool suite. You will be hearing more on this topic later.

They are also convinced that it would have a great value for our customers, if they could enhance our existing DS/Knowledgeware language to make it more “robust”. Some of the near-term objectives in this area are to provide a limited but powerful set of functionalities inside this language to achieve the manipulation and automation of V5 artifacts.

They are planning of delivering more access (in the Knowledgeware language) to manipulate the core V5 entities in a unified manner in future releases.

This is very similar to our objectives of simplicity when you built our applications. Likewise, they are also being driven by similar objectives of promoting a unified representation of objects, a unified way of accessing their characteristics (usage of GetAttributeXXX methods), and a unified way of propagating parameters across objects.

To accomplish those objectives, in V5R16 and subsequent releases of CATIA, they have added a list of brand new methods to access in a generic fashion the different V5 artifacts. Here is the non exhaustive list of what will be becoming feasible through the Knowledge language (for brevity sake, only new ones are mentioned here, there are many old ones that would continue to function as usual).

On any V5 object

• Feature->SetAttributeObject (attributeName: String, ObjectType) : Void
  • Writes the attribute “attributeName” of the object from a value or an object. Can be used for List objects...
• Feature->GetAttributeObject (attributeName: String) : UndefinedType
  • Reads the attribute “attributeName” of the object and returns an object. Can be used for List objects
• Feature.Children : List
  • Returns the list of direct children of the object (does not return values. Only objects). This attribute is Read only.
• Feature->Find (type: String, expression: String, upordow : Boolean ) UndefinedType
  • Finds an object that is either a children or a parent and that is of a given type, and fulfills a condition. It stops when it finds a first object. The last argument explains if we’re interested in the children or the fathers. As a consequence, it allows also to find easily some indirect father of an object
• Feature->Access (path: String, type : String) : UndefinedType
  • Returns an object of a given type from a path.
  • For example: “name1\name2\name3”: will get the feature or parameter that is found by going down in the hierarchy of features and finding the objects with the names name1, then name2, ...
• Feature->Update (): Void
  • Method that performs the update of a feature when it makes sense
  • Implemented in the next release on relation sets, parameter sets, rulebase, constraint satisfaction and optimizations. Will potentially be extended in the future to other objects.

On any V5 parameter

• Literal. Constant : Boolean
  • Reads or writes the constant attribute, which indicates if the value can be edited or not (equivalent to the constant property on a parameter)
• Literal. Show : Boolean
  • Reads or writes the show attribute, which indicates if the value is shown or hidden in the tree
• Literal. AuthorizedValues : List
  • Accesses the list of authorized values (aka Multiple Values for a parameter) in read and write mode

On List features

• List->Filter (type: string, expression: string): List
  • Extracts a sub list of all the elements of a given type that fulfill an expression
• List->Apply(type: String, expression: String): Void
  • Applies a given expression to all the objects of a list that are of a given type

On Design Table

• DesignTable.sheet.FilePath: String
  • Allows to replace the external file of a design table

As you can see, with these extensions of the language, we can write in a very small set of instructions for a complex operation.

For example: "Product->Query("RuleBase","")->Apply("RuleBase","x->Update())" operates a query from a product to access all the rulebases and it solves them.

In addition, there are a lot of other enhancements concerning BKT. And if I had to mention only one enhancement in the rest of the solution, I would mention the Knowledge Pattern which brings us closer to some well known KBE features (quantification in ICAD).

With these extensions, we won’t reach the high level KBE language of our dreams but we will probably cover most scenarios that consist in operating modifications on an existing structure. You’ve certainly noticed that all these operations still do not allow generating new features or constructs from the language… This leads us to the second topic

• Generative capabilities and relationships management
• Tools to analyze and understand a Knowledge execution

We will discuss those topics in the future issues of NewsNet.

Credits:

• Private Communications with Francois Riche, KBE Domain leader, Dassault Systems, France.
• Email Reply to My Request for Enhancements submitted to DS, July 2005.
• Email Communications, with others in DS KBE Development Group and KBE Focus Group, COE web site.
• Prasad, Brian, COE NewsNet, June 2005. "What Distinguishes KBE from Automation" http://www.coe.org/newsnet/Jun05/knowledge.cfm#1
• Private Communications with Task Force Members, KBE Best Practices, COE/DPC-KBE Committee, 2005-2006.