<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>A network of ontologies for the integration of planning and scheduling activities in batch process industries</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Marcela Vegetti</string-name>
          <email>mvegetti@santafe-conicet.gov.ar</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Gabriela Henning</string-name>
          <email>ghenning@intec.unl.edu.ar</email>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>INGAR(CONICET/UTN)</institution>
          ,
          <addr-line>Avellaneda 3657, Santa Fe 3000, Argentinta</addr-line>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>INTEC (CONICET,UNL)</institution>
          ,
          <addr-line>Ruta Nacional 168, km 461,5, Santa Fe 3000</addr-line>
          ,
          <country country="AR">Argentina</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>In the last decades, the integration of informatics applications supporting planning, scheduling and control has been a serious concern of the industrial community. Many standards have been developed to tackle this issue by addressing the exchange of data between the scheduling function and its immediate lower and upper levels in the planning pyramid. However, a more comprehensive approach is required to tackle integration problems, since this matter entails much more than data exchange. So, this article presents an ontological framework that provides the foundations to reach an effective interoperability among the various applications linked to scheduling activities.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Introduction</title>
      <p>
        Despite over twenty years of research in batch scheduling, advanced scheduling
support systems are not very common in the chemical industry yet. In addition, most of
the available commercial systems are not based on the solution methodologies that
academia has developed. One of the reasons why academic approaches are not
adopted in industry is the fact that decision support tools do not integrate with the
enterprise and manufacturing applications because they rely upon quite different
knowledge representations. In the last decades, the integration of informatics
applications supporting planning, scheduling and control has been a serious concern of the
industrial community. The ISA-88 [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ] and ISA-95 [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ] standards have been developed
to tackle this issue by addressing the exchange of data between the scheduling
function and its immediate lower and upper levels in the planning pyramid. However, a
more comprehensive approach is required to address integration problems, since this
matter entails much more than data exchange. In last decade, ontologies have been
considered an effective solution to interoperability problems in many domains.
Therefore, this article presents an ontological framework that provides the foundations to
reach an effective interoperability among the various applications linked to
scheduling activities, focusing on one of the ontologies of such framework.
      </p>
      <p>
        The paper is organized as follows. Section 2 points out some of the problems of
dealing with multiple knowledge representations in the scheduling domain. Section 3
introduces the ontological approach that is proposed to address integration problems.
By means of example, Section 4 describes the ontology that was developed to
formalize the Resource Task Network (RTN) [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ] model, which is one of the components of
the ontology network that is proposed in this contribution. The proposed
formalization is a definitional extension of the Process Specification Language (PSL) [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ].
Finally, section 5 presents some concluding remarks.
2
      </p>
    </sec>
    <sec id="sec-2">
      <title>Different knowledge representations in the scheduling field</title>
      <p>
        Many academic approaches addressing scheduling problems resort to intermediate
representations, like the state-task (STN) or resource-task (RTN) networks (See Figs.
1 and 2 of [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ]), before developing the mathematical model that indeed solves the
problem. However, this representation does not have a direct mapping to the master
data that is usually employed in industry. Thus, the human scheduler has to manually
create the STN/RTN graphical models from data that is spread in different tables of
the enterprise databases.
      </p>
      <p>
        On the other hand, in the industrial domain, the most important input for the
scheduling problem is the ISA-88 master recipe, which provides the set of data that
uniquely defines the production requirements of a specific product batch. Recipes are
recursive structures containing five components: Header, Formula, Procedure,
Equipment requirements and Other Information. See for example Fig. 1, which
depicts the master recipes of P1 and P2, which are the final products of the STN shown
in Fig. 2 of [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ]. Fig. 1 shows that the procedure component of the P1 master recipe is
defined in terms of the T2, T1 and T3 operations. The INT3 recipe entity is also
shown in Fig. 1 and the ones corresponding to the other intermediates can be found in
[
        <xref ref-type="bibr" rid="ref6">6</xref>
        ]. An analysis of Fig. 1, the material in [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ], along with Figs. 1 and 2 of [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ] shows
