Overv iew of Funct ion model l ing - IDEFO

Finn Jorgensen

Institute for Product Development Technical University of Denmark

& Sant + Bendix A/S, Denmark, member of Coopers & Lybrand Consulting Group

Abstract: The paper gives a brief overview over the background and contents of the function modelling methodology IDEF0. The purpose is to inform the reader about the origin of the methodology, the methods related to it, why and how to use it, and the terminology and semantics in the methodology.

1 Introduction

In the United States the IDEF0 modelling technique (Integrated DEFinition method 0) is about to become part of the Federal Information Processing Standard (FIPS) complex. This means that all federal institutions e.g. Department of Defence and suppliers to federal institutions are encouraged to use the method when documenting e.g. manufacturing systems. The methodology will hereby in the future be the "standard" methodology to use in the industry.

2 Background for the development of the IDEF-methodologies

As a result of the considerable rationalisation efforts in the production environment, especially on the shopfloor level, which have characterised this century, it is only a minor part of the total costs of manufacturing a product that refers to the hands-on costs. Today, these costs represent 30 - 40% of the total costs of manufacturing a product. (Not to be mistaken with the time that it takes to manufacture a product - or the period of contact, which based on experience is between 5 - 10% of the total time that it takes to manufacture the product.)

Today, non-touch costs related to manufacturing the product represent 60 - 70% of the total manufacturing costs. Non-touch costs do not only include the indirect costs on the administrative level in a company. They also include costs resulting from the entire information work taking place on the shopfloor (e.g., when the shop foreman instructs a co-worker), intermediate stock costs, control costs, quality costs, etc.

When the above is recognised, it is clear that productivity improvements will have the largest positive effect, if found in the non-touch area. Integrated productivity improvements are also found in this area, as these to a high extent involve information.

The 1DEF0 method was developed to support the analysis work within both the non-touch and the hands-on areas. It was developed with a view to creating the basis

341

for a complete description of a company's functional structure, data requirements, and data creation.

The work on the development of the method was ordered by the U. S. Airforce, which in 1975 commenced the development programme ICAM (Integrated Computer Aided Manufacturing). The programme lasted until 1985 and is responsible for much of the interest in CIM (Computer Integrated Manufacturing) in the U. S. In connection with the programme, a number of methods were developed. When combined, these methods represent a complete description of a company seen from an information point of view. The methods are:

9 Function modelling- IDEFO

9 Information modelling- IDEF1 (and IDEFI-X)

9 Dynamic modelling- 1DEF2

As mentioned, the 1DEF0 method is suitable for describing a company's functions and their interrelation - data requirements and creation. This can be done in a gradual detailing with a determined syntax as to how the model could be broken down in an unambiguous way. With this determined structure and syntax, it can also be used for system documentation in connection with e.g., quality control, where individual or departmental responsibilities in connection with company activities play an important role. The background for the method will be described further in the below.

The 1DEFI method was built on the ideas of Entity-Relationship modelling developed by Chen. In connection with the ICAM programme, Chert was asked - together with a number of other experts within data modelling - to find the most suited method. IDEF1 is thus a method for modelling data and the structure of data. An IDEF1 model can be applied as a basis for the creation of a database on a computer. The method is especially suitable for structuring relational databases. If the reader requires more information on the method, please refer to literature on the subject. A few lhcilities left out from the original Entity-Relationship method have later been added to the IDEF 1 method in order to simplify the use of the method. This enhanced version of 1DEFI, IDEFl-extended, is called IDEF1-X.

The IDEF0 and IDEF1-X methods supplement each other excellently when the purpose is to map the data and function structure of a company's data. However, the methods do not show the sequence or the duration of activities. The IDEF2 method was, therefore, developed in order to model the dynamic behaviour in a company, e.g., duration of process time on a machine, size of a buffer in front of a machine, and waiting time until a machine is available. The aim was that the model should form the basis for computer simulation (evaluation of consequence) of a certain system configuration. The participants in the development of IDEF2 had, as far as the author has been informed, special interests in their own products that were similar to IDEF2. These modelling tools had already been integrated in marketed products for computer simulation and had, therefore, the largest distribution. The result is that today there exists no agreed recommendation for a standard as to how the dynamic behaviour of a system should be analysed or documented.

