p. bernus et al. (eds.), modelling and methodologies for enterprise ... · fluor daniel, inc., is a...
TRANSCRIPT
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.
The Purdue enterprise reference architecture and methodology in industry 15
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:
The Purdue enterprise reference architecture and methodology in industry 17
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
1 INFORMATION HUMAN AND ORGANIZATIONAL
SYSTEMS ARCHITECTURE ARCHITECTURE
z 0
CONTINUING ~ CONTINUING ORGANZATIONAL DEVELOPMENT i!j DEVELOPMENT ...
CONTINUING SKILL AND HUMAN ...... ,_ MAINTENANCE ::> RELATIONS TRAINING < ...
0 1-z w ,_ :;;
1 INFORMATION HUMAN AND ORGANIZATIONAL
SYSTEMS ARCHITECTURE ARCHITECTURE
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
EQUIPMENT ARCHITECTURE
z 0 ;:: CONSTRUCTION <
"' .. .... 0 PLANT TESTING 1-::> < "- COMMISSIONING 0 1-z
~ w
1 MANUFACTURING
EQUIPMENT ARCHITECTURE
z 0 ;:: CONTINUING <
"' DEVELOPMENT 0 1- ... :0 MAINTENANCE < u. 0 ,_ z w ~ w
1 MANUFACTURING
EQUIPMENT ARCHITECTURE
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.
The Purdue enterprise reference architecture and methodology in industry 21
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.
The Purdue enterprise reference architecture and methodology in industry 23
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.
The Purdue enterprise reference architecture and methodology in industry 25
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.
The Purdue enterprise reference architecture and methodology in industry 27
Production Equip.
2
4
6 8
10 Production Equipment
Minimum Equipment
Feasibility Study and Identification of
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.
The Purdue enterprise reference architecture and methodology in industry 29
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.
The Purdue enterprise reference architecture and methodology in industry 31
Feasibility Study and Identification of
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
} PRELIMINARY ENGINEERING
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
Production Equipment
Part One Papers
Feasibility Study and Identification of
Enterprise Business Entity
Polices
Requirements
Functions
Flow Diagrams
Human Roles
3 5 7 9
Control & Info. Systems
} IDENTIRCATIDN
} CONCEPT PHASE
} DEFINITION
PHASE
} PRELIMINARY ENGINEERING
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.
The Purdue enterprise reference architecture and methodology in industry 35
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
Production Equipment
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.
The Purdue enterprise reference architecture and methodology in industry 37
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 Purdue enterprise reference architecture and methodology in industry 39
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
Feasibility Study and Identification of
Enterprise Business Entity (EBE)
1 Definition of Business ntities, Mission, Goals, etc.
Production Equip.
2 4 6 8
~" 10
+ 13
+ 16
~
19
'Y
Production Equipment
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
} PRELIMINARY ENGINEERING
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.
The Purdue enterprise reference architecture and methodology in industry 41
Top Menu Level is to Select Discipline (Vertical Slice)
Process Mechanical Piping Structural, etc.
Control Systems Systems Integration Telecommunications
Feasibility Study and Identification of
Enterprise Business Entity (EBE)
1 Definition of Business ntities, Mission, Goals, etc.
Production Equip.
2 4 6 8
./~
10
• 13
• 16
• 19
~
Production Equipment
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
Control & Info. Systems
} IDENTIFICAnoN
} CONCEPT PHASE
} DEFINITION
PHASE
} PRELIMINARY ENGINEERING
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 ~
The Purdue enterprise reference architecture and methodology in industry 43
1
2 4 6 8
13
Production Equipment
Feasibility Study and Identification of
Enterprise Business Entity (EBE)
Polices
Requirements
Functions
Flow Diagrams
11
14
Human Roles
3 5 7 9
15
Control & Info. Systems
• 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
} PRELIMINARY ENGINEERING
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.