Information and knowledge modeling to support collaborative product development

1. Information and knowledge modeling to support collaborative product development

2. Outline • Introduction • The concept of information modeling( general) • Information Modeling Procedure (general) • Modeling Methodologies (general) • Entity Relationship Approach • Functional Modeling Approach(case study food industry) • Object Oriented Approach (A case study from product life cycle-electric cleaner) • Multi agent systems, Holonic Manufacturing system • Resource, capability, competency and core competency • The competency philosophy (definition and proposed model) • The competency modeling for product life cycle • Research gaps, difficulties and benefits of competency philosophy for product development and collaborative product development • References

3. Introduction The combination of emerging technologies, global competition, and market diversification is imposing a great need for transferring information timely and reliably. Today's manufacturing industry greatly relies on computer technology to support activities throughout a product’s life cycle. Effective and efficient information sharing and exchange among computer systems have been critical issues. For example, in the manufacturing industry, not only can design and manufacturing work be conducted through integrated CAD/CAM processes with electronic linkages to carriers, such as FedEx and UPS, but the entire project and process management activities can be monitored electronically from ideation to product delivery.

4. Information Modeling • An information model is essential to provide the structure for information that is transferred in a communication. An information model is a formal description of a portion of interest of the real world and that provides explicit rules to enable the data items that populate the model to be interpreted without ambiguity. • An example of an information model is the structure of a sentence in a natural language. The grammar of the natural language provides the rules for interpretation of the information model (sentence) and the data items in the structure are the words of the language. To complete the capability to interpret the communication correctly a dictionary that defines the meanings of the data items (words) is also needed. To achieve unambiguous communication, everyone in the communication process must use the same information model and the same dictionary. If the communication process is between two computer software systems then the information model and the dictionary also have to be computer processable. A dictionary also has to have an information model to provide a structure for the items and their definitions.

5. Requirement Analysis In the requirements analysis phase of information modeling development, Wand and Weber state[1], “High-quality conceptual modeling work is important because it facilitates early detection and correction of system development errors.” The Standish Group Project, an international consultancy, released a case study report [2] based on more than 30,000 organizations. It stated that for all the software projects developed, only 16% of them succeed. For the rest of 84%, 31% were totally failed, and 53% had cost and time overruns and missing features. According to another report by McConnell [3], the causes of software failure mainly concentrate on: objectives not fully specified (51%) and bad planning and poor estimating (48%). If we can understand customer’s requirements more accurately in the requirements analysis and model the business context to facilitate the implementation of software, then we can increase the probability of success greatly.

6. Information Modeling Procedure A quality information model should be complete, sharable, stable, extensible, well-structured, precise, and unambiguous. In general, the contents of an information model include - Scope - Information requirements

7. Scope Information modeling starts with the definition of the scope of the model‘s applicability. The scope specifies the domain of discourse and the processes that are to be supported by the information model. It is a bounded collection of processes, information, and constraints that satisfy some industry need. The scope statements include the purpose as well as viewpoints of the model mentioned bellow: type of product, type of data requirements, supporting manufacturing scenario, supporting manufacturing activities, supporting stage in the product life cycle.

8. Scope (Cont) The scope definition may be supported by an activity model and/or a data planning model. An activity model is a representation of the application context, data flows, and the processes of the application. It is a mechanism for gathering high level information requirements. A data planning model provides a high level description of the data requirements for the information model, as well as the relationships among the basic data components. It is used as a roadmap to establish interfaces across a wide range of data. A well-defined scope should be accurate, unambiguous, viable, and meet the industrial need. During the course of the modeling, the scope should be revisited and may be refined. Since the scope provides the boundaries of the application domain, it also serves as a guideline for evaluating the “completeness” of the information model.

9. Information Requirement Depending on the scope, the analysis may include today‘s manufacturing practices, traditional practices, and near future needs. It is important to capture data requirements accurately for the application scope while performing the requirements analysis. Industry reviews of the result of the analysis will help to ensure the completeness and correctness of the information requirements. As the result of the requirements analysis, information requirements should be documented. The definition of each identified information item should be included in the document. This document will be a straw man for developing the information model.

