P. Bernus et al. (eds.), Modelling and Methodologies for Enterprise ... · Fluor Daniel, Inc., is a...

2

Use of the Purdue Enterprise Reference Architecture and Methodology in industry (the Fluor Daniel example)

Gary A. Rathwell Fluor Daniel, Inc. 200 W. Monroe St., Chicago, Illinois, 60606 USA Tel: 312 368 3531

Theodore J. Williams Purdue University 1293 Potter Center Room 308D, West Lafayette, Indiana, 47907-1293 USA Tel: 317 494 7434, e-mail: [email protected]

Abstract The Fluor Daniel Company, a major engineering consulting and construction firm, is applying the Purdue Enterprise Reference Architecture and Methodology (PERA) to their project work. They have established these methods across a range of industrial areas which the company serves. They have used PERA to present a framework around which much of their current work practices can be organized. These will be discussed in this paper.

In addition, application of this new technology upon their existing practices and company culture has engendered the necessity of altering the way in which PERA is presented to company and client personnel and organizations who were not previously familiar with PERA. These changes are also discussed here.

Keywords Enterprise, Enterprise Integration, Integration Methodologies, Architecture

1 INTRODUCTION

Enterprise integration has been a much promoted and debated technology in the United States and most other advanced industrial countries over the last two decades. Originally proposed as computer integrated manufacturing (CIM), it has recently been generally described as computer integrated enterprises (CIE), or more commonly, simply as enterprise integration.

P. Bernus et al. (eds.), Modelling and Methodologies for Enterprise Integration© Springer Science+Business Media Dordrecht 1996

The Purdue enterprise reference architecture and methodology in industry 13

The intuitively obvious, and therefore readily expected, economic and productivity benefits of the process-wide, plant-wide, or corporation-wide coordination of all operating variables have often proven to be a will-of-the-wisp. This is a consequence of the vast amount of detail and the extremely large number of operational variables and plant operating factors which have to be considered in such a project.

What is needed is a management and engineering technology which can have the effect of 'minimizing the apparent complexity' (Nevins, 1991) of these systems. It must also present an intuitively correct and easy-to-follow methodology for unit, plant and company engineering and operational design and planning. Only then can it accomplish the above tasks and attain the hoped for goals of the endeavor. Many attempts by various groups have been made to define this technology but so far success still seems to elude the practitioners.

PERA (Williams, 1991) has recently been proposed as such a methodology and one which appears to have major expectations for success where others have failed. The Fluor Daniel Company has been the major industrial partner to apply this technology to date. They have had considerable success, well beyond that of earlier studies with other methodologies, and expect further benefits as the technology pervades all aspects of their mission.

In selling the use of this technology internally, Fluor Daniel has combined it with their previous common methods. In addition, they have modified the details of presentation of PERA and thus its appearance, but not its content. This has greatly improved the degree and rate of acceptance of this technology by their staff. This paper will treat in detail the resulting combined methodology and the changes made to improve its acceptability.

The new technology has been labeled the Fluor Daniel-PERA methodology by the company.

2 BACKGROUND

Fluor Daniel, Inc., is a major engineering, procurement, and construction company which serves clients in all types of industries, including process and discrete manufacturing. They also serve government, telecommunications, highways, and other 'infrastructure' clients. Fluor Daniel, Inc., is a member company of the Users Group on Architectures for Enterprise Integration at Purdue University and thus is a participant in the ongoing development of the Purdue Enterprise Reference Architecture and Methodology. Purdue University's cooperation in the Users Group was carried out through the Purdue Laboratory for Applied Industrial Control (PLAIC), an engineering unit engaged in postgraduate research in the industrial control field, particularly computer-based process and enterprise-wide control systems. Mr. Rathwell was the principal Fluor Daniel representative to the Users Group. Professor Williams served as Director of PLAIC.

The earliest work in PERA had been carried out by the Industry-Purdue University Consortium for Computer Integrated Manufacturing (Consortium, 1992), a group of ten major process industry, control and computer companies chartered to work together during the period 1989-92. The Users Group succeeded the Consortium with many of the same members.

14 Part One Papers

3 SELLING METHODS

3.1 Why Use the Fluor Daniel-PERA Methodology?

Fluor Daniel personnel who were familiar with the Purdue Enterprise Reference Architecture and the Purdue Methodology (PERA) believed it to be important for their company for the following reasons: 1. It provided a full 'life cycle' for the facilities being developed in the company's

projects with its clients. 2. It provides a means for handling human and organizational factors inherent in these

projects and in Fluor Daniel's approach to these projects. 3. It presents a 'phased' approach to reduce rework in carrying out projects. 4. It provides an understanding of the dynamic interfaces between the many disciplines

of engineering and management working on a particular project. 5. It provides informational models of each phase to improve understanding and to

monitor the work in progress. 6. Perhaps best of all, the PERA diagram looks intuitively correct and presents the life

history in a way which follows the conception which most engineers and industry management have of their plants and companies.

Each of these capabilities were more successful than the corresponding ones available from previous methods or were entirely missing from those earlier methodologies.

3.2 Some Subtle Changes Made in the Presentation to Improve Acceptance

Figures I and 2 present the PERA Life Cycle as initially developed by the IndustryPurdue University Consortium for CIM which originated the PERA Methodology (Consortium, 1992; Williams, 1991; Li, 1994 ). Figure 3 shows the Life Cycle Diagram divided into numbered blocks and nodes. This figure was accompanied in the PERA documentation by an extensive table detailing the tasks required at each numbered location, the models and tools available or needed for carrying out each task and the deliverables to be produced as a result. This listing greatly expanded the brief notations on Figure 2 and particularly those on the second page of Figure 2, a very valuable presentation but requiring considerable detail to present its message. The above listing is not included here for reasons of space requirements in this paper. It is included in the References (Consortium, 1992; Williams, 1991; Li, 1994).

Figure 4 shows the single sheet presentation of all of the above material as eventually used by Fluor Daniel personnel in explaining the architecture and its potential usefulness to their compatriots (both internal company groups and external customers). This was thus a major increase in convenience of reference for the user over the previous Purdue documentation.


IDENTIFICATION OF - r- THE ENTERPRISE BUSINESS ENTITY

CONCEPT PHASE 0 R LAVER

(MISSION, VISION AND VALUES)

- ~ - ,.......

- ~ - - DEFINITION PHASE OR LAVER

- ~ - - (FUNCTIONAL

- - - - REQUIREMENTS)