The 1DEFO and IDEFI-X methods are today used all over the world. Today, the American Department of Defence demands from any company wanting to be a supplier that their activities and data structure have been documented using IDEF0

342

and 1DEFI. The method is also used by the American National Institute for Standards and Technology (NIST). As mentioned before, the methods are expected to be nominated Federal Information Processing Standards, meaning that an even larger part of the American industry will apply these methods.

In Denmark, the methods were imported in connection with the CIM/GEMS project (CIM/General MEthods for specific Solutions), which lasted from 1986 to 1989. Through a close co-operation with Danish industry, the Institute of Production Management and Industrial Engineering and the Institute for Production Development at the Technical University of Denmark transferred these methods to Danish companies and applied the gained experience to adjust the methods to Danish industry and traditions.

3 The origin of IDEF0

The IDEF0 method is based on the Structured Analysis and Design Technique (SADT) from Sottech. The basis of SADT was formed during a project initiated by ITT, where Softech, including "the inventor" Douglas T. Ross, together with MIT (Massachusetts Institute of Technology) formalised the method. Together with Softech, the U. S. Airforce developed the method and demanded through the financing of the development work that it was published so that all companies could use it. On the IDEF Users Group Meeting in Salt Lake City in October 1993 the author of this paper had several talks with Douglas T. Ross, among other things about the difficult negotiations concerning rights to the methods.

In connection with the development work the U. S Airforce had the following requirements to the project:

9 Since the architecture is to depict manufacturing, it must be able to express manufacturing operations in a natural and straightforward way.

9 Since the subject is so vast and complex, it must be concise and provide a straightforward means of locating details of interest easily and quickly.

9 Since it must be used by a wide audience, it must be able to communicate to a wide variety of Aerospace Industry manufacturing personnel as well as to Air Force ICAM Program Office Personnel.

9 Since it must serve as a baseline for generic subsystem planning, development, and implementation, it must permit sufficient rigor and precision to insure orderly and correct results.

9 Since the baseline must be developed through the co-operative effort of a large segment of the Aerospace industry, it must include a methodology (rules and procedures) for its use that permit many diverse groups to develop architecture pieces and that permit wide-spread review, critique, and approval.

9 Since the baseline must represent the entire Aerospace industry rather than any one company or industry segment, the method must include a means of separating "organisation" from function; that is, a common agreement cannot be achieved unless the individual company organisational differences are separated out and only the common functional thread is captured.

343

These requirements were fulfilled to a very high degree. The degree will not be discussed here, as the below description of the method will supply the reader with the basis fbr an evaluation hereof.

4 What can IDEF0 be used for in design and implementation of integrated systems?

IDEF0 has several pul]~oses in connection with the building of integrated systems. A recognised procedure when building integrated systems is that the first step is a general "cleaning up" of the company's existing business procedures (also called "broom and bucket"). People working with productivity improvements cannot be expected to be able to assess all the activities or functions are which are taking place in the company. The IDEF0-method could, therefore, help to clarify a number of aspects (all are, of course, not mentioned):

9 What functions are being performed in the company, by whom and how long do they take?

9 What information do these functions require in order to be able to perform their work and where do they get this information from?

9 What information sets the goals, controls, starts, or stops the execution of the function and where does the information come from?

9 What information is being created in connection with the execution of the function and to where is it sent.

A proper application of the IDEF0 method is to reach an agreement between analysts (preferably company employees) as to how daily routines are being performed. The method can thus be applied for clarifying and reaching an agreement as to how the information apparatus of the company actually functions.

The work performed on the elaboration of the model is, thereby, to a high degree part of the result. The documentation can be used as a basis for a discussion for the future work and as a basis for future system changes. However, an agreement between analysts as to how the system functions is clearly one of the most important results of an IDEF0 analysis.

In Denmark, the IDEF0 method has been used with good results in connection with for example TBM projects (Time-Based Management), where the focus is on the time consumed in each individual manufacturing function, including administrative functions. Furthermore, the new Business Process Re-engineering (BPR) concept is very suited for IDEF0, as IDEF0 is independent of the organisation structure and only focuses on the functions and processes in the organisation. Activity-Based Costing (ABC) is also a method supported by an IDEF0 analysis in many applications seen in the U. S.

