AP scope  |  AP module  |  AP contents  |  AP index
Application module: System structure ISO/WD 10303-1450

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 type definition
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

A discussion ready level of EXPRESS modeling is provided herein. This collects AP233 team work with AP239 and AP210 work presented in a form that passes the EXPRESS error checker. We think that it contains most of the pieces of necessary content. Associated interfacing, harmonization and modularization work is to-be-done

David Oliver's 2003 Visio EXPRESS-G Draft 4 file of proposed system structure modules can be downloaded at http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/system_structure/System_structure_Draft_4_visio.vsd?rev=1.1. This supersedes his Draft #3 which can be downloaded at http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/system_structure/System_structure_Draft_3_visio.vsd?rev=1.1. From this discussion ready EXPRESS-G work associated EXPRESS code was hand derived. The EXPRESS-G's shown in Clause C are derived from the hand coded EXPRESS defined Clause E.

The following notes and associated derived requirments are paraphrased from the AP233 Structure SOW and the Concept Model + Dictionary

The AP233 Structure SOW can be downloaded at http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/system_structure/SOW_structue.doc?rev=1.1. The Concept Model + Dictionary can be downloaded at http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/Concept_Model.ppt?rev=1.1. and http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/Concept_Model_Semantic_Dictionary.xls?rev=1.1.and

These requirements for the Structure Module Set(SMS) reflect both what the AP233 team has learned over the past several years and from their interaction with the SysML team on the joint development of the Concept Model and Semantic Dictionary, see http://www.sysml.org/ for an overview and http://www.sysml.org/artifacts.htm for available downloads.

Most of the nomenclature in this document is taken from the Concept Model. Readers should be cautioned that semantics for the same concept differs in ISO/SC4 modules, in the Concept Model, in general Systems Engineering Standards, and in SysML. There is no common or standard nomenclature at this time. This is totally due to the disconnected development history of these sources.

Harry Frisch is leading the effort to harvest AP239 modules to support the AP233 Project Management Module sets. These module sets provide for management control. To do a vestigial product breakdown is needed. Scheduling required needs to support the allocation of time duration to activities or tasks. Product breakdown is closely related to a part breakdown in the SMS. Similarly the time duration is a physical property that will appear in the SMS. At present these entities need to exist in the Project Management collection of module sets so that this collection will be testable stand alone. As the SMS is completed it will be essential to examine exactly how part hierarchy and product breakdown interrelate in the schema, and where time duration is defined and interrelated to activities and tasks in the Schedule Module Set. This issue of compatibility across the total schema may affect the exact layout of the requirements stated below.

Roger Burkhart is leading a John Deer supported effort to compare SysML defined structure with what is available in the AP239 modules. At present there appears to be parts of the SMS schema missing from the AP239 modules. This is work in progress.

Within the AP233 concept model - Structure, the description of how a system decomposes into its parts and how the parts assemble to make the whole is shown as:



Figure 1 —  

Figure 1 —  

Requirement:shall create an arm consistent with both the AP233 Concept Model and with SysML Structure and Parametrics

Requirement:shall support the information unit concept of Structure

NOTE    Definition - Structure: the description of how a system decomposes into its parts and how the parts assemble to make the whole.

  1. Structure is built from Part, Port, and Interface Specification. Structure decomposes hierarchically. These relationships force Part and Port to also decompose hierarchically.
  2. Structure provides the decomposition, interconnection and other static relationships among the parts of the system.
  3. Physical properties are budgeted to structure using analysis methods, and the emergent performance is calculated using the same methods.
  4. Behavior is allocated to the structure. Form and function are separated conceptually so that the design can be optimized by considering several different structures that can provide the desired emergent behavior and properties.
  5. Example: In a real example of design optimization the engineer does not just look for some local cost function maximum or minimum, but looks at the trend in data to find that region in the design space where the solution is robust; i.e., the solution is both near a cost function min/max point and does not degrade rapidly with variances in variables under design control.

Requirement:shall create an entity for the information unit concept of Part