./"\.. ,/'\.. I

FUNCTIONAL DESIG I OR SPECIFICATION

I I PHASE OR LAVER I I

N

+ .,, + DETAILED

DESIGN PHASE OR LAVER

... ... + MANIFESTATION

PHASE OR LAVER

+ + + OPERATIONS

PHASE OR LAVER

+ + + RECYCLE AND DISPOS AL

PHASE OR LAVER

Figure 1 The layering of the Purdue Enterprise Reference Architecture in terms of the types of tasks that are occurring within those regions on the graphical representation of the architecture.

16 Part One Papers

z 0 ~ L.U cr (f)

iJi >-...J <(

z <(

...J <( z 0 >= () z ::> u.

z 0 ~ L.U cr z Q !;< >--z L.U ::;; L.U ...J a.. ~

w (f) <(

I a.. >a.. w () z 0 ()

L.U (f) <(

I "-z 0 >= z u:: L.U 0

L.U (f) <(

I a.. z <!J iJi L.U 0

z <!J iJi L.U 0

...J <(

z 0 ;::: () z ::> u.

z <!J iJi L.U 0

0 L.U --' ~ w 0

ENTERPRISE BUSINESS ENTITY (EBE)

~ ENTERPRISE INTEGRATION

MISSION, VISION AND VALUES; MANAGEMENT PHILOSOPHIES

/'"""~ MANUFACTURING, PERSONNEL AND INFORMATION POLCIES,

ETC.

l PLANNING, SCHEDULING,

CONTROL AND DATA MANAGEMENT

REQUIREMENTS

l TASK AND FUNCTIONAL

MODULES

l INFORMATION FUNCTIONAL

NETWORK

1

(POLICIES)

(REQUIREMENTS)

(BUILDING BLOCK

MODULES)

(NETWORKS)

PRESENT OR PROPOSED (CONCEPT) PRODUCTION ENTITY INCLUDING

PRODUCT AND OPERATIONAL POLICIES

l PHYSICAL PRODUCTION

REQUIREMENTS (OPERATIONS)

l MANUFACTURING FUNCTIONAL (UNIT OPERATIONS) MODULES,

ETC.

l MANUFACTURING

(UNIT OPERATIONS) FUNCTIONAL NETWORK

j

IDENTIFICATION OF THE

ENTERPRISE BUSINESS ENTITY

CONCEPT LAYER (MISSION, VISION

AND VALUES AND

POLICIES)

DEFINITION LAYER

INFOI)~II."hbN..._.ARCHITECTURE J MANUF~R~ ~ ~ A~ECTURE -........... DISTRIBUTION

.-----.....;.;OJK.:..;,;-;,;:,:;_;_;::_:_::,------l._-, 1<11----- OF INFORMATION 1 HUMAN AND ORGANIZATIONAL 1 MANUFACTURING FUNCTIONS

ARCSHYISTTEECMTSURE 1: ARCHITECTURE 1 EQUIPMENT

z 1

>-- z ~ : ARCHITECTURE

Q• ffigw 1--(.!)w 1 ~ ~· z<ta: ffi~~ :~ ~· O~:::J z:::lt- ,::ii: 01 ~~b 0,_ 0 ,~ ~I QU.W ~~~ I::J c:r:• u~t:: Ou..- ,ce U..l I (.)::>I 1LL o, zwu zU ,o ~· <J:a: ~<a: ·~ wl ~1--<( ~~<( IW

.,_, =>u.. ~ ·~ ~~ :X: 0 I IW t...====;:::=========:::J

INFORMATION SYSTEMS

ARCHITECTURE

z 0

~ ::; 0 1-::> < u. 0 ,_ z w IX w

HUMAN AND ORGANIZATIONAL ARCHITECTURE

z 0 ;:: « ::; 0 1-::> < u. 0 1-z w !;( w

MANUFACTURING EQUIPMENT

ARCHITECTURE

SPECIFICATION LAYER

FUNCTIONAL DESIGN

DETAILED DESIGN LAYER

DETAILED PHYSICAL

L-------------4---------------------------------'~--------------'~----D~E.SIGN

Figure 2 Development of an enterprise program as shown by the Purdue Enterprise Reference Architecture (phase of the program).

2 ::> 3 "' "' z Q ;;: 2 .u ;:;; .u --' ,_ :;§ .u I

.L ::> 2 Q ;;: :::> ~ z ::> :..>

z ::> 3 "-'

"' 'f)

2 Q ;;: " .u 0.. ::>

w (/) ~ :I: "-z

"' u; w 0

ow z"' ~~ :I: z"-2z 1-0 o-::;,1-a::5 I--' (J)~ Zl-O"' o:;;:

UJ

"' ~ :I: "-Cll z 2 ~ a; w "-0

w

"' ~ :I: "---' ~

"' 0 Q.

"' 0 a: 0

~ 0 >-0 w a:


z s> (/) w 0

--' ~ z 0 ;:: 0 z ::> u..

INFORMATION I HUMAN AND A fNIZATIONAL SYSTEMS I ARC~ E URE

ARCHITECTURE : ,...z "-0 Zo z2 ~~~ Q, WI-UJ

!;<o z<a: ~~2 ::fl 0::1:::>

Oo o._a:t- o,...o 5• ::;oo "-ow ou.w ~~t: "'' u~t: U..l I o:;,:I: o, zwo zz 0 .... , <I a: ~<a:

~. ::11-< ::;::z"" ,_, "'u.. ::> i:jo "'o I

l "l INFORMATION HUMAN AND ORGANIZATIONAL

SYSTEMS ARCHITECTURE ARCHITECTURE z

"' z u; w EQUIPMENT

0 PERSONNEL SKILLS DEVELOPMENT ;::

0 SELECTION <

"' 0 w --' < 1-w 0

...... 0 ORGANIZATIONAL PLANNING ,_ SYSTEMS :0 ... ' < LAYOUT ... TRAINING PROGRAMS DEVELOPMENT

0 ,_ z

~ w

1 INFORMATION HUMAN AND ORGANIZATIONAL

SYSTEMS ARCHITECTURE ARCHITECTURE

z PROGRAMMING g

< STAFFING

... ... "' ' ... EQUIPMENT 0 TRAINING ....

INSTALLATION :0 < "-

CHECK·OUT 0 ,... ..... ~

COMMISSIONING~ w



z 0

CONTINUING ~ CONTINUING ORGANZATIONAL DEVELOPMENT i!j DEVELOPMENT ...

CONTINUING SKILL AND HUMAN ...... ,_ MAINTENANCE ::> RELATIONS TRAINING < ...

0 1-z w ,_ :;;



z REVAMPING OF g RETRAINING OF PERSONNEL FOR INFORMATION ;i NEW SKILLS NEEDED FOR NEW SYSTEMS FOR ~ OR REVAMPED INSTALLATION NEW MISSION ~ OR PLANT . ....

...... "-RECYCLE OR 0

1-DISPOSAL z

UNNEEDED w 1-

EQUIPMENT >< w

I MANUFACTURING I EQUIPMENT I

ARCHITECTURE I

~~ '"' ·~ 1:0 o< ,.._ ,o o'Z ow

·~ ow

l MANUFACTURING

EQUIPMENT ARCHITECTURE

z 0

EQUIPMENT ;:: < DETAILED "' 0 DESIGN ,_ ::> < "-0 PLANT ,_ ~ FACILITIES 1- DESIGN >< w

1 MANUFACTURING


z 0 ;:: CONSTRUCTION <

"' .. .... 0 PLANT TESTING 1-::> < "- COMMISSIONING 0 1-z

~ w

1 MANUFACTURING


z 0 ;:: CONTINUING <

"' DEVELOPMENT 0 1- ... :0 MAINTENANCE < u. 0 ,_ z w ~ w

1 MANUFACTURING


z 0 REVAMPING OF ;:: < EQUIPMENT "' 0 FOR 1-:0 NEW MISSION < u. . ... 0 RECYCLE OR 1-

~ DISPOSAL UNNEEDED 1-

>< EQUIPMENT w

SPECIFICATION LAYER

FUNCTIONAL DESIGN

DETAILED DESIGN LAYER

DETAILED PHYSICAL IGN DES

MANIFESTATION LAYER

PLAN T READY FOR RATIONS OPE

OPERATIONS LAYER

OR!':< OLESCENCE THE PLANT OF

RE CYCLE OR DISPOSAL LAYER

REG YCLE OR DISPOSAL OF THE PLANT

Figure 2 (cont.) The later phases in an enterprise system evolution and their tasks in relation to the Purdue Enterprise Reference Architecture.

18

z 0

..J<(!) z w oa: i=(f) (.)z(/) ::l~ u. <

z <

z 0 a w a: z 0

!i 1-' z w :E w ..J a. ~

..J < Zz Qo to: a a: w wa: a. 0

w (/)

< J: a.

b: w (.) z 8

z Qw 1-' (/)

~ ~ tt a. 0

z (!)

Cii w 0 w <i!~ ~5: t z ::l u.-+--

w (/)

< 5: z (!)

Cii w 0

0 w z(f) < < J: za. Qz 1-'Q (.)-

~~ 1-' ..J (f)< z 1-' Q(f) QZ

(/)

z Ow ~ ~ a: J: w a. a. 0

Part One Papers

1 0 1 1

1 3 1 4

1 6 17

19 20

1

3

5 -+--7

---ir---9

1 2

1 5

18

21

Figure 3 Abbreviated sketch to represent the structure of the Purdue Enterprise Reference Architecture.

The Purdue enterprise reference architecture and methodology in industry

2.

4.

6.

Feasibility Study and Identification of

Enterprise Business Entity (EBE) } IDEN11ACAnON

1 Definition of Business ntities, Mission, Goals, etc.

} Production Equip. Control & Info. CONCEPT PHASE

2 Polices 3 4 Requirements 5 6 Functions 7 8 Flow Diagrams 9

} DEFINITION PHASE

~~ ~~

10

.. 13

-t

16

.. 19

Production Equipment

r I I

I 11 I

I I

I I

14

-t

17

.. 20

Human Roles

12

.. 15

+ 18

j_

21

v

Control& Info. Systems

} PRELIMINARY ENGINEERING

PHASE

} DETAILED ENGINEERING

PHASE

} CONSTRUCTION

PHASE

} OPERATIONS

AND MAINTENANCE

I 1. Definition of Business Entities, Mission, Goals, etc. I Production Polices- e.g., Distributed Manuf. 3. Info. Policies- e.g., Corp Network Standard Prod. Requirements- e.g., OSHA, Underwriters 5. Info. Requirements - e.g., Maint. Mgt. System

Prod. Functions - e.g., Generic Unit Operations 7. Info. Functions- e.g., Work Order Tracking

19

8. Process Diagrams - e.g., PFD, Mat'l Balance 9. Info. Diagrams- e.g., Dataflow, Systems Arch. 10. Functional Design 11. Functional Design 12. Functional Des~n

Production Equipment - Human Roles & Org. - e.g., Control & Info. ystems -e.g., P&ID's Plant Layouts Organization Chart, e.g., Entity Rei. Dgms.

Staffing Levels ISAlogic

13. Detailed Design 14. Detail Design 15. Detail Design Production Equipment - e.g., Tasks, Training Plan -e.g., Hardware & Software -e.g., Piping & Conduit Drawings Operation & Maint. Manuals Configuration, Programmil!g

16. Construct, Checkout & 17. Staffing, Trainin~ 18. Assembly, Test & Commiss. Commission Productn Checkout Plant rocedures Control & Info. Systems -Equip. - e.g., Machinery - e.g., Simulator Training e.g., DCS Checkout, Install & Test Program Testing

19. Production- 20. Operate & Maintain 21. Operation of Info & Control e.g., Debottlenecking eg. Ongoing Training, Systems, eg. Maintenance, Cost & Quality Improve. Performance Improvement Debug & Upgrade

Figure 4 PERA enterprise life-cycle model.

20 Part One Papers

It should be remembered at this point that the Fluor Daniel personnel making the presentations as well as the representative members of the Industry-Purdue University Consortium and the Purdue University personnel who developed the Purdue Methodology were all personnel with control and information systems engineering backgrounds.

At first the Fluor Daniel presentations of PERA were met with a 'ho-hum' attitude from the listeners, most of whom were from other disciplines than control and information systems. (The lecturers were using modified versions of the Purdue prepared materials (Figures 1, 2 and 3).) They noticed this inattention and resolved to determine why such an important set of materials (in their eyes) was so poorly received.

They correctly surmised (fortunately) that the problem was that the listeners received this material as just another scheme to build up the importance of the control area and not something that could be of very major importance to every discipline in Fluor Daniel or their customers.

The answer to this problem, once identified, was simple. Just flip-flop the model (or framework) of PERA so that the mission-fulfilling tasks (the customer product and services functions) were on the viewer's left and the information functions (data, control and communications) were on the viewer's right. Then PERA and the Purdue Methodology were readily accepted as something of relevance to all! Compare Figure 4 with Figures 2 and 2 (continued).

This also meant that the 'left-to-right' order followed the sequence of the design steps. For example, during the Preliminary Engineering Phase, one might design a tank and a pump (Item 10 of Figure 4) which would be represented on the Piping & Instrumentation Diagram (P&ID). The decision would then follow that the operator would not manually run this pump since it needed to start and stop every 5 minutes (Item 11 ). The instrumentation to sense tank level and start the pump would then be added to the P&ID (Item 12).

Thus two ways of 'ordering' the PERA steps should be considered. One is of priority of importance or rank, and the other is of precedence in time. By reordering PERA it now fits the perceived order of placement in both priority & precedence.

This perception is a result of the long-standing custom in Western countries that the place of priority or precedence is up and/or to the viewer's left, and that the sequence will be from the top to bottom and left to the right.

Think of a few examples! 1. National flags when displayed in a group, 2. The medals on a soldier's uniform, 3. The guest of honor in a receiving line, 4. The arrangement of the elements in a Matrix, 5. Reading a book, 6. Etc.

Thus the non-control system practitioners were, probably subconsciously, viewing the original PERA presentation as not reflecting the importance and sequencing of their own disciplines and correspondingly glorifying the importance of the control and information field. This is especially significant when one considers that information and control comprises only about 15% of the budget of an industrial plant construction project, the rest being devoted directly to mission fulfillment equipment and related items. Hence the reversal of perception when this small difficulty was corrected.


Please note that the reversal of position of mission and information tasks also entails a reshuffling of the assignment of the box number description of tasks (see Figures 3 and 4 and related discussion) in the separate phases. Information and control tasks will now have the higher number of each group of three in each phase rather than the lower as before. The reasoning is the same as before in terms of acceptance.

The Purdue group had not noticed this before since their audiences had almost always been those interested specifically in enterprise integration or control systems.

This Fluor-Daniel Form of the PERA Diagram will be used in the remainder of the figures in this paper. However, it is noted that other users may have equally strong reasons to modify the PERA diagram in other ways to meet their own needs. In addition, the Purdue staff has studied other aspects of PERA which are much easier to show on the original form of the Framework or Architectural Diagram.

4 INTEGRATION OF HUMAN AND ORGANIZATIONAL FACTORS

A singularly important contribution of the PERA Enterprise Integration Reference Architecture has been its presentation of a very simple yet again intuitively correct method for accounting for the place of the human worker in any enterprise. The system works as listed in Table 1 and in the following discussion.

In order to show the true place of the human in the implementation of the enterprise functions, we need to assign the appropriate functions to the human element of the system. This can be done by considering the functional tasks as grouped in three boxes in the preliminary engineering or specification phase. These are separated by defining and placing sets of three dashed lines in the graphical architecture representation. This action will separate the two functional analysis streams into three as shown in Figure 5 and thus assign the tasks or functions involved to the appropriate boxes. The resulting columns of boxes then define the automated information tasks which become the Information Systems Architecture functions and the automated manufacturing tasks which become the Manufacturing Equipment Architecture functions The remainder (non-automated) become the functions carried out by humans as the Human and Organizational Architecture,

The Automatability Line (see Figure 5) shows the absolute extent of pure technological capability to automate the tasks and functions. It is limited by the fact that many tasks and functions require human innovation, etc., and cannot be automated with presently available technology.

The Humanizability Line (see Figure 5) shows the maximum extent to which humans can be used to actually implement the tasks and functions. It is limited by human abilities in speed of response, breadth of comprehension, range of vision, physical strength, etc.

22 Part One Papers

Table 1 The concepts that form the Purdue Enterprise Reference Architecture (manufacturing facility example).

I. All tasks in the manufacturing enterprise can be classified either as Informational or as Physical Manufacturing, i.e., involving only the moving and transformation (use) of Information, or, conversely, the moving and transformation (use) of Material and Energy.

2. All information transformation tasks can be categorized under functional headings such as planning, scheduling, control, data management, etc. Therefore, the need for such tasks in the enterprise or CIM system can be derived from the requirements of the enterprise for such functions.

3. Likewise, the requirements for material and energy transformation-type tasks can be categorized under the heading of physical production requirements or plant operations and the necessary tasks similarly derived.

4. Normally, information or data will undergo multiple transformations, i.e., many separate tasks (where a task define each transformation) in fulfilling the informationhandling requirements for an enterprise or CIM system. These transformations or tasks are usually successive operations forming sets of sequential and parallel networks.

5. The same is true of the material and energy transformation tasks for fulfilling the physical production or plant operations requirements for the enterprise.

6. In each case the networks involved can be combined, if desired, to achieve one major network of each type (Informational Transformations or Material and Energy Transformations, respectively) the totality of which defines the functionality of the enterprise or other business entity being considered (i.e., the totality of the information network, plus the manufacturing networks, both of which are developed separately but used conjointly).

7. The two networks interface in those tasks that develop operating variable state or status from the manufacturing processes (sensors) and those that deliver operational commands to the operational units (actuators and related devices). Except for these tasks and their related requirements, which do affect the other networks, each network can be developed independently of the other.

8. All tasks can be defined functionally without reference to their method of implementation. It makes no difference whether they are conducted by humans are machines (or in what type of equipment or where). All of these latter considerations are implementation details. Any discussion of the place of the human can be postponed in the manufacturing system development until after all tasks and functions are defined.


Table 1 (cont.)

9. The ultimate split of functions between humans and machines is determined as much by political and human relations-based considerations as by technical ones.

10. The split of functions for implementation between humans and machines (on both the information and manufacturing sides of the diagram of Figure 2) forms the first definition of the implementation of the resulting manufacturing system. Because of the inclusion of humans, there must be three separate elements in the implementation scheme: the Information System Architecture, the Human and Organizational Architecture, and the Manufacturing Equipment Architecture.

11. Provided all timing, coordination, etc., requirements are fulfilled, it makes no difference functionally what functions are carried out by personnel versus machines or what organizational structure or human relations requirements are used.

12. The split in assignment of these functions (i.e., between humans and physical equipment) can be expressed on a diagram by an Extent of Automation line.

13. The diagrams noted above can be extended to show the whole life history of the manufacturing enterprise.

14. All tasks in the Information Architecture can be considered as control in its very broadest sense, either immediately or at some future time. Likewise, all data collected and information generated is ultimately to effect control of the overall system being considered, either now or in the future.

The only other use of this data and information is in the context of a historical record.

15. Likewise, all operations on the manufacturing side can be considered conversions, the transformation (chemical, mechanical, positional, etc.) of some quantity of material or energy.

16. Once the integration of all of the informational functions of an enterprise have been properly planned (the Master Plan), the actual implementation of such an integration may be broken up into a series of coordinated projects, any and all of which are within the financial, physical, and economic capabilities of the enterprise, which can be carried out as these resources allow as long as the requirements of the Master Plan are followed. When these projects are completed, the integration desired will be complete.

24 Part One Papers

Table 1 (cont.)

17. All tasks will be defined in a modular fashion, along with their required interconnections, so they may be interchanged with other tasks that carry out similar functions but in a different manner.

18. Likewise, these tasks will be implemented in a modular fashion, again permitting their later substitution by other different methods of carrying out the same function. The choice of these implementation methods can be governed by independent design and optimization techniques as long as the task specifications are honored.

19. Provided the modular implementation just noted is used, the interconnections between these modules can be considered interfaces. If these interfaces are specified and implemented using company, industry, national, and/or internationally agreed upon standards, the interchange and substitution noted in Item 17 and I 8 will be greatly facilitated.

20. By considering that manufacturing is a type of customer service, i.e., production of goods for purchase by the customer, and then expanding customer service to include all possible goods and services the enterprise may render to the customer, we can expand the Architecture to cover all possible types of enterprises. Thus the right-hand side of the Architecture would then represent the customer service rendered by any enterprise even if that service itself involved information.

Still a third line is presented which can be called the Extent of Automation Line (see Figure 5) which shows the actual degree of automation carried out or planned in the subject Enterprise Integration system. Therefore, it is the one which actually defines the boundary between the Human and Organizational Architecture and the Information Systems Architecture on the one hand, and the boundary between the Human and Organization Architecture and the Manufacturing Equipment Architecture on the other side.

The location of the Extent of Automation Line is influenced by • Economic • Political • Social

Customs -- Laws & Directives -- Union Rules

as well as Technological factors.


INFORMATION FUNCTIONAL

NETWORK

MANUFACTURING (UNIT OPERATIONS)

FUNCTIONAL NETWORK

flUMAN AND ORGANIZATIONtL I MANUFACTURING SYSTEMS EQUIPMENT I --.1 ARCHITECTURE

I~ ARCHITECTURE 1 E-<z "" ARCHITECTURE

~ ;z:l >I z8 0 I I ~ Ol

t:l E-<~~ I~ l;z: 1=1 ~E-o~ 0 IE-<

==I z<~ zz~ I~ 1- E-< E-< .... I - <I 0::\E;:::> ~;;;::;> 1<

I~ ~I ~I =-~E-< z;::;>E-< I; I~ ==I -l=:l E-<1 :::Eou OE-<u I~ =I I< ~I ~I 0""~ =-u~ I~ I;;:,

;sl N ""I :::EI uzE-< :::E<E-< I< < 1- -= o.._- I"" -I I~

01 ~I z~u U;::;>::t I~ 10 ~I E-<1

<=~ zzu IE-< I~ ~I ;;;.:ll ::iEE-<< <<~ IE-< l;z: ~I

~ l;;;.:l E-<1

~ ;;::;> ::;E::\E< ~ IE-< ;;;.:ll

I= ~I ="" ;;::;> 1;;.< =I 0 ~

r+- I I = I I

Figure 5 Introduction of the automatability, humanizability and extent of automation lines to define the three implementation architectures.

26 Part One Papers

The Automatability Line showing the limits of technology in achieving automation will always be outside of the Extent of Automation Line with respect to the automation actually installed (see Figure 5). That is, not all of the technological capacity for automation is ever utilized in any installation for various reasons. Thus, the Human and Organizational Architecture is larger (i.e., more tasks or functions) and the Information System and Manufacturing Equipment Architecture are smaller (less functions) than technological capability alone would allow or require.

Note that for a completely automated plant as an extreme case, both the Automatability Line and the Extent of Automation Line would coalesce together and move to the left edge of the Information Architecture block and correspondingly to the right edge of the Manufacturing Architecture block. Therefore, the Human and Organizational Architecture would disappear and the Information Systems Architecture and the Manufacturing Equipment Architecture would coincide with the unmanned Information Architecture and the unmanned Manufacturing Architecture, respectively. Note that Figure 5 uses the Fluor Daniel form of the PERA diagram, i.e., Enterprise Mission aspects are placed in the left (Figure 4), as well as succeeding figures.

Fluor Daniel used the above discussion to emphasize several rules of project developed procedure as shown in Figure 6.

The Fluor Daniel training sessions also emphasized the state of knowledge of Human and Organizational factors and that this resulting lack requires that special attention be given to this area by project management to assure success. Figure 7 shows this.

5 THE IMPORTANCE OF A PHASED APPROACH

Figure 8 and the following discussion of the Purdue phased approach and its academic justification allowed Fluor Daniel to emphasize a similar approach to the organization of their project work. Purdue had used the Axioms of Engineering Design developed by Professor Nam Suh (1990a, 1990b) to show the correctness of PERA as an engineering design. Fluor Daniel applied the same axioms to their project management. These are shown in Figure 9. Suh's work also carried several corollaries to the axioms. These readily show the impact of late modifications to scope or equipment specifications of the project and the need for early and firm project decisions. This is dramatically illustrated by Figures 10 and 11. Figure 12 also shows how project work can become 'unstable' if too many changes are made too quickly. It is important to note in Figure 11 the impact of continuing project work on the financial commitment to a project. As listed there, Conceptual Engineering involves approximately a 1% involvement; Preliminary Engineering involves 2%; and Detailed Engineering about 8%. After this Construction accounts for 80% while Project Acceptance by the User commits all funds involved Thus as strongly shown in the Fluor Daniel-PERA Methodology early decision making is vitally important.


Production Equip.

2

4

6 8

10 Production Equipment

Minimum Equipment


Enterprise Business Entity EBE

Polices

Requirements

Tasks/Functions

Flow Diagrams

11 Human Roles

Control & Info.

3

5

7

9

12 Control & Info. Systems

Minimum Automation

Maximum Equipment Maximum Automation

• Define Human & Organization Factors at Preliminary Engineering Phase

• Equipment, Automation and Human Roles are Interdependent .,.. Equipment - A Conveyor vs. Manual Bag Dumping .,.. Control - Automatic Sequencing vs. Manual Valve

Actuation

• Must .,Put Stake In Ground., for Downstream Design, i.e., Make Decisions Early and Keep Them.

• Policies Define Consistent Automation or Payback Goals

Figure 6 Integration of human and organizational factors.

28 Part One Papers

Feasibility Study and

}D£NnRCATION

Identification of Enterprise Business Entity

EBE

1

Production Equip. Control & Info. CONCEPT PHASE

2 Polices 3 4 Requirements 5

} 6 Functions 7 DEFINITION PHASE