that these recipe representations are quite different and that a direct mapping is not
possible. On top of the recipe information, the scheduling problem needs additional
input data, such as demands to be fulfilled, plant topology with unit features, etc. This
last type of information is not represented neither in the STN/RTN graphs nor in the
ISA-88 recipe model. Usually, industry specifies it in the so called physical model
proposed by ISA-88, while in academia it is handled in an informal way that is not
machine procesable and can lead to misinterpretations.
      </p>
      <p>
        Having all this input information, a mathematical model is built and then solved.
The resulting production schedule needs to be communicated to the adjacent levels in
the planning pyramid: (i) to the lower process control layer to materialize batch
execution and (ii) to the upper production planning and control (PPC) level for plan
management activities. In practice, the results included in the solver output file need to be
translated into the control recipe (the one that according to ISA-88 standard is
employed by the control system to perform batch execution) and into the operations
schedule, an explicit representation of the schedule according to the ISA-95 standard.
As a result, it can be seen that in order to perform scheduling activities and to
articulate them within the planning pyramid, several knowledge representations and models
need to interplay. For instance, to transform a given master recipe into a control one,
the procedure that is conceptualized in Fig. 2 would need to be executed (actually,
such an approach was never made explicit by researchers devoted to the industrial
scheduling field and it is presented in this contribution). Currently, the translation
from one representation to another is manually done, in the few cases it is indeed
carried out. In fact, none of the academic proposals take into account the automatic
translation of the solver output file into representations that are useful from an
industrial point of view, i.e. control recipes and explicit schedule representations. In
addition to the manual translation workload, these heterogeneous data models employ
distinct terms to refer to the same concepts. Besides these semantic issues, since the
models are not formal, they cannot be interpreted by a computer and can also be
ambiguous. Moreover, an analysis of the ISA-88 and ISA-95 standards [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ] reveals some
overlappings on the information and activities handled by them (e.g. product
definition vs. recipe specification; equipment capability vs. physical model), which
discloses some collision points. The problems pointed out in the previous paragraphs are
some of the difficulties preventing the integration of scheduling activities within the
planning pyramid and, more specifically, precluding the adoption of advanced
scheduling approaches in industry.
      </p>
    </sec>
    <sec id="sec-3">
      <title>Ontological approach that supports scheduling activities</title>
      <p>
        In order to tackle the problems posed in the previous section an ontological approach
is addressed in this contribution. Following the interlingua approach [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ], this
contribution proposes the construction of a network of ontologies (see Fig. 3) that has the
Schedule Reference Ontology (SRO) as a common vocabulary. This network also
contains local ontologies that formalize the different sources of information
supporting scheduling activities. Specifically, it contains the ontologies of the ISA-88 and
ISA-95 standards, the STN/RTN representations, the mathematical programming
models (whenever MILP/MINLP-based solution approaches are pursued), etc. The
implementation of this ontology network requires the formalization (triangles in Fig.
3), with a previous conceptualization in certain cases (diamonds in Fig.3), of the
various information sources. Moreover, the development of ontology alignment agents
(circles in Fig. 3), which map concepts of the local ontologies to their definitions in
the SRO common vocabulary, is also required. This core ontology plays a central role
in the network, acting as a bridge between the different ontologies in the net. The
development of the proposed network of ontologies is the starting point for the
automatic construction and translation of models that are employed during the scheduling
activities, as well as for the correct exchange of information among the scheduling
applications and the other manufacturing applications with which they interplay.
Some work has been done by the authors in relation to the formalization of ISA-88
standard [
        <xref ref-type="bibr" rid="ref7 ref9">7,9</xref>
        ]. In this article, the conceptualization and formalization of the RTN is
addressed.
      </p>
    </sec>
    <sec id="sec-4">
      <title>RTN conceptualization and formalization</title>
      <p>
        The approach that has been followed to formalize the RTN model is to develop a
definitional extension of PSL (Process Specification Language)[
        <xref ref-type="bibr" rid="ref4">4</xref>
        ]. The aim of PSL is