10. Information Requirement After the scope is defined, the next phase is to conduct a requirements analysis. There is no standard method for collecting information requirements. However, requirements analysis may be accomplished by: - Literature surveys, - Standards surveys, -Domain experts’ interviews, - Industrial data reviews, -State-of-the-art assessments.

11. Modeling Methodologies Information modeling is a technique for specifying the data requirements that are needed within the application domain. There are different practices in developing an information model: - Entity Relationship Approach (ER) - Functional Modeling Approach - Object Oriented Approach (O-O)

12. Entity Relationship Approach (ER) The ER approach focuses on how the concepts of entities and relationships might be applied to describe information requirements. The ER approach is based on a graphical notation technique. The basic constructs in an ER model are the entity type, the relationship type, and the attribute type. The notation is easy to understand and the technique has been useful in modeling real problems. There are commercial tools available to map ER models into commercial DBMSs (Database Management Systems). ER approach is a better selection if data requirements are at the higher levels of detail. • E/R Models are often represented as E/R diagrams (ERDs) that • Give a conceptual view of the database • Can identify some problems in a design The disadvantage of the ER model is its lack of preciseness in supporting the detailed levels.

13. Entity Relationship Approach (ER) Entity-relationship models use information objects (entities) to represent objects in the real world, specify the properties of real world objects as attributes of the information objects and show the relationships between the objects. Entity-relationship models provide specifications for information about objects by the following capabilities: ….. is_a …… (entity) … has_a ……. (attribute) ….is_related_to…. (one-to-one or one-to-many) My name is Shiva

14. Entity Relationship Approach (ER) • Example: In a University database we might have entities for Students, Modules and Lecturers. Students might have attributes such as their ID, Name, and Course, and could have relationships with Modules and Lecturers (tutor). • E/R Modeling is used for conceptual design • Entities - objects or items of interest • Attributes – facts about, or properties of, an entity • Relationships – links between entities • Relationships are links between two entities • The name is given in a diamond box • The ends of the link show cardinality

15. Case study for entity relationship approach[6] The University Food Company manufactures shelf-stable and refrigerated packaged food products for university dining halls and supermarket brand labels under contracts with supermarkets. The company has been automating some of its business systems. For example, the company previously developed a material tracking system for controlling incoming raw materials . This tracking system establishes lot numbers for ingredients and other raw materials and maintains a record of the location of each material lot in the warehouse. Management wishes to extend the information system to include the gathering of information about the manufacture of the products as well as the control of finished goods after manufacture.

16. Production line layout Combine and cook ingredients T1 Weighing Station T4 T2 Mix cooked ingredient T3 Fill and Seal Trays T5 Palletizing

17. Requirement Analysis • Most design projects require extensive study before any attempt is made to • develop a data model. Some basic questions need to be answered: • What are the goals of the project? • What are the boundaries of the system that is the object of the design? • What are the needs of the prospective users? • Who are the sources for gathering relevant information? During the initial stages of a project, the analyst must decide what the client wants from the information system.

18. Information modeling for the case study consist of three phases: 1) Preliminary study and Problem Definition • Description of operation • Identifying system redesign objectives • Defining ‘as is ‘ IDEF0 activity diagram and establishing system boundaries 2) Design Phase 3) Implementation phase

19. Description of operation The first step of the project is to study the operations involved in the manufacture of the products and to understand the general objectives of management and production personnel for the information system. Several individuals have been identified as key sources of information on the client side. There are three different points of view for this case study: 1) Plant manager 2) Production line supervisor 3) Quality control manager

20. Description of operation Con. The plant manager has instructed the production line supervisor and production personnel to brief you on the operations in the target area. To perform his briefing, the production supervisor has prepared there subject: 1)Bill of material(BOM): structure for a “typical” product manufactured by University Food Company. 2)Production line layout: include levels of production 3)Process diagram: Flow of material in relation to production operations