8 Flow Diagrams 9

} PREUMINARV 12 ENGINEERING

PHASE

} DETAILED 13 15 ENGINEERING

PHASE

16 18 } CONSTRUCTION PHASE

} OPERATIONS 21 AND

MAINTENANCE

Production Human Roles Control & Equipment Info. Systems

• No "Human Factors" or Organization Design Discipline .

• Many Disciplines have Input (Controls, Process, Mech, etc.)

• Plant Operations Expertise, Training, etc., not yet Assigned to Specific Fluor Daniel Groups.

Figure 7 Human and organizational responsibility is split.


Why Use a Phased Approach ?

Because it allows the Project to;

Reduce rework Improve Communications

Improve Quality Reduce Costs

Why should this be so ?

Figure 8 Why use a phased approach?

30 Part One Papers

Dr. Nam P. Suh of M.I.T. has Proposed that there are two Basic Axioms or Rules of Project Management:

Axiom 1 In Order to Manage Complex Projects, You Must Divide Into Independent Sub Projects. (or Divide and Conquer)

Inputs .,, Sub Project

,, Outputs

Axiom 2 That Subdivision is Best Which Results In the Minimum Number Of Inputs & Outputs. (or Don't Cut it Where It's Th ickest)

Figure 9 Axioms of project management.



