Manufacturing Information Systems - ISA-88/95 based Functional Definition 07 May 2006 Jean Vieille Psynapses 10, rue du Stade Dompierre-les-Tilleuls, 25560 (France) +33 6 74 45 47 27 psynapses2 (skype) j.vieille@psynapses.com www.psynapses.com HYPERLINK "http://www.psynapses.com/vieille" www.psynapses.com/vieille Table of Content TOC \o "1-3" \h \z \u HYPERLINK \l "_Toc138825389" 1 Scope of Manufacturing Information Systems PAGEREF _Toc138825389 \h 3 HYPERLINK \l "_Toc138825390" 1.1 Overview PAGEREF _Toc138825390 \h 3 HYPERLINK \l "_Toc138825391" 1.2 ISA-88/95 Functional Framework PAGEREF _Toc138825391 \h 4 HYPERLINK \l "_Toc138825392" 1.2.1 Extended ISA-88 Physical Model PAGEREF _Toc138825392 \h 4 HYPERLINK \l "_Toc138825393" 1.2.2 ISA-88 Procedural Model PAGEREF _Toc138825393 \h 4 HYPERLINK \l "_Toc138825394" 1.2.3 ISA-95 Activity Model PAGEREF _Toc138825394 \h 5 HYPERLINK \l "_Toc138825395" 1.2.4 ISA-88/ISA-95 Product Development Model PAGEREF _Toc138825395 \h 5 HYPERLINK \l "_Toc138825396" 1.2.5 ISA-88/ISA-95 Fit to Production Lifecycles PAGEREF _Toc138825396 \h 6 HYPERLINK \l "_Toc138825397" 1.3 Different views of Manufacturing Information Systems PAGEREF _Toc138825397 \h 7 HYPERLINK \l "_Toc138825398" 1.3.1 Decisional view PAGEREF _Toc138825398 \h 7 HYPERLINK \l "_Toc138825399" 1.3.2 Time view PAGEREF _Toc138825399 \h 8 HYPERLINK \l "_Toc138825400" 1.3.3 Capability view PAGEREF _Toc138825400 \h 9 HYPERLINK \l "_Toc138825401" 1.3.4 Operational view PAGEREF _Toc138825401 \h 9 HYPERLINK \l "_Toc138825402" 1.3.5 Process and Task styles PAGEREF _Toc138825402 \h 10 HYPERLINK \l "_Toc138825405" 2 Roadmap to Smart Manufacturing Control PAGEREF _Toc138825405 \h 11 HYPERLINK \l "_Toc138825406" 2.1 Overview of Information Systems Lifecycle PAGEREF _Toc138825406 \h 11 HYPERLINK \l "_Toc138825407" 2.2 Functional vs. Technical Core Systems PAGEREF _Toc138825407 \h 13 HYPERLINK \l "_Toc138825408" 3 Functional Core System Development PAGEREF _Toc138825408 \h 14 HYPERLINK \l "_Toc138825409" 3.1 Resource Modelling PAGEREF _Toc138825409 \h 15 HYPERLINK \l "_Toc138825410" 3.1.1 Manufacturing Operation Categories PAGEREF _Toc138825410 \h 16 HYPERLINK \l "_Toc138825411" 3.1.2 Material Resources PAGEREF _Toc138825411 \h 16 HYPERLINK \l "_Toc138825412" 3.1.3 Equipment Resources PAGEREF _Toc138825412 \h 16 HYPERLINK \l "_Toc138825413" 3.1.4 Personnel Resources PAGEREF _Toc138825413 \h 17 HYPERLINK \l "_Toc138825414" 3.1.5 Segments PAGEREF _Toc138825414 \h 17 HYPERLINK \l "_Toc138825415" 3.2 Functional Definition PAGEREF _Toc138825415 \h 17 HYPERLINK \l "_Toc138825416" 3.2.1 Process and Task Definition PAGEREF _Toc138825416 \h 18 HYPERLINK \l "_Toc138825417" 3.2.2 Task Characterization PAGEREF _Toc138825417 \h 18 HYPERLINK \l "_Toc138825418" 3.2.3 Task consolidation PAGEREF _Toc138825418 \h 18 HYPERLINK \l "_Toc138825419" 3.2.4 Task Description PAGEREF _Toc138825419 \h 19 HYPERLINK \l "_Toc138825420" 3.2.5 Segments PAGEREF _Toc138825420 \h 19 HYPERLINK \l "_Toc138825421" 3.3 Equipment Control Definition PAGEREF _Toc138825421 \h 19 HYPERLINK \l "_Toc138825422" 3.4 Operation Control Definition PAGEREF _Toc138825422 \h 20 HYPERLINK \l "_Toc138825423" 3.5 Operation Management Control Definition PAGEREF _Toc138825423 \h 20 HYPERLINK \l "_Toc138825424" 3.6 Develop and Map the Technical Core System PAGEREF _Toc138825424 \h 21 HYPERLINK \l "_Toc138825425" 4 Conclusion PAGEREF _Toc138825425 \h 22 Table of Figures TOC \h \z \c "Figure" HYPERLINK \l "_Toc138825426" Figure 1, Critical Manufacturing Enterprise Flows PAGEREF _Toc138825426 \h 3 HYPERLINK \l "_Toc138825427" Figure 2, ISA-88/95 Physical Model PAGEREF _Toc138825427 \h 4 HYPERLINK \l "_Toc138825428" Figure 3, ISA-88 Procedural Model PAGEREF _Toc138825428 \h 5 HYPERLINK \l "_Toc138825429" Figure 4, ISA-95 Part 3 Manufacturing Operation Management Activity Model PAGEREF _Toc138825429 \h 5 HYPERLINK \l "_Toc138825430" Figure 5, ISA-88/95 Product Development Model PAGEREF _Toc138825430 \h 6 HYPERLINK \l "_Toc138825431" Figure 6, ISA-88/95 Fit to Production Lifecycles PAGEREF _Toc138825431 \h 7 HYPERLINK \l "_Toc138825432" Figure 7, ISA-88/95 Physical/Decisional Hierarchy PAGEREF _Toc138825432 \h 8 HYPERLINK \l "_Toc138825433" Figure 8, Temporal View of ISA-95 Activity Model PAGEREF _Toc138825433 \h 9 HYPERLINK \l "_Toc138825434" Figure 9, Manufacturing Information Systems Lifecycle PAGEREF _Toc138825434 \h 11 HYPERLINK \l "_Toc138825435" Figure 10, Master Project Components PAGEREF _Toc138825435 \h 12 HYPERLINK \l "_Toc138825436" Figure 11, Relationships Between Master and Instance Projects PAGEREF _Toc138825436 \h 13 HYPERLINK \l "_Toc138825437" Figure 12, Functional Core System Overview PAGEREF _Toc138825437 \h 14 HYPERLINK \l "_Toc138825438" Figure 13, Functional Core System Development Process PAGEREF _Toc138825438 \h 15 HYPERLINK \l "_Toc138825439" Figure 14, Facility Model at the Heart of MIS PAGEREF _Toc138825439 \h 15 HYPERLINK \l "_Toc138825440" Figure 15, Modelling Process PAGEREF _Toc138825440 \h 16 HYPERLINK \l "_Toc138825441" Figure 16, Functional Definition Process PAGEREF _Toc138825441 \h 17 HYPERLINK \l "_Toc138825442" Figure 17, Task Consolidation PAGEREF _Toc138825442 \h 19 HYPERLINK \l "_Toc138825443" Figure 18, Developing & Mapping Technical Core System PAGEREF _Toc138825443 \h 21 Scope of Manufacturing Information Systems Overview Manufacturing plants control encompasses many tactical and operational functions, addressing several types of manufacturing related operations from receipt of raw material to shipping of finished goods, from production itself to equipment maintenance through inventory movements and material quality tests, from customer order lines to work dispatching in addition to controlling the manufacturing operations themselves. These functions fall under different responsibilities, though they must operate collaboratively under effective business management directions. The role of information in a manufacturing company can be simply summarized by the figure below. Considering the 3 main flows (Material, money, information) crossing an enterprise system, one can immediately point out the specific importance of information: material flow constrains money flow (no payment until delivery) information flow constraints material flow (no delivery until shipment documentation is issued) money flow (no payment until invoice is issued) Figure SEQ Figure \* ARABIC 1 , Critical Manufacturing Enterprise Flows A manufacturing information system is thus an enabler to reaching higher levels in financial performance. On the contrary, a poorly designed and tuned information system definitely hurts the plant's ability to serve the Company's goal of sustaining and increasing profits. In consequence today's ideal information systems are flexible, ultimately invisible information infrastructures that constantly adapt themselves to the actual resources, products, business and decision processes of the enterprise. They are no longer a constraint to develop differentiating, winning strategies. Attaining such an ideal situation implies reaching the highest level of maturity in developing and maintaining such information systems that allow with minimized effort to: Adding new capabilities, cancelling, extending, improving existing capabilities in real time Capturing existing constraints impacting the bottom line as user requirements Implementing or supporting continuously improving manufacturing and business processes Allowing to take benefit of the technology as it is available, when and where appropriate ISA-88 and ISA-95 standards provide a set of models considered as best engineering practices for industrial information systems in charge of manufacturing execution. ISA-88 for describing functional and informational aspects of physical and chemical transformation processes and tasks ISA-95 for describing functional and informational aspects of operation management processes and tasks While this paper introduces an extensive, holistic approach to industrial information systems lifecycle, it only describes the functional requirement approach regardless of it's concern with the master (common templates definition and maintenance) or instance (actual) projects. It deliberately puts aside the informational (ISA-88 and ISA-95 data structure models) and technical (implementation) aspects. ISA-88/95 Functional Framework This shortened paper supposes that the reader has a sufficient understanding of both standards. This section presents some of the ISA-88 and ISA-95 models which are of interest here. They are not described in detail, but briefly explained in their role for the discussion. Extended ISA-88 Physical Model This hierarchical model presents the physical asset as well as the location-based enterprise's organisation. It starts from the actual physical equipment in Control Modules and progresses by virtual aggregations to a less and less physical meaning, ending to the enterprise itself. The originating ISA-88 model was extended by ISA-95 to include alternate terminology for 2 specific levels, later unified in ``Work Centre'' and ``Work Unit''. This terminology aims at addressing non-batch manufacturing strategies. The user is free to use any of the proposed terms, but the stated extensibility and collapsibility affirmed in ISA-88 lets it open to additional levels and specific terms. Work Centre and Work Unit have a very consensual purpose and use in any industry while other levels can be more specific. The 2 lowest levels are of interest for equipment control only; they have a specific role when applying ISA-88 smart automation concepts. The most important ISA-88 ``secret'' is the underlying equipment focus design, which is quite uncommon in the traditional business IT approach. This principle is the basis for flexibility; it is generalized here for all aspects of manufacturing control. It implies that nothing can be discussed without first identifying the supporting equipment entity. Figure SEQ Figure \* ARABIC 2 , ISA-88/95 Physical Model ISA-88 Procedural Model This model was defined in order to structure the functional definition for both equipment control (within equipment entities) and operation control (called ``master / control recipe'' in ISA-88). It only applies to 3 physical levels according to the mapping shown in the figure. The original Process Cell and Unit have been replaced by the ISA-95 unified Work Centre and Work Unit terminology. The green colour corresponds to the operation control, while the blue colour corresponds to the equipment control. Figure SEQ Figure \* ARABIC 3 , ISA-88 Procedural Model ISA-95 Activity Model This model defined in ISA-95 Part 3 describes the operation management functions to supervise any operational activity. It can be applied to the production itself, but also to quality, maintenance, inventory and any other operational planned and dependent activity making use of resources. Figure SEQ Figure \* ARABIC 4 , ISA-95 Part 3 Manufacturing Operation Management Activity Model ISA-88/ISA-95 Product Development Model Both standards have provisions for describing product related processes. From the product development R&D stage to the operating procedure to make the product using a specific facility, a robust business process can be defined based on the standard scheme. While ISA-88 explicitly defines the transformation process from the product's physical and chemical transformation to the actual equipment aware processing, ISA-95 just defines a common structure to handle processing breakdown and resource constraints and usage. The following figure summarizes the product lifecycle in relationship with standards' models and elements. Green and blue rectangles correspond respectively to operation and equipment related information and activities. Yellow is for shared, generic templates that are the basis for knowledge management and building blocks for assembling product definition from either processing requirement (R&D) or execution specification (Operations). Text in orange corresponds to ISA-95; text in dark blue corresponds to ISA-88 concepts. Figure SEQ Figure \* ARABIC 5 , ISA-88/95 Product Development Model This model commonly applies to an operation-independent, long duration process from market sensing to validated operating procedures through lab elaboration, pilot development, and scaled industrialization. However, as demand driven supply chain operations become the norm, this process can be integrated in the production scheduling, involving sophisticated automation support for dynamic industrialization from customer request to resource mobilization. ISA-88/ISA-95 Fit to Production Lifecycles To summarize the scope and respective coverage of both standards we might consider the following production related lifecycles: Product development cycle is supported by Product Definition and Product Segment models in ISA-95, by Recipes and Recipe Procedural/Process elements in ISA-88 Resource engineering cycle is supported by Production Capability and Process Segment models in ISA-95 and by Equipment Procedural Elements in ISA-88. The Physical model is shared by both standards Production cycle is supported by Production Schedule and Performance models and by ISA-88 batch concept. Figure SEQ Figure \* ARABIC 6 , ISA-88/95 Fit to Production Lifecycles Different views of Manufacturing Information Systems Manufacturing information systems might seem complex because they address very different interacting domains that can be loosely coupled, synchronized in real time or simply collaborative. Some possible views of MIS are presented below. Decisional view Execution/Business Domains The ISA-95 standard starts by setting a boundary between the execution and the business domains. This segregation can be considered from the responsibility point of view at the user requirement level. Decision processes are considered split between those who: Direct the enterprise mission to serve its customers Manage to accomplish this mission by making the best use of the enterprise resources Thus, the scheduling process is declined in different time horizons and often clearly split between these domains. However, modern scheduling methods tend to be more global, implementing collaborative, interweaved decision processes from customer order to actual manufacturing and delivery. Ultimately, lean/TOC approach tends to even eliminate hierarchical scheduling by feeding the production lines workbook with customer orders. The ISA-95 split between Business and Execution is actually more about highlighting a ``technical'' boundary that helps define data structures for interfacing the corresponding systems. These systems do not necessarily address their ``legal'' responsibility domains. For example, local KPIs used to monitor equipment usage can be supported by a dashboard-enabled ERP. In consequence this split may not be so important for the user requirement point of view. A finer split according to the user's role in the decisional organization is more adapted. Physical/Decisional Hierarchy From the top level carpet covered floor occupied by the Enterprise executives to the machines and tools crowded shop floor haunted by workers, the physical and decisional hierarchies closely match. For the manufacturing information systems purpose, the physical model represents the basic framework. ISA-88 proved that the equipment centric approach making the information system just a part of the actual equipment is appropriate for addressing flexibility in all aspects. This should be true for the entire manufacturing information system: any part of the facility embeds and confines its corresponding part of the information system (functionally at least). The ISA-95 standard is quite insensible to the nature of the physical model. However, ISA-88 is quite firmly articulated around its model, at least for its lower parts because of the processing meaning of these levels, which is of no importance for the more accounting oriented ISA-95. Figure SEQ Figure \* ARABIC 7 , ISA-88/95 Physical/Decisional Hierarchy Time view The manufacturing information system support can be considered according to the time a function occurs relatively to the moment of the work execution: Before operation execution These activities are performed before execution occurs During operation execution These activities are performed while execution goes on (Real time interaction) After operation execution These activities are performed after execution has been completed or while it is being performed, but not in real time (asynchronously) Not time related (Reference data) These activities are performed independently of the execution. They provide the necessary information for execution and may be affected by the execution (resource status and usage) REF _Ref134791883 \h Figure 8 shows how this view applies to the ISA-95 operation management activity model. Figure SEQ Figure \* ARABIC 8 , Temporal View of ISA-95 Activity Model Capability view The capability defines the level of support a system can offer. For example: Visibility Examples: Data collection, performance monitoring, reporting Control Examples: PID control, automatic start-up, production orders and reporting automated workflow, work specification enforcement, quality control Optimization, anticipation: Examples: Statistic or Real time process improvement, resource usage optimization (finite capacity scheduling, lean operations, DBR), Performance objectives and improvement processes against strategic criteria (SPC, 6 Sigma) An enterprise might decide to draw a roadmap that builds on this capability scale in the given order. Operational view The classical hierarchy from the enterprise goals to the actual operations is commonly summarized in: Strategy: Where we want to go and the magic to get there Tactics: How we are to proceed to implement the strategy Operations: How we execute the mission by activating material and financial flows MIS essentially support operations though they can provide basis information for tactics and even strategy, or tactics might be embedded in operation as in TOC and Lean approaches. Supporting operations means controlling 3 types of processes: Equipment Process Control Equipment Processes are about running individual equipments regardless of their purpose in the whole manufacturing system (i.e. heating, grinding, filling, moving vs. making a product or fulfilling a service) ISA-88 split control in Basic (interlocking, control loops), procedural (sequencing actuators to provide process oriented services) and coordination (equipment - operator interaction, equipment entities / equipment procedural elements interaction and allocation) ISA-95 process segment model adds the resource dimension to the ISA-88 behavioural concepts Operation Process Control Operation Processes are about running the facility in order to execute the manufacturing system mission (i.e. making a product or fulfilling a service) ISA-88 defines Recipes to support operating procedures that execute the manufacturing system mission of creating value (making a product, fulfilling a sellable service). ISA-95 Product definition and production schedule models add the resource dimension to the ISA-88 behavioural concepts Operation Management Process Control Operation management processes are about preparing and launching product making or service execution, monitoring and reporting execution, managing resources and product / service definitions ISA-95 Part 3 specifically addresses this subject (activity model section REF _Ref134706537 \r \h 1.2.3 ) Process and Task styles Everything that produces value and/or consumes resources implies a process. A process defines situations and scenarios that are involved for having a system achieving its' objectives. A process is made of lower level processes. Ultimately, when a process is not split anymore, it is called a Task (a process sequences tasks, that can be themselves a process made of tasks). These two terms cover the same notion; it just depends where the breakdown stops. Many different names can be given to process and tasks: Business processes in management related activities, Procedures, operations and phases in S88 based batch control, routing in discrete manufacturing etc. The notion of process might appear very different depending of its outcome. For example: Real Time (RT) Involves direct interaction with automation or operators Operator input must occur within seconds for execution to continue Application stoppage or poor performance immediately impacts execution Transactional (TS) Volume entry of information or data Speed might be a productivity issue, but Primary requirement is for data accuracy, integrity, and reliability Inaccurate information would cause significant direct business consequences Data Storing & Archiving (SA) A process for selecting, summarizing, validating etc. data for future use or records purposes Bottom up process to transform low-level raw data into information for upper levels Analytical (AN) Analysis of data in various fashions to learn from the data Output may be an outer feedback loop to processes and Quality Assurance Modelling and Simulation (MS) Processes based on predetermined model Examples are design simulation (engineering stage), planning and scheduling (operations stage) Collaborative (CL) Supports teamwork between several people who need to work together to provide information or solve a problem Generally an activity spread out over time, usually unstructured Workflow A sequence of activities, which must follow a predetermined path or sets of paths between individuals, functions or machines Differs from Collaboration by being very structured Resource view The resource view concentrates on what is available in the facility. Resources and capabilities Product view Value adding activities Roadmap to Smart Manufacturing Control The role of manufacturing information systems is to support manufacturing operations by: Providing relevant and timely information for the decision making, at different levels of the company hierarchy Automating and securing the sequencing of manufacturing and business processes, when this adds value Supporting the enterprise strategies, not constraining them in any way This has to be kept in mind when defining the requirements for such a system, but doesn't help much when it comes to lay them down, exploring the area where the information system can help or must act: In a way that is understandable, sustainable on the long run Aligned with the system's actual implementation The goal is to align the whole system definition from the strategic objectives to the actual implementation of software modules or applications, in a dynamic perspective. Overview of Information Systems Lifecycle These are some assumptions that served as a basis for the proposed approach: Information technology is evolving fast. We are still living at the prehistoric times of the information age; today's technology is far from what it will be tomorrow. Application centric systems give place to process subordinate services. Pre-integrated off the shelf systems will be replaced by orchestration management and execution of services from diverse origins installed on standard infrastructures. In manufacturing, machines generate wealth, not IT. However, IT supports processes that create wealth Manufacturing definitely goes lean and agile requiring highly flexible information systems that meet its requirements. Strategies must be implementable on the spot MIS projects are subject to particular difficulties. Failures are numerous; successes are often only technology prowess. The main reason is the distance between the strategic objectives and the technology challenges associated with the vague mapping between goals and means, resulting in unclear responsibilities, loss of sight of strategic objectives, user requirements vs. installed solutions discrepancy, exacerbate intrinsically uncontrollable nature of IT projects... The overall life cycle presented on REF _Ref134759531 \h Figure 9 is intended to tighten the MIS ongoing development lifecycle within an agile, controlled process. Figure SEQ Figure \* ARABIC 9 , Manufacturing Information Systems Lifecycle 1. MIS Strategic Guidance Identify expectations from Company's Top Management. It delivers Status and maturity level of the manufacturing information systems in terms of services they provide, or constraints they impose Requested improvements & corresponding global economical impact 2. MIS Master Plan Based on strategic guidance, the Master Plan designs and maintains the roadmap for implementing the necessary changes and monitors Master and Implementation projects. It delivers: A continuously updated, sequenced, measured and controlled suite of projects, consistent with master project components 3. MIS Master Project Ultimate process management maturity is a requirement for the company in search of excellence. The Master Project is a permanent action covering the entire life cycle of the company's manufacturing facilities. It guaranties perenniality, evolution, risk mitigation of real projects and delivers: Resources models ``Functional Core System'' of company-wide generic user requirements as standard processes and tasks "Technical Core System" of company-wide solution components for use in Instance Projects / target systems Development and deployment guidelines for all aspects of the Master and Instance Projects execution Figure SEQ Figure \* ARABIC 10 , Master Project Components 4. Instance Projects Instance projects are actual projects, implementing master project solution components on particular facilities, implementing the directives of the Master Plan. Upstream actions must be concretized by tangible and rapid results by the successful completion of the Instance projects. The relationships between Master and Instance projects are presented in REF _Ref134762766 \h Figure 11 . Operation control projects might correspond to introducing a new product or a processing improvement, Equipment control projects might correspond to the installation of new machines or adding to them new automated capabilities, Operation management control projects might correspond to developing a new KPI or an electronic Kanban application. Figure SEQ Figure \* ARABIC 11 , Relationships Between Master and Instance Projects 5. Facility Life and Back Arrows From 1 to 4, the arrows indicate a consistent activity flow / decisional workflow that will make things happen. The last, but somewhat the initial point of start is the facility life itself. Strategic guidance certainly takes into account what happens in the facilities, among market, customers, suppliers, and economic, social and natural environment. But feedback is active at every level to maintain dynamics, momentum and support among all company levels, roles and persons. The upper decisional level shall be in sync with actual implementation: unspoken requirements showing up during the system implementation and commissioning have to be taken into account (or rejected!). This maintains the consistency with the core system, to address issues from a broader perspective, and to make the corresponding improvements available at the enterprise level Only the functional aspects of master / instance projects are presented. Functional vs. Technical Core Systems At the heart of the methodology is an irrevocable split between the functional user requirements and the technical solution components that are used to implement them. Both must evolve independently: Functional user requirements to define the needs to develop the Enterprise strategies Technical components to make the best use of available technology for implementation These 2 dimensions only appear in Master and Instance Projects Master project defines both standard user requirements, technical components and the mapping between both Instance project implements requested, template based user requirements using available technical components, all part of the Master Project deliverables. Functional Core System Development Overview Because of the strong resource based concepts of both ISA-88 and ISA-95 due to the inherent nature of manufacturing systems, a core system can hardly be defined ``off-line'', without any reference to actual facilities. In real life the core system will generally be developed based on Instance (sometime `pilot`) projects. Pragmatism is the key and the feedback loop might provide the main input for the Master Project, which acts as a control structure. Figure SEQ Figure \* ARABIC 12 , Functional Core System Overview The overall process for developing the functional core system follows the hierarchy of operational aspects of manufacturing control. (See REF _Ref134779283 \r \h 1.3.4 ) Stage 1: Resource Modelling Modelling resources is the initial step that provides the framework for the functional definition. Stage 2: Equipment Control Controlling equipment is the very initial level to control a manufacturing system. No product can be made, no management process makes sense without an operating facility Stage 3: Operation Control Operation control supports the execution of work operating procedure to make the product or to deliver the service. It is the next level of controlling a manufacturing facility, making use of properly controlled equipment and able to address management directions regarding the work execution activity. Stage 4: Operation Management Operation management connects to the business planning systems; it directs operation control, prepares, analyses, track and reports work execution; it manages resources and work definitions. Develop and Map the Technical Core System The defined functional core system serves as a basis for developing and/or mapping technical components using actual capabilities of available solutions. The organizational and process based functional core system development is summarized in REF _Ref134767619 \h Figure 13 Figure SEQ Figure \* ARABIC 13 , Functional Core System Development Process Resource Modelling The resource models describe the assets of the enterprise facilities. It is the shared information that articulates all manufacturing information system aspects, from strategy to operations, from Master Project development to Instance Projects realization, for structuring functional and technical core systems. Figure SEQ Figure \* ARABIC 14 , Facility Model at the Heart of MIS Modelling facilities is an ongoing activity that maintains the current state of the enterprise assets known by the manufacturing information system. It is critical as the flexible manufacturing information system is literally built inside (specifically physical assets) or around the enterprise assets. As modelling essentially deals with resources, 2 aspects of the modelling shall be distinguished: The ``static'' model that describes the resources that are defined at the engineering or organisational level in terms of generic entities that might need specific MIS support regardless of the actual entities that refer to them The ``dynamic'' part of the model that is affected by daily operations For example, material classes are generally part of the ``static'' model, while material lots are ``dynamic'' entities. Material definition can be either static or dynamic depending on the variability of the material roster and the specifics that can be attached to material definitions. Equipment or personnel classes are ``static'' while actual persons are normally ``dynamic''. Equipments as hierarchy structural elements are static (a given factory, work centre) or dynamic (a specific machine within a pool of identical machines) The core system is never concerned about ``dynamic'' parts of the model, though the average number of instances (material definitions, material lots, persons, equipments) might be stated. Modelling involves the following steps as described bellow. Figure SEQ Figure \* ARABIC 15 , Modelling Process Manufacturing Operation Categories ISA-95 Part 3 defines the following Manufacturing Operation Categories (MOCs): Production, Quality tests, Maintenance, Inventory control. Other or different MOCs can be defined. Example: Inbound, Outbound logistics, Internal transfers, Tooling, Cleaning. Sometimes several MOCs can be defined in lieu of a given ISA-95 standard MOC. For example, bulk production and packaging can be defined as specific MOCs instead of being part of the same ISA-95 ``Production'' MOC. The key words behind MOCs are Execution Responsibility and Typology. The objective is to define the actual MOCs as execution Responsibility sub-domains to drive requirement information collection. Note: Collaboration between MOCs within execution responsibility domain and with Business responsibility domains is highlighted, providing a comprehensive input for likely integration requirement. Material Resources Normally only Material classes are identified in the Core system. Material classification allows specification of segment input/output, filter information and associate specific functionalities or processes, etc... Classification is multidimensional and shall be consistent with business modelling options. Material Properties can be defined. Equipment Resources Equipment can be defined according the ISA-88/95 physical model (though this is not mandatory if the Enterprise already has one). The equipment entities are identified and classified at all hierarchy levels. The granularity of the physical modelling depends on the operational aspects to be considered. When dealing with Operation Management or Operation process control, the breakdown can stop at the Work unit level (schedulable pieces of equipment). For the Equipment Control purpose, the finest granularity is required, up to the control module and device module (instrument) level. At this point, the Flow Analysis approach for braking down the control modules can be used for safety purpose or increased flexibility at the equipment level. Equipment class Properties can be defined. Equipment identification and classification is the main input for the functional breakdown, work segmentation and system user access definition. Personnel Resources Personnel classification allows to specifying required qualification, system accesses, etc... Classification is multidimensional and shall be consistent with business modelling options Personnel Properties can be defined. Segments Segments (Process segment in ISA-95, as a generalization of this concept to all MOCs) define the actual work capabilities of the facility and associate the corresponding resources. Segments are hierarchically defined from a very broad perspective (the entire factory making a particular brand of products) to the smallest processing capability (a single ISA-88 phase). This concept is fully aligned with the ISA procedural model (segment = Equipment or Recipe Procedural Element) that concentrates on Operation and Equipment control, except that ISA-88 considers procedural elements as functional entities, while ISA-95 considers segments as resources. (See REF _Ref134775721 \h Figure 6 ) The term segment will be kept and generalized to represent a manufacturing process capability. It will be handled here as functional entities (ISA-88 concept) rather than as resources (ISA-95 concept) and will be discussed in the corresponding sections of the functional definition. Functional Definition Functional definition applies to the 3 operational aspects of the manufacturing information system (equipment control, operation control and operation management). This split is a modelling choice; it does not correspond to a possible reality where they would act separately. Actually the corresponding processes can communicate. For example: A planning process gives instruction to start a production run using an operation process (making the product) which itself will trigger equipment process (executing a job on a particular resource). A manufacturing operation process requires an analysis process to proceed, from sampling, to returning results. However, this approach implies a strict conceptual independence, which allows any process to activate any task or process within or outside its domain. Flexibility is not negotiable. The functional definition is basically the same in each case. Figure SEQ Figure \* ARABIC 16 , Functional Definition Process Process and Task Definition Processes define the highest functional requirement level. They illustrate situations and tasks activation scenarii: They can be Manual, semi or fully automated They are hierarchic: High-level processes activate lower level processes; elementary processes are tasks They are ``embedded'' in Equipment. In ISA-88, Equipment + Control = Equipment Entity. Any process or task execute within a given equipment entity and can potentially act on the lower level equipment entities under the embedding equipment entity The process definition highlights the tasks involved in their execution. The next steps will elaborate, refine, consolidate and classify this task list. Consolidation attempts to reconcile similar tasks into generic, less numerous task classes. From the optimized task list, processes are amended to match this more global functional modular definition. Task definition and process alignment are executed iteratively until satisfaction. Doing this exercise the first time will end up with a consistent set of hopefully reusable functional components. Next projects will make use of these components as much as possible. They will improve and complete them to form the Enterprise Functional Core System. Task Characterization Task characterization defines usage attributes and Justification of the services to be provided. Typical characterization attributes can be: Physical level defines the position of the task in the physical/decisional hierarchy. In the case of operation management processes, segments restrict the task applicability to particular segments MOCs can restrict the task applicability to specific Manufacturing Operation Categories Technical constraints define the task environment and condition of usage Dependencies indicate that a task execution depends on the existence of other tasks. This is used to justify apparently non value adding tasks Style defines the type of functionality the task achieves (see REF _Ref134784049 \r \h 1.3.5 ) Roles specify the personnel classes who have access to the task. It also specifies if the task is under the responsibility of business or execution Justification gives technical and financial reasons for implementing the task and associated implementation priority Information defines the consumed / produced / manipulated / presented information based on ISA-95 Parts 1/2 Task consolidation This object-based classification greatly simplifies and harmonizes manufacturing related processes by propagating best practices and questioning unjustified specifics. The MOC and process oriented specification typically produces an inconsistent list of tasks. It is necessary to sort them out in order to have a reduced, consistent, reusable list of tasks populating the growing up Enterprise Manufacturing Information System functional core-system. Figure SEQ Figure \* ARABIC 17 , Task Consolidation For example, multi-MOCs similar tasks can be: Harmonized between MOCs (identical, but separate) Example in office environment: MS Word Example in manufacturing environment: work instructions dispatching Kept specific by MOC (they are different) Example in office environment: AutoCAD (R&D) / PowerPoint (Marketing) Example in manufacturing environment: Batch engine (production) vs. Word based SOP (material receipt) Shared between several MOCs (the same task instance address the functional needs for several MOCs) Example in office environment: Address book Example in manufacturing environment: Resource management Task Description Once the resource and functional objects have been consistently identified, functional details can be introduced to complete the requirements, providing the extensive input to develop the adequate technical core system. Functional description will actually explain the expected task behaviour in normal and exceptional operation conditions. The next sections REF _Ref134796460 \r \h 3.4 to REF _Ref134796477 \r \h 3.6 will present specifics for each type of control. Segments Segments (Process segment in ISA-95, as a generalization of this concept to all MOCs) define the actual work capabilities of the facility and associate the corresponding resources. Segments are hierarchically defined from a very broad perspective (the entire factory making a particular brand of products) to the smallest processing capability (a single ISA-88 phase). This concept is aligned with the ISA procedural model that concentrates on Operation and Equipment control. In this case, segments are called Equipment or Recipe Procedural Elements (see REF _Ref134775721 \h Figure 6 ) and map to a specific equipment. The merge of ISA-95 segment and ISA-88 procedural element is quite straightforward: adding ISA-95 resource information to ISA-88 functional information. In consequence the term segment will be kept and generalized to represent a manufacturing process capability. Equipment Control Definition Following ISA-88 concepts, equipment control must define its inherent capabilities regardless of the final product or service to be produced or delivered. Equipment related processes are process-oriented functionalities provided by equipment. In ISA-88, they are Equipment Procedural Elements: Equipment Procedures, Equipment Unit Procedures, Equipment Operations and Equipment Phases Equipment related Tasks are functional elements handled by processes: Lower level EPE (Unit procedure, Operation, Phases) Control modules: tasks are the behavioural content of the control modules identified in Resource modelling Segments EPE are what the facility can potentially do. In this case, they can be considered as Engineered Segment, provided by the equipment manufacturer, rather than by the company's process engineer. Operation Control Definition Following ISA-88 concepts, operation control (recipes) defines how to make the product or deliver the service using equipment capabilities provided by equipment control (see above) Operation related processes are product or service related functions In ISA-88, they are Recipe Procedural Elements: Recipe Procedures, Recipe Unit Procedures, Recipe Operations and Recipe Phases. ISA-88 PFC (Procedural Function Charts) description language can be used to describe these processes graphically. Recipe related Tasks are functional element handled by processes: Lower level RPE (Unit procedure, Operation, Phases) Matching EPE (Unit procedure, Operation, Phases) Segments RPE are also what the facility can potentially do. In this case, they can be considered as Elaborated Segment, developed by the company's process engineer, but unknown by the equipment manufacturer. Operation Management Control Definition Operation management is mainly discussed in ISA-95. It relates to handling resources and production orders or customer demand for the best company advantage. Operation management related processes and tasks are order and resource related functions ISA-95 is quite vague on what the operation management processes are. It rather defines ``activities'' which are more discussion topics than formal processes and tasks. Example of operation management processes can be: Bulk material receipt by truck, by train, Palletized material receipt, On-receipt, on-line, on-shipment analysis, Bulk Product shipping, Internal bulk transfer, New orders processing, Order cancellation from execution, from business, Unsolicited order reporting, Order completion reporting, Process improvement suggestion processing, Material lost reporting... These processes can be categorized at will to help extensive and structured requirement gathering. For example: Execution management processes deal with work organization and execution Resources management processes deal with resources rather than work execution Operation management processes deal with operation performance, including dashboards, performance indicators, and general activity reports. They are not linked to work orders or resource control Repository synchronization processes aim at maintaining consistency between configurations databases in all systems involved in previous processes. The need for such processes largely depends on business management policies and supply chain dynamics. These processes can be: Partially or fully automated, they can be manually controlled as well MOC specific, generic for several MOCs or shared by several MOCs. For example, on-line QC tests process can involve tasks within Production and Quality test MOCs Confined within Business responsibility / system, within Execution responsibility / systems, or they can cross the Business/execution responsibility / system boundaries. BPMN (Business Process Management Notation) can be used to describe these processes graphically. Segments Segments handled at the operation management level are those defined at the equipment and operation control levels. Develop and Map the Technical Core System As seen previously, the Functional core system lifecycle feeds the development of the technical core system. The latter provides a repository of standard solution for addressing the needs to support a particular facility or process. The purpose is to match the functional requirements (consolidated tasks) with the capabilities of the available solutions. Figure SEQ Figure \* ARABIC 18 , Developing & Mapping Technical Core System Inherent capabilities providing embedded solution functionalities that can map onto one or several tasks Integration capabilities that can leverage inherent capabilities to fulfil the requirements. Integration is what can be done within the system to develop interaction between standard modules without impacting the solution integrity Specific developments that are needed to complement the solution inherent capabilities (1) and integration artefacts (2). Existing applications that can still operate in the target solutions Manual procedures that can be applied instead of a software implementation The possibility for a particular element of the solution - an application component - to address more than one task requirement is assessed against technical constraints, information consistency, user interaction, and applicable Manufacturing Operation Categories. This is an objective process that can help reduce the number of possible solutions by eliminating those that do not inherently cover enough requirements using methods (1) and (2) Conclusion This paper presents in short a goal oriented lifecycle approach to manufacturing information systems development, leveraging the robust ISA-88 and ISA-95 standards. Predicted for decades, demand driven supply chain, pull production or lean operations are becoming the norm. As a direct consequence, information systems can no longer structure the Enterprise: they must support its strategic, tactical and operational organization, decision and actions. Manufacturing Information Systems are in charge of equipment control, operation control and operation management control. At the heart of the enterprise valued know-how, this special mix results in innumerable number of combinations: MIS are neither off-the-shelf systems nor one-shot projects; they result in an ongoing effort to adapt them to address the enterprise strategic guidance and resource landscape. Successful MIS projects positively impact the company's bottom line if they support its strategy instead of entangling it (this is not uncommon). This implies a breakthrough approach for setting up the indispensable flexible design: Top down, looped global lifecycle (able to work bottom up) Master project providing resources for actual instance projects Split between functional and technical core-system Shared resource model Pragmatic development through actual or pilot instance projects Extensive capture of the user needs through highly structured framework Implicit to Explicit Knowledge conversion and management supporting a continuous improvement process The ISA-88 and ISA-95 standards offer a common vision, terminology and framework for addressing the entire manufacturing system support. Acronyms MIS Manufacturing Information System ERP Enterprise Resource Planning Systems EPE Equipment Procedural Element RPE Recipe Procedural Element (in Master/Control Recipe) REP Recipe Process Element (in General/Site Recipes) DBR Drum Buffer Rope - Scheduling method based on TOC TOC Theory of Constraints MOC Manufacturing Operation Categories BPMN Business Process Management Notation PFC Procedural Function Charts (from ISA-88 Part 2) PPC Process Procedure Chart (from ISA-88 Part 3) Manufacturing Information Systems - ISA-88/95 based Functional Definition PAGE ISA-95 / MESA Best Practices Working Group ISA-95 Best Practices Technical Report, 1st Edition Page PAGE 22 Jean Vieille - Psynapses 07/05/2006