1 / 36

FUNCTION MODELING USING IDEF-0

IE 590 INTEGRATED MANUFACTURING SYSTEMS Lecture 7. FUNCTION MODELING USING IDEF-0. IDEFØ The IDEF Function Modeling Method. Terminology of IDEFØ. Function Modeling Functions and activities Diagrams, Boxes, and Arrows ICOMs: Inputs, Controls, Outputs, and Mechanisms

giulia
Download Presentation

FUNCTION MODELING USING IDEF-0

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. IE 590 INTEGRATED MANUFACTURING SYSTEMSLecture 7 FUNCTION MODELING USING IDEF-0

  2. IDEFØThe IDEF Function Modeling Method

  3. Terminology of IDEFØ • Function Modeling • Functions and activities • Diagrams, Boxes, and Arrows • ICOMs: Inputs, Controls, Outputs, and Mechanisms • Arrows, links, relationships, and concepts • Splits, Joins, Unbundling, Bundling, and Branching • Decompositions • Viewpoint, Purpose, and Context • NIST (FIPS ) standard

  4. What is a Function Model? A Representation of the Activities and Relationships Between Activities in an Existing or Planned System.

  5. What is IDEFØ? • An IDEF method for modeling functions • Graphics (diagrams) • Text (glossary & narrative) • Provides both a process and a language for constructing a model of the decisions, actions, and activities in an organization

  6. What is an IDEFØ Model? • A definition of activities and information • Within a particular Context • Having a consistent Viewpoint • For a particular Purpose • Series of diagrams (that decompose a subject into manageable chunks) • A foundation for requirements specification, design, and programming • A useful record throughout the life-cycle of an enterprise

  7. IDEFØ Diagram • Definition of activities performed • Definition of information “Surrounding” the functions

  8. Example IDEFØ Diagram Customer Expectations Understanding of Customer Requirements Needs Establish Reqmnts. Requirements A1 Contract for Tradeoff Decisions Alternative Technologies Design System Design Knowledge of Previous Design A2 Raw Material Product Build System A3 Analysis Methods Design Methods Fabrication Methods

  9. CONTROL INPUT OUTPUT FUNCTION MECHANISM Diagram Construction (1) • Boxes represent functions • Arrows represent real objects or data

  10. CONTROL LABEL INPUT OUTPUT LABEL LABEL FUNCTION LABEL MECHANISM LABEL Labels

  11. CONTROL Diagram Construction (2) INPUT OUTPUT Label MECHANISM • Labels are words that name functions and data/real objects • Function labels are verbs or verb phrases and are put in the center of the function box • Data labels are nouns or noun phrases • Data labels name the input, control, output, and mechanism arrows

  12. IDEFØ Function • An Activity, Action, Process, or Operation • A Description of “What Happens” in a Particular Environment • Accomplished by People, Machines, Computers • Labeled with an Active Verb or Verb Phrase Function Label

  13. A1 A2 A3 IDEFØ Functions (Activities) Represented as a box in an IDEF0 Model. First diagram has one Function which bounds the context of the Model. (A - 0 diagram) Diagram has a maximum of 6 functions & a minimum of 3

  14. IDEFØ Relationships (Between Functions) • Represented as arrows • AKA concepts • Real objects, data, people, machines, and computers

  15. ICOMs • Inputs • Controls • Outputs • Mechanisms

  16. INPUTS FUNCTION Inputs • Real Objects or Data Needed to Perform a Function • Objects or Data Transformed by a Function • Labeled with a Noun or Noun Phrase

  17. OUTPUTS FUNCTION INPUTS Output • Objects or Data Produced as a Result of the Function • Labeled with a Noun or Noun Phrase

  18. CONTROLS INPUTS OUTPUTS FUNCTION Control • That which Governs the Accomplishment of the Function • Things that Influence or Determine the Outputs • Labeled with a Noun or Noun Phrase

  19. CONTROLS OUTPUTS FUNCTION INPUTS MECHANISMS Mechanism • Person, Device, or Data which Carries out the Function • The Means by which the Function is Performed • Labeled with a Noun or Noun Phrase

  20. Box and Arrow Relations in a Diagram (Join) FEED BACK OUTPUT TO CONTROL OUTPUT TO INPUTS INPUT 1 OUTPUT TO CONTROL ARROWS 2 BRANCHING (Split) 3 OUTPUT OUTPUT TO MECHANISM

  21. OUTPUT DATA 1 2 ONCE THIS DATA IS SUPPLIED, FUNCTIONS 2 & 3 CAN OPERATE SIMULTANEOUSLY OR SEQUENTIALLY 3 Arrows: "Branching" Output can branch and be used by two functions simultaneously or sequentially Without labels we cannot tell how the branching occurs

  22. Arrows: "Joining" PRODUCTION ITEMS PROCURED ITEMS CONTROL PRODUCTION ITEMS & TOOLS FINISHED SUB-PARTS

  23. COMMENTS SYSTEM REQUIREMENTS DRAFT SPECIFICATIONS DESIGN REVIEW DRAFT SPECIFICATION APPROVED WITH DESIGN CHANGES DESIGN Arrows: "Feedback"

  24. C B A A B C Bundling and Unbundling Bundle: Concepts B and C are bundled to form concept A. Unbundle: Concept A is unbundled into concepts B and C.

  25. Unbundle Management Directives Bundle Files Keep Records Customer Records A1 Account Entries Transaction Entries Orders Deliver Products Prices &Tax Tables Billing Entries A2 Transactions Perform Billing Invoices A3 Bundles and Unbundles Files = Customer Records + Price & Tax Tables Account Entries = Transaction Entries + Billing Entries

  26. Bundles and Unbundles: PCB ASSEMBLY Unbundle Management Directives Process plan Bundle Solder paste method Process Plan = loading details + solder paste details + chip placement method Assembly Records = soldering completed data + placement completed data Load board onto m/c Bare boards Placement method A1 soldering completed data Assembly Records Apply solder paste placement completed data A2 Paste applied board Place chip on board Chip positioned board A3

  27. More General More Detailed Function Decomposition Parent Diagram A0 “Parent” Activities Represent a Higher Level of Abstraction than that of Their “Children” A-0 A1 Child Diagram A2 A3 A4 A0

  28. A1 A2 A3 A4 A0 A31 Further Decomposition Parent Diagram Parent Activity Child Diagram A32 A33 A34 A3

  29. Decomposition • Establishes model hierarchy • Functions are comprised of other functions • Decompositions is a process of breaking down of the functions (level-by-level) • Data consistency is required throughout the level-by-level decomposition breakdown

  30. Complexity Simplification TechniqueTunnelled Arrows Tunneled Arrows at Unconnected Ends (Concept Does Not Appear on the Next Higher Level.) Tunneled Arrows at Connected Ends (Concept Does Not Appear on the Next Lower Level.)

  31. Tunneling Example This control will not appear on child diagram. This control will still be designated as C3 on child diagram. A0 Parent Diagram A-0 This output will not be shown on parent diagram. C1 C3 I1 A1 A2 O1 A3 Child Diagram A0

  32. Steps in Building a Model • 1. Define Viewpoint, Purpose, and Context • 2. Develop the Context Diagram (Putting the situation in context) • 3. Decompose activities to fit scope of modeling task (complete modeling per rules, etc) • 4. Develop glossary

  33. Model Orientation!!!! • Context (Subject) The Boundaries of the Subject Matter • Viewpoint (Bias) The Perspective from which a Subject is Analyzed • Purpose (Objective) The Reason(s) a Model is Created

  34. Inventory Policy Purchase policy Stock Levels Acquire Payments Materials Rejected Materials A0 Vendor ABC Co. Example - Context Diagram A-0 Diagram

  35. Purchase Policy Inventory Policy Inspection Policy Reorder Stock Check Stock Qty PO Prep. Policy Levels Levels & Det Reorder Qty A1 Prepare Purchase Order Authorize & Mail P O A2 Invoice Receive PO Produce & Rejected Ship A3 Material Receive OK Material Shipment & Material Inspect A4 Payments Restock & Make Payment A5 ABC Co. Vendor Example - Decomposition of the Context Diagram A0 Diagram

  36. Function Model for Planning and Implementing a Feat Ext module • Purpose: To obtain a better understanding of the various tasks involved in planning and implementation of a feature extraction module • Context: We will assume CAD model formats, process planning requirements and resources available (people and computers) are known. The FE module will be built using available existing resources (no new tools or software will be purchased). • Viewpoint: that of an industrial / mfg engineer who has a background in designing / building software systems

More Related