to create a process specification language to facilitate the complete and correct
exchange of process information among manufacturing applications. PSL is structured
in two main layers: core theories and definitional extensions. Fig. 4 shows the PSL
theories and extensions that are required for the RTN extension proposed in this
contribution. The Core Theory is the kernel of PSL since it defines its basic concepts,
which are Activity, Object and Timepoint. These three concepts are used in almost all
theories and/or definitional PSL extensions. The Outer Core theory groups the
theories related to Subactivities, Occurrence Trees, Activity Occurrence, Discrete State,
Atomic and Complex Activities. All of them require the concepts that are defined in
the Core theory. The Resource Requirements theory uses the Core and the Outer Core
theories to define the set of axioms that constrains the definition of the resource
requirements of an activity. All these theories become the foundation for the definition
of several extensions. In particular, the Processor Activity [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ] and Resource Roles
[
        <xref ref-type="bibr" rid="ref11">11</xref>
        ] definitional extensions are required for the specification of the RTN extension to
be presented in the next two sections.
      </p>
      <p>
        The RTN model is based on two fundamental concepts: resources and tasks. A task
is an operation with a given duration that can consume and generate resources [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ].
According to Castro et al. [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ], the concept of resource is entirely general and includes
all entities that are involved in the process steps, such as materials, processing and
storage equipment, personnel, as well as utilities (steam, cooling water, etc.).
      </p>
      <p>
        The proposed extension specifies the definition of the Task and Resource concepts
as well as some axioms that constrain these definitions in the domain of RTN. In this
proposal the Common Logic implementation [
        <xref ref-type="bibr" rid="ref13">13</xref>
        ] of PSL was chosen and therefore,
the proposed extension has been implemented in this language.
4.1
      </p>
      <sec id="sec-4-1">
        <title>Resource definition</title>
        <p>
          The Resource Roles extension (RRe) [
          <xref ref-type="bibr" rid="ref11">11</xref>
          ] axiomatizes the fundamental intuitions
about resources. According to this extension an Object is a resource only with respect
to the role that it plays in some activity that requires the Object. Therefore, this
extension does not axiomatize any other properties of resources [
          <xref ref-type="bibr" rid="ref14">14</xref>
          ].
        </p>
        <p>
          In RTN the concept of resource includes all the entities that are involved in the
process steps [
          <xref ref-type="bibr" rid="ref3">3</xref>
          ]. In this sense this definition is similar to the resource concept that is
specified in PSL. However, in RTN, resources can be specialized in materials (raw
materials, intermediate ones, and final products), processing and storage equipment,
manpower and utilities. Therefore, the proposed formalization specifies this taxonomy.
The proposed RTN uses the RRe definitions to specify the different resources that are
involved in the definition of an RTN model.
        </p>
        <p>
          Definition 1: Every resource ?r is either a material, a utility, a storage_unit, a
processing_unit or personnel.
Definition 2: A resource ?m is a material if and only if ?m is an input material or
output material of at least one task ?t. Both, input_material and output_material are
definitions belonging to Processor Activity extension [
          <xref ref-type="bibr" rid="ref10">10</xref>
          ]. This extension states that
an object ?m is an input material for an activity ?t if and only if ?t is a processor
activity which consumes or modifies ?m. Similarly, an object ?m is an output material for
an activity ?t if and only if ?t is a processor activity which produces or modifies ?m.
(forall (?m) (iff (material ?m)
(exists (?t) (and (task ?t) (or
(input_material ?m ?t)
(output_material ?m ?t))))))
Definition 3: A material ?m is a raw material if ?m participates as an input material in
at least one task ?t1 and there is no task in which ?m is an output material
(forall (?m)(iff (raw_material ?m) (and
(material ?m)
(exists (?t1) (and (task ?t1)
        </p>
        <p>(input_material ?m ?t1)))
(not (exists (?t2) (and (task ?t2)</p>
        <p>(output_material ?m ?t2)))))))