Enterprise Business Entity

Production Equip.

2---+--4_-+--

6 ---+--8_-+--

10

Polices

Requirements

Functions

Flow Diagrams

11

14

Control & Info.

--+--3 --+--5 --+--7 --+--9

I 12 1Rework I

;---,-------'

~~---~-----~-~---r------~

~------.-------~

19 20 21

~~~~~~==~==~==7 Production Equipment

Human Roles Control & Info. Systems

} IDENTIACATIDN

CONCEPT PHASE

} DEFINITION

PHASE


PHASE

} DETAILED

ENGINEERING PHASE

} CONSTRUCTION

PHASE

} OPERATIONS

AND MAINTENANCE

(_. Any Change In Outputs Of Previous Phase Negates Axiom 1 (Makes Dependent).

~ e.g., Add Valve on P&ID (10) during Detailed Design (13) ~ Rework Piping (13) ~ Rework Wiring and DCS Configuration (15) ~ Change Sequence of Operation (12)

(_. If Preliminary Engineering is Impacted, since (1 0), (11) & (12) Interact, all Subprojects in Next Phase are Made Dependent.

Figure 10 Impact of corollaries to engineering axioms.

32

2 4 6 8


Part One Papers


Enterprise Business Entity

Polices

Requirements

Functions

Flow Diagrams

Human Roles

3 5 7 9

Control & Info. Systems

} IDENTIRCATIDN

} CONCEPT PHASE

} DEFINITION

