ANSI/ISA-88 and ANSI/ISA-95 are two well accepted standards in the industrial domain that provide a set of models considered as best engineering practices for industrial information systems in charge of manufacturing execution and business logistics. The main goal of ANSI/ISA-88 is the control of batch processes, whereas the one of the ANSI/ISA-95 standard is the development of an automated interface between enterprise and control systems. In consequence, both standards should interoperate. However, there are gaps and overlappings between their corresponding terminologies. Moreover, there are additional problems, such as semantic inconsistencies within each of the standards, as well as the use of an informal graphical representations in one of the ANSI/ISA-88 models. This work presents an ontological approach that aims at formalizing the ISA-88 standard as a first step towards its integration with a formal representation of the ANSI/ISA-95 one. Additionally, methodological aspects of the ontology development process are presented.
APS/MES
Control Systems
ISA-95
ISA-88
To overcome these semantic challenges, this work proposes the formalization of the ISA-88 [Ans10] standard as a first step towards its semantic integration with the ISA-95 [Ans00] one. This article is organized as follows: section 2 briefly introduces the ISA-88 standard. Section 3 presents general methodological considerations for the development of the proposal, describes the main concepts of the ontology and its application to a case study. Conclusions and future work are drawn in Section 4. 2
The ISA-88 standard originally addressed batch process control issues, and was later extended to tackle discrete manufacturing and continuous processes. It organizes knowledge along three different perspectives: the physical model, the process model, and the procedural control one. All these representations are hierarchical ones.
The physical model hierarchically organizes the enterprise into sites, areas, process cells, units, as well as equipment and control modules. The three higher levels are more precisely defined in the ISA-95 standard, as they are often beyond the scope of batch control. The criteria for establishing these boundaries are not well defined neither in the ISA-88 nor in the ISA-95 standard. The process model is a multi-level hierarchical model for the high level representation of a batch process, and it is the basis for defining equipment independent recipe procedures. The ISA-88 standard divides a batch process hierarchically into process stages, process operations and, finally, process actions. The procedural control model is a hierarchical representation that depicts the orchestration of procedural elements to carry out process oriented tasks.
According to ISA-88 a recipe provides the necessary set of information that uniquely defines the production requirements for a specific product. Recipes are defined at different abstraction levels: General, Site, Master and Control. Distinct recipes (at the same abstraction level) may exist for different sets of raw materials that can be used to manufacture the same product. This work focuses on the Master and Control recipes since they are the ones that take part on integration issues. A Master recipe includes cell specific information, which is based upon equipment types and classes. Finally, the Control recipe is obtained from the Master one by incorporating batch specific information, such as batch size, the allocation of process equipment, and the definition of quantities of raw materials by scaling the recipe parameters according to the adopted batch size. Thus, the master recipe acts as a template for the derivation of control recipes. Typically, the information comprised in a recipe includes: (i) the header, with the recipe ID, version, status, date, etc., (ii) the formula, containing process inputs (data about the materials, energy and other resources that are required), expected outputs (products, by-products and waste products), and process parameters (temperatures, flowrates, processing times, etc.), (iii) equipment requirements, (iv) the recipe procedure, which defines the sequential and parallel actions needed to produce a batch of a certain product, and (v) safety and compliance information.
The recipe procedure, which is the core part of a recipe, can be hierarchically decomposed into recipe unit procedures, recipe operations and recipe phases, which define the procedural control model. Each unit procedure consists of an ordered set of operations, which consist of an ordered set of phases. The ISA-88 standard proposes a graphical model, referred as the Procedure Function Chart (PFC), in order to represent the recipe procedure for both, the Master recipe and the Control one. Although there are several accepted ontologies for process representation, like PSL (Process Specification Language) [ISO04], the model included in the standard is one adopted by batch industries for the specification of their production processes. Therefore, in this article a formalization of PFC is done. A PFC is defined by a set of symbols representing recipe procedural elements, begin and end points, resource allocations, synchronization elements, recipe transitions and directed links, as well as selection and simultaneous sequences. Figure 2 illustrates the PFC of a recipe for Mint Swirled Toothpaste production and partial details of the low level PFC associated with this recipe [Par00]. According to the control model of ISA-88, the recipe of a Mint Swirled toothpaste batch is related to a procedure called Mint Swirled Toothpaste Production in the example. Figure 2 shows three encapsulated unit procedures, which correspond to the production of mint and gel toothpaste and the mixing of both components. Figure 2 also shows the details of the Make Gel Toothpaste unit procedure, which encapsulates a sequence of three operations: Add Ingredients, React and Prepare to Transfer. The first operation combines various ingredients to form a new intermediate material. The second one mixes, heats, and then cools the new mixture to create toothpaste. Finally, the last operation gets the vessel ready to transfer its contents to the blender/extruder unit. The last two operations are linked by an explicit transition, which implies that the condition Approved by lab has to be satisfied before the Prepare to Transfer step operation starts.
An expansion of the Add Ingredients operation is included in the right part of Figure 2. Five phases are comprised in this operation. Each phase performs a unique and independent function. The phase Add Water precedes the following three parallel phases: Add Filler, Add Flavorings and Add Stabilizers. The three phases have to be completed before the Add Sodium Fluoride phase starts. The two pairs of horizontal lines represent the begin and end of the parallel sequence.
Mint swirled thootpaste production procedure Make mint toothpaste +
Make gel toothpaste
Swirl toothpaste
+ Steps + + +
Approved By Lab
Make Gel toothpaste unit procedure
+ Add Ingredients
React Prepare to Transfer + + +
Add ingredients operation
Add Water Add Fillers
Add Flavorings
Add
Stabilizers
Add Sodium Fluoride Procedure
Unit Procedure
Operation
Phase Explicit Transition
Implicit Transition
Begin Node
End Node
Simultaneous sequence
As it can be seen in Figure 2 any procedural element above the level of a phase may represent an encapsulation of other procedural elements pertaining to the subsequent lower level in the procedural control hierarchy. Moreover, the level of the control model to which a step belongs, is represented by 1 to 4 diagonal lines located at the corners of the step rectangle. Therefore, the different types of steps are identifiable only by a person that analyzes the diagram. Only such person is capable of detecting which steps (unit procedures, operations, phases) are executed in parallel, which is the predecessor or the successor of a given step, or which are alternative steps. In consequence, the relation between a procedural element and the components that it encapsulates is not understandable without a human eye. Therefore, the implicit nature of this graphical representation makes it impossible for a computer to infer knowledge from it. In addition, the graphical representation of a PFC lacks the capacity to automatically validate the correctness of a diagram. The formalization of the PFC that is presented in this work helps to overcome this drawback.
In order to deal with the semantic challenges introduced in section 1, this work proposes a formalization of the ISA88 and ISA-95 standards by defining an ontology per each standard and then an ontology to integrate them. This approach avoids defining just one big ontology, which would be very complex and rigid, by sticking to a "divide and conquer" strategy.
The development of each ontology has been carried out separately. The formalization of ISA-88 has been done first because it is the one that has the major semantic inconsistencies in its term definitions. The models proposed within ISA-88 are taken into account to divide the proposed ontology into small ontology modules. The same approach was considered in the formalization of the other standard. Due to space limitations, only a part of the formalization of the ISA-88 ontology is presented in this paper. In particular, the main concepts involved in its Procedural Control Module, which is the one of the most advanced modules in this project's implementation, are introduced in the following paragraphs.
For the development of the Procedure Control ontology, an ad-hoc methodology based on well accepted principles has been proposed. It has the following four stages: • Requirements specification: identifies the scope and purpose of the ontology. • Conceptualization stage: organizes and converts an informally perceived view of the domain into a semiformal specification using UML diagrams. • Implementation stage: codifies the ontology using a formal language. • Evaluation stage: allows making a technical judgment of the ontology quality and usefulness with respect to the requirements specification, competency questions and/or the real world.
It should be mentioned that these stages were not truly sequential; indeed, any ontology development is an iterative and incremental process. If some need/weakness was detected during the execution of a given stage, it was possible to return to any of the previous ones to make modifications and/or refinements. Moreover, as it is proposed by Ontology Summit 2013 Communiqué [Neu13], some evaluation activities have been done in all the stages of the proposed development process. Some highlights of these methodological stages are given in the remaining of this section.
Competency questions, which were proposed by Uschold and Gruninger [Usc96] in their methodology, helped at this stage to identify the requirements. The gathered competency questions were classified in groups related to the levels defined in the control model. A small sample of the competency questions that were stated, are the following: • Which are the procedural elements associated with a given Master Recipe? • Which are the conditions that should be fulfilled to start a given Operation? • Which are the operations comprised in a given Unit Procedure? • Which are the phases that need the conclusion of a given phase P in order to start their execution? • Which phases are executed in parallel with a given phase P?
The second main step in the development process required the identification and capture of the domain concepts and their relationships, trying to fulfill the previous requirements. To support this activity, UML (Unified Modelling Language) [OMG13] was adopted. In addition to class diagrams, constraints about the objects in the model and invariants on classes have been added using OCL (Object Constraint Language) [OMG14]. The complete results of this stage are not described due to lack of space. However, a partial model will be described in this section.
As it was mentioned in Section 1.1, the ISA-88 procedural control model describes recipe procedures. Therefore, the main concepts in the corresponding ontology are related to recipes and their components. Figure 3 introduces the main concepts associated with recipe definition.
The RecipeEntity is the combination of a ProceduralElement with associated recipe information, which includes a Header, EquipmentRequirements and a Formula.
Each Recipe Entity is built up of lower-level recipe entities. But these levels should be hierarchically organized according the procedural control model. Therefore, the concepts ProcedureRecipeEntity, UnitProcedureRecipeEntity, OperationRecipeEntity and PhaseRecipeEntity have been added to the ontology in order to represent recipe entities at Procedure, UnitProcedure, Operation and Phase Level respectively. Eq. 1 shows how the instances of ProcedureRecipeEntity are inferred. Similar expression have been defined to compute recipe entities at the other levels. In addition, to guarantee consistency in this hierarchy, constraints on the composedOf relationship have been added to the proposed ontology. All RecipeEntities, except the ones at Phase level, which does not have components, should include composedOf recipe entities belonging to the immediate lower level. Eq. 2 states this constraint for the ProcedureRecipeEntity. context ProcedureRecipeEntity::allInstances():Set(ProcedureRecipeEntity) body: RecipeEntity.allInstances()->Select(r| r.level.oclIstypeOf(ProcedureLevel)) context ProcedureRecipeEntity inv ProcedureComposedOfUnitProcedure: self.component->forall(r:RecipeEntity | r.oclIsTypeOf(UnitProcedureRecipeEntity)) (1) (2)
A Recipe is a RecipeEntity, which is defined at the highest level of the procedural control model. In particular, a MasterRecipe is a RecipeEntity at the ProcedureLevel, which is the highest one (Eq. 3). Similarly, a ControlRecipe is also a RecipeEntity that is derivable from a MasterRecipe. context MasterRecipe::allInstances():Set(MasterRecipe) body: RecipeEntity.allInstances()->Select(r:RecipeEntity| r.level.oclIstypeOf(ProcedureLevel)) (3)
A transition whose only condition is that the directly preceding step has to finish its execution.
A transition having a condition that has to evaluate to true in order to activate the following step in the transition.
A link that relates recipe elements among which there is a certain form of synchronization.
A link that represents material transfer from a step to another one.
A kind of synchronization that does not involve movement of material.
A node that represents a recipe procedural element: procedure recipe entity, unit procedure recipe entity, operation recipe entity or phase recipe entity. According to the level of the procedure control model associated to the PFC in which the step is defined, this concept can be specialized in ProcedureStep, UnitProcedureStep, OperationStep, and PhaseStep.
A node that controls de intended thread of execution of the recipe procedural elements.
A node that identifies the start of each procedural structure and/or each subordinate structure.
A node that indicates the end of a procedural structure and/or a subordinate structure. A node that defines the start of independent threads of execution of certain recipe elements, which are executed in parallel.
A node that indicates the end of independent threads of execution.
Decision Node
A node that specifies the beginning of alternative threads of execution. Merge Node
A node that shows the joining of alternative threads of execution.
The main goal of the ontology implementation activity is to create a computable model deployed in an ontology
language from the conceptual model created during the conceptualization phase. Based on its ample acceptance, the
OWL 2 language [
The development process has been guided by the principles of coherence, conciseness, intelligibility, adaptability, minimal ontological commitment and efficiency. Some of these principles are conflicting among themselves. Due to such incompatibilities, a suitable balance between the clashing principles was sought. Nowadays it is widely accepted that there is a lack of a formal methodology that considers all these criteria, which could be applied to evaluate domain ontologies. According to Gómez-Pérez [Gom96] , the ontology evaluation phase comprises three aspects: (i) ontology validation, (ii) ontology verification, and (iii) ontology assessment. Validation and verification activities are associated with a technical judgment of the content of the ontology with respect to a frame of reference, which can be requirement specifications, competency questions, or the real world. In turn, assessment focuses on judging the ontology content from the user’s point of view. The results of using the proposed ontology in the development of different types of applications in various contexts are required to be analyzed in order to assess the ontology.
Although there is no formal methodology that considers all the aforementioned evaluation criteria, many authors have reached an agreement on assessment needs during all the ontology lifecycle stages [Neu13]. Having them in mind, partial evaluation through competency questions has been done during the implementation phase. To do so, the ontology has been applied to represent recipe information of several literature case studies [Hai11] [Fis90], including the PFC that is shown in Figure 2 [Par00]. In particular, the results of executing some of the competency questions of this case study are introduced in Table 2. For the sake of simplicity, prefixes are omitted in Table 2. While the namespace corresponding to the proposed ontology is represented with the p0 prefix, the rdf one identifies the namespace of the RDF (Resource Description Framework) language.
The formal competency question in the first row of the table asks about explicit transition links (?lk rdf:type p0:ExplicitTransition) having a condition (?lk p0:HasCondition ?cnd.) that points to a step (?lk p0:To ?stp.) at the operation level (?stp p0:HasStepLevel p0:Operation.) and, from this set of links, the query filters the operation step Prepare2TransferStep (FILTER (?stp = p0:Prepare2TransferStep). The execution of this SPARQL query gives as a result the ApprovedByLab condition which according to the PFC shown in Figure 2 is necessary to be fulfilled in order to start the mentioned operation.
The second SPARQL query in Table 2 selects all the recipe entities (?rcp rdf:type p0:RecipeEntity.) at the UnitProcedure level (?rcp p0:HasLevel p0:UnitProcedure.) whose procedural structure has some step as element (?rcp p0:HasProceduralSTR ?up, ?up p0:HasElement ?op and ?op rdf:type p0:Step triples). From this set of results, the query filters the unit procedure that is of interest to the competency question (FILTER (?rcp = p0:MakeGelRcp)).
The third question searches whether there is a phase that needs the end of the AddWater phase to start its execution. This query is more complex because it should consider different situations in which the mentioned phase is located in the PFC: (i) before a DecisionNode; (ii) before a ForkNode; (iii) in a simple sequence, (iv) after a JoinNode; or (v) after a MergeNode. SELECT ?ph WHERE { ?frk rdf:type p0:ForkNode. ?lk p0:From ?frk. ?lk p0:To ?ph. ?ph rdf:type p0:Step. ?lk2 p0:From ?frk. ?lk2 p0:To p0:AddFillersStep. FILTER (?ph != p0:AddFillersStep) } |ph| AddFlavoringStep AddStabilizersStep SELECT ?op WHERE { ?rcp rdf:type p0:RecipeEntity. ?rcp |op| p0:HasLevel p0:UnitProcedure. ?rcp p0:HasProceduralSTR ?up. ?up p0:HasElement ?op. ?op rdf:type p0:Step. FILTER (?rcp = p0:MakeGelRcp)} SELECT ?op2 WHERE { {?lk p0:From ?op. ?lk p0:To ?cnd. |op2| ?cnd rdf:type p0:DecisionNode. ?lk2 p0:From ?cnd. ?lk2 p0:To ?op2. ?op2 rdf:type p0:Step. FILTER (?op = p0:AddWaterStep) } UNION { ?lk p0:From ?op. ?lk p0:To ?cnd. ?cnd rdf:type p0:ForkNode. ?lk2 p0:From ?cnd. ?lk2 p0:To ?op2. ?op2 rdf:type p0:Step. FILTER (?op= p0:AddWaterStep) } UNION { ?op2 rdf:type p0:Step. ?op rdf:type p0:Step. ?lk p0:To ?op2. ?lk p0:From ?op. ?op2 rdf:type p0:Step FILTER (?op = p0:AddWaterStep)} UNION { ?lk p0:From ?op. ?lk p0:To ?cnd. ?cnd rdf:type p0:JoinNode. ?lk2 p0:From ?cnd. ?lk2 p0:To ?op2. ?op rdf:type p0:Step. FILTER (?op = p0:AddWaterStep)} UNION { ?lk p0:From ?op. ?lk p0:To ?cnd. ?cnd rdf:type p0:MergeNode. ?lk2 p0:From ?cnd. ?lk2 p0:To ?op2. ?op rdf:type p0:Step FILTER (?op = p0:AddWaterStep)} }
The last question presented in Table 2 looks for phases that should be executed in parallel with the AddFillers one. In order to do that, the query searches if there is any step that follows the ForkNode to which the AddFillers AddIngredientStep ReactStep Prepare2TransferStep AddFlavoringsStep AddFillersStep AddStabilizersStep phase is linked to. If the mentioned phase does not follow a ForkNode, the query gives an empty result because AddFillers is not in a parallel sequence.
The implementation of several cases studies, as well as the formalization and execution of the whole set of competency questions have allowed the identification of missing concepts and properties that have to be added to the ontology. Among others, these concepts are related to the detailed description of equipment units and their relations to recipes and the different levels of the procedural control model. 4
This contribution describes an ontology based approach that can play a central role in solving nowadays integration problems that appear in the enterprise hierarchical planning pyramid when adopting the ISA-88 and ISA-99 standards. The definition of three ontologies is suggested: one per each standard formalization and another ontology to integrate the previous ones. In particular, the article focuses on the formalization of PFCs, the graphical representation of the recipe procedures proposed by ISA-88. Since knowledge is explicitly and formally expressed, the ontology supports inference processes and an analysis of the construction of valid PFCs. In addition, some methodological aspects of the proposed ontology development process are also shown.
It is necessary to perform more activities to evaluate and validate the proposed formalization. In parallel with these tasks, the formalization of ISA-95 and the definition of the integration ontology are being carried out.
The authors acknowledge the financial support received from CONICET (PIP 11220110100906 and PIP 11220110101145), UNL (PI CAI+D 2011) and UTN (PID 25-O156). [Ans00]
ANSI/ISA-95.00.01-2000: Enterprise-Control System Integration. Part 1: Models and terminology, 2000.
ANSI/ISA–88.00.01: Batch Control Part 1: Models and Terminology, 2010.
Fisher, T. Batch Control Systems: Design, Application and Implementation. Instrument Society of America, North Carolina, 1990.
ISO 18629 - Process specification language. Part 1: Overview and basic principles, 2004.
Kreipl, S., Dickersback, J.T., Pinedo, M.: Coordination Issues in Supply Chain Planning and Scheduling. In: Herrmann, J. (ed), Handbook of Production Scheduling, 177-212. Springer ,2006. Maravelias, C., Sung C., Integration of Production Planning and Scheduling: Overview, challenges and opportunities, Computers and Chemical Engineering, 33, 1919-1930, 2009.
Muñoz, E., Espuña, A., Puigjaner, L.: Towards an Ontological Infrastructure for Chemical Batch Process Management, Computers and Chemical Engineering, 34, 668-682, 2010.