NOTE    Definition - Part: The static parts of the system including their interconnection and interconnection descriptions.

  1. The Part is simply a part of a component list
  2. A Part does not represent an actual physical object that is or was existing in the real world.
  3. A Part is a type of Product that collects the definitional information of the versions of either a part or of a non-countable material.
  4. Physical Property is assigned to part.
  5. Many persons think of parts as components, but manufacturing thinks of them as assemblies because they build assemblies.
  6. Assembly is a standard ISO naming convention. It may be desirable to alias this name.
  7. The name used herein follows the STEP manufacturing point of view of looking at a part or component and talking about it as an assembly because their job is to assemble it.
  8. This is a place where it may be advisable for clarity to use the words component or part as an alias for Part.
  9. To support verification and validation work there is the need to distinguish between part design and part realized.

Requirement:shall create a hierarchy for Part.

Requirement:shall create the ability to distinguish between part (build as designed) and part realized (built as designed); as needed to support system verification and validation work.

stepmod module - Part_and_version_identification_arm - Introduction

  1. data that identify parts and their versions

stepmod module - Part_and_version_identification_arm - In scope

  1. identification of a part;
  2. identification of a non-countable material;
  3. identification of a version of a part or of a non-countable material.

stepmod module - Part_view_definition_arm - Introduction

  1. representation of characterization views of a version of a part

stepmod module - Part_view_definition_arm - In scope

  1. identification of a characterization of a version of a part, relevant in one or more application domains and one or more life-cycle stages.

stepmod module - Part_definition_relationship_arm - Introduction

  1. representation of relationships between definitions of parts.

stepmod module - Part_definition_relationship_arm - In scope

  1. representation of the fact that a part version results from the transformation of another.

stepmod module - Product_as_individual_arm - Introduction

  1. representation of data that records the identification of an existing or potential future artefact
  2. an actual product whose properties can only be known by observation or by derivation from observations.

stepmod module - Product_as_individual_arm - In scope

  1. representation of the information to identify an actual product;

stepmod module - Assembly_structure_arm - Introduction

  1. epresentation of assembly relationships.

stepmod module - Assembly_structure_arm - In scope

  1. specification of the use of a product version as a component of an assembly;
  2. specification of a parent-child assembly relationship;
  3. identification of a component of an assembly with respect to an upper level in the assembly structure.

Concerns, Observations and comments (Radack/Baker exchange)

  1. The problem with the concept of assembly is that some user's "part" is another user's assembly. For example, microchips are single parts to most users, but clearly have a bill of materials if you manufacture them. In the aircraft industry, a carbon fibre composite can be viewed as a single part for most purposes (it certainly cannot be disassembled) but has a complex, careful defined structure for its own manufacturing process.
  2. From the STEP viewpoint, saying something is an assembly is equivalent to saying you have the breakdown into smaller physical components. "assembly" is not a classification of the thing in itself, but an observation on whether your organization thinks about it in terms of components. In that sense, a pilot's log book treats an aircraft as a single part, since he does not record a list of component parts.
  3. In a PDM context, an assembly is something that is in itself configuration controlled (in a configuration context), and is made from configuration controlled parts. Here, an assembly is a convenient holder for "a collection of parts". It would not affect the end product if a different collection of assemblies were used, as long as the same collection of parts in the same position is the result. The old 'Product Manager' explicitly supported the restructuring of the design assembly breakdown into a manufacturing assembly breakdown. There are also often differences between the assembly structure used in manufacture and the assemblies provided as spares.
  4. Which all goes top reinforce that "assembly" is as much a description of the user organization as the product. Since STEP does not transfer business processes, it is probably best to treat "assembly" as a placeholder for a family of concepts that need further specification.
  5. If you are saying that it does not make sense to say that an Assembly is a kind of Product or Part I agree. Assembly should be treated as a relationship which is part of a structure. We should be able to say "A is assembled from B, C and D within structure X" but not "A is an assembly". Different structures are needed to account for different activities or purposes, e.g., manufacture, maintenance, and disposal.
  6. Well put.