21. Cheese sauce cook sheet Bill of material structure for macaroni and cheese

22. Data planning model Raw ingredients Combine and cook(mac) 1 73 5 243 75 3 4 74 2 Mix cooked components Fill and Seal Trays Store Trays Combine and cook(chess and sauce)

23. b) SYSTEM REDESIGN OBJECTIVES The system redesign objectives have to do with the redesign of the information collection system and how that information is used. It does not have to do with the redesign of the physical processes of manufacture, which are fixed. The objectives of the information system design are usually expressed by the clients of the system analyst and have to be interpreted by the analyst. In this scenario, we will assume that discussions have taken place with the plant manager, quality control manager, and the production line supervisor. b-1)Plant Manager If we have defect anywhere in the food chain, the government(FDE) wants to be ready to respond by tracking down the source of contamination and warning the recipients of the food products. This is obviously a necessary precaution from the FDA point of view. The plant manager is primarily interested in complying with new FDA requirements that is, being able to trace lots of raw ingredients to the batches of final product into which they went.

24. b-2) Quality Control Manager We are way behind the rest of the industry in automating our quality control records. Our quality control records come from two sources. My technicians get samples from the line and analyze them here in the lab. We retain a paper record on each analysis. The guys on the line are responsible for collecting and recording some data.the quality control manager thinks it is at least as important to automate the documentation of the quality tests during the preparation of the batches so that a routine audit of the quality tests on past batches is possible. b-3) Production Line Supervisor FDA wants us to record which lots of ingredients go into which batches of product, and we will have to find a way to comply with this regulation. The production line supervisor would like to accommodate these new requirements. He suggests the need to automate the data collection requirement.

25. Activity model recipe Control production processes Material staged for production Finished product Shop floor production reports A0 Node A0,control production processes The material staged for production is input to this activity, which is transformed into finished product on the output side. In addition, the activity provides an information output, shop floor production reports. There are controls on the activity. The recipe is the complete description of how the product is made.

26. Activity model Con. recipe Material staged for production combine and cook Ingredients A1 Shop floor production reports Mix cooked Ingredients A2 Cooked ingredients Mixed ingredients Fill and seal Trays A3 Decomposition of node A0 Store Trays in Refrigerator A4 Finished production Sealed and labeled trays

27. Activity model Con. recipe Combine Ingredients A11 Material staged for production Shop floor production reports Combined ingredients Cook Ingredients A12 Cooked ingredients Sample Cooked Ingredients A13 Sample to QC lab Technician T1 Decomposition of node A1 QC technician

28. Activity model Con. recipe Transfer Cooked Ingredients A21 Cooked ingredients Combined cooked ingredients Mix Combined Ingredients A22 Shop floor production reports Ingredients ready for pumping Insert Filler Pump A23 Mixed ingredients Decomposition of node A2 Technician T2

29. Activity model Con. recipe Mix ingredients Fill Package A31 Material staged for production Filled trays Shop floor production reports Weigh Tray A32 Rejected trays Accepted tray Piston filler Seal Package A33 Decomposition of node A3 Sealed tray Print Label information A34 Finished production In-line scale Sealing machine Inkjet printer

30. Activity model Con. recipe Stack Trays on Pallets A41 Seal and labeled trays Shop floor production reports Palletized trays Transport Pallets to Warehouse A42 Technicians Relocated trays Store in Refrigerator A43 Finished product Decomposition of node A4 Fork life truck driver

31. INTRO Combine Fill Seal Store Warehouse Cook Entities Relationships Attributes

32. Agenda for Design Identifying User Information Needs Defining entities and relationships Defining attributes Establishing the global data model Evaluating the need for transaction Implementation Phase