4.1 Top-down Planning- Bottom-up Implementation

The building of a company-wide CIM system cannot take place all at once. You have to start with limited elements of the system in areas where the largest economic effect - or largest demonstrative effect (influencing on attitudes) - can be found. The main principle when building CIM systems is to "think big" but "start small". If you want to

344

work based on this principle, IDEF0 is an excellent tool, as it supports the selection of areas where the first CIM applications should be built and at the same time ensures that these will be integrable with future applications.

5 L imitat ions to method

The IDEF0 method was originally built to describe the relation and nature of activities. Data represented in the method are not shown ha relation. I.e., based on an IDEF0 model it is not possible to build a database or a new paper system (you need an IDEFl-model to cover these aspects). Equally, the method does not describe quantifiable sizes (e.g., size of stock). The method was also not designed to describe detailed process operations (material flow, time on stock, etc.)

6 IDEF0 - te rmino logy and concepts

The below shortly describes the IDEF0 terminology. Based on this chapter, the reader should be able to read and understand the main principles of an IDEF0-diagram.

6.1 Boxes = functions

The above describes the main idea of IDEF0. The method is particularly powerful due to the graphics that are applied to a very high degree. The graphical symbols have a very determined meaning in an IDEF0-model. The graphical symbols making up a model are simply arrows and boxes.

The company's functions, e.g., manufacturing of the product, production control, storage, informing of staff, etc., are described in IDEF0 using boxes. As the method should differentiate between the organisationally limited functions and the "actually performed" functions, the functions are in IDEF0 described using active verbs, i.e., "control production", "manufacture part", "mount gasket", "develop product", etc., and not "production control, "manufacturing of part", "mounting of gasket" or "product development".

The boxes, therefore, also describe a limit to the scope of the function. This is very useful when the function is to be detailed in another diagram.

6.2 Arrows = data or materials

Within the IDEF0 method there are four main types of information, i.e., input, output, constraints, and resource mechanisms. As compared to former methods, the two last categories are new making the method especially suited for describing manufacturing activities. A description of the four types of information follows. In IDEF0, information or materials are described using arrows. Placing of the arrows on the sides of the box is as shown in Figure 1. Input means input to the co-worker.

345

Information controlling the transformation

(start, goal, limits, quality, choices, stop)

1 Physical / I Data/physical objects object/data ~ 1 Transform | ~ that are transformed transformed I v or produced by a in a function | function

T Mechanism (optional)

Person/tool forming part of or performing the function

Figure 1. The main elements of an IDEF0 diagram - the box, the arrows and text.

Input: In connection with the manufacturing of products, the co-workers (the functions) require a certain amount of information in order to be able to perform the planned work. This information could be priority lists, drawings, parts lists, quality specifications, etc. The method is especially suitable for describing information, but the arrows can also contain materials and thus help describe material flows. In an 1DEF0-diagram, input information is shown using an arrow entering the box on the left side.

Output: In the execution of the work, the co-worker (the function) transforms or creates an amount of information to be applied in connection with the product (times, amount, quality, etc.). This information could also be used for post-calculations or as default times in the future planning. As mentioned, an arrow can also contain materials and not just information about materials. Output is always shown using an arrow leaving the box on the right side.

Constraints: In a production environment all performed activities are subject to a number of limitations determined by functions taking place earlier in the production course. The co-worker's activities are started based on constraints. Constraints can also be verbal instructions from the shop foreman, the arrival of an order card, a routing list, or the item which is to be processed. Constraints can also be information as to when a given activity should terminate or a message about change in choice of tool or material. Constraints means limitations, formulation of goals, control data, etc. Constraints enter the box from the top.

Resource mechanisms: Functions cannot be performed without the presence of a resource mechanism. Examples of resource mechanisms are: machines, calculators, co-workers, electricity, fixtures, tools, etc. At the top level of a model it makes no sense to state all resource mechanisms used by a company. Therefore, a diagram only

346

shows the resource mechanisms where it is necessary to underline that the mechanism must be present or where it is a question of a special type of mechanism. In connection with the documentation of quality control systems, responsibilities as to the execution of activities can be shown using resource mechanisms. Resource mechanisms always enter the box from the bottom.