PHASE


PHASE

} DETAILED

ENGINEERING PHASE

}CONSTRUCTION

PHASE

} OPERATIONS

AND MAINTENANCE

(_.. Changes Which Span More Than One Phase Makes All Included Phases Dependent

~ Oops, old Sam can't run fast enough! Need to add Automated Sequence (21)

~ Change Control Hardware & Software (12}

~ Add Valves & Sensors to P&ID (1 0) ~ Modify Piping & Wiring Design (13)

~ Modify Plant Equipment (16) ~ Test & Commission (19)

~ Retrain Operators (20)

c... Impact is Amplified by Each Subsequent Phase (1%- 2%- 8%- 80%- 100%)

Figure 11 Impact of corollaries to engineering axioms (continued).

The Purdue enterprise reference architecture and methodology in industry

Feasibility Study and

} IDENTIACATION

Identification of Enterprise Business Entity

} CONCEPT PHASE

2 Polices 3 4 Requirements 5 } 6 Functions 7 DEFINITION

PHASE 8 Flow Diagrams 9

I } PRELIM.,.RY

:Rework12 ENGINEERING PHASE

} DETAILED 14 ENGINEERING

PHASE

} CONSTRUCTION PHASE

} OPERATIONS 19 20 21 AND

MAINTENANCE