Concerns, Observations and comments

  1. Part stuff appears to service - for design, build as
  2. Product_as_individual stuff appears to service - individual instance, built as
  3. DWO - During the Asheville meting it became apparent that the SC4 approaches all distinguish between the design of a thing and the actual manufactured thing itself. SysML will likely follow that approach as well. Currently the the concept model makes no such distinction.
  4. DWO - Issue: Distinguish between design and the manufactured things based on those design
  5. DWO - Possible approach: The current entity Part can be a superclass with a subclass for design and a subclass for the manufactured things based on that design. Keep the interface relationship at the superclass level so that interfaces and interconnection apply to both subclasses and the interfaces may be preserved between design and manufactured thing. Generate names and definitions for the superclass and the two subclasses. Generate the relationship between the design and the manufactured thing. Check on any changes that need to be made to the validation and verification parts of the model. These may be minimal because design and manufactured things are validated and verified in a similar manner. The particular analysis/measurement technique and infrastructure may differ, but thosse models allow for prescription of analysis, measurement, and infrastructure for each verification and validation.
  6. Jozsef Bedocs - built vs. design: Subclassing the manufactured thing from the designed thing has potential issues. Fundamentally, the manufactured thing is not necessarily the same as the designed thing. It would be better to have the manufactured thing subclass to Part and associate unidirectionally the manufactured thing and the designed thing.

Requirement:shall create an entity for the information unit concept of Link related to part

NOTE    Definition - Link: A particular kind of Part that is used when it is helpful not to model or specify its details.

  1. Link must be provided in the concept model because a number of application tools use the concept.
  2. Links ultimately are fully specified and become system-assembly.
  3. Example: In a pumping system it may be useful to define the pumps and tanks while representing the piping as links without detail. At some point in the design detail like diameter, flow impedence, pressure rating, and corrosion resistance must be defined. At his point the link becomes a part.

Requirement:shall create an entity for the information unit concept of Port related to part

NOTE    Definition - Port: A connection point on a Part in the Part decomposition hierarchy.

  1. Each Part (part or component) attaches to others at particular locations. These locations are called Ports.
  2. Example: This is a familiar idea when one thinks of the port on a power cord that plugs into a port on the wall to get electric power. It also applies to the surface of a bridge, a port, that interacts with wind, a port. In the second case the concept is less intuitive and more formal but it works.
  3. Ports connect to ports.
  4. Systems interconnect with one another port-to-port. Ports couple to desired things in the environment and also to the ports of things that cause failure, threaten security or safety.
  5. Note that when a system interacts with its environment that the boundary between the system and the environment is the collection of all interacting ports.
  6. Example: Consider a ultrasonic transmitting transducer coupled to a water tank and a receiver transducer coupled to the tank. The transmitter port connects to a water port and couples sound energy into the water. The intensity at any point is a result of the impedance match between the two ports, the radiation pattern of the transducer, and the attenuation and dispersion in the water. The receiving transducer is attached to another port of the water. The received signal is dependant on the relative impedance of the two ports, the sound distribution in the water, and the radiation pattern of the receiving transducer.
  7. Example: This example is often oversimplified as "broadcast" neglecting the port to port conditions and the properties of the medium and neglecting the ports.
  8. The alias for Port is Interface_connection, the term that is used in AP239.

Requirement:shall create a hierarchy for port.

Requirement:shall create the ability to provide for both information templates and information instances for the information concept units of part and port.

Requirement:shall create an entity for the information unit concept of Interconnection

NOTE    Definition - Interconnection:A listing of the ports that interconnect with one another.

  1. Interconnection specifies which ports attach to which other ports. Together Part, Port, and Interconnection specify how parts go together to constitute the whole.
  2. This description does not include Behavior or Physical Properties.
  3. The interconnection may exist for structural reasons without any flow from port to port. The interconnection may exist because functions are assigned to particular assemblies, and the output from one function is an input to the other function. In this case the ports and their interconnection must exist to support flow.
  4. The alias for interconnection is Interface_connection, the term used in AP239.

Requirement:shall support various classes of port to port interface representational complexity.

  1. Simple property: A scalar property is needed to characterize port to port connectivity; e.g., the thermal conductivity of a thermal insulation plate.
  2. Complex property: A property with complex dependencies is needed to characterizes port to port connectivity; e.g., the characterization of the welding together of two Alaska pipleine pipes.
  3. Simple part: A simple part characterizes port to port connectivity; e.g., international electric plug adapter.
  4. Complex part: A complex part characterizes port to port connectivity; e.g., Alaska pipeline support structure with its embedded heat pipe to prevent permafrost melt. Alaska pipeline U joints designed for earthquake failure protection.
  5. Other examples from Asheville: Tire tread for on and off road vehicles; Suspension system for a land operated vehicle, Also sort of electrical cabling and harnesses, all sorts of mechanical hinges with 1,2,3,4,5,6 degrees of freedom including flexibility, joint slop, damping, etc.