The content of the arrows is always described with a noun, e.g., drawing, parts list, production plan, flange, instruction, form, etc.

In connection with the elaboration of a diagram there might be some doubt as to whether the information that you want to show should be categorised as input or constraint. The questions to be asked are whether the information in any way initiates, defines goals, defines the function or describes how much time it should take. If so, it is a constraint. IDEF0 defines a main rule to be applied when in doubt. It says that if in doubt, the information should be represented in the diagram as a constraint.

6.3 Drawing of a diagram

The procedure applied when drawing a diagram is of course individual. The IDEF0 method requires that a number of choices are made when diagramming. There is no rule as to how these choices should'be made. Figure 2 shows how a typical manufacturing process is diagrammed using the method. The diagrammer should, before diagramming, consider how the entering activities should be grouped. Three functions were chosen in the example, i.e.,

9 Plan production

9 Procure materials and resources

9 Perform manufacturing

In the diagram the boxes are numbered from the left to the right (not shown in Figure 2). Arabic numerals are applied and located in the lower right comer of the box.

6.4 Purpose, viewpoint, and context

In order to guide the focusing of an IDEF0 modelling there are a number of requirements that have to be observed before starting the actual modelling. The previously mentioned procedure can be applied at a very early stage of the modelling. When starting the work with the model to be published (applied), an agreement must have been reached as to: purpose, viewpoint, and context.

Purpose, viewpoint, and context describe the limits, surroundings, and stop criterias of the model. They are characterised by the fact that they are all established before the actual modelling starts and that they are attached to the final model.

Purpose

The reason for describing the purpose of the model is to guide the modelling work in the correct direction and to ensure that an agreement is reached as to when the model has been elaborated sufficiently in order to fulfil the purpose. IDEFO models consist of a hierarchy of models, gradually detailing one another. It is, therefore, important to establish a criterion for when the modelling work should be finished in order to control the time consumed for this work.

347

1. Draw the boxes

Plan production

2. Add major inputs and outputs Product I [ design ~ Plan

production

Procure I materials and I

resources I

Production plan

Perform ] production