Production Human Roles Control & Equipment Info. Systems

(_. Each Step in an Inter-Phase Rework Loop has Both Time Delay and "Gain".

(_. Thus, it May be Mathematically Demonstrated from Dr. Suh's Equations that these "Rework Loops" Not Only Waste Effort & Time, but Can Become Unstable.

(_. If Information is Exchanged Too Quickly Between Subprojects, the Rework Loop Becomes Unstable. Lack of Progress, or Even Negative Process Ensues.

(_. If Information is Too Slowly Exchanged Between Subprojects, the System Becomes Unresponsive, and Work May be Wasted on Design Elements which have Already Changed.

Figure 12 Dynamic model of interaction.

33

34 Part One Papers

6 INTERFACES

Purdue had also done considerable work to define and analyze the interfaces that occur in an enterprise engineering project not only between the individual task modules involved but also within and between the phases of the engineering project as shown by the PERA architecture.

Again, the Fluor Daniel staff took advantage of this information to teach the behavior of their project performance factors and propose methodologies which would avoid the resulting problems. They also took advantage of opportunities uncovered by this information. Some of this is already shown in Figures 8-10. Figures 11-14 emphasize the importance of considering each and all of these interfaces and their effects on the project and on the resulting plant and its performance. Figures 16 and 17 summarize the requirements for the good project practices developed from this.

7 THE FLUOR DANIEL WORKBENCH

As noted, the lengthy table which accompanied Figure 3 in the Purdue documentation of PERA (not reproduced here) presented an extensive list of the assignments of tasks, models of the tasks and their interconnections, tools to carry out these tasks, and the interfaces between tasks and phases throughout the enterprise development and operational life history.

Fluor Daniel already had a large set of engineering procedures and tools to carry out most of this work, much of it computerized and interconnected with a massive companywide database of specifications, procedures, report formats, tools, etc The PERA outline gave them an excellent new mechanism for organizing, categorizing, and teaching the technology to their company and client personnel. Figures 18 and 19 present two aspects of what is a massive teaching and operational capability now being set up and used in Fluor Daniel known as the Fluor Daniel Engineering Workbench. Figure 20 shows how the Workbench follows the pattern of PERA. As can be seen, the PERA Diagram and the associated Methodology have been of major help in this effort.

8 LESSONS FOR MANAGEMENT

The PERA technology has not only been of use to Fluor Daniel's engineering and construction groups but it can also be used to help management in their future planning and decision making. Figure 21 illustrates this point.

Fluor Daniel's management had prided themselves on the company's excellence in and concentration on the area of the Detailed Design and Construction of plants. This is Blocks 13 and 16 on Figure 21. However, Figure 21 points out that the downsizing which is occurring in many of their customer companies has created an opportunity to expand Technical Services and access the full set of activities defined in the PERA models.


Each Phase (e.g., Detailed Engineering) is Actually Divided into a Number of Subprojects, One for Each Discipline Group Engaged. Interfaces Exist at All Subproject Boundaries.

13

OUTPUTS


INPUTS

14

OUTPUTS

Human Roles

OUTPUTS

Control& Info. Systems

} DETAILED

ENGINEERING PHASE

Each Discipline Subproject Receives Inputs from Other Disciplines, and Gives Outputs to Other Disciplines. These Occur Within the Phase, and Follow the Same Axioms as Inputs and Outputs from Other Phases.

Inputs __ _..

Inputs

13 Detailed Engrg.

Sub-Project

Outputs

Figure 13 Inter-discipline interfaces.

Outputs 1-----.

36 Part One Papers

Interfaces Exist at ALL Subproject Boundaries. For Example:

Preliminary Engineering

INPUTS

1 ........ 1 ........ .1 .... ··················· ···················· ...

. ·· ··. (.. '\ --

\ ....•... ~ ······ ... . ..

.· ··... . ·· ... '-----------' ... ········

·-...... ... ·····

·r········1········1·

OUTPUTS

Must Facilitate Interfaces Within Phases (Version Control)

Must Control Interfaces Between Phases (Change Orders)

Figure 14 Interfaces.


Interfaces Exist at ALL Subproject Boundaries.

Operations

11 / ....... / ·. ····... . .... ·············

······· ..... 1''•·····1········1'' ·····················

.·· ..

OPERATOR OUTPUTS

Figure 15 Interfaces (cont.).

38 Part One Papers

Let•s say this is all true, how can we use it to work smarter ?

Apply the principles we have deduced to:

Define better work processes

Build a better data model

Consciously address Human &

Orqanizational issues in desian

Set up reference material &

computer systems to help

Figure 16 More reasons for a phased approach.


The Following Can Then be Deduced from the Principles Described Above:

• Optimum "Tuning" Between Phases is Different than Within Phases, but Both May Become Unstable.

• Reduction of Time Delays (e.g., to Produce Deliverables) Will Improve the Responsiveness Which is Possible Without Becoming Unstable.

• Data Should be Released Between Disciplines in Self-Consistent Sets to Minimize Recycle and Instability.

• Scope Changes Should be Issued for Any Revision of Inputs from the Previous Phase, or for Any Out-of-Sequence Discipline Work.

• If Phases Must be Done in Parallel, it is Critical to Understand Interactions to Minimize Impact.

• The Number of Discipline Subprojects Should be the Minimum Required to Bring the Necessary Expertise and Resource Level to Bear.

• In Preliminary Engineering, I 0, II, I2 are Not Independent. As a Result, Effective Execution Requires a Small Multi-Skilled Team Operating in a Tightly Interactive Design Environment.

Figure 17 Deduction from dynamic model.

40

\..

Part One Papers


Enterprise Business Entity (EBE)


Production Equip.

2 4 6 8

~" 10

+ 13

+ 16

~

19

'Y


I I I I I

.J

Polices

Requirements

Functions

Flow Diagrams

11

14

+ 17

~

20

'Y

Human Roles

Control & Info.

3

5

7

9

~" I I I I I

.,

12

+ 15

~

18

~

21

.,. Control & Info. Systems

} IDENTIFICATION

CONCEPT PHASE

} DEFINITION

PHASE


PHASE

} DETAILED

ENGINEERING PHASE

} CONSTRUCTION