Requirement:shall create an entity for the information unit concept of Interface Specification

NOTE    Definition - Interface Specification: A description of a Port of a Part that includes the geometric description, I/O description, protocols that must be met, assemblies of parts required to join two ports, allowable defect characteristics, etc. The interface_description includes the emergent properties of the interface that is the result of the two ports interacting, and is not associated with either.

  1. Each port has associated with it a description, an Interface Specification, that describes the geometry, forces, transferred material or energy or information, protocols, how to assemble to it, and tests that may be required of the port-to-port connection. For two ports to be interconnected their interfaces must be compatible.
  2. The interface specification describes emergent properties and behaviors of the interface.
  3. The interface specification allows for an interface that consists of multiple parts.
  4. Parts interact physically through direct physical contact, exchange of Elements, and through forces they exert such as gravity, compression or torque. Thus I/O is bound to ports and described by interfaces. The interface may consist of more than the two ports and may involve an assembly of parts as in the case of two flanges that are assembled with six bolts and an O-ring. The interface may also require detailed description to define what occurs there or how it is maintained.
  5. Example: For two ports to connect, their interfaces must be compatible. The current carrying capacity of a plug and a socket is a result of the surface area of contact, the contact force, the wiping action on plugging them together, and the surface conductivity of both. This is an emergent property that is not assignable to either port individually.

stepmod module - Interface_arm - Introduction

  1. representation of interfaces between products
  2. interaction between co-functioning products, or a product and its environment,
  3. the product attributes that are necessary to exist at a common boundary

stepmod module - Interface_arm - In scope

  1. the identification of the interface specification;
  2. the identification of a version of an interface specification;
  3. the representation of an interaction or connection between two or more products;
  4. the identification of the interface connector, the part of a product with which one or more other products or the environment will interact.

Concerns, Observations and comments

  1. Extensions may be needed to service full range of AP233 needs


Figure 2 —  

Figure 2 —  

Requirement:shall create allocation relationships between Part and Text Requirement subclasses Physical Property Requirement and Imposed Design Requirement

Requirement:shall create allocation relationships between Interface Specification and Text Requirement subclass Interface Requirement

Physical Property, its relationship to the Structure hierarchy and to analysis is shown in Figure 5. The key concept is that performance, behavior and physical properties of the whole results from the structure, the behavior and physical properties of the parts. They are not related to a class tree.



Figure 3 —  

Figure 3 —  

Requirement:shall create an entity for the information unit concept of Physical Property

NOTE    Definition - Physical Property: What an Element exhibits or does not exhibit in response to excitation and stimulation from auxiliary measurement entities that are not part of its context.

  1. This is the subclass of property that encompasses measurable characteristics that require additional instrumentation to measure them. They cannot be established from responses to the enviropnment alone. All of the "properties" used in analysis with differential equations fall into this category.
  2. Example: Responses of an Element like mass, power consumption, MTBF, etc. are critically important and appear in requirements. They are not measured by responses to excitation from their environment.

System Assemblies in the Part tree all have Physical Properties such as mass, power consumption, geometry, MTBF, drag coefficient, etc. The Physical Properties are assigned to a particular Part. A Physical Property has a name and an ID that identifies it uniquely. For example, many different System Assemblies have the Physical Property mass. Consequently each of these assigned Physical Properties needs an ID. Each has an associated unit in which it is measured.

A Physical Property assigned to a particular Part has values. The value may be expressed as a mean, a mean with variance, a probability distribution, or a histogram. All of these values are a result of a set of measurements and analysis of the data. The value goes through a series of versions as the system definition evolves. The Part is declared to have a Required or Budgeted Value.

The Part may have a Target Budget Property Value used as a guide or target as designers consider alternatives. A Part, as a whole, may have a Calculated Property Value based on analysis of the properties, behaviors and interactions of its parts. When a Part is built, it may have a Measured Property Value.



Figure 4 —  

Figure 4 —  

