DAS 5941 Tpicos Especiais em Automao da Manufatura

A Metodologia IDEF0
A metodologia IDEF (ICAM DEFinition methodology) utilizada como suporte formalizao desses passos; mais especificante, a sua componte de descrio funcional, a IDEF0 (Integration Definition for Function Modeling). Esta metodologia correpondeu a uma iniciativa da US Air Force para a criao de ferramentas e metodologias de suporte ao desenvolvimento de sistemas avanados de manufactura. A IDEF0 permite descrever, atravs de uma hierarquia de diagramas, o modelo funcional do sistema que se pretende analisar ou implementar. Apenas para facilitar a compreenso do leitor, muito basicamente, cada uma das tarefas (interrelacionadas) de um dado diagrama representada por uma caixa. Nas quatro laterais de uma caixa so identificadas todas as informaes de entrada, as informaes / produto de sada, os recursos disponveis para a sua realizao e as condies para a sua activao, respectivamente. A figura 1 mostra a estrutura geral dum diagrama em IDEF0 atravs dum exemplo hipottico. Neste, descreve-se como a actividade denominada tornear pea X executada (portanto, no interior da caixa identificada o nome geral da actividade). Na parte lateral esquerda identificam-se as entradas (inputs) para a actividade. No caso, uma pea em bruto. Na parte inferior descrevem-se os recursos existentes para o processamento da tarefa. No caso, um torno Y com o seu operador, as devidas ferramentas e o programa CNC de torneamento. Na parte superior especificam-se as condies necessrias para que a actividade possa ser iniciada. No caso, que a ordem de manufactura chegue na estao de trabalho (no torno). Na parte lateral direita relacionam-se os resultados (outputs) da actividade. No caso, a pea X torneada e um relatrio de inspeco de qualidade. Numa ptica de inter-relacionamento entre actividades, os resultados duma actividade podem servir de entrada e/ou condies de habilitao para uma outra. Ainda, no canto inferior da caixa o diagrama identificado em relao ao diagrama de maior hierarquia ao qual pertence, iniciado sempre pela letra A. No caso, o diagrama o A21, o que significa que o primeiro diagrama da exploso dum diagrama A2.

Prof. Ricardo Jos Rabelo / Departamento de Automao e Sistemas / UFSC

DAS 5941 Tpicos Especiais em Automao da Manufatura

ordem de manufactura A2

pea X torneada

Tornear pea X
pea em bruto A 21 relatrio de inspeco

torno Y & operador

ferramentas

programa CNC

Figura 1 - Exemplo dum diagrama IDEF0

Prof. Ricardo Jos Rabelo / Departamento de Automao e Sistemas / UFSC

DAS 5941 Tpicos Especiais em Automao da Manufatura

The U.S. Air Force IDEF Methods

A structured approach to enterprise modeling and analysis
IDEF (Integration DEFinition) methods are used to perform modeling activities in support of enterprise integration. The original IDEF Methods were developed for the purpose of enhancing communication among people who needed to decide how their existing systems were to be integrated. IDEF (Function Modeling Method) was designed to allow a graceful expansion of the description of a systems functions through the process of function decomposition and categorization of the relations between functions (i.e., in terms of the Input, Output, Control, and Mechanism classification). IDEF1 (Information Modeling Method) was designed to allow the description of the information that an organization deems important to manage to accomplish its objectives. IDEF3 (Process Flow and Object State Description Capture Method) has been developed to support the structuring of descriptions of the user view of a system; and, IDEF5 (Ontology Description Capture Method) serves as a method for fact collection and knowledge acquisition. The second class of IDEF methods that have been developed are focused on the design portion of the system development process. That is, they encapsulate the best known method for design with a particular technology (or class of technology.) Currently, there are two IDEF design methods; IDEF1X (Data Modeling Method) and IDEF4 (Object-Oriented Design Method). IDEF1X was developed to assist in the design of semantic data models. IDEF4 was developed to address the need for a design method to assist in the production of quality designs for objectoriented implementations.

INTEGRATION DEFINITION FOR FUNCTION MODELING (IDEF0)