PHASE

} OPERATIONS

AND MAINTENANCE

(_. In Preliminary Engineering, 10, 11 & 12 are Not Independent. As a Result, Groupbase/Sharebase Distinction is Not Useful During Preliminary Engineering Phase.

(_. Construction Database Structure and Needs are Different.

(_. Operations Databases are Also Different-e.g., CMMS (Computerized Maintenance Management Services).

Figure 18 Data structure.


Top Menu Level is to Select Discipline (Vertical Slice)

Process Mechanical Piping Structural, etc.

Control Systems Systems Integration Telecommunications




Production Equip.

2 4 6 8

./~

10

• 13

• 16

• 19

~


I I I I I

Polices

Requirements

Functions

Flow Diagrams

11

14

• 17

• 20

~

Human Roles

Then Select the Phase

Control & Info.

3 5 7 9

./"-..... I

I I I

12

• 15

• 18

• 21


} IDENTIFICAnoN

} CONCEPT PHASE

} DEFINITION

PHASE


PHASE

} DETAILED

ENGINEERING PHASE

} CONSTRUCTION

PHASE

} OPERATIONS

AND MAINTENANCE

Then Select from a List of Tasks which are Required During that Phase.

Figure 19 Workbench structure mirrors Fluor Daniel-PERA methodology.

0~

~

.... =

ac

-· c

(l

) "'