Requirement:shall create an entity for the information unit concept of Unit, value, version of value, tolerance and version of tolerance.

NOTE    Definition - Unit:Establishes the standard of measure against which he values of physical_properties shall be stated.

NOTE    Definition - Property value: A numeric value assigned to a physical_property

  1. Required_budgeted_property_value: A property value aloocated to a part by a requirement, or budgeted to that part by analysis.
  2. Calculated_property_value: A property value of a whole calculated or estimated from the values of the parts that assemble to make the whole.
  3. Target_budget_property_value: A temporary property value used by a designer as the design work proceeds and different design alternatives are considered.
  4. Measured_property_value: A property_value established by measurement of an actual part.

Requirement:shall create relationships among physical property, unit, value, and tolerance

Requirement:shall create an allocation relationship between Part and Property

Requirement:shall create allocation relationship between Part and Function

Requirement:shall create an allocation relationship between Part and State

Requirement:shall create entities for the information unit concept of Alternative Parts

Any one assembly is an interconnection of assemblies one tier down in the tree. The emergent properties of any assembly are a result of the properties, interconnection, and interaction of the sub-assemblies from which it is built. The relationships may be very non-linear in the physical world as observed with phenomena like combustion and friction.

The basic relationships for analytical modeling of emergent properties and budgeting of properties are shown in Figure 5. A set of engineering equations or estimates, analytical models, are used by systems engineers to budget properties to the interacting sub-assemblies as a guide to designers at the lower level. When designs for all of the sub-assemblies are available, their individual properties and interactions are better defined. The same equations are used to calculate the emergent properties of the complete assembly. The fidelity of the calculations increases as the work proceeds.

A Part, as a whole, may have a Calculated Property Value based on analysis of the properties, behaviors and interactions of its parts. This is accomplished by estimation or by an analysis that solves the relevant engineering equations. This makes it necessary to represent physical properties as parameters in the equations of the relevant analysis model. Model Parameter provides this parameterization. It has an attribute of its of the unit of measure applicable to the analysis. This may be different from the unit assigned to Physical Property. The reference_document attribute specifies the standard document that contains the reference for the Model_parameter. A default value and valid range can be specified when needed.

Parameter_assignment assigns parameters to model_parameter that in turn is a parameter for analytical_model. Analytical_representation has a set of parameter_assignments and is modeled by one or several analytical models. be solved, Analytical _representation. The several Analytical_models provide answers at different levels of fidelity and with different efforts of computation. AM_port connects the analytical results back to the appropriate location in the part hierarchy.

Requirement:shall create an entity for the information unit concept of Analytical Representation

NOTE    Definition - analytical_representation: Is the association of specific properties of specific system assemblies with an analytical_model in order to unambiguously characterize the performance of a specific part

Requirement:shall create an entity for the information unit concept of Analytical Model

NOTE    Definition - analytical_model:Provides a mathematical description of the properties of a system.

stepmod module - Analytical_model_arm - Introduction

  1. for the representation of information needed to properly interface to and exchange the source code contents of an externally defined computer-interpretable model of a particular behaviour. This model allows a behaviour to be described using a mathematical form (e.g., algorithm, table). A model is independent of any particular product. A model is not directly executable to return a result until application data have been applied.

stepmod module - Analytical_model_arm - In scope

  1. identification of externally defined analytical and computer-interpretable models and their versions;
  2. identification of the parameters of an analytical model;
  3. the application of an analytical model to a real or imaginary object together with the needed parameter assignments;

Concerns, Observations and comments

  1. Concept of "Ports" within Analytical_model_arm carries the implicit assumption of analog/discrete input/output signals. This is a ee-domain specific concept. Need to remove all "port" stuff.
  2. model_parameter_type and signal_flow _direction types not needed. Not general enough
  3. How does this map to input and output data files of arbitrary complexity?
  4. What does analog and discrete map to?
  5. Vector-tensor physical property type needs reference frame
  6. Cast in the language of EE-ize, can't see the mapping to multi-disciplinary analytical models
  7. Significant alteration may be needed to service full range of AP233 needs
  8. Reason: This arm is designed to service a lower level of data abstraction than needed by AP233.
  9. Maybe: a "lite" version of this module work service needs?
  10. From TT What in Analytical_model is specific to electrical/mechanical domain? We have spent a lot of extra time in that module to make things flexible yet very concrete so there could be little confusion by a data extractor and a data receiver. Is it the digital and analog port stuff? I added that specifically so that we could identify quantities on the ports that have through and across variables. Mike Loeffler had a look at it and agreed it is good stuff, so I am a little confused.

