MG2201ProcessModelingandDesignMethodology Lecture1&2.ModelsandModeling Dr.

DanielTSemere

20091103

ModelsandModeling InDesignandOperationofManufacturingSystems

Model A model is an approximation, representation, or idealization of selected aspects of the structure, behavior, operation, or other characteristics of a real-world process, concept, or system. (IEEE 610.12-1990). Modelling Modeling is the act or process of making models or representation of a real world object. Two way-outs are always done during modeling to reduce the complexity of the real world 1. abstraction a. leaving out the irrelevant. Eg You want to model a production line to do capacity analysis, i.e., you want to know how much you can produce in a given time. If raw material supply is not an issue, you may leave to model how frequently and in how much amount it is supplied. b. aggregate the details. Eg. In the above scenario, you may not distinguish between machines and the people operating them, this means you aggregate a station as a machine/operator system. 2. assumption - compensate for lack of knowledge or information. ModelandView A view is a representation of a system from the perspective of related concerns or issues. (IEEE 1471-2000). View is a model attribute. E.g. A manufacturing system can be modeled from different perspectives that may result in flow models, manufacturing function models, layout models, control models, etc. The set of views chosen to describe a system can vary. A good set of views should deliver the complete view of the system in relation to the objective of the modeling. MajorSystemViews The following are main system views often used in production systems design development and operation.

Form (structural) view Functional view Behavior view Performance or requirements view Data view Managerial view

Each of these views result in a set of models of the system which are described as follows. FormModels. Form models show what the system is, its components and the interfaces among them. Even less tangible physical forms such as communication protocol standards and logics may be included in such models. Models of form vary widely in their degree of abstraction and role. For example, an abstract model may capture only the look and feel of the system. A dimensionally accurate but hollow model can assure proper interfacing of physical parts. The two types of form models useful in manufacturing systems are scale models and block diagrams. ScaleModels The most widely used type of form models are scale models. Scale models are used for communication, and may function as part or basis for behavior or performance modeling. A typical example in manufacturing system can be a mock-up product that are made to enhance communication or even to make engineering evaluations during the product development early stages. BlockDiagrams The system is modeled in such a way that each block will represent a certain system element. The term block diagram has been is used loosely but distinct from other types of models; elements of the block diagram must correspond to physically identifiable elements of the system, i.e., system interconnect diagrams that show specific physical elements connected by physically identifiable interfaces. Manufacturing process diagrams are drawn with a standardized set of symbols. These represent manufacturing systems at an intermediate level of abstraction, showing specific classes of operation but not defining the machine or the operational details. Enhancements to block diagrams can be made. For instance system flow diagrams that show components in the same fashion as interconnect diagrams but illustrate the flow of information in the system.

ActivityModels Activity or functional models represent what the system does. Often such models are static, i.e., there is no time dimension. The activities in a system can conveniently be captured at multiple level of abstractions. Function Model in IDEF0 IDEF0 function models shows activities or functions in boxes and Input, Control, Output and Mechanisms (Means), the ICOMs, of the activity in arrows connected to the boxes shown below. Input: anything that comes into the activity and changed to the output as a result of the activity. Activities do not necessarily need to have input due to model abstraction. Control: anything that is used to constrain the activity. Eg. Rules, laws, the outputs of other activities which limit the solution space, etc. Output: the results of the activity relevant to the context. Mechanism (Means) : Anything that is used to do the activity such as tools, references, methods, etc.

Example of IDEF0 Model

C1: Report Template

I1: Data

Write Report A0

O1:Report

M1:Word Processor

Each box (activity) has a node identifier or simply a node number. In the above example A0 is the node number and placed often on the bottom right corner of the

Context Diagram The most abstract activity is called the context diagram and defines the view and scope of the activity. Below is an example of a context diagram for, Systems Integration for Manufacturing Application, SIMA, activity model. Context diagrams have A0 as identifier.

Decomposition: Activities can be decomposed to show the sub-activities that composed them. The decomposition can go decomposed to show sub sub activities and further. Decomposition shows not only the sub activities but also how they are related to each other through the ICOMs.

Node numbers in a given abstraction level are given consecutively like A1, A2, A3, etc. The childern of an activitiy have node numbers that show the node number of their parent and their consecutive number in the level. Eg, A21, A22, A23, etc are children of A2 and the last number identify the activity in the level. The first level of the SIMA Activity Model looks as below.

Exercise Select an activity in development or operation of a manufacture process and model the activities. Start from the context diagram, identify the ICOMs, show the decompositions to at least two levels excluding the context diagram. The following materials are course references for this section 1. SIMA Activity Modeling Part 1. 2. IEEE standard for IDEF0 Modeling

BehaviorModels These are models that show of how the system or the object of transformations behaves as process progress i.e., behavior models capture the set of steps in terms of object or system states or process sequences. The models address at least two questions for each step: When should each step be taken? When are the inputs to each step determined?

In manufacturing system design and analysis, three categories of behavior models are used: 1. Control Flow models 2. Data Flow models 3. State Machines Controlflow A distinguishing feature for Control flows is that they show what step follows after a completion of another. Control flow is the oldest and most popular form of behavior model, often as flow charts. Control flows are efficient in capturing the process sequence and the logic between steps. Exercise: Take any process in manufacturing and model the process using a flow chart. IDEF3 IDEF3 is a behavior modeling method and belongs to IDEF family of methods. The IDEF3 Process Description Capture Method was created specifically to capture descriptions of sequences of activities and logics. IDEF3 has to schematics namely: process schema and Object Schema. The process schema focus on processes and their temporal and logical relations. Consider the following example. The model contains four processes represented by boxes. Unlike IDEF0 arrows here represent predecessor

Syntax

Exercise: For the activity model you do earlier, model the process using IDEF3. Decomposition

Objects Schematics The basic construct is the basic state transition schematic or simply, transition schematic

& X

Junctions in Objects Schematics

Referents and notes

Referents may be used in IDEF3 Process and Object schematics to Refer to a previously defined UOB without duplication of its definition Transfer control or indicate a loopback in the processing. Form references or links between the process schematics and object schematics. A Call-and-Continue referent indicates that the referenced element needs only to initiate before the focus element can progress to completion. A Call-and-Wait referent indicates that the referenced element needs to both initiate and complete before the focus IDEF3 element can progress to completion.