I -('t)

(l)

N

~-~

::l

(l)

::l

(l)

('")

'"1

'"1

-·

(l)

::l ~

(TQ

(/l

~

::;·

o(T

Q

'"1

'1::

l ~'"1

g-.2

. ::

l (l

) ('"

) ('"

) ::

:;

....

.

~

..0 t:

::;·

(l) a (l) ::l ~

~

:::tl

::l .... o· ::l ~

(/l

(/l

::r

0 ~

::l ~ ~ >

~

::l

0.. .... ::r

(l) '11

;:

0 7

Co

nce

ptu

al

En

gin

ee

rin

g

Ph

ase

Pre

limin

ary

E

ng

ine

eri

ng

P

hase

'

Con

trol

& I

nfor

mat

ion

Sys

tem

s

En

terp

rise

•

Ent

erpr

ise

Inte

grat

ion

Vis

ion

• Obje

cll~

es, S

trate

goes

& G

oa

ls

Def

init

ion

&

• M

ea

sure

me

nts

Po

licie

s ·P

olic

ies

• Opp

ortu

niti

es

• F

acto

red

Est

imat

es a

nd

Ben

efits

-T

elec

omm

unic

atio

ns S

OW

Sys

tem

s In

tegr

atio

n S

OW

I

onc-e

otua

J Es

tom

. :;o

nceo

tua

:>cn

e<l

once

tu

aJ t

:st.o

m.

one

tua

iSc:

tled

Sco

pe o

l Fac

it~i

es

I S

CO

Pe

ol ~eo

vice

s I· R

equi

rem

ents

I

~cope 0

1 t-a

cjrto

es

1· R

equi

rem

ents

I

Ma

jor

Re

qu

ire

me

nt S

cop

e o

f Wor

i<

I re

limin

ary

Est

im.

1: p

ntro

l Lev

el S

ched

ng

inee

ring

S

f

F

Tr

Sco

pe o

f S

ervi

ces

Eng

.Del

iver

able

s E

quip

me

nt

~ope

1° ~~

1 oe

s E

ngin

eeri

ng

ng

. Inp

uts

nsta

llatio

n •

unc

oona

pe

e .

. .

Eat

,ior

Li

Con

stru

ctoo

n ra

onon

g &

SII.

J -

uo

me

nt

st

Tra

in &

Sta

rtup

~

Fun

ctio

ns

I S

cop

e Chan~~

~ '

Fun

ctio

nal W

orl<

Pro

cess

C

hang

e M

an

ag

em

en

t

Tas

ks

·PM

R

• Wor

i< I

nstr

uctio

ns

·De

via

tio

n

• W

ori<

Flo

w O

gms

·Ch

an

ge

Ord

er

Co

ntr

ol S

yste

ms

SO

W

_j_

Con

cepi

Ual

ES1

om .

once

otua

l sch

ed

Sco

pe o

l F ac

ilrue

s

I· R

equi

rem

ents

I

+>

N ;p ::t ~ (I

I ., ~

(II ~


1

2 4 6 8

13




Polices

Requirements

Functions

Flow Diagrams

11

14

Human Roles

3 5 7 9

15


• Current Flour Daniel Focus is 13, and Flour Daniel Construction, Inc. (FCI) is 16.

• Integration of 13 & 16 is a Key Opportunity.

• Better Margins to be Made in (1 to 12)-Front End, (15, 18, 21 )-Control & Information Systems, and (14, 17, 20)-Training, Organizational Consulting & Personnel.

} IDENTIFICATION

} CONCEPT PHASE

} DEFINITION

PHASE


PHASE

} DETAILED

ENGINEERING PHASE

} CONSTRUCTION

PHASE

} OPERATIONS

AND MAINTENANCE

• Doing Rest Adds Value to (13 & 15) (Commodities).

• Clients are Losing Skills in Process, Operations & Controls. Flour Daniel Must Plan to Provide these Skills.

• This Requires Training New Graduates Through Plant Maintenance and Operations, Since Clients are No Longer Hiring and Training.

• Investing only in (13) is a Poor Strategy.

• Any Model of our business Must Include Dynamic as well as Steady State Behavior.

Figure 21 Key messages for Fluor Daniel.

44 Part One Papers

9 SUMMARY

This paper has presented a review of some of the ways in which Fluor Daniel, Inc., has used the Purdue Enterprise Reference Architecture and Purdue Methodology (PERA) to form the basis for organizing their own project execution and project management tools and system to be one integrated whole.

The ways which they used to slightly modify the presentation of PERA to greatly increase its relevance and acceptance by engineering disciplines other than control and information systems are most noteworthy. Similar methods might be used by other groups.

Most other major developments associated with PERA such as the Axioms of Engineering Design, the study of Interfaces, etc., have also been incorporated into the Fluor Daniel system.

It should be appreciated that all of the changes described here have been cosmetic, i.e., changes in wording, arrangement of figures, etc., to satisfy discipline and cultural preferences of the prospective users. There have been no changes in the technology expressed by PERA or the concepts involved.

Nevertheless, it must also be appreciated that these modifications, cosmetic as they may be, can have a profound effect on the degree and rate of acceptance by others of these technologies.

10 ACKNOWLEDGMENTS

The authors very much appreciate the help of Mrs. Barbara Beaver and Dr. Hong Li in the preparation of this paper.

11 REFERENCES

Nevins, J.M. (September, 1991) Contributions to the IFAC/IFIP Task Force on Architectures for Enterprise Engineering, Bordeaux, France.

Industry-University Consortium. (June 1992) Purdue Laboratory for Applied Industrial Control, An Implementation Procedures Manual for Developing Master Plans for Computer Integrated Manufacturing, Report Number 155, Purdue Laboratory for Applied Industrial Control, Purdue University, West Lafayette, Indiana.

Williams, T.J., and the Members of the Industry-Purdue University Consortium for CIM. (December 1991) The Purdue Enterprise Reference Architecture, Technical Report 154, Purdue Laboratory for Applied Industrial Control, Purdue University, West Lafayette, Indiana. Also published as: Williams, T.J., The Purdue Enterprise Reference Architecture, Instrument Society of America, Research Triangle Park, North Carolina.

Li, Hong. (December 1994) A Formalization and Extension of the Purdue Enterprise Reference Architecture and the Purdue Methodology, Ph.D. Thesis, Purdue University, West Lafayette, Indiana). Also published as: Li, Hong, and Williams, T.J., A Formalization and Extension of the Purdue Enterprise Reference Architecture and the Purdue Methodology, Technical Report 158, Purdue Laboratory for Applied Industrial Control, Purdue University, West Lafayette, Indiana (December 1994).

Suh, N.P. (1990) The Principles of Design. Oxford University Press. Suh, N.P., and Sekimoto, Shinya. (1990) Design of thinking design machine. Annuals of

the CIRP, 39, 145-170.

P. Bernus et al. (eds.), Modelling and Methodologies for Enterprise ... · Fluor Daniel, Inc., is a...

Documents

Transcript of P. Bernus et al. (eds.), Modelling and Methodologies for Enterprise ... · Fluor Daniel, Inc., is a...