Requirement:shall create entities to support the information unit concept of Rules

NOTE    Definition - rules: rules are defined by a constraint relating two elements based upon characteristics of a design;

stepmod module - Production_rule_arm - In scope

  1. rules that define a constraint by relating two elements based upon characteristics of a design
  2. management of rules;
  3. items within the scope of application module Model parameter, ISO/CD-TS 10303-1703;
  4. items within the scope of application module Software, ISO/CD-TS 10303-1746;
  5. items within the scope of application module Specification document, ISO/CD-TS 10303-1747.

stepmod module - Production_rule_arm - Introduction

  1. This module provides for the representation of the information needed to describe design constraints, commonly referred to as rules. The information describes the rule's relationship to product characteristics, formal description of the functions that embody the rule, in addition to the configuration management aspects applied to the rule. The configuration management information supports rule version control and supports a formal process to making changes to an existing rule.

Concerns, Observations and comments

  1. Rules need to service every aspect of systems engineering from high level institutional rules for product development to low level rules that insure product manufacturability
  2. This module is from AP210 - It still needs to be interface with AP233

Requirement:shall create entities for the information unit concept of Parameters with units, values and tolerances

NOTE    Definition - model_parameter: a formally declared variable of the analytical model provided for an external application to populate at execution time in a computing environment

stepmod module - Model_parameter_arm - Introduction

  1. representation of information needed to describe model parameters, mechanism for overriding them and their assignments to products. Model parameters can be classified.

stepmod module - Model_parameter_arm - In scope

  1. identification of a parameter for a model;
  2. assignment of values to a model parameter;
  3. assignment of a parameter to a model;
  4. overriding of a parameter assignment;
  5. assignment of a parameter value to a product;

Concerns, Observations and comments

  1. Model parameters can be vector-tensors with reference frames
  2. What to do about input/output files for multidisciplinary problems.
  3. Need to wrestle down "parameter" vs. May-2002 Lambda calculus thoughts
  4. Reference material can be downloaded at http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/system_structure/Parameter_property_and_Lambda_calculus.doc?rev=1.1 and http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/system_structure/Parameter_and_Lambda_calculus.doc?rev=1.1

Requirement:shall create provide Parameters with Units

Requirement:shall create an entity for the information unit concepts of Parameter Value, Tolerance and Assignment.

