|
Welcome to the COE Discussion Forum!
|
|
|
|
To participate in the discussion forum, you must be logged in to the website. If you forget your login information, please contact COE Headquarters at coe@coe.org or (800) 263-2255.
If you are new to the COE Discussion Forum and would like to participate, please register.
|
|
| Forum Highlight: CATIA V6 |
|
|
 |
|
 |
| You are not authorized to post a reply.
|
|
| Author |
Messages |
|
COE-FORUM-USER
 |
| 20 Oct 2005 02:35 PM |
|
Dear COE forum members:
This message is aimed to disseminate the issuance of the “KBE services for PLM” Request For Proposal (RFP) that recently has been ready made by the Object Management Group standardisation body (OMG).
Through the efforts of the last months, a RFP to submit standards for KBE services in a PLM environment has been made ready within the OMG. This activity has involved in one hand the collection of the needs and viewpoints of several Product Life Cycle (PLM) and Knowledge-Based Engineering (KBE) systems users, vendors and researchers. On the other hand, the RFP has been satisfactorily assessed by the OMG’s Architecture Board as a valid requirement statement for a Model-Driven Architecture (MDA) standard.
The ultimate target of this activity is to facilitate the response to the convergence of KBE and PLM technologies as an important component for future product realisation technologies.
The RFP document can be accessed through:
http://www.omg.org/cgi-bin/doc?dtc/05-09-11
Background information on the RFP can be found in the Manufacturing Technology & Industrial Systems Task Force (ManTIS) website:
http://mantis.omg.org/
Once the RFP has been officially issued by the OMG, the next step consists in developing and submitting standard proposals. The standard coming out from this process will rely on the consistency and industry-supported MDA modelling approach. Consequently, it is expected that the resulting specification will benefit both the end users and vendors communities. Immediate benefits are listed below:
Benefits for PLM/KBE end users
- Enhanced interoperability between KBE platforms.
- Better management of the knowledge inside KBE applications through the PLM.
- More efficient deployment of KBE within organisations.
Benefits for PLM/KBE vendors
- Added value to PLM and KBE products.
- Reduced barriers to take up KBE.
- Increased market for PLM/KBE.
Once accepted, it becomes the international standard for that KBE and PLM users can achieve service integration independent of hardware and software platforms. At this early phase of KBE take-up, standards would reduce the fear barrier for end-user adoption of KBE and enhance the value of both KBE and PLM software offerings.
Both PLM and KBE vendors have the opportunity to influence the definition of the standard.
We would like at this point to ask for feedback response from the vendor and end user community participating in this mailing list. The idea is to figure out the perceived value of the RFP and the willingness to participate on activities towards the definition of the standard.
In order to facilitate the collection of your feedback about this activity we have prepared a questionnaire. The questionnaire can be downloaded from the following address:
http://www.omg.org/cgi-bin/doc?mantis/2005-10-01
It contains instructions on how to fill it up, but I insist on asking not to hesitate to contact me in case any additional information is needed.
Best regards
______________________________
Pablo Bermell-Garcia
Department of Enterprise Integration
Cranfield University
Bedford, United Kingdom,
MK430AL
p.bermell@cranfield.ac.uk
|
|
|
|
|
JMSWTLK
|
| 23 Oct 2005 12:33 PM |
|
I took this post by Pablo about PLM/KBE as great news.
Everyone interested in KBE and PLM ought to thoroughly look at Pablo's coverage of the issues. I hope that they get a lot of feedback. I plan to submit some.
http://www.omg.org/cgi-bin/doc?mantis/2005-10-01
In the meantime, I’m writing this note for several reasons. One of them is that PLM deals with an entirely different domain than CAX, from a certain perspective. This needs some discussion, it’s my opinion.
At the recent COE Aerospace, KBE was an almost ever-present topic. I liked seeing that since I've been doing knowledge (AI) type of work since the early 80s (hence, the Lisp reference) and see KBE as evidence of a certain type of intelligence.
But, there really has been no cohesive theory worked out (that I know of) for KBE (or knowledge for that matter). Perhaps, the KBE work with its close mapping with 'real' entities might be just the vehicle that we need to get the incoherencies reduced (I didn't say eliminated).
At COE, I particularly enjoyed a presentation by Cirrus Shakeri and Pierre Pinard of Dassault Systemes. In brief, the important point was that the CATIA v5 KBE suite can be laid out somewhat like the below, in terms of movement from the more detailed/specialized to the more abstract/generalized (excuse my use of the acronyms).
detailed/specialized <---------------------> abstract/generalized
KWE/KWI/KWA/PEO -------- BKT/BK2 -------- PFD/PFO
Now, if you'll bear with me for the moment, at the same time we can think in a similar fashion about the languages being discussed in the context of KBE.
CAA/RADE ------------------- VBA --------------- KBE
There are two ways that we could look at the axis: 1) left to right denotes greater problem solving power or 2) left to right means less involvement with details of the machine.
Much of the discussion about KBE, in my mind, is getting too much hung around the specifics of computing and is dealing with things that ought to be hidden (unless we need to see them). Problem solving power comes via specialization within a domain where the general view is of little concern and for the most part weak.
From a certain view, it is easier to morph from the specific to the general than it is operate the other way. We all have experienced this in our maturing process as humans.
So, what KBE can bring to the table is this: problem solving assistance within a specific domain. As such, KBE is much more than Automation. Actually, ‘specific’ and ‘general’ ought to have little letters, since in the recurrent/iterative characteristics of things, one framework/paradigm/viewpoint’s ‘specific’ may be another’s ‘general.’
Now (here is another point) what we need to think about in terms of PLM is that it is not an abstraction of CAX. What I mean by that is that some might want to put CAX on the left and PLM on the right in the above axis.
That’s not true, though.
Rather what we have are two sub-domains that overlap. Many of the specifics of CAX ought to be (and are) hidden from certain views of PLM. Certain PLM concerns are not directly related to some CAX decisions.
In this regard, PFD/PFO can be used in the CAX context as much as they can be used within PLM. And, what’s termed KWE (etc.) could be applied at the PLM level as well as at the CAX.
Finally, where many might be spinning their wheels with the languages (see above), perhaps they ought to be looking at how they can exploit the growing maturity of the KBE suite.
|
|
john.m.switlik@ieee.org
316-204-0758
http://en.wikipedia.org/wiki/User:JMSwtlk |
|
|
|
| You are not authorized to post a reply. |
|
|
|
ActiveForums 3.6
|
|
|
|