Definition 4: A material ?m is an intermediate material if ?m participates both as an
input_material in at least one task ?t1 and as an output_material in at least another
task ?t2.
(forall (?m) (iff (intermediate_material ?m)
(and (material ?m)
(exists (?t1 ?t2) (and (task ?t1) (task ?2)
(input_material ?m ?t1)
(output_material ?m ?t2)
(&lt;&gt; ?t1 ?t2) )))))
Definition 5: A material ?m is a final product if ?m does not participate as
input_material in any task and is an output_material in at least one task.
Definition 6: A dedicated_storage_unit is a storage_unit that can only store a unique
material.
(forall (?dsu ?m1 ?m2)
(iff (dedicated_storage_unit ?dsu)
(and (material ?m1) (material ?m2)
(can_store ?dsu ?m1)(can_store ?dsu ?m2)</p>
        <p>(= ?m1 ?m2))))
Definition 7: A shared storage unit is a storage_unit that can store different materials
(forall (?ssu)
(iff (shared_storage_unit ?ssu) (exists (?m1 ?m2)
(if (and (can_store ?ssu ?m1)(can_store ?ssu ?m2)
(&lt;&gt; ?m1 ?m2))))))
Definition 8: A processing_unit is a reusable or possible_reusable resource that can
perform at least one task.
(forall (?pu) (iff (processing_unit ?pu)
(exist (?t) (and (or (reusable ?pu ?t)</p>
        <p>
          (possibly_reusable ?pu ?t))
(can_perform ?pu ?t)))))
The definitions of reusable or possible_reusable resources are stated in RRe [
          <xref ref-type="bibr" rid="ref11">11</xref>
          ]. A
resource ?r is reusable (possible_reusable) by an activity ?a if any other activity that
also requires ?r is still possible to be performed after ?a completes its occurrence, in
every (some) possible future.
        </p>
        <p>An example of a reusable resource is a processing unit that does not require
setup/changeover between activities. As soon as one activity occurs, it is always possible
to execute the next activity. In contrast, a possibly reusable resource is a processing
unit that requires some setup/changeover between different activities. After the first
activity occurs, it is available for the other activity, but only if the setup/activity
activity occurs first.</p>
        <p>Definition 9: A utility is a reusable resource that acts as a service or commodity
having a limited capacity
(forall (?ut) (iff (?utility ?ut)
(exists (?t ?q)(and (reusable ?ut ?t)
(max_capacity ?ut ?q)))))</p>
      </sec>
      <sec id="sec-4-2">
        <title>4.2 Taskdefinition</title>
        <p>The other main concept of RTN model is task. This section deals with the definition
of this important concept and with the specification of a set of axioms that constrains
it.</p>
        <p>Definitions 10-12: a task is a processor activity that has at least one input_material
and at least one output_material, which are consumed and created, respectively, in
given quantities.
(forall (?t) (iff (task ?t)(exists (?m ?m2 ?q1 ?q2)
(and (processor_activity ?t)
(input_material_demand ?m ?t ?q1)
(output_material_generation ?m2 ?t ?q2)))))
(forall (?m ?t ?q1)(iff (input_material_demand ?m ?t ?q1)
(and (material ?m) (task ?t) (input_material ?m ?t))))
(forall (?m ?t ?q1)
(iff (output_material_generation ?m ?t ?q1)</p>
        <p>
          (and (material ?m) (task ?t)(output_material ?m ?t))))
The Processor Activity extension of PSL [
          <xref ref-type="bibr" rid="ref10">10</xref>
          ] defines a processor_activity as "an
activity which uses some set of resources, consumes or modifies some other set of
resources, and produces or modifies a set ofobjects."
A set of axioms is also developed to represent constraints on the RTN ontology.
These axioms make coherent the concepts inthe considered engineeringfield.
Axiom 1: Every task ?t is related to one or more processing units in which a task
occurrence can be performed.
(forall (?t) (if (task ?t)(exists (?pu)
(and (processing_unit ?pu)
        </p>
        <p>(can_perform ?pu ?t)))))