Concerns, Observations and comments (Erik Herzog)

  1. Please find attached a more detailed description on what I believe is missing from the system structure modules as proposed. This document, from Erik, can be downloaded at http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/system_structure/Erik_system_structure_1.doc?rev=1.1
  2. To Erik: I reviewed your proposal and am requesting more information: How does a conceptual_part differ from a system? Tom
  3. Good question Tom: Do I need both a system entity and a conceptual product entity? I do ask the same question at regular intervals, have intense debates with myself and tend to come up with justifications each time. I will put together a justification document,
  4. Erik: As you are putting together the justification document, the central thing (from my perspective) is to capture what explicit mechanisms are used for identification. Tom
  5. To Eric From David:

    I always like what you do and it leads to interesting discussions. I have just scanned your comments on structure. Let me add some thoughts that may not have been clear in the information you have seen so far. Your diagrams appear to be correct. However, we have planned to include a breakdown for real physical manufactured things. after all, verification is done against the real stuff, not just against designs (Parts in STEP).

    So I would add breakdowns for real stuff to the pictures you have drawn.

    In real work sometimes one sets up conceptual or logical parts and then the actual designs. Sometimes it is done with two or more alternative designs and a trade study to select the best approach. When we did a real time ultrasonic cardiac imager in the 80's we considerd large wobble transducers, fresnel lenses, and phased arays. Trade studies showed only phased arrays would work. For the front end signal processing we did a trade study of standard digital circuits vs. CCD's. this took experimental work to sort out the best design approach. My only point is that there may be more design alternatives than just two, and the number you get may vary with where you are in the decomposition hierarchy. I think this can all be handled through use of Part for design and the generous version capability that includes defining the context for the version and the part view definition. Most often the work is upgrading where 90% or more of the system is predetermined and it is being enhanced for the market.

    As stated above we need not just Part, but also real manufactured stuff. Here too there may be more than one version of real things to represent. For example, there is the first product built - like first car to track or first engine to test. These often contain parts that are hand crafted and not manufactured with the regular assembly line. Next there is often pre-production that is used for test marketing but built on an assembly line that is not the final one for full scale manufacture. There is also spare parts manufacture, spare part refurbishing, and a part hierarchy particular for maintenance that emphasizes line replaceable units. As with design, I believe that one can use a single real thing breakdown, and use versions to handle the several related but different breakdowns for specific purposes. In accord with this Asheville decision we sent an Issue to Julian, who is working on the concept model, to add to that model the distinction between design and the real stuff manufactured from design that may have part numbers.

    When we went into the Asheville meeting the .vsd model used System Breakdown for System. During that meeting a consensus was reached with the help of the more EXPRESS expert contributors like Spiby and Price, that we make System equal Product. The Product decomposition then becomes the System Breakdown. Part, as a subclass of Product, represents design. It seems logical to use Product_as_Individual for real physical manufactured stuff that is tested and verified against requirements.

    If we do this, there seems to be no need for several PLCS modules - Product Breakdown, System Breakdown, Physical Breakdown, and Functional Breakdown. We set this up as a crtitical issue - not to use these. We set up as a critical issue what these breakdowns are because the documentation is ambiguous and shows a lot of cut and paste such that different modules share nearly identical descriptions. Unfortunately the documentation does not provide examples. We hope team members or Rob Boddington will help clarify concepts these modules support. The most mysterious of these breakdowns is Functional Breakdown with Functional Instance. Examples of functional instances and how they differ from requirements would be helpful.

    If this makes sense to you, it would add to your figures a breakdown for real physical manufactured things currently associated with the Product_as_Individual module. This could be modified in Valencia if we find convincing reasons to do so. I welcome any comments on this.

  6. To Eric from David:

    I have attached a schematic (a little like the ones in your recent communication) to show what we have had in mind for AP233. It is a bit different than the diagram you drew for the AP233 approach. Perhaps it satisfies some of what you perceived to be needed. Please let me know how much it satisfies or does not satisfy your concerns. David's attachment can be dowloaded from http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/system_structure/David_system_structure_1.ppt?rev=1.1

    What you meant by conceptual parts was not clear to me and I have interpreted it as alternative designs. There is a whole process step with its own set of tools used at a higher level of decomposition to do concept analysis or strategic planning. We expect to have a vendor of these tools and an expert in the field working with us on strategic planning in the near future but not in time for WD-1. Some of this can be found in my book and in the book on strategic planning by Gale, cited in my book. This book can be downloaded at http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/system_engineering/Engineering%20Complex%20Systems%20%28book%29.pdf?rev=1.1. Much of what is needed for strategic planning can be accomplished by modeling the business developing its strategic plan for a product as a system. The context model at that level then includes competitors, competitive products, and markets (customers), etc. We will need to work through examples with a tool designed for this to isolate the additional entities and relationships that are needed in AP233.

    Note that at the beginning of the Asheville meeting System was identified with the System Breakdown Module. At that meeting the collective wisdom of the team was to identify System directly with Product, and we changed the Structure module to accomplish this after the meeting. The assignment of application entities to modules in the schematic charts is based on that decision at Asheville; System = Product.

  7. To All from Erik:

    The attached document http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/system_structure/Erik_system_structure_2.pdf?rev=1.1 is produced to justify whe AP-233 WD5 included separate physical architecture and system architecture structures. The document is produced in response to the statements by Tom T. Tom has seen earlier versions of this document and he now has a good understanding of the AP233 WD5 model, Whether he accepts it or not is a completely different issue. So, the rationale is provided and the debate is open!

Notes extracted from Valencia and Rochester meetings summer 2005



Figure 5 —   System identification and version (Attic copy)

