English
Français
File preview
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
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