AP scope  |  AP module  |  AP contents  |  AP index
Application module: Analysis identification ISO/WD 10303-1476

Cover page
Table of contents
Copyright
Foreword
Introduction
1 Scope
2 Normative references
3 Terms, definitions and abbreviations

4 Information requirements
   4.1 Required AM ARMs
   4.2 ARM entity definitions
5 Module interpreted model
   5.1 Mapping specification
   5.2 MIM EXPRESS short listing

A MIM short names
B Information object registration
C ARM EXPRESS-G   EXPRESS-G
D MIM EXPRESS-G   EXPRESS-G
E Computer interpretable listings
F Application module implementation and usage guide
Bibliography
Index

Annex F
(informative)

Application module implementation and usage guide

This annex provides a rather random collection of notes associated with the both the creation of an analysis capability within STEP and its associated application. The purpose is to provide a single placeholder for various emails of significance that where not widely distributed and will soon be lost in our large email archive boxes.

Systems Engineering Analysis Support for Decision Making
  1. Provide hyperlink to the file "AP233 Decision_analysis(1).pdf" given to Phil in Hangzhou
  2. Provide hyperlink to followup document with abstracts for all figues, definitions for all semantics used and key to the mapping to OWL via Protege "Decision_making16.pdf"
  3. To-be-done Cross check content of this document with content of this and companion schemas
Original note from Keith Hunten (base defined):

Here is something to start on. I have yanked the pertinent information from AP209E1 and copied it here. http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/analysis/Analysis_Identification_Module_Input.doc?rev=1.1. Take a look and see what you think and get back to me. There definitely needs to be some more work done on this - see my comments in the ARM EXPRESS for E2 section.

More guidance from Keith (Thu, 05 Jan 2006)

Now that we are starting to talk about integration of specific types of analyses please cast a look at the attached Part 53 document. This part evolved from the European GEM program, and then it was integrated along with the CGNS computational fluid dynamics work into the STEP IRs. In the (now aborted) AP237 work this part was used to integrate the CFD analysis to the structure we have just been working on.

The intent is for Part 53 http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/analysis/WG12N2170_Part_53_Document.pdf?rev=1.1. to serve as the basis for integrating multiple disciplines together - so our next step needs to be looking at putting together an ARM for these concepts. Of course we can take the typical current approach of just re-casting it as an ARM

Please look at the Part 53. It has a very carefully thought out relationship of properties to analysis in general.

Please check out diagram 10 in the AP209E1 ARM provided in http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/analysis/AP209_ARM_Overview.pdf?rev=1.1. - it has the concepts of nominal (what we call Materials and Processes) type properties, and the idealized ones for an analysis.

Feedback from Phil (Wed, 4 Jan 2006)

OK Here is my first cut at fixing up your schema! I still have a number of issues:

The following comments within the email are collected. These provide Phil's rational for removing attributes listed in Keith's base. Actual code etc. sent by Phil has been delete, its all in the in the arm.exp files

From Keith Hunten to Phil

I could not agree more! There are several attributes that need to be removed - there are notes in the file I sent to Harry on that subject. The base of this is that in the modular APs and architecture the 'old' AP203/AP209 way of associating things like approvals, contracts, security and the like has now changed quite a bit. This is the task that remains to complete the conversion of the analysis_identification module.

This of course gets me to one of my favourite soapboxes - now that these concepts are modularized and done essentially by interaction operators and assignments, they are nearly invisible to the casual observer! Now we do not have a product definition that says it may have an approval - there is just an approval 'floating out there' that may be used - and it is up to the user/implementor to find it. We definately will need really good RPGs here to say the least - I wlll be quite interested to see how good a job your DEXs do in bringing this across.

More from Keith

Lots of good ideas here - looks like the two of you have answered most of my comments.

The DDPD is indeed a product_view_definition - but in the context of a design/analysis integration this needs to be expilcitly deliniated. I suppose I could be convinced to forgo this specialization - however this distinction was brought out as being important during the original requirements gathering and anlysis stage of AP209.

From Phil

I agree that we need to support external files. I think we should follow the External_model module approach (although I have issues about the scope limitation in that module to require it to be a geometric model!).

I have moved the relationship to product_version into a separate module. I'm not sure if this relationship should only be to product versions, do we want to cover Psychometric analysis of people with this structure, if so we would need a more general assignment capability.

NOTE    Harry says - This could be of major importance to human operated systems

I have moved the status flag out of analysis version to a separate entity which then related to the analysis version this allows different status' to be applied to the same version over time, this is then managed using effectivity_assignment.

I have deleted the Design_discipline_product_definition from the module. Since it is not related to any other aspect it should not be a part of this module and at best should be in a separate module. However, based on my first point, if we allow analysis of non-products, then we cannot assume that the definition of the non-product would be given in a subtype of a product_view_definition.

Finally I have removed the CAE file reference. There could easily be zero, one or many files associated with the analysis definition, i.e. results file, mesh file parameters file etc. I think this should be handled using the same structure you use for specifying the analysis definition, then creating a special subtype of that structure which includes a file reference. Please have a look at External_model, that creates a subtype of Geometric_model with an external file reference. This approach allows the same handling of the concepts irrespective of where they are held (internally in the data structure or in an external file).

NOTE    Harry says - Key don't forget

From Phil - Thoughts on usage

Some thoughts I have on how this can tie together with the work we are doing in AP233. As currently specified in the associated definitions from the previous version of AP209, an analysis represents the results of an analysis process. Therefore we need to have some tie up between an activity_actual (representing the performance of the analysis be a particular person using particular resources on a specified date/time) and the analysis results.

From my AP233/Vivace perspective I also want to have a relationship between derived/calculated properties of a product and the analysis which lead to these property values. The way I currently see it is that we would have an independent property assignment of the property value to the product. This property would be associated with the same analysis activity in the role of an output. I also think the property should be linked directly to the analysis results via a justification as in "this property is justified by these analysis results".

From Harry

The abstraction level that my head is at is defined in the Analysis in support of decision making slides that we overviewed in Hangzhou and that you have an I think are working with via Vivace. These are now at http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/analysis/AP233_Decision_analysis_1.pdf?rev=1.1. If what you say is supportive of what I outlined there I'm happy. I yield to you guys on the deep EXPRESS detail.

One point that I feel is important is the concept parameters being a resultant type view of a collection of properties. The hard point is that my parameters coming out of my analysis become the properties that you will use in your analysis. I tried to capture this in the slides but haven't the fogggiest idea as to how this is expressed in EXPRESS.

It distrubes me that AP233 is trying to use the word "parameter" for a very focus purpose in the SBB domain. We really need to take that word back and use it in the most generic context possible.



© ISO — All rights reserved