Axiom 2: Every task has bounds in the size of the batch that it can handled in each
processing unit. These limits are indicated bythe parameters min and max batch size.
Both parameters should be expressed in the same unit of measure, but due space
limits the specification of this constraint, which is indicated by the legal_batch_size
expression, is not shown.</p>
        <p>(forall (?t) (if (task ?t) (exists (?pu ?maxbs ?minbs)
(and (processing_unit ?pu) (can_perform ?pu ?t)
(max_batch_size ?t ?pu ?maxbs)
(min_batch_size ?t ?pu ?minbs)
(legal_batch_size ?maxbs ?minbs)))))
Axiom 3: The duration of each task ?t depends on the processing unit ?pu in which it
will be executed. There are two alternative ways of specifying the task duration. On
the one hand, the duration is represented by a unique parameter (?fixd). On the other
hand, two parameters are used: a fixed duration (?fixd) and a variable duration
(?vard), which depends on the batch size. When using two parameters for describing
the task duration, some constraints are imposed in the unit of measures of both
parameters. These constraints are specified in the definition of the legal_duration
expression. However, due to the lack of space, this specification is not shown in this
article.
(forall (?t) (if (task ?t)
(or (exists (?pu ?fixd)(fixed_durantion ?t ?pu ?fixd))
(exists (?pu ?fixd ?vard)
(and (fixed_durantion ?t ?pu ?fixd)
(variable_duration ?t ?pu ?vard)
(legal_duration ?fixd ?vard))))))
Axiom 4: The utility requirement of a task in a given processing unit is expressed
using two parameters: fixed and variable amount. The unit of measure of both
parameters should be consistent. This restriction is specified in the definition of
legal_amount expression, which is not shown in this article for space reasons.
(forall (?t ?ut)
(if(and (task ?t)(utility ?ut)(require ?t ?ut))
(exists (?fixa ?vara)
(and (fixed_amount ?t ?pu ?fixa)
(variable_amount ?t ?pu ?vara)
(legal_amount ?fixa ?vara) ))))
Axiom 5: A task occurrence (an activity occurrence) ?tocc has to be executed in a
processing unit ?pu that is related to its corresponding task ?t and its size in this
specific ?pu has to be between the max and min batch size specified for ?t
(forall (?tocc)
(iff (occurrence_of ?tocc ?t)
(exist (?t ?pu ?q ?maxbs ?minbs) (and
(task ?t) (processing_unit ?pu)
(can_perform ?t ?pu) (executed_in ?tocc ?pu)
(size ?tocc ?pu ?q)
(max_batch_size ?t ?pu ?maxbs)
(min_batch_size ?t ?pu ?minbs)
(and (&gt;= ?q ?minbs)(&lt;= ?q ?maxbs))))))
5</p>
      </sec>
    </sec>
    <sec id="sec-5">
      <title>Conclusions</title>
      <p>Ontologies support interoperability by providing semantic terminology in a computer