33. Identifying User Information Needs Plant manager : Lot tractability from raw materials to finished goods. Quality control manager: Relate quality control data to batches with which they are associated. Quality control data are collected throughout the production process at various steps in the process, which we shall call “operations.” Operations include cooking, mixing, filling, and so on. Productionline supervisor: Data input should not be cumbersome. This is not a requirement that would be considered at the conceptual phase because it has to do with physical implementation of the data model and its associated user input requirements.

34. Defining Entities and Relationships PLANT MANAGER VIEW 3 Rule : A material lot may go into zero, one, or more batch lots. Each batch lot will contain more than one material lot. A batch lot is simply the combining of portions of existing material lots into a new material lot that has a new lot number, for example, combining cheddar cheese, cornstarch, and so on from lots of raw ingredients into a lot of the cheese sauce. 1 2 OPR. A OPR. B Subassembly Final Product

35. Defining Entities and Relationships

36. Defining Entities and Relationships QUALITY CONTROL MANAGER VIEW 2 1 Rule 3: A material lot may have zero, one, or more quality control records associated with it. A quality control record is associated with one material lot. Rule 4: A quality control record requires one or more samples to be tested. Each sample yields one test result. Each sample is associated with one quality control record.

37. Defining Entities and Relationships Rule 5: A quality control record is associated with a quality control test procedure, which is a description of how to perform a test. A quality control test procedure may have many quality control records associated with it.

38. DEFINING ATTRIBUTES PLANT MANAGER VIEW QUALITY CONTROL MANAGER VIEW

39. Global Data Model After the analyst has completed the user views, she or he must review the models with the individuals who provided the details that make up those views. It is important that there is agreement between analyst and user that the data model and attributes have captured the principal relationships of interest by the user. Once they have reached an agreement, the analyst should unite these views into a single data model for further analysis, as shown in Diagram.

40. Global Data Model con. EVALUATING THE NEED FOR TRANSACTION ENTITIES Since our model includes the MATERIAL_LOT and will be united with the database shown in Figure 5.15 when implemented, which includes the WAREHOUSE_LOCATION entity, it is natural to include the LOT_TRANSACTION entity. FINALIZING AND VALIDATING AN IDEF1X GLOBAL INFORMATION MODEL

41. Implementation Phase • Creating database tables and relationships • Defining data entry methods • Creating queries, forms, and reports • Establishing data security and access methods

42. Final Data Base schema

44. Functional modeling

45. Functional Modeling Approach • The emphasis of the functional modeling approach is placed on specifying and decomposing system functionality. • The functional approach addresses the system's processes and the flow of information from one process to another. It uses objects and functions over objects as the basis. The approach often uses data-flow diagrams. A data-flow diagram shows the transformation of data as it flows through a system. The diagram consists of processes, data flows, actors, and data stores. In the case where functions are more important and more complex than data, the functional approach is recommended. This approach has been in wide use. • Functional Flow Block Diagram • End product of functional decomposition – shows sequence of system activities • Incrementally refine and mark inputs / outputs / controls • Used to illustrate system organization and major interfaces • Build at the later stage of Concept Generation • Sample system functional breakdown - see next page

46. Functional Modeling Level-0 System Requirements Top-level functions Level-1 Function A Function B Function C Function D Function E Function F Second-level functions Level-2 E.2 E.4 E.5 E.1 E.3 E.3 E.6 Figure: System functional breakdown

47. Functional Modeling Level-0 Area of a cube Top-level functions Level-1 6 * Area of square Second-level functions Level-2 Length of square * Length of square Example of a System functional breakdown

48. Levels in Functional Decomposition • Level 0 • This is where you start – the highest level involving one block only, i.e. a block corresponding to your system • Define inputs, outputs and system functionality (requirements) • Level 1 • Typically referred as main system architecture • Architecture means the organization and interconnection between modules. Describe the operation – how modules work together. • Define functional requirements for each module. • Level 2 • Typically shows the organization of components within a single module

49. Modeling functional design information for injection mold design Case study [16]

50. INJECTION MOLD