Table of content:
Note that each Wiki page has its own table of content about the details on that page.
Table of content:
Note that each Wiki page has its own table of content about the details on that page.
This is an old revision of the document!
Product modeling is the process of creating a product model of an individual product. A product model can be a model of any man made object or natural object. A product model can be a stand-alone model, it can be an element of a model library, or it can an integral part of a [wiki:“Facility Information Models” Facility Information Model]. Product modeling differs from [wiki:“Knowledge modeling in Gellish” knowledge modeling] which aims to develop knowledge models that express knowledge about kinds of things. A product model can either be a model of a real world object or a design (a realistic imaginary object). Examples of product models is a design or real piece of equipment, motor, car, or one of its components, such as a bolt, shaft, cable, etc. Also bigger assemblies, such as a buildings, railways, factories or process plants are products.
The design of a product often begins with the fuctional design. Therefore, we will first discuss the definition and the modeling of a function in Gellish English.
A design process usually begins with a functional specification or the requirements, for example as specified in the 'Systems Engineering' methodology (see ISO/IEC 15288).
Such a functional design specifies a 'function' that shall be performed by a new facility or product. The intention of a specification of the function is that the options for a technical solution are kept open. The idea is that in a later stage it shall be specified what the characteristics are of the designed physical object that will performs that function.
If we want to model a design in Gellish English we should be clear about what a function is and how we can distinguish between a design and a realised physical object.
A function as used in Systems Engineerig appears to be a process that needs to be performed or enabled.
A design process results in a product model of a physical object that will be the performer or enabler of the process (the function). Or more precise: a design is a prdduct model that specifies the composition and characteristics of a realistic imaginary individual physical object that is intended to be realised by a materialised physical object and that is suitable to perform the required function.
When the facility or product is fabricated it becomes a materialised (realised) physical object, that has characteristics that can be measured and which shall be compliant with the characteristics of the design.
The above definition of a function implies that a specification of a function in Gellish should start with the definition of the process that needs to be performed. So design of a function means: design of a process (an occurrence). For example, there may be a requirement to clean waste water, which in other words can be expressed as the requirement that we need the function 'waste water cleaning', or we may require to transport a number of people. Such a required process is not a process in general, but a particular process with specified input and specified output, by which the required performance of the process is defined. For example, it is required to clean a particular stream of waste water, coming from a particular source, such as the effluent water of a particular plant. That particular waste water stream should have specified properties, whereas the cleaning process will result in a clean water product stream that shall also have specified properties. The quantity and properties of those streams are not properties of the process, as is often specified, but they are properties of the streams that specify the required performance of this particular water cleaning process.
A required function or process can be specified in Gellish English as follows:
UID of left hand object | Name of left hand object | UID of an idea | UID of kind of relation | Name of kind of relation | UID of right hand object | Name of right hand object | UID of UoM | Name of UOM |
---|---|---|---|---|---|---|---|---|
101 | cleaning process-1 | 201 | 1225 | is clasified as a | 192452 | water treatment | ||
102 | S1 | 202 | 1225 | is clasified as a | 105 | waste water stream | ||
102 | S1 | 203 | 4785 | is input in | 101 | cleaning process-1 | ||
103 | S2 | 204 | 1225 | is clasified as a | 106 | clean water stream | ||
103 | S2 | 205 | 4786 | is output of | 101 | cleaning process-1 | ||
102 | S1 | 206 | 1727 | has as aspect | 104 | quantity of S1 | ||
104 | quantity of S1 | 207 | 1225 | is classified as a | 551327 | volume flow rate | ||
104 | quantity of S1 | 208 | 5025 | has on scale a value equal to | 920466 | 300 | 570450 | m3/d |
etc. |
Note that UIDs above 1000 are selected from the Gellish Dictionary. Lower numbers in this example are user created. The objects 101 through 104 are individual objects that are properly defined by the facts that classify them by a concept (or kind) from the Gellish dictionary. However, the concepts with the UIDs 105 and 106, waste water stream and clean water stream, do not exist yet in that dictionary. Therefore they should be defined according to the rules for proper definitions of concepts and by doing so they become proprietary extensions of the dictionary. The process can be specified in more detail as is described in the section about modeling of activities and processes.
Product information or a product model of a real or imagined (designed) individual product consists of a coherent collection of expressions of ideas about the product. Typically it has a hierarchy of decompositions of the object as its main structure, expressed as a collection of composition relations. Each component in the model has its own aspects. Documents and drawings may be related to the whole assembly or to the components that they describe. For example, a product model can be as complex as a model of a complete process plant, or of a facility such as a railway system and its components, but it can also be a single device or a simple component.
A product model shall at least consist of a classification relation and may include expressions that use the following kinds of relations:
An illustration of the application of a some of the above relations for the design of process unit 100 is given in the following table:
Name of left hand object | Name of kind of relation | Name of right hand object |
---|---|---|
process unit 100 | is classified as a | water treatment unit |
process unit 100 | is performer of | cleaning process-1 |
V-101 | is classified as a | horizontal vessel |
V-101 | is a part of | process unit 100 |
V-101 | has as aspect | internal volume of V-101 |
etc. |
An extensive description of the design of objects is provided in 'Semantic Information Modeling Methodology Application Handbook' that is available via the download area of this website.
A specification of a process or a specification of a design can be done from scratch, as in the above example, but it is also possible first to specify a knowledge model in Gellish of such a process and/or such a performer or enabler physical object and then use knowledge-based design software that guides the development of the specification of the process and/or of the design on the basis of such knowledge.
Continue with Modeling of activities and processes