understandable format. This article proposes the definition of a network of ontologies
to solve the interoperability problems associated with the execution of scheduling
activities and their interplay with other functions within the Planning pyramid. This
ontology network, whose architecture is presented in this contribution, is the starting
point for the automatic construction and translation of models that are employed
during the scheduling activities. In addition, one of the ontologies of this network is
introduced along with its implementation in common logic as a definitional extension of
PSL.
6</p>
    </sec>
    <sec id="sec-6">
      <title>Acknowledgments</title>
      <p>The authors acknowledge the financial support received from CONICET (PIP
11220110100906 and PIP 11220110101145), ANPCyT (PICT-2013 1310), UNL (PI
CAI+D 2011) and UTN (PID 25-O156).
7</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <source>ANSI/ISA-88.00.01: Batch Control Part 1: Models and Terminology</source>
          ,
          <year>2010</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2. ANSI/ISA-95.
          <fpage>00</fpage>
          .
          <fpage>01</fpage>
          -
          <lpage>2000</lpage>
          :
          <article-title>Enterprise-Control System Integration</article-title>
          .
          <source>Part 1: Models and terminology</source>
          ,
          <year>2000</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Castro</surname>
            ,
            <given-names>P.M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Barbosa-Póvoa</surname>
            ,
            <given-names>A.P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Matos</surname>
            ,
            <given-names>H.A.</given-names>
          </string-name>
          (
          <year>2003</year>
          ).
          <article-title>Optimal Periodic Scheduling of Batch Plants Using RTN-Based Discrete</article-title>
          and
          <string-name>
            <surname>Continuous-Time Formulations</surname>
            :
            <given-names>A Case</given-names>
          </string-name>
          <string-name>
            <surname>Study</surname>
            <given-names>Approach</given-names>
          </string-name>
          , Ind.
          <source>Eng. Chem. Res.</source>
          ,
          <volume>42</volume>
          ,
          <fpage>3346</fpage>
          -
          <lpage>3360</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4. ISO 18629-
          <issue>1</issue>
          (
          <year>2004</year>
          )
          <article-title>Process specification language -- Part 1: Overview and basic principles</article-title>
          .
          <source>ISO/TC 184/SC 4</source>
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Giménez</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          <string-name>
            <surname>Henning</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Marevelias</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          (
          <year>2009</year>
          ).
          <article-title>A novel network-based continuous-time representation for process scheduling: Part I. Main concepts and mathematical formulation</article-title>
          .
          <source>Computers and Chemical Engineering</source>
          ,
          <volume>33</volume>
          ,
          <fpage>1511</fpage>
          -
          <lpage>1528</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>VH</surname>
          </string-name>
          (
          <year>2014</year>
          )
          <article-title>SRO Data Repository https://sites</article-title>
          .google.com/site/sropse2015/Last access:
          <source>30th November</source>
          <year>2014</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Vegetti</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          and
          <string-name>
            <surname>Henning</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          (
          <year>2014</year>
          ).
          <article-title>ISA-88 formalization. A step towards its integration with the ISA-95 standard, FOMI 2014 Proceedings</article-title>
          , Brasil.
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Ciocoui</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gruninger</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Nau</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          (
          <year>2000</year>
          ).
          <article-title>Ontologies for integrating Engineering Applications</article-title>
          ,
          <source>Journal of Computing and Information Science and Engineering</source>
          ,
          <volume>1</volume>
          ,
          <fpage>12</fpage>
          -
          <lpage>22</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>Vegetti</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          and
          <string-name>
            <surname>Henning</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          (
          <year>2015</year>
          ).
          <article-title>An ontological approach to integration of planning and scheduling activities in batch process industries</article-title>
          ,
          <source>PSE/ESCAPE 2015 Proceedings, Denmark.</source>
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <article-title>National Institute of Standards and Technologies (</article-title>
          <year>2008</year>
          ).
          <article-title>PSL ontology - Processor Activities extension</article-title>
          . Available on-line: http://www.mel.nist.gov/psl/pslontology/part46/processor.html
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <article-title>National Institute of Standards and Technologies (</article-title>
          <year>2008</year>
          ).
          <article-title>PSL ontology - Resource Roles extension</article-title>
          . Available on-line: http://www.mel.nist.gov/psl/pslontology/part44/res_role.html
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>Wassick</surname>
            ,
            <given-names>J.M</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ferrio</surname>
            <given-names>J</given-names>
          </string-name>
          . (
          <year>2011</year>
          ).
          <article-title>Extending the resource task network for industrial applications</article-title>
          ,
          <source>Computers and Chemical Engineering</source>
          <volume>35</volume>
          ,
          <fpage>2124</fpage>
          -
          <lpage>2140</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13. ISO/IEC 24707 (
          <year>2007</year>
          ).
          <article-title>Common Logic (CL): a framework for a family of logic-based languages</article-title>
          .
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <surname>Schlenoff</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gruninger</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lee</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          , (
          <year>2000</year>
          ).
          <article-title>The Essence of the Process Specification Language. Transaction of the Society for Computer Simulation International</article-title>
          , Vol.
          <volume>16</volume>
          ,
          <issue>N4</issue>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>