Procure [ Materials ,. d I " materials an Resources ~ resources I "

Materials J Perform I Produck q production "

3. Connect input and output and add constraints Production ~ requirements

Product / de~_~ productionPlan I Production~ lan

Procure [Materials materials and[ "]

resources r /

T [ [Per form[Product .~ "--~ production ]

Planners Resources Figure 2. Methodology for drawing diagrams.

348

An example could be that the purpose of the model is to describe the course of an order through the company from reservation of the product by the customer until it is delivered.

6.5 Viewpoint

The viewpoint of an IDEF0 model ensures that the criteria for the model are established (similar to purpose). Model viewpoint could for example be production planning and control, i.e., only production planing and control aspects are included in the model. Detailed information of the production technical department is for example perhaps not included. Another viewpoint could be quality management.

Viewpoint could be described more in detail using a house as an example, If you want to "model" a house, there are several viewpoints. The family interested in the house will most probably look at the architect's perspectives first. The plumber will look at a diagram showing where plumbing is required, and the electrician would be interested in seeing where to install the required electricity.

Viewpoint is important in order to economise with the space in the diagrams and with the time consumed by the modelling work. The drawing that is sent to the plumber should only contain the information that is relevant for him, as additional information will only cause confusion and "steal" time.

Context

Context means connection and delimitation. Determination of a model's context limits the functional area that is being modelled.

The best way of describing the modelled area is to look at the first diagram in the model. The first diagram in a model only consists of one box, which on an overall level shows the functions contained in the model. Figure 3 shows a so-called A-0 diagram (pronounced A minus 0, which is a specific IDEF0 term). The model only describes activities in connection with the manufacturing of hair dryers. The diagram also shows the main types of input, output, constraints, and resource mechanisms applied in the model.

As mentioned, viewpoint primarily describes the content of the arrows, and context primarily describes boxes. These can, however, not be seen out of context, and there will, therefore, bee some overlap between these functions.

As has already been mentioned, the agreement as to purpose, viewpoint, and context is a very important prerequisite for the modelling work. If the modelling work involves several employees in the company and possibly consultants, it is extremely necessary that all involved "modellers" together agree upon purpose, viewpoint and context. When performing this work, it will most likely become evident that there are many different conceptions of the model to be built. It is, therefore, important to agree upon a drawn up purpose, viewpoint, and context and then work with these as the basis. It is not difficult to imagine what the model would look like, if no agreement has been reached before starting the modelling work, much less the wasted effort contributed by the participants.

349

Drawings

i rderorder priority

L I

Raw materials I Produce 9 l hair dryer

1 Finished parts

Scrap

Fools Vlachinery

Figure 3. Example of a so-called A-0 diagram, which is limiting the contents of functions and data of the model.

7 Hierarchical decomposition of an IDEF0 model

One of the characteristics of an IDEF-model is the possibility to represent a very complex system in a gradual degree of detailing. It also ensures that details can be found and that connections to other elements in the model can be seen immediately. This is made possible by allowing a box to be "opened", thereby seeing what it contains in a very detailed form.

The hierarchy in an IDEF0 model is based on the so-called node-numbering convention (cf. figure 4). According to this convention, the first diagram, which only contains one box, is called A-0, i.e., A minus 0. The A-0 diagram could be detailed further in an A0 diagram, i.e., A zero. The A0 diagram describes the first subgrouping of the function mentioned in the A-0 diagram.

The advantage of node-numbering now becomes apparent, as the breakdown of the first box in the A0 diagram is called AI, the second box in the A0 diagram is called A2, etc. The above drawing illustrates yet another level, i.e., A12, which contains the details of box 2 in diagram A1 and A32, which is the details of box 2 in diagram A3. It is evident, that all arrows from the top level diagram has to be migrated to the lower level of the model.

Only 6 boxes are allowed in one diagram. This is partly due to the fact that psychologists have proved that we are only capable of containing 5 - 7 things in our head at the same time and that this limit will imply that the hierarchical structure is applied. The lower limit of 3 boxes has been included to ensure that the diagram will contain sufficient details to justify a decomposition hereof.

350

A12

~j l , ,

Figure 4. The hierarchical decomposition of an IDEF0 model.

More general

Ir More

detailed

The diagrams can be detailed by decomposition of the individual boxes. The Node number shows the level of the decomposition. Eg. diagram A32 is the detailed

description of box 2 on diagram A3.

8 Diagramming rules

The 1DEF0 method differs from similar methods in that IDEF0 applies a fixed set of requirements as to how to build a diagram. The aim of these strict requiremnets is to attain a very reader friendly representation as it will be possible for a person familiar with the method to very quickly gain an overview of the contents of a diagram. Another aim is to build a standard representation, which can be understood by all. These requirements should be observed. The below shortly describes the most important rules.

Input, output and, constraint arrows represent "data classes" or "data categories".

Figure 5. Example of an information stream with the common name "Production guidelines"

351

Output fi'om a box should always originate 100% from input and resource mechanisms together. Control information is normally not transformed.

Constraint, input, and resource mechanisms can branch out. Data on each branch can be used at the same time (it is for instance copied oz" retrieved from a data base). When arrows are divided into components, the content is available on each arrow, if otherwise has not been stated (see figure 6).

I Prepare I Budget budget g"

Produce [ product ]

Figure 6. Dala on each branch can be used at the same time.

9 Diagramming rules

Below some of the fundamental diagramming rules are mentioned. The main purpose of the (very strict) rules are the aim of reaching a standard representation and high level of readability.

Boundary arrows should be collected Not separated

Apply vertical and horizontal I ~___.~ rather arrows than[

The distance between parallel arrows should be so that text can be placed in between

l rather J than r

352

Arrows with the same source and destination are joined, if the content is related.

I 11 ~ ratherthan Arrows should not cross, unless absolutely necessary

II ]_ rather than

Crossings that can be used.

IIII

When an arrow contains input as well as control, it should be diagrammed as control.

The boxes should always I show control and output. I Input is optional.

Control feedback is "up and over".

I ,I

Crossings that cannot be used.

II~ --I- I I ratherthan

or

2, 1

! !

89 Input feedback is "down and under".

,[ I

I

353

10 Example of an IDEF0 diagram

An example of an IDEF0 diagram can be found at the end of this contribution.

11 References:

Integrated Computer-Aided Manufacturing (ICAM), Architecture Part II, Volume IV - Function Modeling Manual (IDEF0), Sofiech Inc., Wright-Patterson Air Force Base, Ohio 45433., AFWAL-TR-81-4023, Volume IV.

A short Course in Systems Development Methodology (SDM), ICAM Technology Transfer course, Ric Mayer, Texas A&M University, Dept. of Industrial Engineering, USA.

IDEF0 - Functioning, ICAM Technology Transfer course, Ric Mayer, Texas A&M University, Dept. of Industrial Engineering, USA.

IDEF0 - Function Modelling, Course material, Peter Yeomans, MicroMatch Limited, 10 Salamanca Crowthorne, England, RG 11 6AP, February 1987.

lntroduktion til CIM, Funktionsmodellering - IDEF0, course material, Finn Jorgensen, Institute for Product Development, Technical University of Denmark, 1989.

Funktionsmodellering - IDEF0, course material, Finn Jorgensen, Institute for Product Development, Technical University of Denmark, ! 990.

Overblik over Funktionsmodellering - IDEF0. Course handbook in the course Industrial Information Systems, DTU. Finn Jorgensen, Institute for Product Development, Technical University of Denmark, 1991.

Funktionsmodellering - IDEF0. Manual for Reviewere. Issued for Asea Brown Boveri. Finn Jorgensen, Institute for Product Development, Technical University of Denmark, 1992.

IDEFl-Information Modelling, ICAM Technology Transfer, Robert E. Young. Dept. of Industrial Engineering, Texas A&M University, USA.

A Structured Approach to FMS modelling, S. K. Banerjee; 1. AI-Maliki Int. J. Computer Integrated Manufacturing, 1988,vol. 1, no. 2, page 77-78.

IDEF - Anvendt sore driflsteknisk v~erktoj, J. J. Ibsen; P. Karsholt, Institute for Production Management and Industrial Engineering, Technical University of Denmark, publication no. DI.87.10 - B, 1986.

Prototype af et CIM-System, Udviklet og implementeret under anvendelse af IDEF- metoderne, 2. Edition, Michael Rasmussen & Finn Jorgensen, CIM/GEMS publication no. CG88/T28, 1988.

IDEFl-lnformationsmodellering, course material, Robert E. Young, CIM/GEMS project 1988.

USED

AT:

AU

THO

R: F

inn J=

gens

en & M

icha

el

PRO

JECT

: CI

M/G

EMS a

t John

CO

MPA

NY: J

ohn D

oe Inc.

FI

LE:

F:~

MIC

HFIH

NU~

31-G

EN

E.DR

W

NOTE

S: 1

2

3

4

5

8

7

$

9

10

DAT

E:

t4/0

6 W

ORK

ING

~

D

ATE

REV:

. 02

D

RAFT

X RE

COM

MEN

DED

PUBL

ICAT

ION

I

CO

l'r

r'n

r~

D

Res

erva

tions

Expe

cted

I

I udg

et

Rec

eive

orde

m

& Pe

rfor

m Mai

n Pl

anni

ng

~O

pi~

i i I I I 9

r i

Cal

cula

te

Mat

eria

l Re

quire

men

ts

Prod

uctio

n D

o sc

hedu

les

t c,

~t~

-~

el

,nn~

g

Man

ufac

turin

g da

ta

)

Sa~

s pro

ject

~

Res

ourc

e use

Purc

hase

orde

rs

Purc

hase

Mat

ed-

als a

nd Sla

lt

Pred

atio

n

Run

n~g u

der

s

War

ehou

se leve

l

Surv

ey a

nd

' ~'

co

.~

~:

Stoc

k ~e

Pm

duc~

on

Smw

w

Gm

ltml

Wal

ll~m

m

Prod

uctio

n orde

rs

& P

rioR

ies

Com

p~te

d

NUM

BER:

.o

oE:

A31

T,

,.E:

Rec

eive

Ord

ers,

Con

trol

and

Initi

ate

Man

ufac

turi

ng

[~