Federal Information Processing Standards Publications (FIPS PUBS) are issued by the National Institute of Standards and Technology after approval by the Secretary of Commerce pursuant to Section 111(d) of the Federal Property and Administrative Services Act of 1949 as amended by the Computer Security Act of 1987, Public Law 100-235. 1. Name of Standard. Integration Definition for Function Modeling (IDEF0). 2. Category of Standard. Software Standard, Modeling Techniques. 3. Explanation. This publication announces the adoption of the Integration Definition Function Modeling (IDEF0) as a Federal Information Processing Standard (FIPS). This standard is based on the Air Force Wright Aeronautical Laboratories Integrated Computer- Aided Manufacturing (ICAM) Architecture, Part II, Volume IV - Function Modeling Manual (IDEF0), June 1981. This standard describes the IDEF0 modeling language (semantics and syntax), and associated rules and techniques, for developing structured graphical representations of a system or enterprise. Use of this standard permits the construction of models comprising system functions
Prof. Ricardo Jos Rabelo / Departamento de Automao e Sistemas / UFSC

DAS 5941 Tpicos Especiais em Automao da Manufatura

(activities, actions, processes, operations), functional relationships, and data (information or objects) that support systems integration. This standard is the reference authority for use by system or enterprise modelers required to utilize the IDEF0 modeling technique, by implementors in developing tools for implementing this technique, and by other computer professionals in understanding the precise syntactic and semantic rules of the standard. Objectives The primary objectives of this standard are: To provide a means for completely and consistently modeling the functions (activities, actions, processes, operations) required by a system or enterprise, and the functional relationships and data (information or objects) that support the integration of those functions; To provide a modeling technique which is independent of Computer-Aided Software Engineering (CASE) methods or tools, but which can be used in conjunction with those methods or tools; To provide a modeling technique that has the following characteristics: - Generic (for analysis of systems of varying purpose, scope and complexity); - Rigorous and precise (for production of correct, usable models); - Concise (to facilitate understanding, communication, consensus and validation); - Conceptual (for representation of functional requirements rather than physical or organizational implementations); - Flexible (to support several phases of the lifecycle of a project). Applicability The use of this standard is strongly recommended for projects that: a. Require a modeling technique for the analysis, development, re-engineering, integration, or acquisition of information systems; b. Incorporate a systems or enterprise modeling technique into a business process analysis or software engineering methodology. The specifications of this standard are applicable when system or enterprise modeling techniques are applied to the following: a. Projects requiring IDEF0 as the modeling technique; b. Development of automated software tools implementing the IDEF0 modeling technique. The specifications of this standard are not applicable to those projects requiring a function modeling technique other than IDEF0. Nonstandard features of the IDEF0 technique should be used only when the needed operation or function cannot reasonably be implemented with the standard features alone. Although nonstandard features can be very useful, it should be recognized that the use of these or any other nonstandard elements may make the integration of models more difficult and costly.
Prof. Ricardo Jos Rabelo / Departamento de Automao e Sistemas / UFSC

DAS 5941 Tpicos Especiais em Automao da Manufatura

IDEF Function Modeling Method

IDEF is a method designed to model the decisions, actions, and activities of an organization or system. IDEF was derived from a well-established graphical language, the Structured Analysis and Design Technique (SADT). The United States Air Force commissioned the developers of SADT to develop a function modeling method for analyzing and communicating the functional perspective of a system. Effective IDEF models help to organize the analysis of a system and to promote good communication between the analyst and the customer. IDEF is useful in establishing the scope of an analysis, especially for a functional analysis. As a communication tool, IDEF enhances domain expert involvement and consensus decisionmaking through simplified graphical devices. As an analysis tool, IDEF assists the modeler in identifying what functions are performed, what is needed to perform those functions, what the current system does right, and what the current system does wrong. Thus, IDEF models are often created as one of the first tasks of a system development effort. IDEF Concepts The IDEF method has basic concepts that address each of the needs previously discussed. The basic IDEF concepts include the following. Cell Modeling Graphic Representation The "box and arrow" graphics of an IDEF diagram show the function as a box and the interfaces to or from the function as arrows entering or leaving the box. To express functions, boxes operate simultaneously with other boxes, with the interface arrows "constraining" when and how operations are triggered and controlled. The basic syntax for an IDEF model is shown in the figure below. Communication IDEF concepts designed to enhance communication include the following: Diagrams based on simple box and arrow graphics. English text labels to describe boxes and arrows and glossary and text to define the precise meanings of diagram elements.

