ADAM: R&D Article
Ranky, P.G.: An Object Oriented System Analysis and Design Method (CIMpgr) and an R&D Case Study
Published by ADAM at http://www.cimwareukandusa.com, © Copyright by CIMware Ltd. UK and CIMware USA, Inc.
Please feel free to download this paper with its full contents, FREE of charge, but always mention the website: http://www.cimwareukandusa.com and the author(s) as the source!
Website: http://www.cimwareukandusa.com
Email: cimware@cimwareukandusa.com
Address: Paul G. Ranky, Dr.
Techn/PhD, Full, Tenured Research Professor, The Department of
Industrial and Manufacturing Engineering, New Jersey Institute of
Technology, Newark, NJ 07102, USA, Email: ranky@admin.njit.edu
Concurrent Engineering represents a structured, logical framework which supports a systematic approach to the integrated, concurrent design of products and their related processes, including manufacture and support of hardware as well as software systems. This method is intended to ensure that developers consider all elements of the entire product life cycle from conception through to final disposal, and even de-manufacturing, including quality, cost schedule and user requirements.
In contrast to the old, conventional, or sequential hardware as well as software product design method, Concurrent Engineering (and consequently Concurrent Software Engineering) focuses on customer satisfaction, on teamwork as well as on Design for Manufacturing, Design for Assembly and Quality issues. (Note, that in software terms Design For Manufacturing can mean designing and manufacturing software for different delivery platforms, operating systems, various intranets and the Internet with different download capabilities. For consistency, note that within this article the term Concurrent Engineering applies to the integrated hardware as well as software product/ process worlds).
Based on the above definition, it is essential to understand that none of the concurrent, or other engineering methods work in practice unless they are skillfully
The above thought process implies the need of employing tested enterprise/ product and process modeling, system analysis and system design methods. One of these object-oriented (OO) methods, CIMpgr, developed by the author, based on a variety of object oriented concepts, is described in this article with a detailed case study. (At the time of writing, CIMpgr and similar OO methods are widely used by all major hardware and software manufacturers around the world).
System modeling, system analysis, system design, DFD, CIMpgr, Concurrent Engineering, CIM, Computer Integrated Manufacturing, Enterprise modeling, Case study, Object Oriented Design and Manufacturing, ERP and ERM (Enterprise Resource Planning and Enterprise Resource Management)
The 21st Century undoubtedly will be the 'knowledge driven century', meaning that information that can be turned into value adding knowledge will represent more power than ever before. Most of this new data will be gained directly from machines/ processes and people operating these machines integrated into systems of cells and digital factories. In terms of the client-server architecture, these resources will be web-pages of intranets and eventually the Internet.
This Internet helps to reduce waste, as well as acts as a systems integration and collaborator enabler for creating new ideas that can be turned into product and then sold to a global economy quicker and at a lower cost than ever before. In this new economy, leading companies are discovering that besides minimizing design and manufacturing costs and maximizing quality, they can achieve competitive advantage by introducing new, innovative products that satisfy individual consumers on a global basis. This is possible because of the highly integrated collaborative opportunities of product and process design, information technology and management. Gains of such 'hot new products' can not only increase the company's market share but it can create an entirely new market category, in which the company is first, therefore enjoys the efficiency gains by orders of magnitude.
Innovation in integrated design and manufacturing coupled with enterprise management systems contributes to further cost reductions and sustainable growth. This is because Product Lifecycle Management (PLM) activities and software systems, in integration with Enterprise Resource Planning and Management (ERP&ERM) with Supply Chain Management (SCM) coupled with Customer Relationship Management (CRM) represent a very powerful methods base. These systems can be used on a real-time basis to fine tune a business, continuously learn, innovate and satisfy customer needs, therefore sustain growth and make profit on a global basis.
The primary delivery mechanism for the above outlined system is e-business via extranets/ intranets and the Internet. At the beginning, the key value of e-business is cost savings, customer satisfaction and revenue growth. As soon as the factory, or organization understands the benefits of web-enabled enterprise processes that share resources, applications and data, the opportunities for further waste reductions and growth are even more dramatic. This is the stage when the e-business gradually becomes a network of connected lean e-businesses of design, manufacturing, remote quality control, maintenance and others.
To summarize, the key is that by understanding market drivers based on mutually beneficial collaborative problem solving processes enables companies to move beyond traditional design, manufacturing and trading mechanisms to new and different ways of solving challenges and capturing new markets. Those companies and individuals that will be able to capture the essence of this new 'knowledge driven' economy, and then take decisions, based on accurate data sets gained from elementary processes up to high level activities, will be tomorrow's digital factory leaders.
Following these introductory thoughts, the aims of CIM & CE (Comouter Integrated Manufacturing and Concurrent Engineering) are very clear: getting rid of waste, organizing our knowledge in our minds, focusing on new opportunities driven by the customer and integrating the
In other words, CIM, Concurrent Engineering, ERP and ERM (Enterprise Resource Planning and Enterprise Resource Management) address the whole enterprise, including humans and machines, the business systems, product design, process planning, manufacturing planning, the shop floor, packaging and maintenance.
This article focuses on one of the static object oriented system modeling / process modelling methods, including object oriented analysis and design, namely CIMpgr, applicable to a very wide variety of different enterprises and systems ([1] to [9]).
Some of the benefits of simultaneity
Simultaneity, or concurrency, or parallelism (for the purpose of our discussions meaning exactly the same) compared to the classical, or sequential, or linear approach offer striking benefits. As an example, imagine one person building an automobile or a house, or a software package, or re-engineering an enterprise, versus an able team performing the same task with enthusiasm, cooperation, coordination, good tools and mutual efforts. (The core issue of course is the way the information system model is designed, validated and built before any work starts!)
The purpose of Concurrent Engineering (including Concurrent Software Engineering using an object-oriented approach) is to increase productivity and to create products that are of high quality, are reliable, less expensive than that of the competitors', and reflect the customers' requirements ([9] and [10]).
To summarize, the idea of CE is to simultaneously satisfy important issues, such as:
The key issue is that the system analysis of the factory or organization and the resulting new architecture must take into account:
Note, that the first major step towards achieving the "integrated whole" is the creation of a well designed, object oriented information system model!
There are three vital points to recognize in this context:
1. Design, including the product, process and the information system model design, is the first step in product manufacture ("product" meaning hardware as well as software).
2. Every important design decision must be considered with great care at the earliest stage by a team of
- system analysts,
- system designers,
- integrated product and process designers,
- manufacturing engineering/ software engineering and
- marketing experts,
- hardware and software quality and
- maintenance engineers,
- as well as the customers.
3. Product design needs careful analysis and "fine tuning" to take advantage of the available and skillfully applied design and analysis methods and technologies.
As a summary, the fundamental reason for modeling is to be able to analyse, design, test and validate a new, novel, unknown system, or process.
An information system architecture for modeling purposes
In order to be able to design the product and the processes at the same time we need to create an information system architecture, a framework as well as various user led processes and electronic tools that are going to enable communication across departmental, factory, even continent lines. The basic approach we follow is to analyze and design objects, that have attributes that dictate their behavior, the navigation between these objects, often meaning the information flow (and the material flow if these are physical objects), and processes (that basically represent transfer functions that can turn the state of the object from one to another), in integration, rather than isolation.
Within each of these main groups we need to discuss the applicable methods, tools and technologies.
First let us list some methods, tools and technologies relating to knowledge acquisition, knowledge representation, CIM & CE system analysis and design ([10] to [16] and [25]):
Information flow related methods
Material flow related methods
Process related methods
and
Project management related methods and activities
including:
The important issue is that all above processes and activities need to rely on a well designed, object oriented information system model. This should be the foundation for most decisions. Without that the benefits of the "integrated whole" will be missed; and in many cases, this will be learned only by going through disastrous situations during the project...
CIM and Concurrent Engineering are pertinent examples of the need for system description by modeling. A fully operational Concurrent Engineering setup is a system of relatively high complexity - even more so if it is integrated into a CIM, or into an even broader ERM (Enterprise Resource Management) environment.
The complexity of these system designs is further complicated by the emphasis that must be put on "design for manufacture" (DFM) of the objects and components to be produced. This is an area where a compromise must be found between what is best for the manufacturing system and what is best for the product. It is becoming increasingly acknowledged that no longer can hardware and software designers and manufacturing/ test engineers work separately. Considering this complexity, the need to describe a system in a concise, multilayered, and object oriented way becomes obvious.
When modeling systems, static models are used for system definition. These become the frameworks around which to build the dynamic models which are used to simulate the system's operational performance.
Dynamic models are used to identify all the important situations the system can "get itself into" after a period of time in operation. For example, FMS designers use dynamic simulation in particular for situations like queue buildups, lack of part or tool transportation capacity, AGV (Automated Guided Vehicle) capacity, collisions, over- or under- utilization of cells, the effect of a breakdown or multiple breakdowns, or even system deadlock. Undesirable characteristics of this nature can then be identified and in most cases designed out of the system before it is built ([15]). As an other example, network design and software engineers use dynamic modeling for network architecture design, for ISP (Internet Service Provider) load balancing, for performance prediction, for capacity planning, for real-time capacity adjustment testing and many others.
CIM and Concurrent Engineering/ Concurrent Software Engineering Information System Data flow Diagrams
In systems modeling, Data flow Diagrams, including their data dictionaries, and their process descriptions are often used to specify and describe a system. Data flow Diagrams (DFD's) were originally developed for modeling the flow of data in large software systems but they are equally effective at representing the flow of entities in factories and offices. DFD's show the transformations that occur within systems without making assumptions about how they occur ([14]). When applied to describe the behavior of objects, DFDs can be useful for OO process modeling. (As we shall see later, the key difference between CIMpgr and DFD is the way the object attributes are identified and grouped. In this sense, CIMpgr models are significantly more accurate, nevertheless DFDs are simpler).
As examples, refer to simple and more complex enterprise models, that have significant design and manufacturing processes, and even Internet/ satellite links between them. Note, that in these DFD diagrams the ellipses mean processes (or the behavior of objects), the links between the processes (or the navigation paths between objects) represent data flows, the parallel lines are data depositories, or data stores, or data bases, and the square boxes are data sources, or data sinks (representing the boundaries of the modeled system).
DFDs can identify the functional elements, or objects of a system and the information flow between the elements. Similarly, each process box of a DFD may also be decomposed into another full DFD diagram, layer-by-layer, to show greater detail.
DFD's are not flowcharts since they do not describe sequences of processes, rather the data flow of a system without reference to time or the order of events, all in a structured, graphical format. The data flow can be likened to the material handling system between machines in a factory. Here the machines represent processes that change the data. Data is filed for reference, for temporary storage, or future use in the data store. The data source identifies the origin of the systems data and the sink identifies its ultimate destination.
In many cases, the DFD's are used in preference to other diagrams because they are easy to understand both conceptually and in presentation. On the other hand, as we'll se below, compared to DFDs, CIMpgr models can provide a more accurate decision space, a better system specification and design model.
When designing and drawing these diagrams the following should be noted:
DFD is a graphical method for "modeling" a system. A complete DFD model is a set of diagrams which systematically illustrate the object-to-object relationships between the 0bjects, their functions and entities.
The diagrams are often arranged in a layered, tree-like fashion which together can be thought of as a collection of carefully coordinated objects, describing a system under investigation.
Following the layered approach of decomposing/ identifying objects in a complex system, at the top of the tree there is a very high-level description of the entire system and further down the tree one goes, so the descriptions of the individual parts (objects) of the system become more detailed.
For example, the parent diagram can describe a machine shop as an activity which converts materials and an engineering drawing into the finished component by the use of engineering expertise and the appropriate production machine(s). Decomposing this, the child diagrams then can detail the information in the parent diagram by identifying the major activities involved in manufacturing the particular component, e.g. studying the engineering drawing, determining the manufacturing process(es) required and manufacturing the component. Thus the overall activity described in the top diagram is gradually detailed by the child diagram in this layered architecture.
Similarly, each box (or object) on the child diagram can be described in greater detail by child diagrams of its own. This process of showing greater and greater detail (until the required level of system description is reached) is called decomposition.
It is important to mention, that if inheritance is on, attributes effecting objects in higher level classes (layers) get inherited by lower level child objects. This is a good feature because OO visual programs, or object/ class diagrams (like DFDs and CIMpgrs diagrams) don't become crowded, making them difficult to interpret.
As a software systems engineering example for the above, consider the following: The concept of making devices to become web-pages in the digital factory is novel and is already spreading in industry through PC machine and robot controller networks. This trend is expected to broaden rapidly and eventually cover a very wide area, including the
What is clear from the observed facts and trends (mostly based on studies performed in teh USA), is that Internet/ intranet -based innovation in integrated design and manufacturing coupled with enterprise management systems contributes to further cost reductions and sustainable growth. This is because networked and object-oriented, collaborative Product Lifecycle Management (PLM) activities and software systems, in integration with Enterprise Resource Planning and Management (ERP&ERM) with Supply Chain Management (SCM) coupled with Customer Relationship Management (CRM) represent a very powerful methods base. (These systems can be used on a real-time basis to fine tune a business, continuously learn, innovate and satisfy customer needs, therefore sustain growth and make profit on a global basis; as a significant example, the USA automobile industry has reported cost savings in the area of 30 percent).
To summarize this section, making a complete DFD model of a system is an iterative process. To understand this, consider the situation where an industrial system of some sort is being modeled:
In more detail, the process by which you can achieve the above outlined and expected results can be as follows:
This cycle is then typically repeated several times as the higher levels of the model become approved and the lower, more detailed level diagrams are drawn.
The CIMpgr method, toolset and diagrams
The CIMpgr method is a well tested set of integrated methods and interfaced/ integrated tools and technologies for the purpose of analyzing, specifying, designing, implementing/ integrating, operating, maintaining/ supporting and project managing systems, including large scale software systems, Computer Integrated Manufacturing Enterprise (CIME) and Concurrent Engineering developments.
The CIMpgr method complies with the U.S. initiated, international standard object-oriented UML (Unified Modelling Language) and the European CIM-OSA standard CIM reference architecture. It provides practical and simple solutions for modeling existing enterprises and creating new, more efficient and profitable, high quality systems, products and organizations with special emphasis towards SMEs (small-to-medium size manufacturing enterprises) ([9] and [10]).
The CIMpgr Method - Objectives
Provide a well tested set of:
The CIMpgr Method - Architecture
In terms of architecture CIMpgr is:
follows the principles of:
The CIMpgr Method - Structuring Concepts
As with most enterprise modeling methods, CIMpgr follows the well established sequence of critical processes, including the following:
1. Establish the strategy (and the behavior of objects that dominate your decision space)
2. Analyze requirements (and the behavior of objects that dominate your requirements space)
3. Analyze and review existing systems (i.e. their objects and the behavior of these objects)
4. Design and investigate different options (of selecting objects, as well as navigation schemes between objects)
5. After an iterative sequence, create a conceptual design and then the appropriate design of the new system
6. Analyze cost benefits (most importantly analyze "value added versus non-value added" processes and activities)
7. Plan training and possible future developments
8. Plan the implementation/ integration and the maintenance activities
CIMpgr is an integrated system analysis, design (i.e. system modeling) methodology, relying on industrial consulting experience as well as on well-known (e.g. DFD and IDEFo) and new interfaced/ integrated system modeling tools, standards and technologies that support the consultant in his or her work. Note, that the first diagram illustrates the basic, top layer CIMpgr object with the attributes of the object, grouped into inputs, outputs, controls and resources.
VERY IMPOARTANT! Note, that the fact that we group our attributes into these categories makes our modeling approach very easy to read and understand, as well as offers a smooth integration path to the UML, Unified Modeling Language approach, by the Object Management Group; (http://www.omg.org) and to systems and languages such as Rational Inc.'s ROSE 2000.
The second diagram explains more "what is what". Note, the significant benefits over the DFD method in that each process (or in other words object having behavior) can have not just inputs and outputs, as attributes, but also a clearer understanding of under what conditions does the process "fire", or in other words, become an active object and perform.
The unique feature of CIMpgr is represented by the way different methods and tools are integrated and applied to a practical industrial problem ([9]). The open-ended and modular, object oriented design enables the tools to be used in a very flexible way ([37] to [44]).
The combined method and open toolset includes the following:
1. System requirements analysis, knowledge acquisition and knowledge representation methods and tools, including interviewing techniques, knowledge based expert system tools, DFD, SADT/ IDEFo, object oriented CIMpgr, UML (Unified Modeling Language), simulation and others.
2. Static system analysis and specification tools, including DFD/ Yourdon, SADT/ IDEFo, object oriented CIMpgr, UML (Unified Modeling Language), value engineering, Total Quality Management, ABC (Activity Based Cost) analysis and others.
3. Dynamic system analysis and specification tools, including possible links to discrete event modeling, simulation (e.g. Witness, or SIMfactory, or others) object oriented simulation (e.g. SIMPLE), Petri-net modeling ([24] and [25]) and others.
4. System design tools, including DFD/ Yourdon, SADT/ IDEFo, object oriented CIMpgr, UML (Unified Modeling Language), discrete event modeling, simulation (e.g. Witness or SIMfactory, or others) object oriented simulation (e.g. SIMPLE), Petri-net modeling, CASE tools for software design and others.
5. Project planning, control and project management tools (e.g. MS-Project).
6. Multimedia presentation and education/ training tools (e.g. web-based, or CD-ROM/ DVD -based interactive multimedia talking books).
The CIMpgr Method - Integration
The method represents an integrated enterprise
relying on several existing and new tools, standards and technologies.
The CIMpgr Method - Implementation and Integration Management
Since computers are involved in the increasingly fast and intelligent decision making process at all levels of the product design and manufacturing industry, more skilled engineers and managers are required who have both a broader view of the business, the design and manufacturing facility and a good understanding of the processes involved.
In the words of Russel G. Hanson, Transtech, USA: "If organizations are to reap the benefits possible with CIM they must plan and manage the human aspects of technological change".
The following list of activities is a representative description of the CIMpgr Implementation/ Integration Management process:
1. Initiate project
2. Conduct preliminary analysis and design (find the objects, their classes of objects, their attributes and behavior)
3. Conduct detailed system analysis and design
4. Build the system
5. Implement/ install/ integrate/ maintain the system
The most important areas of knowledge for the "Concurrent Engineer" include the ability to describe, define and analyze different models as a system by specifying its structure, its components and their relationships. It is almost impossible to outline the areas of the required engineering knowledge without knowing the actual processes involved, but he must have a thorough understanding of the technical aspects of his own job as well as a broad understanding of other areas.
The trend is that teams of multi-skilled people are superseding the individual as the basic unit of work and accountability. The reason for this is that teams can take responsibility for producing entire products and can motivate their members more effectively than managers can motivate individuals.
In fact, Concurrent Engineering teams often manage themselves. Converting a concept into a complex product is an involved procedure consisting of many steps of refinement. The initial idea often doesn't work; iteration and teamwork is thus a key issue.
The case study illustrates several aspects of the above described enterprise and system modeling philosophy and methodology. Most importantly it gives a realistic example of such activity. The actual model shown is based on a small design and manufacturing enterprise that is keen on developing and manufacturing individually tailored products ([22] and [27] to [35]).
The example is reasonably generic, meaning that it can be ported to describe other, similar enterprises, in that it illustrates the way a small enterprise struggles by configuring and then integrating off-the shelf commercially available parts and system components (including software) into their designs.
Let us "walk through" or rather "hyperlink through" these figures, all twenty of them (file sizes on average 40K each!), to explain this system in some detail. It should be noted, that in many cases a simpler solution is satisfactory, but then in many other cases such models stretch to even 50 to 150 diagrams.
The principle that should guide the modeling team is that such models should be relatively easy to follow and extend, thus the number of layers should be kept to that of an appropriate number, but as a rule of thumb, typically not exceeding six.
To conclude this thought it is obvious that the more experienced the modeling team, the clearer and simpler the diagrams are! This requires experience as well as strong collaboration by all parties involved.
Let us turn our attention to the diagrams themselves and try to understand the modeling team's thought process by explaining the CIMpgr diagrams in this case study.
A sequential navigation path through the CIMpgr model
Page 1: This is the first page of the model, representing the top layer and setting the scene for the entire model. The process itself is marked as "Ao", meaning that this is the top layer process. (Note, that instead of Ao, one should use Bo, Co, etc. in case the model is very large, and in case there is a good logical way to split it into more parts. Also note, that the KISS principle, "keep it simple and straightforward", is very important here too!)
Note the fact, that there is a "Modeling viewpoint" as well as a "Modeling purpose" on each top page (or at the top level) of every CIMpgr model. This is very important, since the same real-world system could be modeled from a variety of different viewpoints as well as for a variety of different purposes.
As can be seen, the major data source of this top layer process is the "Customer with purchasing power", and the output, as accepted, is the "New, well documented, high quality product". The "satisfied customer" is a data sink, from the model's point of view. (Data sources and data sinks are important, since they set the boundary of the model).
Also note that the highest priority input is the "Customer requirements" input data set. This is indicated by the fact that the input arrow is very close to the arrow end of the input priority gauge. (As you'll see in other CIMpgr articles, mathematically this means a high weight at the input scale end, pushing up the particular value to the top of the scale, following the same principle as in scheduling jobs, following the WSPT, or weighted shortest processing time rule).
At the top of the process box, there are the controls. Often it is difficult to separate input from controls. As a rule of thumb, for controls, one should always be able to answer the question: "What does it limit, or control?, or "What restrictions does the particular control impose on the process?" (Note, that "Cost and time" are typical and good examples for controls, because there is never "enough of them"...)
At the resource side of the process note, that "Human resources" represent the most important resource for this process (as for most, despite the fact that many companies and even some universities do not value their human resources high..., managers learn about this when they have to operate machines, or teach courses...)
Colored in green, at the top right corner, there is a data store that serves the entire process. We put it there to indicate that this data store relates more to the output and control side of the process, than the others. This is a useful notation that keeps analysts "on the ground" by reminding them of certain priorities when modeling real-world systems.
Also note, that this data store includes all data stores that are below (in terms of layers) this CIMS Database. As with Inputs, Outputs, Controls and Resources, database content too, is decomposed to typically smaller objects, as you move downwards in the model, from the parent object to the children object(s).
In this particular case, the CIMS (Computer Integrated Manufacturing System) database is clearly an object oriented, integrated database, consisting of sub-databases, including Analysis, Design, Production, Corporate Knowledge and Quality related databases.
Last but not least, observe the standard CIMpgr notation, such as the "Author", "Date", "Version", "Model title", and others. These are important to keep these diagrams in good order, in particular when there are many of them... Obviously one could customize the layout of such frames according to their own needs. (Note, that thorough organization of such models will support the ISO9001 document storage requirements, reduce redundancy as well as errors and waste).
After this introduction let us further "dive into" the model and see the details...
Page 2: This is the child page of page 1. As can be seen, Ao is broken down to A1, A2, A3, A4, A5 and A6 processes. Some of these are explained in more detail in further pages, some are not. (This is because the model authors felt that the decomposed processes were the important issues of this project at the time of modeling. Obviously the rest of the processes, such as A3, A5 and A6 could be developed anytime due to the object oriented nature of the entire system design).
Note in this page the various feedback loops. One of them is the QC (Quality Control) feedback loop. This is important from an ISO 9001 point of view. Also note the way iterative processes are illustrated with feedback loops.
As can bee seen the individual, process linked (green) databases/ data stores build up the entire system's operational database. The notation indicates that the input/ output (or read/write) can be manual and/or computer based. This is because at the time this model was created, this system still had most of its data in files, on paper, rather than stored electronically in a proper database.
Page 3: This page represents the decomposed model of process A1. As can be seen the core of this activity, in this model, is the "Product Structure Planning Process". (This is why it is colored red). Also note, the appearance of the "customer" data sink again. This indicates that this link between the A14 process and the customer is a strong one, because it terminates here.
Page 4: This page breaks down process A2. Note, that there is an important iteration between these processes.
Page 5: This page is a process description. Note, that many different methods can be used for process description, including:
The purpose of the process description is to define and/or explain the transfer function of the process. In other words, to compute the output(s) based on the input(s), the control(s), and the resource(s). Note, that if at all possible this should be a mathematically describable transfer function, nevertheless there are many processes in the real-world that cannot be described mathematically due to their complexity, or fuzziness, or other reasons.
Page 6: This is the process description of process A14.
Page 7: This is the process description of processes A12 and A13.
Page 8: This is the process description of process A11.
Page 9: This is a further decomposition of process A4. (As can be seen the product of this company consists of both hardware as well as software integrated into a single product).
Page 10: This is a process description of process A22.
Page 11: This is a Data Dictionary page, because it describes the meaning of the term "Customer Requirements" to the readers of this model. The Data Dictionary is very important in particular if some special in-house standard terminology is used in the model, or if there is a special emphasis on the correct and accurate interpretation of a certain terminology that is crucial for all of us to follow.
Page 12: This is a Data Dictionary page, describing the term "Project info." (Note, that in most cases there are several pages of Data Dictionary entries. As experience shows, many large projects go wrong because project partners don't understand the teminology, or misunderstand some of them; therefore an accurate and complete Data Dictionary, or Glossary of Terms is crucial).
Page 13: This is the ERD, or Entity Relationship Diagram of our model. It illustrates the one to-one and the one-to many relationships between the entities. This is important if the CIMpgr model is used for building a database too. For the purpose of this article we have incorporated this page for completeness, but we do not deal with the database aspects here ([25]).
Page 14 and Page 15: are Data Dictionary pages, a terminology definition, supporting the indicated process description.
Page 16: This is the process description of process A6.
Page 17: This is the process description of process A5.
Page 18: This is the process description of process A4.
Pages Page 19: and Page 20: (and further pages: not shown here) are supporting pages, in that they help to orient the database designer in terms of what process or processes does a certain data support. This is the data/ process diagram, that could be very useful in many database and networking applications.
This concludes our CIMpgr case study.
Advanced in Information Technology, mechanical, electronic, bio-medical and pharmaceutical product / process design, manufacturing and assembly companies face unprecedented challenges as well as opportunities in the development and operation of information-based, knowledge managed digital enterprises.
Simultaneously financial institutions, academic institutions and government have to be part of this global change process and help and lead the world-wide "e-transition" in collaborative design and manufacturing processes, customer support, marketing, procurement, logistics, supply chain, e-commerce, de-manufacturing, maintenance, education and other areas. The advanced design and manufacturing/ assembly industry is increasingly operating on a globally integrated, Internet-based collaborative model of production and support in which OEMs (Original Equipment Manufacturers) assemble products out of components and objects (both hardware and software) by a network of distributed suppliers. This distributed client-server model is enabled by the Internet, company intranets and consortium based extranets.
In response to this need, the modern integrated product and process as well as system design and manufacturing engineer is working with computers and computer-controlled machinery, thus he/ or she must be familiar with the way integrated engineering projects are designed, manufactured/ coded, tested, maintained and documented. It is also very important to have expertise and
The modern, internationally employable engineer must have the ability to communicate with team members, to reason, manage, develop prototypes and perform economic and time analysis, based on known facts and also on information which is not available but can be obtained by simulation.
To summarize, in general he or she must be well above average in accuracy and thoroughness in his or her job. (Besides a good overall systems approach, attention to detail is essential!) Furthermore, must be enthusiastic about it and must collaborate with other people over the web, as otherwise will not be able to overcome occasional setbacks, panic situations and the vast amount of work involved ([33] to [41]).
References and further reading
[1] Merhar, C et al: Simultaneous design for manufacturing process selection of engineering plastics, Int Jnl Mater & Prod Techn 1994 9(1/2/3) 61-78
[2] Lenau, T and Alting, L: Models of manufacturing processes for design information systems, Proc CIRP Seminars, 21 (2) 129-135 EN
[3] Chen, C, Swift, F et al: Development of a feature based and object-oriented Concurrent Engineering system, Jnl Intelligent manufacturing Feb 1994 5(1) 23-31 EN
[4] Camarinha-Matos, L.M., Pinheiro-Pita, Rabello, R and Barata, J: Towards a taxonomy of CIM activities, Int, J. Computer Integrated Manufacturing, Vol. 8, No. 3, p. 160-176.
[5] Reuven Karni and Rubinovitz, J: A taxonomy for the materials handling and transfer environment, Int, J. Computer Integrated Manufacturing, Vol. 8, No. 3, p. 177-188.
[6] Anders Adlemo and Sven-Arne Andreasson: A dependability taxonomy for flexible manufacturing systems, Int, J. Computer Integrated Manufacturing, Vol. 8, No. 3, p. 189-196.
[7] Marcos Wilson, C. Aguiar and Richard H Weston: A Model driven approach to enterprise integration, Int, J. Computer Integrated Manufacturing, Vol. 8, No. 3, p. 210-224.
[8] Perakath C. Benjamin, Menzel, C., Mayer, R., and Padmanaban, N.: Toward a method for acquiring CIM ontologies, Int, J. Computer Integrated Manufacturing, Vol. 8, No. 3, p. 225-234.
[9] Ranky, P G: Concurrent /Simultaneous Engineering Methods, Tools and Case Studies, CIMware Ltd., ISBN1-972631-04-5, 264p. http://www.cimwareukandusa.com
[10] Ranky, P G: An Introduction to Concurrent/ Simultaneous Engineering, An Interactive Multimedia Presentation on CD-ROM with off-line Internet support (650 Mbytes), published by CIMware, Multimedia design & programming by P G Ranky and M F Ranky, http://www.cimware@cimwareukandusa.com
[11] Ranky, P G: An Introduction to Flexible Manufacturing, Automation and Assembly, An Interactive Multimedia Presentation on CD-ROM with off-line Internet support (650 Mbytes), published by CIMware. Multimedia design & programming by P G Ranky and M F Ranky, http://www.cimware@cimwareukandusa.com
[12] Ranky, P G: An Introduction to Total Quality and the ISO90001 Standard An Interactive Multimedia Presentation on CD-ROM with off-line Internet support by CIMware (IEE and IMechE Approved Professional Developer). Multimedia design & Programming by P G Ranky and M F Ranky, http://www.cimware@cimwareukandusa.com
[13] Ranky, P G: Computer Network Architectures for World Class CIM Systems, CIMware, ISBN 1-872631-01-0, 231 p. http://www.cimwareukandusa.com
[14] Ranky, P G: Manufacturing Database Management and Knowledge Based Expert Systems, CIMware Ltd., ISBN 1 872631-03-7, 240 p http://www.cimwareukandusa.com
[15] Ranky, P G: Flexible Manufacturing Cells and Systems in CIM, CIMware Ltd., ISBN 1-872631 02-9, 264 p. http://www.cimwareukandusa.com
[16] Ashton, P.T and Ranky, P G: A methodology for analyzing concurrent engineering and manufacturing processes at Rolls-Royce Motor Cars Limited, ICCIM Conference proceedings, Singapore, IEEE 1993.
[17] Ashton, P.T and Ranky, P G: The Development and Application of an Advanced Concurrent Engineering Research Tool-set at Rolls-Royce Motor Cars Limited, Japan/USA Factory Automation Conference proceedings, Kobe, Japan, IEEE 1994.
[18] Bisgard, S.: A conceptual framework for the use of quality concepts and statistical methods in product design. Journal of Engineering Design. Vol 3(2), 1992 p. 117-133.
[19] Barghouti, N. and Kaiser, G.: Modeling concurrency in rule based development environments. IEEE Expert. p. 15-27, 1990
[20] Booch, G.: Object Oriented Design with Applications. Benjamin Cumminggs, 1990.
[21] Barghouti, N. and Kaiser, G.: Modeling concurrency in rule based development environments. IEEE Expert. p. 15-27, 1990
[22] Bürli, Pato, Eigner, Ranky et al: ORDAT Eureka/FAMOS Research Report, 1993
[23] Rudas, I J, and Horvath, L: A modelling of a manufacturing process using a Petri net representation, Enginering Applications of Artificial Intelligence, 1997 10(3) 243-255 EN
[24] Shih, H M and Leung C K H: Management Petri net - a modelling tool for management systems, Int Jnl Production Research, 1997 35(6) 1665-1680 EN
[25] Tanik, M. and Chan, E.: Fundamentals of Computing for Software Engineers, Van Nostrand Reinhold, 1991, 251 p.
[26] CD-ROM/web: Ranky, P G: An Introduction to Total Quality and the ISO90001 Standard An Interactive Multimedia Presentation on CD-ROM with off-line Internet support, published by CIMware, 1997, 1998. Multimedia design & programming by P G Ranky and M F Ranky.
[27] Ranky, P. G. with Scoccola, J. (MCI-Worldcom, USA): An Introduction to Computer Networking and the Internet with Engineering Examples. A 3D interactive multimedia electronic book with 3D objects, text and videos in a browser readable format on CD-ROM/ intranet by http://www.cimwareukandusa.com, CIMware USA, Inc. and CIMware Ltd., UK, ISBN 1-872631-09-6, 1999, 2000, 2001. Multimedia design & programming by P G Ranky and M F Ranky.
[28] Ranky, P G: Modern Laser Applications: Guiding light, IEE: London: Manufacturing Engineer, The Technical Journal of the Institution of Electrical, Electronic and Production/Industrial Engineers, UK, Vol. 77, No. 6, December 1998, pp. 261-263.
[29] Ranky, P G: Some Generic Algorithmic Solutions to the Problem of Dynamic Scheduling in Flexible Manufacturing Systems that Operate Globally, ADAM (Advanced Design And Manufacturing), An international R&D journal over the Internet hosted by: http://www.cimwareukandusa.com, 24 p.
[30] Ranky, P G: An Object Oriented Development Model of Multimedia Techniques, The Second Regional Conference on Innovations in Teaching and Learning, NJIT, Newark, funded by the Gateway Coalition Grant, National Science Foundation, USA, January 1999.
[31] IEEE encyclopedia book chapter in the Webster: fully refereed Wiley Encyclopedia of Electrical and Electronics Engineering, Ranky, Paul G and Ranky, Mick F: "CD-ROMs, DVD-ROMs and Computer Systems", John Wiley and Sons, USA, 1999, p. 106 to 122. ISBN 0471 - 13946 - 7 (set), ISBN 0471 - 13942 - 4 (Volume 3).
[32] Kluwer book chapter, Encyclopedia of Production and Manufacturing Management (ed. by Paul M. Swamidass, Auburn University, AL, USA), Ranky, P G: Flexible Design & Manufacturing Systems, 1999, 22p. Kluwer Academic Publishers. Norwell, MA, USA, 1999-2000.
[33] Ranky, P.G.: Design, Manufacturing and Assembly Automation Trends and Strategies in China, Assembly Automation, MCB University Press, Vol 19, No. 4, Dec. 1999, p. 301-305. (This article has received the "Highly Commended Award of 2000", a Literati Club Award for technical authoring excellence in 2000, by MCB Universtity Press, UK).
[34] Ranky, P.G.: Modular fieldbus designs and applications, Assembly Automation, MCB University Press, Vol 20, No. 1, Jan. 2000, p. 40-45.
[35] Ranky, P. G.: Some Analytical Considerations of Engineering Multimedia System Design within an Object Oriented Architecture, IJCIM (International Journal of CIM, Taylor & Francis, London, New York) ), Vol. 13, No. 2, May 2000, p. 204-214
[36] Ranky, P.G., and Ranky, M.F.: A Dynamic Operation Control Algorithm with Multimedia Objects for Flexible Manufacturing Systems, IJCIM (International Journal of CIM, Taylor & Francis, London, New York, ), Vol. 13, No. 2, May 2000, p. 245-263
[37] Ranky, P.G.: Engineering Multimedia in CIM (Computer Integrated Manufacturing), IJCIM (International Journal of CIM, Taylor & Francis, London, New York, ), Vol. 13, No. 2, May 2000, p. 169-171
[38] Ranky, P.G., Das, S and Caudill, R.: A Web-oriented Virtual Product Disassembly and Identification Method for DFE (Design for Environment) and Electronic Demanufacturers, 2000 IEEE (USA) International Symposium on Electronics and the Environment, Organized by IEEE (USA), and the Computer Society, USA, May, 2000, San Francisco, CA, USA, Conference Proceedings.
[39] Ranky, P G.: A Multimedia Web-based Flexible Manufacturing Knowledge Management Framework, Japan-USA International Symposium on Flexible Automation, ASME (American Society of Mechanical Engineers), July, 2000, Ann Arbor, MI, Conference Proceedings.
[40] Ranky, P G.: An Object Oriented Virtual Concurrent Engineering Model and Product Demonstrator Case Study, Japan-USA International Symposium on Flexible Automation, ASME (American Society of Mechanical Engineers), July, 2000, Ann Arbor, MI, Conference Proceedings.
[41] Ranky, P G.: Virtual Collaborative Concurrent Engineering and Disassembly, Half Day R&D Seminar for the Japan-USA International Symposium on Flexible Automation, ASME (American Society of Mechanical Engineers), July, 2000, Ann Arbor, MI, Conference Proceedings.
[42] Ranky, P G.: Utilizing Manufacturing Cells and Systems in a Job Shop (The Analysis, Design and Computer Control of Lean, Flexible Manufacturing Work Cells & Systems with Practical Examples), IMTS 2000, International Machine Tool Conference, Chicago, September, 2000, Proceedings.
[43] Frazer, A. and Ranky, P.G.: A Case-based Introduction to the National Electronics Manufacturing Initiative (NEMI) Plug and Play Factory Project; An interactive multimedia publication with 3D objects, text and videos in a browser readable format on CD-ROM/ intranet by http://www.cimwareukandusa.com, CIMware USA, Inc. and CIMware Ltd., UK, ISBN 1-872631-41-x, 2000, 2001. Multimedia design & programming by P G Ranky and M F Ranky.
[44] Upcraft, S. and Ranky, P.G.: A Case-based Introduction to Rapid Prototyping Solutions; An interactive multimedia publication with 3D objects, text and videos in a browser readable format on CD-ROM/ intranet by http://www.cimwareukandusa.com, CIMware USA, Inc. and CIMware Ltd., UK, ISBN 1-872631-42-8, 2000, 2001. Multimedia design & programming by P G Ranky and M F Ranky.