Figure 5 —   System identification and version (Attic copy)

  1. Phil recalled the existance in the stepmod attic of Ian's module system_identification and version
  2. This module will enable system = product to be removed
  3. It will enable system to be made a subtype of product
  4. Phil to clean up the (Attic copy) version as shown above.
  5. Phil to verify that type extensions exist for system and requirements.
  6. A USE FROM placeholder for system_identification_and_version is to be placed in WD#2
  7. Results to be reviewed at PDES fall off-site.
  1. Extensive discussion on this subject with a detail walk through AP239 interface_arm example population by Phil see http://cvs.sourceforge.net/viewcvs.py/*checkout*/stepmod/stepmod/etc/ap233/references/system_structure/Phil_PLCS_Interface_example_4.pdf?rev=1.1
  2. The arm.exp segment within AP233 WD#1 module system_structure tagged as "Product_interface" is effectiviely a copy of what is in AP210. (To be removed.)
  3. After the detail walk through it appears that stepmod AP239 module "interface_arm" will service AP233 needs.
  4. A few open issues remain, to be clarified via further population of example in time for PDES fall off-site review.
  5. This work will be done by Phil Spiby, Joe Bedocs and Harald Eisenmann
  6. Population will be to clarify multiple usage and emergent properties concerns
  7. Populate SysML interface model with same example.
  8. Detail review by AP210 + AP239 + SysML gang necessary
  9. Lothar has interconnection concerns: At occurrence level (Several levels of hubs and ports, Package connectors), Reference designator
  10. WD#2 decision was to remove "Product_interface" segments from WD#1 system_structure and replace with USE FROM Interface_arm;
  1. Extensive discussion on the WD#1 proposed breakdown approach vs. AP239 stepmod breakdown modules
  2. A lack of detail understanding during WD#1 development exposed. It now appears that the AP239 breakdown modules will work.
  3. Breakdowns allow you to take different cuts at the system allowing you to point to associated parts. Are pointers to parts.
  4. Assembly provides another view of problem from the realized/realizable "as is" perspective. Its a relationship that holds the semanitics of connection, the "as is" view.
  5. Decision - Remove WD#1 segments of AP233 system_stucture module tagged "System_engineering_system_breakdown".
  6. Replace with USE FROMs to stepmod breakdown modules
  7. No need for hybrid breakdown
  8. Lothar still has some issues associated with the stepmod breakdown modules. These require detail PDES offsite discussion.
  1. Phil/EuroSTEP gang to check out animate object support
  2. Questions arose with respect to the modeling of people (operators)
  3. Use Part for design, product_as_realized for individual, links to alternatives needed to support trade-off studies.
  4. Make sure that we can do alternative design trade-off studies
  1. Valencia agreement with AP210 was to remove all AP210 module_lite segments of WD#1
  2. Replace these with USE FROMs to unabridged AP210 modules
  3. Note that in the stepmod/etc/AP210 folder several fixes are defined for stepmod modules used by the AP210 modules
  4. There was sufficient discussion on analysis to reveal that many analysis views exist with no common agreement as to where the interface between Systems engineering and domain engineering is to be placed.
  5. Harry to attempt to lay the puzzle pieces on the table.
  6. Need to create some example populations that expose/clarify the need for all views
  7. How to satisfy all. What's really different about the different views of analysis need?
  8. AP233 FBB and SBB Behavior analysis view, linear analysis, AP210 analysis view, AP209 analysis view, AP239 (verification) analysis view, decision making [rules of thumb, peer reviews, negotiations, politics], etc.
  9. To be discussed at the PDES offsite
  1. Valencia agreement with AP210 was to remove all AP210 module_lite segments of WD#1
  2. No discussion on Rules at Rochester

Change Log from base line AP233 WD#1:

  1. WD#2 - Removed "Product_inteface" segment from arm.exp
  2. WD#2 - Added placeholder comment line "USE FROM System_identification_and_version_arm;
  3. WD#2 - Removed "System_engineering_system_breakdown" segment from arm.exp
  4. WD#2 - Added USE FROM physical_breakdown, system_breakdown, zonal_breakdown,
  5. WD#2 - Removed all _lite versions of AP210 analysis and rules modules.
  6. WD#2 - Added USE FROM Analytical_model, Characteristic, Model_parameter, Software
  7. WD#2 - Added USE FROM Production_rule


© ISO — All rights reserved