Prof. Ricardo Jos Rabelo / Departamento de Automao e Sistemas / UFSC

DAS 5941 Tpicos Especiais em Automao da Manufatura

IDEF Function Box and Interface Arrows The gradual exposition of detail featuring a hierarchical structure, with the major functions at the top and with successive levels of subfunctions revealing well-bounded detail breakout. A "node chart" that provides a quick index for locating details within the hierarchic structure of diagrams. The limitation of detail to no more than six subfunctions on each successive function.

Rigor and Precision The rules of IDEF require sufficient rigor and precision to satisfy needs without overly constraining the analyst. IDEF rules include the following: Control of the details communicated at each level (three to six function boxes at each level of a decomposition). Bounded Context (no omissions or additional out-of-scope detail). Diagram Interface Connectivity (Node numbers, Box numbers, C-numbers, and Detail Reference Expression). Data Structure Connectivity (ICOM codes and the use of parentheses). Unique Labels and Titles (no duplicated names). Syntax Rules for Graphics (boxes and arrows). Data Arrow Branch Constraint (labels for constraining the data flow on branches). Input versus Control Separation (a rule for determining the role of data). Data Arrow Label Requirements (minimum labeling rules). Minimum Control of Function (all functions require at least one control). Purpose and Viewpoint (all models have a purpose and viewpoint statement). Methodology Step-by-step procedures are provided for modeling, review, and integration tasks. Formal training courses for transferring the methodology are available. Organization versus Function The separation of organization from the function is included in the purpose of the model and carried out by the selection of functions and interface names during model development. This concept is taught in the IDEF course, and the continual review of these concepts during model development ensures that organizational viewpoints are avoided. Sequence and Timing Independence Applying the IDEF method results in an organized representation of the activities and the important relations between these activities in a nontemporal fashion. IDEF does not support the specification of a recipe or process. Such detailed descriptions of the specific logic or timing associated with the activities requires the IDEF3 Process Description Capture Method.

Prof. Ricardo Jos Rabelo / Departamento de Automao e Sistemas / UFSC

DAS 5941 Tpicos Especiais em Automao da Manufatura

Strengths and Weaknesses of IDEF The primary strength of IDEF is that the method has proven effective in detailing the system activities for function modeling, the original structured analysis communication goal for IDEF. Activities can be described by their inputs, outputs, controls, and mechanisms (ICOMs). Additionally, the description of the activities of a system can be easily refined into greater and greater detail until the model is as descriptive as necessary for the decision-making task at hand. In fact, one of the observed problems with IDEF models is that they often are so concise that they are understandable only if the reader is a domain expert or has participated in the model development. The hierarchical nature of IDEF facilitates the ability to construct (AS-IS) models that have a top-down representation and interpretation, but which are based on a bottom-up analysis process. Beginning with raw data (generally interview results with domain experts), the modeler starts grouping together activities that are closely related or functionally similar. Through this grouping process, the hierarchy emerges. If an enterprise's functional architecture is being designed (often referred to as TO-BE modeling), top-down construction is usually more appropriate. Beginning with the top-most activity, the TO-BE enterprise can be described via a logical decomposition. The process can be continued recursively to the desired level of detail. When an existing enterprise is being analyzed and modeled (often referred to as AS-IS modeling), observed activities can be described and then combined into a higher level activity. This process also continues until the highest level activity has been described. One problem with IDEF is the tendency of IDEF models to be interpreted as representing a sequence of activities. While IDEF is not intended to be used for modeling activity sequences, it is easy to do so. The activities may be placed in a left to right sequence within a decomposition and connected with the flows. It is natural to order the activities left to right because, if one activity outputs a concept that is used as input by another activity, drawing the activity boxes and concept connections is clearer. Thus, without intent, activity sequencing can be imbedded in the IDEF model. In cases where activity sequences are not included in the model, readers of the model may be tempted to add such an interpretation. This anomalous situation could be considered a weakness of IDEF. However, to correct it would result in the corruption of the basic principles on which IDEF is based and hence would lose the proven benefits of the method. The abstraction away from timing, sequencing, and decision logic allows concision in an IDEF model. However, such abstraction also contributes to comprehension difficulties among readers outside the domain. This particular problem has been addressed by the IDEF3 method.

Prof. Ricardo Jos Rabelo / Departamento de Automao e Sistemas / UFSC