Purpose
As information technology in manufacturing has advanced, the ability of software applications to interoperate has gained significance Initially, translation programs facilitated one-way communication between specific applications, but as the number of applications grew and information complexity increased, providing translators for every application pair became challenging Standards-based translation mechanisms have streamlined integration for manufacturing software developers, allowing them to create a single translator that connects their software to an interchange standard This approach enables their application to interoperate with numerous other applications that have similar translators, enhancing overall efficiency and communication in manufacturing operations.
The challenge of interoperability in manufacturing is particularly evident in the use of process information across various engineering and business software applications, such as manufacturing simulation, production scheduling, and project management Each application interprets and utilizes process information differently, leading to inconsistencies in how this information is represented A key difficulty in establishing a standard for exchanging process information arises from the varied meanings associated with terms used by different applications For instance, a workflow system may define a "resource" as information for decision-making, while a process planning system views it as a person or machine performing a task Attempting to integrate these differing concepts can lead to confusion, highlighting the need for a neutral standard that accounts for both the semantics and syntax of the applications involved, ensuring that all potential meanings of the exchanged information are accurately captured.
The Process Specification Language (PSL) project at the National Institute of
The National Institute of Standards and Technology (NIST) is developing a neutral, standardized language for process specification, aimed at serving as an Interlingua to unify various process-related applications across the manufacturing life cycle This language stands out due to its formal semantic definitions, or ontology, which provide clear and precise meanings As a result, information exchange can occur without the need for hidden assumptions or subjective interpretations, enhancing clarity and efficiency in manufacturing processes.
Approach
The development of the PSL followed a structured five-phase approach: gathering requirements, analyzing existing processes, creating the language, implementing a pilot, and validating the results before submitting it as a candidate standard The initial phase successfully produced a detailed set of requirements essential for defining manufacturing processes.
In the second phase of the project, the PSL team identified twenty-six process representations for analysis based on phase one requirements Most representations concentrated on the syntax of process specifications, neglecting the semantics, which is crucial for accurately conveying meaning across different applications This discrepancy led to the development of a formal semantic layer, or ontology, in the third phase, utilizing the Knowledge Interchange Format (KIF) specification By clearly defining the essential concepts related to manufacturing process information through this ontology, PSL successfully integrated various existing manufacturing process applications in the project's fourth phase.
Scope
This study focuses on discrete processes within manufacturing, encompassing all stages of the design and manufacturing life cycle It incorporates both business processes and manufacturing engineering processes to identify shared elements in process specification and to recognize the ongoing and future integration of business and engineering functions.
The objective of this project is to develop a "process specification language," distinct from a "process characterization language." A process specification language serves to define a process or a series of processes, incorporating relevant parameters and settings for either prescriptive or descriptive purposes It consists of an ontology and various presentations In contrast, a process characterization language focuses on describing the behaviors and capabilities of a process without tying them to a specific application, such as the dynamic or kinematic properties like tool chatter or performance limits.
The Process Specification Language (PSL) serves as a neutral interchange language designed to integrate various process-related applications throughout the manufacturing lifecycle, from initial conception to retirement This initiative closely collaborates with several related projects, including the A Language for Process Specification (ALPS), Toronto Virtual Enterprise (TOVE), Enterprise Ontology, and Core Plan Representation (CPR) projects Additionally, PSL works alongside collaborative efforts such as the Shared Planning and Activity Representation (SPAR), Process Interchange Format (PIF), and WorkFlow Management Coalition (WfMC) projects, enhancing its impact across multiple organizations and academic institutions.
ALPS was a NIST research project whose goal was to identify information models to facilitate process specification and to transfer this information to process control The
The PSL project, a spin-off of the ALPS initiative, aims to delve deeper into process specification challenges while expanding its exploration across a wider range of manufacturing sectors.
The TOVE project provides a generic, reusable data model that provides a shared terminology for the enterprise that each agent can jointly understand and use The
The Enterprise Ontology project aims to create a comprehensive set of terms and definitions pertinent to business enterprises, facilitating better adaptation to a rapidly changing environment through enhanced business planning, increased flexibility, and improved communication and integration While both the Enterprise Ontology and TOVE concentrate on business processes, they share common semantic concepts with the manufacturing process-oriented PSL.
The CPR project aims to develop a model that addresses the diverse representation needs of various military planning systems Funded by ARPI, the SPAR project shares similar objectives with CPR, as both initiatives strive to establish a unified model for defining plans, processes, and activities Coordination among participants in SPAR, CPR, and PSL has been evident, highlighting the shared foundations of their core models However, it is important to note that SPAR and CPR specifically concentrate on military-related plans and processes.
PIF is an interchange format that relies on formally defined semantic concepts, similar to PSL, but it specifically targets the modeling of business processes It provides a unified syntactical representation through the BNF (Backus-Naur Format) specification of the Ontolingua 1 Frame syntax.
The Workflow Management Coalition has created a Workflow Reference Model aimed at defining the key characteristics, terminology, and components necessary for developing and ensuring the interoperability of workflow specifications While workflow is a component of the PSL project, the Workflow Reference Model plays a crucial role in maintaining consistency throughout the project.
Numerous prior initiatives have aimed to create process representations tailored to specific representational areas and functionalities, such as workflow, process planning, artificial intelligence planning, and business process re-engineering These representations vary in purpose, ranging from those that graphically document processes to internal representations for software applications and neutral formats that facilitate integration The outcomes of these efforts were thoroughly analyzed during the second phase of the PSL project, with a selection of existing process representations illustrated in Figure 1 For further details on the representations depicted, please refer to [2].
1 No approval or endorsement of any commercial product in this paper by the National Institute of
This document, created by employees of the United States Government as part of their official responsibilities, is a work of the U.S Government and is not protected by copyright.
Figure 1: A Sampling of Existing Process Representations
The Need for Semantics
Current process modeling methods fail to provide a clear specification of the semantics associated with process terminology, resulting in inconsistent interpretations and applications of information This inconsistency hampers analysis, as models are often tailored to specific applications and lack reusability Furthermore, interoperability challenges emerge because the systems supporting various enterprise functions were developed independently and do not share a common semantic framework for their process models.
In the context of data exchange between two process planning applications, such as those illustrated in Figure 2, it becomes evident that while both applications may utilize similar terms like "material" and "workpiece," the lack of explicit definitions for these terms complicates the understanding of their corresponding concepts Although both applications refer to "resource," the meaning of this term varies between them, highlighting that mere terminology sharing is inadequate for achieving interoperability To facilitate effective communication, it is essential for the applications to align their semantics, ensuring that the meanings of their respective terminologies are clearly defined and understood.
A Language for Process Specification (ALPS)
O-Plan Formalism (Task Formalism) OZONE
Parts and Action (Pact) PAR2 (Product-Activity-Resource 2) ISO/DIS 10303-49, Process Structure and Properties
PERT (Program Evaluation and Review Technique) Networks
Petri Nets Process Flow Representation (PFR) Process Interchange Format (PIF) Version 1.1 Quirk Models
Visual Process Modeling Language (VPML)
AND/OR GraphsData Flow DiagramsDirected GraphsState Transition DiagramsTree Structures
A solid foundation for designing, analyzing, and executing processes necessitates a formal specification of process model semantics Utilizing ontologies is an effective method for creating this specification An ontology provides a formal description of entities within a specific domain, detailing their properties, relationships, constraints, and behavioral patterns.
[11] It provides a common terminology that helps to capture key distinctions among concepts in different domains, which aids in the translation process
The PSL aims to enhance application interoperability by developing translators that convert native application formats to PSL Without a unified language like PSL, each application requires a unique translator for every interaction, leading to a complex need for n(n-1) translators for n different ontologies By utilizing PSL as a standardized medium, the number of necessary translators is streamlined to n, as it only requires translation between native ontologies and the interchange ontology This method emphasizes the exchange of files containing process information, necessitating clear semantics in process descriptions Consequently, there can be no procedural interpretation or implicit assumptions about application behavior, as all assumptions must be explicitly defined for accurate translation based solely on the input file.
What is PSL?
The Language
A language comprises a lexicon, which is a collection of symbols, and a grammar that dictates how these symbols can be combined to create coherent expressions In the context of PSL (Process Specification Language), the lexicon includes both logical symbols, such as boolean connectives and quantifiers, and nonlogical symbols The nonlogical elements consist of expressions like constants, function symbols, and predicates that represent fundamental concepts within the PSL ontology Key components include the 1-place predicates 'activity,' 'activity-occurrence,' 'object,' and 'timepoint,' which denote the four primary entity types in the PSL ontology Additionally, function symbols like 'beginof' and 'endof' indicate the timepoints marking the start and end of activities, while 2-place predicates such as 'is-occurring-at,' 'occurrence-of,' 'exists-at,' 'before,' and 'participates-in' articulate significant relationships among various elements within the ontology.
The PSL (Process Specification Language) is fundamentally grounded in the grammar of KIF (Knowledge Interchange Format), a formal language designed for the seamless exchange of knowledge between diverse computer programs KIF's rigorous framework is essential for unambiguously defining concepts within the PSL Ontology, facilitating the exchange of manufacturing process information Similar to KIF, PSL features a precise BNF (Backus-Naur Form) specification, which outlines the grammatically correct expressions of the language This clarity in definition not only enhances understanding but also enables the development of computational tools for process information transfer, a key objective of PSL By establishing a fixed language definition, translators can be created to bridge PSL with other well-defined representation languages For detailed specifications, refer to the PSL BNF in Appendix D.
Model Theory
The model theory of PSL offers a precise mathematical framework for understanding the semantics of PSL's language It typically involves a structured set, such as a lattice, partial ordering, or vector space This theory establishes meanings for the terminology used and defines a concept of truth for the language's sentences based on this model The goal is to correlate each concept within the language to an element of a specific mathematical structure, including lattices, linear orderings, and vector spaces.
A model theory provides a foundational framework for understanding the mathematical structures associated with it, enabling reasoning about the concepts represented by the terms in the PSL language and their logical connections Consequently, the collection of models serves as the formal semantics for the ontology.
Proof Theory
The proof theory consists of three components: PSL Core, one or more foundational theories, and PSL extensions.
The PSL Core consists of axioms that serve as a syntactic representation of PSL model theory, ensuring soundness and completeness Each axiom holds true across all models of the PSL language, and any sentence that is true in every PSL model can be derived from these axioms This close relationship between the Core axioms and PSL model theory allows the Core to effectively provide semantics for the terms within the PSL language.
PSL Core aims to axiomatize intuitive semantic primitives essential for describing basic processes, maintaining a straightforward and uncontroversial approach with minimal assumptions about their nature However, this simplicity results in a lack of logical strength, making it insufficient for defining the auxiliary notions necessary for a more detailed description of diverse processes To address this limitation, PSL incorporates foundational theories that enhance expressive power, allowing for precise definitions and axiomatizations of primitive concepts These foundational theories enable the definition of numerous auxiliary terms and facilitate the proof of significant metatheoretical properties for both the core and its extensions.
Set theory is one of the most recognized and powerful foundational theories in mathematics It provides a comprehensive framework for classical mathematics, allowing for the definition of integers, real numbers, and topological spaces as specific types of sets Through these definitions, the classical properties of these mathematical concepts can be derived as theorems within set theory.
For the purposes of PSL, a modified and extended version of the situation calculus serves as a more suitable foundation due to its inherent compatibility with PSL's primitives—situation, action, and fluent This alignment allows for a natural identification or definition of PSL primitives in terms of situation calculus Furthermore, the situation calculus is robust enough to encompass a variety of auxiliary concepts, and with the integration of set theory, it can effectively support the proof of fundamental metatheoretic results regarding the Core and its extensions.
The third component of PSL is its extensions, which provide the necessary resources to express information about concepts beyond the PSL Core These extensions contribute to PSL's clean and modular design, allowing users to maintain a simple foundational theory while accommodating more complex processes that require additional expressive capabilities Instead of overcrowding PSL Core with every potential concept, a variety of modular extensions have been developed and can be integrated as needed, enabling users to customize PSL to meet their specific expressive requirements.
An extension of the basic PSL language involves adding new constants and predicates, accompanied by axioms that define their interpretation, thereby creating a semantics for these linguistic items A notable example of this is the theory of time durations, which PSL Core lacks the capacity to express In various contexts, the ability to convey time durations is crucial Therefore, a theory of time durations has been developed to complement PSL Core, enhancing its expressive capabilities for users.
Definitional extensions, when integrated with foundational theories like situation calculus, consist of new linguistic items that can be fully defined by the foundational theory and PSL Core, thereby not adding new expressive power or theoretical complexity Despite this, they are valuable for succinctly describing complex processes due to the intricate nature of many definitions In contrast, nondefinitional extensions introduce at least one concept that cannot be defined within the confines of PSL Core and the selected foundational theory.
The three components of the PSL architecture and their relations are illustrated in Figure
3 The solid arrows indicate the definability relation The dashed lines indicate partial definability, i.e., the case where some, but not all the additional linguistic items in the language of an extension are definable Two or more solid arrows pointing to the same oval indicate the possibility that more than one given theory might jointly be used to define a new extension Therefore, we might have connected PSL Core to foundational theories, but this would not sufficiently distinguish the central role of the Core from the more auxiliary roles of extensions Hence, we picture PSL Core as sitting directly upon the foundational theories “(+ Foundational Theory) ” in the PSL Core box indicates that PSL Core together with a foundational theory are typically used to formulate definitional extensions.
Figure 3: The PSL Semantic Architecture
Informal Semantics of PSL Core
PSL Core is founded on a rigorous mathematical first-order theory, which includes a formal language, a defined mathematical semantics, and a set of axioms that articulate this semantics The ontology of PSL Core comprises four primitive classes: OBJECT, ACTIVITY, ACTIVITY_OCCURRENCE, and TIMEPOINT, alongside two primitive functions and three primitive relations Among the relations, PARTICIPATES is one of the key elements that define interactions within the framework.
The terms IN, BEFORE, and OCCURRENCE-OF are fundamental to understanding the two primary functions, BEGINOF and ENDOF Collectively referred to as entities, ACTIVITIES, ACTIVITY_OCCURRENCES, TIMEPOINTs (or POINTs), and OBJECTs are distinct classes that do not overlap with one another.
Intuitively, an OBJECT is a concrete or abstract thing that can participate in an ACTIVITY The most typical examples of OBJECTs are ordinary, tangible things, such
Definitional extensions encompass both tangible entities, such as people, chairs, and car bodies, as well as abstract concepts like numbers OBJECTs can be created or cease to exist, marking specific beginning and end points in time However, some OBJECTs, like numbers, are eternal and do not possess finite start or end points In certain contexts, it may also be beneficial to represent common OBJECTs as lacking definitive temporal boundaries.
An ACTIVITY-OCCURRENCE refers to a specific event in time, such as the first mountain stage of the 1997 Tour de France or the eruption of Mt St Helens It is primarily defined by two key elements: its temporal extent, marked by its starting and ending points, which can extend indefinitely, and the collection of OBJECTs involved in the ACTIVITY throughout its duration.
TIMEPOINTs in PSL Core are organized through a transitive, non-reflexive, and total ordering known as the BEFORE relation, indicating that time is infinite but not dense While there is no inherent density between distinct TIMEPOINTs, users can introduce denseness as an additional postulate if desired The concept of POINTs at infinity (INF+ and INF-) is included for convenience Time intervals are not considered primitive in PSL Core, as they can be defined using TIMEPOINTs and ACTIVITIES, while TIMEDURATIONS are part of an extension that enhances the PSL Core framework.
The foundational concepts of the PSL Core are formally established as a first-order theory, which accurately encapsulates the essential characteristics of the PSL ontology Key axioms pertaining to ACTIVITIES, OBJECTs, and TIMEPOINTs are detailed in Section 5.2.
Extensions in PSL 1.0
PSL Outer Core
The PSL Outer Core consists of a select group of highly versatile extensions that are widely applicable across various contexts This core includes three key extensions that stand out due to their generic nature and broad relevance.
The Subactivity Extension outlines the aggregation and decomposition of activities, introducing the idea of a primitive activity that cannot be further divided Additionally, the Activity-Occurrence Extension establishes relationships between activity occurrences based on their start and end times Meanwhile, the State Extension presents the concepts of pre-state, which occurs before an activity occurrence, and post-state, which follows it.
Generic Activities and Ordering Relations
Figure 4 depicts the essential modules in PSL necessary for defining terminology related to generic activity classes and their ordering relationships There are nine key extensions to PSL Core, with four pertaining to generic process modeling concepts and five focused on scheduling, which will be addressed in Section 3.4.3 The four extensions related to generic process modeling concepts are outlined as follows.
Figure 4: PSL modules for generic classes of activities and their ordering relations
The initial extension pertains to deterministic activities, while the subsequent three focus on nondeterministic activities, where not all subactivities take place during the main activity For instance, when fabricating an engine block, one might choose between using a casting machine or modifying an existing block Junctions represent a specific type of nondeterministic activity, facilitating the concepts of splits and joins In a split, one of several potential activities may follow, whereas in a join, one of multiple activities must precede the next action.
PSL Extensions for Schedules
The development of these extensions was driven by the needs identified during the PSL pilot implementation, particularly with ILOG Scheduler 4.3 Initially, the pilot lacked extensions that could fully articulate concepts like temporal constraints Consequently, it became essential to create new extensions that included terminology with precise definitions, accurately reflecting the intuitive meanings associated with ILOG Schedule concepts.
Scheduling involves allocating resources to activities while adhering to temporal constraints, which encompass the duration of tasks and the sequence in which they occur This understanding has led to the development of five extensions within PSL 1.0, as illustrated in Figure 4.
Approach for Developing Extensions
The analysis of the extensions within PSL reveals that while some representational areas, like "ordering of activities," have been extensively developed through frameworks such as "Ordering Relations for Complex Sequence Actions," "Ordering Relations over Activities," and "Temporal Ordering," other areas remain underexplored.
“Process Intent” have not yet been addressed
The development of the PSL (Process Specification Language) ontology has been driven by specific needs, beginning with a single scenario known as the EDAPS (Electromechanical Design and Planning System), which was created by Steve Smith at the University of Maryland.
The concepts from the initial scenario were defined and modeled within the Process Specification Language (PSL) and subsequently expanded as additional scenarios were examined The PSL ontology was further developed to include concepts from various manufacturing software applications, facilitating the exchange of process information among these systems.
As more software applications become “PSL-compliant,” PSL will be continually expanded to ensure that ALL process-related concepts are capable of being represented within the language.
Introduction
This section aims to offer informal documentation of the PSL Core and its extensions, providing a clear English description of the concepts introduced within them While formal definitions and axioms, expressed in the knowledge interchange format, are included for reference, the informal documentation is entirely based on these formal elements.
The classification used in this document is the one provided by the IDEF5 Ontology
Capture methods categorize entities into groups sharing similar characteristics, akin to types or classes Each individual within these groups is uniquely identifiable, resembling objects in the object-oriented paradigm Additionally, relations are utilized to define and express the connections between these individuals.
Finally, functions are used to express properties.
PSL Core
Kinds for the PSL Core
The PSL Core introduces the following kinds of elements:.
A class or type of action For example, ‘paint-part’ is an activity It is the class of actions in which parts are being painted activity- occurrenc e
An event or action that takes place at a specific place and time An instance or occurrence of an activity E.g., paint-part is an activity, painting in Maryland at 2
PM on May 25, 1998 is an activ ity-occurrence. timepoint A point in time. object Anything that is not a timepoint or an activity.
The following axioms pertain to these four kinds.
• Axiom 9 Everything is either an activity, an activity-occurrence, an object, or a timepoint.
• Axiom 10 Activities, activity-occurrences, objects, and timepoints are all distinct kinds of things.
Activities are arguments to the following relations.
Relation Arguments Informal Definition is-occurring-at Activity- occurrence, timepoint
The specified activity occurrence takes place at a defined timepoint, meaning that this timepoint falls within the start and end times of the activity's occurrence An activity occurrence refers to a specific instance of the given activity.
Activity-occurrences are arguments to the following relations.
Relation Arguments Informal Definition participates-in object, activity, timepoint
The specified object plays an unspecified role in the occurrence of a particular activity at a specific time This activity occurrence represents a unique instance of the given activity.
Activity-occurrences are arguments to the following functions.
Function Arguments Return value Informal Definition beginof activity-occurrence timepoint
The timepoint at which the occurrence begins. endof activity-occurrence timepoint The timepoint at which the occurrence ends.
The following axioms pertain to activity-occurrences.
• Axiom 12 An activity-occurrence is the occurrence-of a single activity.
• Axiom 14 The timepoint at which an activity-occurrence begins always precedes the timepoint at which the activity-occurrence ends.
Objects are arguments to the following relations.
Relation Arguments Informal Definition exists-at object, timepoint The object exists at the given timepoint. participates-in object, activity- occurrence, time
The given object plays some (indeterminate) role in the given activity occurrence at the given timepoint. point
Objects are arguments to the following functions.
In programming, function arguments are essential for defining the inputs a function requires to operate The return value is the output produced by the function after processing these inputs An informal definition of the "begin of object timepoint" refers to the moment an object is created, while the "end of object timepoint" signifies when the object no longer exists Understanding these concepts is crucial for effective coding and object lifecycle management.
Timepoints are arguments to the following relations.
Relation Arguments Informal Definition participates-in object, activity- occurrence, time point
The given object plays some (indeterminate) role in the given activity occurrence at the given timepoint. before timepoint, timepoint
This relation establishes a total ordering of timepoints, allowing for comparisons such as strictly less than or greater than between two timepoints It also includes the concepts of less than or equal to (beforeEq) and greater than or equal to (betweenEq) for more nuanced temporal relationships Additionally, it specifies the existence of an object at a particular timepoint, indicating that the object is present during that specified time.
The specified activity is taking place at a designated timepoint, meaning that this timepoint falls within the range defined by the start and end time of the activity's occurrence.
Timepoints are return values to the following functions.
Function Arguments Return value Return value
Beginof object timepoint The timepoint at which the object comes into existence.
Endof object timepoint The timepoint at which the object ceases to exist.
Individuals for the PSL Core
The PSL Core introduces the following individuals. inf- The timepoint that is before all other timepoint. inf+ The timepoint that is after all other timepoint.
The following axioms pertain to inf+ and inf-.
• Axiom 5 Inf- is before all other timepoints.
• Axiom 6 Every timepoint else than inf+ is before inf+
• Axiom 7 Given any timepoint t other than inf-, there is a timepoint between inf- and t.
• Axiom 8 Given any timepoint t other than inf+, there is a timepoint between t and inf+.
Primitive Relations for the PSL Core
The PSL Core introduces the following relations.
Before timepoint, timepoint This relation is used to impose a total ordering on timepoints. occurrence-of activity- occurrence, activity
An activity occurrence refers to a specific instance of a particular activity In this context, the object involved plays a significant role in the activity occurrence at a designated timepoint.
The following axioms pertain to the before relation.
• Axiom 1 The before relation only holds between timepoints.
• Axiom 2 The before relation is a total ordering.
• Axiom 3 The before relation is non-reflexive.
• Axiom 4 The before relation is transitive
The following axioms pertain to the occurrence-of relation.
• Axiom 11 The occurrence-of relation only holds between activities and activity-occurrences.
• Axiom 12 An activity-occurrence is the occurrence-of a single activity.
• Axiom 17 Every activity-occurrence is an occurrence-of an activity.
The following axioms pertain to the participates-in relation.
• Axiom 15 The participates-in relation only holds between objects, activities, and timepoints, respectively.
• Axiom 16 An object can participate in an activity only at those timepoints at which both the object exists and the activity is occurring.
Primitive Functions for the PSL Core
The PSL Core introduces the following functions
Function Arguments Return type Informal Definition endof activity timepoint The timepoint at which the activity ends. endof object timepoint
The timepoint at which the object ceases to exist. beginof activity timepoint The timepoint at which the activity begins. beginof object timepoint
The timepoint at which the object comes into existence.
The following axioms pertain to the beginof and endof functions.
• Axiom 13 The begin and end of an activity-occurrence or object are timepoints.
• Axiom 14 The timepoint at which an activity-occurrence begins always precedes the timepoint at which the activity-occurrence ends.
Defined Relations for the PSL Core
The PSL Core defines the following relations.
Between timepoint, timepoint, timepoint Strictly less than and strictly greater than.
BeforeEq timepoint, timepoint Less or equal than.
BetweenEq timepoint, timepoint, timepoint Less or equal to and greater or equal to. exists-at object, timepoint A point in time in which an object exists. is-occurring-at
The specified activity-occurrence is occurring at the specified timepoint I.e., the specified timepoint is between or equal to the begin timepoint and end timepoint of the specified activity occurrence.
The following is the formal definition for the between relation.
Definition 1 Timepoint q is between timepoints p and r if and only if p is before q and q is before r.
The following is the formal definition for the beforeEq relation.
Definition 2 Timepoint p is beforeEq timepoint q if and only if p is before or equal to q.
The following is the formal definition for the betweenEq relation.
Definition 3 Timepoint q is betweenEq timepoints p and r if and only if p is before or equal to q, and q is before or equal to r.
The following is the formal definition for the exists-at relation.
Definition 4 An object exists-at a timepoint p if and only if p is betweenEq its begin and end points.
The following is the formal definition for the is-occurring-at relation.
Definition 5 An activity occurrence is-occurring-at a timepoint p if and only if p is betweenEq the activity'occurrence’s begin and end points.
Definitions and Axioms for the PSL Core in the formal language
In this section the definitions and axioms for the PSL Core are given explicitly in the formal PSL language (Note: The lexicon items ‘defrelation’, ‘exists’, ‘forall’,
‘and’, ‘or’, ‘not’, ‘=’, ‘’, and ‘=>’ are defined in the KIF Reference Manual [3].)
Definition 1 Timepoint q is between timepoints p and r if and only if p is before q and q is before r.
Definition 2 Timepoint p is beforeEq timepoint q if and only if p is before or equal to q.
Definition 3 Timepoint q is betweenEq timepoints p and r if and only if p is before or equal to q, and q is before or equal to r.
Definition 4 An object exists-at a timepoint p if and only if p is betweenEq its begin and end points.
Definition 5 An activity occurrence is-occurring-at a timepoint p if and only if p is betweenEq the activity occurrence’s begin and end points.
(defrelation is-occurring-at (?occ ?p) :=
(betweenEq (beginof ?occ) ?p (endof ?occ))))
PSL Core Axioms
Axiom 1 The before relation only holds between timepoints.
Axiom 2 The before relation is a total ordering.
Axiom 3 The before relation is non-reflexive.
Axiom 4 The before relation is transitive.
Axiom 5 Inf- is before every other timepoint.
Axiom 6 Every timepoint else than inf+ is before inf+
Axiom 7 Given any timepoint t other than inf-, there is a timepoint between inf- and t.
Axiom 8 Given any timepoint t other than inf+, there is a timepoint between t and inf+.
Axiom 9 Everything is either an activity, an activity-occurrence, an object, or a timepoint.
Axiom 10 Activities, activity-occurrences, objects, and timepoints are all distinct kinds of things.
Axiom 11 The occurrence-of relation only holds between activities and activity- occurrences.
Axiom 12 An activity-occurrence is the occurrence-of a single activity.
Axiom 13 The begin and end of an activity-occurrence or object are timepoints.
Axiom 14 The timepoint at which an activity-occurrence begins always precedes the timepoint at which the activity-occurrence ends.
Axiom 15 The participates-in relation only holds between objects, activities, and timepoints, respectively.
Axiom 16 An object can participate in an activity only at those timepoints at which both the object exists and the activity is occurring.
Subactivity Extension
Defined Classes in the Subactivity Extension
The subactivity extension defines the following kind.
Kind Informal Definition primitive-activity A primitive activity is an activity that does not have any subactivities.
Defined Relations in the Subactivity Extension
The subactivity extension defines the following relation.
Relation Arguments Informal Definition subactivity activity, activity
This relation defines a partial ordering over the set of activities with respect to aggregation and decomposition
Formal Axioms in the Subactivity Extension
Axiom 1 The subactivity relation is reflexive.
Axiom 2 The subactivity relation is asymmetric.
Axiom 3 The subactivity relation is transitive.
Axiom 4 For any two activities, there exists another activity which contains them both as subactivities.
Definition 1 A primitive activity is an activity that does not have any proper subactivities.
Activity-Occurrences Extension
Introduced Relations in the Activity-Occurrences Extension
The activity-occurrence extension introduces the following relations.
Relation Arguments Informal Definition occurrence- contains
An occurrence occ1 contains another occ2 if occ1 happens during occ2 occurrence- activity-occurrence,An occurrence occ1 is earlier than another occ2 if earlier
| activity-occurrence occ1 ends before occ2 begins. occurrence- overlap
Occurrences occ1 and occ2 are considered overlapping when there exists a time interval during which both events are happening, specifically when occ2 begins before occ1 and concludes before occ1 does.
The following axioms pertain to these relations.
Axiom 1 If two occurrences stand in the successor relation, than they stand in the occurrence-earlier relation.
Axioms 2 and 3 The relations occurrence-contains and occurrence- overlap are reflexive.
Axiom 4 If an activity-occurrence stands in the relation occurrence- earlier with itself, than its beginning and ending point are equal.
Axiom 7 If an activity-occurrence occ1 contains an activity-occurrence occ2, than the beginning timepoint of occ1 is before or equal to the beginning timepoint of occ2, and the ending timepoint of occ2 is before or equal to the ending timepoint of occ1.
Axiom 8 If an activity-occurrence occ1 is earlier than an activity- occurrence occ2, then the beginning timepoint of occ1 is before or equal to the beginning timepoint of occ2.
Axiom 9 If an activity-occurrence occ1 overlaps with an activity- occurrence occ2, then the beginning timepoint of occ2 is before or equal to the beginning timepoint of occ1, the beginning timepoint of occ1 is before or equal to the ending timepoint of occ2 , and the ending timepoint of occ2 is before or equal to the ending timepoint of occ1.
Defined Relations in the Activity-Occurrences Extension
The activity-occurrence extension introduces the following relations.
Relation Arguments Informal Definition successor activity-occurrence, activity-occurrence, activity-occurrence
An activity occurrence, referred to as occ2, is considered the successor of another activity occurrence, occ1, when occ1 takes place before occ2, and no other activity occurrences intervene between them This relationship highlights the sequential nature of activity occurrences, establishing a direct connection between the two.
An activity occurrence, referred to as occ1, is considered a subactivity occurrence of another activity occurrence, known as occ2, if the activity associated with occ1 is a subactivity of the activity linked to occ2 Additionally, occ1 must have a relationship of occurrence containment with occ2.
Formal Axioms in the Activity-Occurrences Extension
Definition 1 One activity-occurrence is the successor of another if and only if the fist activity-occurrence is earlier and there does not exist any other activity-occurrence between them
(and (occurrence-earlier ?occ1 ?occ2)
Definition 2 An activity-occurrence occ1 is a subactivity-occurrence of an activity-occurrence occ2 if the activity of which occ1 is an activity- occurrence is a subactivity of the activity of which occ2 is an activity- occurrence and occ1 stands in the occurrence-contains relation with occ2
(defrelation subactivity-occurrence (?occ1 ?occ2) :=
Axiom 1 If two activity-occurrences stand in the successor relation, than they stand in the occurrence-earlier relation.
Axioms 2 and 3 The relations occurrence-contains and occurrence- overlap are reflexive.
(forall (?occ) (occurrence-contains ?occ ?occ))
(forall (?occ) (occurrence-overlap ?occ ?occ))
Axiom 4 If an activity-occurrence stand in the relation occurrence- earlier with itself, than its beginning and ending point are equal.
Axioms 5 The relations occurrence-contains is transitive
(=> (and (occurrence-contains ?occ1 ?occ2)
Axioms 6 The relations occurrence-earlier is transitive
(=> (and (occurrence-earlier ?occ1 ?occ2)
Axiom 7 If an activity-occurrence occ1 contains an activity-occurrence occ2, than the beginning timepoint of occ1 is before or equal to the beginning timepoint of occ2, and the ending timepoint of occ2 is before or equal to the ending timepoint of occ1.
(and (beforeEq (beginof ?occ1) (beginof ?occ2))
(beforeEq (endof ?occ2) (endof ?occ1)))))
Axiom 8 If an activity-occurrence occ1 is earlier than an activity- occurrence occ2, then the ending timepoint of occ1 is before or equal to the beginning timepoint of occ2.
(beforeEq (endof ?occ1) (beginof ?occ2)))
Axiom 9 If an activity-occurrence occ1 overlaps with an activity- occurrence occ2, then the beginning timepoint of occ2 is before or equal to the beginning timepoint of occ1, the beginning timepoint of occ1 is before or equal to the ending timepoint of occ2 , and the ending timepoint of occ2 is before or equal to the ending timepoint of occ1.
(and (beforeEq (beginof ?occ2) (beginof ?occ1))
(beforeEq (beginof ?occ1) (endof ?occ2))
(beforeEq (endof ?occ2) (endof ?occ1)))))
States Extension
Classes of Objects in the States Extension
The following kind is defined in the state extension.
A fluent is a characteristic of the world that can change due to an activity occurring It is considered to hold before an activity if the property exists prior to the event, and it continues to hold after the activity if the property remains afterward.
Introduced Relations in the States Extension
The states extension introduces the following relations.
State fluent, activity- occurrence The state relation holds between a fluent and an activity-occurrence, if the fluent holds before the activity-occurrence.
Post-state fluent, activity- occurrence
The effect relation holds between a fluent and an activity if the fluent holds after the activity-occurrence.
Integer and Duration Extension
Primitive Kinds in the Integer Extension
Integer The class of integers: 0, -1, 1, -2, 2, etc.
Defined Kinds in the Integer Extension
PosInt The class of positive integers: 1, 2, 3, etc
NegInt The class of negative integers: -1, -2, -3, etc.
Individuals in the Integer Extension
The integer xtension introduces the following individuals.
The following axioms pertain to this individual.
Axiom 1 The sum of any integer and 0 is that integer.
Axiom 2 The difference between any integer and 0 is that integer.
Functions in the Integer Extension
Integers are arguments to the following functions.
Function Arguments Return Type Informal Definition
+1 Integer Integer +1 is the sucessor function on integers
-1 Integer Integer -1 is the predecessor function on integers +
Integer, Integer Integer + is the addition function
Integer Integer - is the subtraction function
The following axioms pertain to these functions.
Axiom 3 The successor and predecessor functions are one-to-one on the integers.
Axiom 4 An integer is less than its successor and greater than its predecessor.
Axiom 5 No integer is between a given integer and its successor or predecessor.
Axiom 6 The successor of any integer i with the successor of any integer j is the successor of the sum of i and j; the successor of any integer i with the predecessor of any integer j is the predecessor of the sum of i and j.
Axiom 7 The difference between an integer i and the successor of any integer j is the predecessor of the difference between i and j; the difference between an integer i and the predecessor of any integer j is the successor of the difference between i and j.
Relations on Integers
Integers are arguments to the following relation.
Integer < is the less-than relation on integers
The following axioms pertain to this relation.
Axiom 8 The less-than relation is transitive on the integers.
Axiom 9 The less-than relation is irreflexive on the integers.
Axiom 10 The less-than relation is a total ordering on the integers.
Axiom 11 An integer is less than its successor and greater than its predecessor.
Axiom 12 No integer is between a given integer and its successor or predecessor.
Formal Definitions and Axioms for Integers
To establish a theory of integers, we define the predicate Integer, the constant '0', and the function symbols '+1' and '-1' for successor and predecessor functions Additionally, we introduce the predicate ' (holds-after (activity-fluent ?a) ?occ)
(and (hold-before (activity-fluent ?a) ?occ)
(and (holds-before (activity-fluent ?a) ?occ)
(and (holds-before (activity-fluent ?a) ?occ)
(not (legal-activity (terminate ?a) ?occ))))))
Temporal Ordering Relations Extension
Defined Relations in the Temporal Ordering Extension
The temporal ordering extension defines the following relations.
Relation Arguments Informal Definition before-start- delay activity- occurrence, activity- occurrence, activity- occurrence, duration
The term "before-start-delay" refers to the relationship between two subactivity occurrences, occ1 and occ2, within a main occurrence, occ, indicating that occ2 starts at least d timepoints after the initiation of occ1 Additionally, the concept of "before-end-delay" involves the timing of activity occurrences and their respective durations, highlighting the importance of scheduling in project management.
In project management, the term "before-end-delay" (occ1, occ2, occ, d) indicates that occurrences occ1 and occ2 are sub-activities of the main occurrence, occ, with occ2 beginning at least d timepoints after the completion of occ1 Additionally, the concept of "after-start-delay" in activity occurrences refers to the duration and timing of activities, ensuring proper scheduling and resource allocation.
The term "after-start-delay (occ1, occ2, occ, d)" indicates that occurrences occ1 and occ2 are sub-activities of the main occurrence, occ, with occ2 concluding at least d timepoints after the initiation of occ1 Additionally, the "after-end-delay" concept involves specific activity occurrences and their respective durations.
The notation (after-end-delay occ1 occ2 occ d) indicates that occurrences occ1 and occ2 are sub-activities of the main activity occ, with occ2 concluding at least d timepoints after the end of occ1 Additionally, the term "start-equal-start" refers to the simultaneous initiation of activity occurrences.
The notation (start-equal-start occ1 occ2 occ d) indicates that occurrences occ1 and occ2 are sub-activities of a larger occurrence, with occ2 starting precisely d timepoints after occ1 This structure highlights the relationship between various activity occurrences, emphasizing their duration and timing in relation to one another Understanding these occurrences is crucial for analyzing the sequence and duration of activities within a given framework.
The notation (start-equal-end occ1 occ2 occ d) indicates that occurrences occ1 and occ2 are sub-activities of the main activity occ, with occ2 commencing exactly d timepoints after the conclusion of occ1 This framework highlights the relationship between activity occurrences and their respective durations.
In the context of activity occurrences, the notation (end-equal-start occ1 occ2 occ d) indicates that occ1 and occ2 are sub-activity occurrences of a primary occurrence, occ, with occ2 concluding precisely d timepoints after the initiation of occ1 This relationship highlights the connection between the start and end times of these activities, emphasizing their durations and interdependencies.
(end-equal-end occ1 occ2 occ d) means that occ1 and occ2 are subac tivity occurrences of occ and that occ2 ends exactly d timepoints after occ1 ends.
Formal Definitions for the Temporal Ordering Extension
(defrelation before-start-delay (?occ1 ?occ2 ?occ ?d) :=
(and (subactivity-occurrence ?occ1 ?occ)
(beforeEq (timeAdd (beginof ?occ1) ?d) (beginof ?occ2))))
(defrelation before-start-delay (?occ1 ?occ2 ?occ ?d) :=
(and (subactivity-occurrence ?occ1 ?occ)
(beforeEq (timeAdd (endof ?occ1) ?d) (beginof ?occ2))))
(defrelation after-start-delay (?occ1 ?occ2 ?occ ?d) :=
(and (subactivity-occurrence ?occ1 ?occ)
(beforeEq (timeAdd (beginof ?occ1) ?d) (endof ?occ2))))
(defrelation after-end-delay (?occ1 ?occ2 ?occ ?d) :=
(and (subactivity-occurrence ?occ1 ?occ)
(beforeEq (timeAdd (endof ?occ1) ?d) (endof ?occ2))))
(defrelation start-equal-start(?occ1 ?occ2 ?occ ?d) :=
(and (subactivity-occurrence ?occ1 ?occ)
(= (timeAdd (beginof ?occ1) ?d) (beginof ?occ2))))
(defrelation start-equal-end(?occ1 ?occ2 ?occ ?d) :=
(and (subactivity-occurrence ?occ1 ?occ)
(= (timeAdd (endof ?occ1) ?d) (beginof ?occ2))))
(defrelation end-equal-star(?occ1 ?occ2 ?occ ?d) :=
(and (subactivity-occurrence ?occ1 ?occ)
(= (timeAdd (beginof ?occ1) ?d) (endof ?occ2))))
(defrelation end-equal-end(?occ1 ?occ2 ?occ ?d) :=
(and (subactivity-occurrence ?occ1 ?occ)
(= (timeAdd (endof ?occ1) ?d) (endof ?occ2))))
Junctions Extension
Classes of Activities in the Junctions Extension
The junctions extension defines the following kinds.
An or-split is an activity where at least one of its subactivities occurs whenever the main activity takes place In contrast, an and-split requires that all subactivities occur simultaneously with the main activity An xor-split allows only one subactivity to occur at a time when the main activity is initiated A sync-start activity ensures that if two or more subactivities happen, they all begin at the same time Similarly, a sync-finish activity guarantees that if multiple subactivities occur, they all conclude simultaneously.
A sync-start-and-split activity is an activity that is both a sync-start and an and-split activity. sync-start-or- split
A sync-start-or-split activity is an activity that is both a sync-start and an or- split activity sync-finish- and-split
A sync-finish-and-split activity combines the characteristics of both sync-finish and and-split activities Similarly, a sync-finish-or-split activity integrates elements of sync-finish and or-split activities, highlighting the versatility of these processes in project management.
Formal Definitions for the Junctions Extension
(=> (and (subactivity-occurrence ?occ2 ?occ)
(defrelation sync-start-and-split(?a) :=
(defrelation sync-start-or-split(?a) :=
(defrelation sync-finish-and-split(?a) :=
(defrelation sync-finish-or-split(?a) :=
Motivation
For accurate and complete translations, it is essential for translators to adhere to the formal specifications of the representation's semantics Handwritten translations lack this guarantee, making it challenging to demonstrate that they achieve the intended "correct" translation, a task that is rarely accomplished.
Overview of Semantic and Syntactic Translation
Translation is a two-stage process involving syntactic and semantic translation The syntactic translator serves as a parser that bridges the PSL syntax, such as KIF, with the native syntax of an application, ensuring that the application's terminology remains unchanged This process is visually represented in Figure 5, which depicts the translation transaction between two applications and highlights the role of the PSL Ontology.
Semantic translation involves replacing terms from one application with definitions from the PSL ontology These translation definitions are based on ontological definitions created using consistent foundational theories This process includes defining the terminology of the application ontology exclusively with PSL terms, as well as defining PSL terminology solely with terms from the application ontology.
Figure 5: Translation to/from PSL
This procedure is effectively illustrated through an example, which emphasizes the resource construct at each stage of the translation process We start with a basic file formatted in the syntax of Application A.
The syntactic translator takes this file and produces a corresponding file using PSL syntax, but still preserving Application A terminology
The semantic translator takes this file and produces a file containing only PSL terminology by substituting the definitions of all Application A terms with their definitions in PSL
We now follow reversed steps to translate the file into Application B Using the translation definitions for Application B, the PSL file is mapped to a file containing only Application B terminology forall (?r)
Finally, the syntactic translator for Application B maps the file back into Application B syntax.
The ontology-based approach to compliance differs significantly from traditional standards compliance methods Instead of mandating uniform terminology, an application is considered PSL-compliant if it provides definitions for its terms based on a foundational theory or another ontology With these definitions in place, it becomes possible to establish translation definitions between the application and PSL.
The Process Specification Language (PSL) aims to standardize manufacturing process information, acting as an Interlingua to enhance information exchange between various manufacturing software applications This document outlines Version 1.0 of PSL.
Other efforts to develop mechanisms for the exchange of data, such as ISO 10303 (informally known as The STandard for the Exchange of Product model data (STEP))
The Process Specification Language (PSL) addresses the complexities of data exchange in manufacturing by focusing on both syntax and semantics, ensuring that terms and concepts are accurately represented across different software applications This approach is essential for effective communication in a diverse manufacturing environment where process models vary significantly Version 1.0 of PSL marks the initial step toward a comprehensive language for specifying and exchanging process information, with plans for iterative refinement based on pilot implementations These implementations will evaluate the language's effectiveness in real-world scenarios, guiding necessary expansions to capture and exchange all relevant manufacturing process information now and in the future.
[1] Schlenoff, C., Knutilla, A., Ray, S., Unified Process Specification Language:
Requirements for Modeling Processes: NISTIR 5910, 1996, National Institute of
Standards and Technology, Gaithersburg, MD.
[2] Knutilla, A., et al., Process Specification Language: An Analysis of Existing
Representations, NISTIR 6133, 1998, National Institute of Standards and Technology, Gaithersburg, MD.
[3] Genesereth, M., Fikes, R.: Knowledge Interchange Format (Version 3.0) - Reference Manual, 1992, Computer Science Dept., Stanford University, Stanford, CA.
[4] Catron, B., Ray, S., ALPS: A Language for Process Specification, Int J Computer Integrated Manufacturing, 1991, Vol 4, No 2, 105-113.
[5] Fox, M., et al, An Organization Ontology for Enterprise Modeling: Preliminary Concepts,” Computers in Industry, 1996, Vol 19, pp 123-134.
[6] Uschold, M., et al., “The Enterprise Ontology,” The Knowledge Engineering
Review, Vol 13(1), pp 31-89, Special Issue on “Putting Ontologies to Use,” (eds
Uschold, M and Tate, A.), Cambridge University Press
[7] Pease, A., Core Plan Representation (CPR), http://www.teknowledge.com/CPR2/, November 13, 1998.
In the article "Roots of SPAR – Shared Planning and Activity Representation," published in The Knowledge Engineering Review, Tate explores the foundational concepts of SPAR, emphasizing its role in enhancing collaborative planning and activity representation This work is part of a special issue focused on the practical applications of ontologies, edited by Uschold and Tate, and is available through Cambridge University Press For more information, visit the provided link.
The PIF Process Interchange Format and Framework, as discussed by Lee et al in their article published in The Knowledge Engineering Review, provides a structured approach for utilizing ontologies effectively This work, featured in a special issue edited by Uschold and Tate, emphasizes the significance of standardizing process interchange to enhance knowledge engineering practices.
[10] Workflow Management Coalition Members, Glossary: A Workflow Management Coalition Specification, Belgium, 1994.
[11] Uschold, M and Gruninger M., Ontologies: Principles, Methods, and Applications, Knowledge Engineering Review, 1996, Vol 11, pp 96-137.
[12] Reiter, R., The frame problem in the situation calculus: a simple solution
(sometimes) and a completeness result for goal regression, Artificial Intelligence and Mathematical Theory of Computation: Papers in Honor of John McCarthy, 1991, pages 418-440, Academic Press, San Diego.
[13] PSL Ontology – Current Theories and Extensions, http://www.nist.gov/psl/psl- ontology/, June 28, 1999.
[14] Hayes, P., A Catalog of Temporal Theories, Tech Report UIUC-BI-AI-96-01, 1996, University of Illinois.
[15] Smith, S.J.J., at al., Integrating Electrical and Mechanical Design and Process Planning, Proceedings of the IFIP Knowledge Intensive CAD Workshop, 1996, Carnegie- Mellon University (CMU)
[16] ISO 10303-1:1994, Product data representation and exchange: Part 1: Overview and fundamental principles.
[17] Extensible Markup Language (XML) 1.0, W3C Recommendation 10-February-
1998, http://www.w3.org/TR/1998/REC-xml-19980210.
[18] Resource Description Framework (RDF) Model and Syntax, W3C Recommendation
22 February 1999, http://www.w3.org/TR/REC-rdf-syntax/.
[19] Resource Description Framework (RDF) Schema Specification, W3C Proposed Recommendation 03 March 1999, http://www.w3.org/TR/PR-rdf-schema/.
[20] ISO 10303-11: 1994, Product data representation and exchange: Part 11: EXPRESS language reference manual
This article presents an example of a PSL exchange file, utilizing a KIF-like syntax for the completed pilot implementation Future iterations of the PSL specification will provide more comprehensive details regarding the syntax and grammar of the PSL exchange language, which may evolve to differ from KIF.
(doc make-gt350 "Make GT350")
(and (doc make-interior "Make Interior")
(forall (?a : (activation-of ?a make-interior))
(exists (?o1 : (instance-of ?o1 a002-bench)) (in ?o1 ?a)))
(and (duration make-interior 5) (beginof make-interior 7)))
(and (doc make-drive "Make Drive")
(forall (?a : (activation-of ?a make-drive))
(exists (?o1 : (instance-of ?o1 a003-bench)) (in ?o1 ?a))))
(and (doc make-trim "Make Trim")
(forall (?a : (activation-of ?a make-trim))
(doc make-chassis "Make Chassis")
(doc final-assembly "Final Assembly")
(doc make-harness "Make Harness")
(doc make-wires "Make Wires")
(doc assemble-engine "Assemble Engine")
(doc machine-block "Machine Block")
(doc change-mould "Change Mould")
(doc setup-furnace "Setup Furnace")
(doc analyze-metal "Analyze Metal")
(doc clear-cavities "Clear Cavities")
(doc setup-racks "Setup Racks")
(doc remove-racks "Remove Racks")
(doc batch-complete "Batch Complete")
(and (doc make-gt350-proc "Make GT350 Process")
(subactivity make-interior-1 make-gt350-proc)
(subactivity make-drive-1 make-gt350-proc)
(subactivity make-trim-1 make-gt350-proc)
(subactivity make-chassis-1 make-gt350-proc)
(subactivity final-assembly-1 make-gt350-proc)
(subactivity j2 make-gt350-proc) (subactivity j1 make-gt350-proc) (subactivity make-harness-1 make-gt350-proc)
(subactivity make-wires-1 make-gt350-proc)
(subactivity assemble-engine-1 make-gt350-proc)
(subactivity j4 make-gt350-proc) (subactivity j3 make-gt350-proc) (subactivity machine-block-1 make-gt350-proc)
(subactivity change-mould-1 make-gt350-proc)
(subactivity setup-furnace-1 make-gt350-proc)
(subactivity analyse-metal-1 make-gt350-proc)
(subactivity melt-1 make-gt350-proc)
(subactivity wait-1 make-gt350-proc)
(subactivity clear-cavities-1 make-gt350-proc)
(subactivity j8 make-gt350-proc) (subactivity j7 make-gt350-proc) (subactivity j6 make-gt350-proc) (subactivity j5 make-gt350-proc) (subactivity setup-racks-1 make-gt350-proc)
(subactivity pour-1 make-gt350-proc)
(subactivity remove-racks-1 make-gt350-proc)
(subactivity batch-complete-1 make-gt350-proc)
(idef-process make-gt350-proc))
"The occurrence of Make-Interior in the Dec-19 schematic")
(forall (?a : (activation-of ?a make-interior-1))
(forall (?a : (activation-of ?a make-interior-1))
(exists (?p : (activation-of ?p make-gt350-proc))
"The occurrence of Make-Drive in the Dec-19 schematic")
(forall (?a : (activation-of ?a make-drive-1))
(forall (?a : (activation-of ?a make-drive-1))
(exists (?p : (activation-of ?p make-gt350-proc))
"The occurrence of Make-Trim in the Dec-19 schematic")
(forall (?a : (activation-of ?a make-trim-1))
(forall (?a : (activation-of ?a make-trim-1))
(exists (?p : (activation-of ?p make-gt350-proc))
"The occurrence of Make-Chassis in the Dec-19 schematic")
(forall (?a : (activation-of ?a make-chassis-1))
(forall (?a : (activation-of ?a make-chassis-1))
(exists (?p : (activation-of ?p make-gt350-proc))
"The occurrence of Final-Assembly in the Dec-19 schematic")
(forall (?a : (activation-of ?a final-assembly-1))
(forall (?a : (activation-of ?a final-assembly-1))
(exists (?p : (activation-of ?p make-gt350-proc))
(exists (?p : (activation-of ?p make-gt350-proc))
(follows j2 final-assembly-1 make-gt350-proc)
(and (and_split j2 make-gt350-proc)
(subactivity make-drive-1 j2) (subactivity make-trim-1 j2)
(exists (?p : (activation-of ?p make-gt350-proc))
(and (and_split j1 make-gt350-proc)
(subactivity make-drive-1 j1) (subactivity make-trim-1 j1)
"The occurrence of Make-Harness in the Dec-26 schematic")
(forall (?a : (activation-of ?a make-harness-1))
(forall (?a : (activation-of ?a make-harness-1))
(exists (?p : (activation-of ?p make-gt350-proc))
"The occurrence of Make-Wires in the Dec-26 schematic")
(forall (?a : (activation-of ?a make-wires-1))
(forall (?a : (activation-of ?a make-wires-1))
(exists (?p : (activation-of ?p make-gt350-proc))
"The occurrence of Assemble-Engine in the Dec-26 schematic") (forall (?a : (activation-of ?a assemble-engine-1))
(forall (?a : (activation-of ?a assemble-engine-1))
(exists (?p : (activation-of ?p make-gt350-proc))
(exists (?p : (activation-of ?p make-gt350-proc))
(follows j4 assemble-engine-1 make-gt350-proc)
(and (and_split j4 make-gt350-proc)
(exists (?p : (activation-of ?p make-gt350-proc))
(and (and_split j3 make-gt350-proc) (subactivity j5 j3)
"The occurrence of Machine-Block in the Dec-27 schematic")
(forall (?a : (activation-of ?a machine-block-1))
(forall (?a : (activation-of ?a machine-block-1))
(exists (?p : (activation-of ?p make-gt350-proc))
(follows clear-cavities-1 machine-block-1 make-gt350-proc))
"The occurrence of Change-Mould in the Dec-1 schematic")
(forall (?a : (activation-of ?a change-mould-1))
(forall (?a : (activation-of ?a change-mould-1))
(exists (?p : (activation-of ?p make-gt350-proc))
"The occurrence of Setup-Furnace in the Dec-1 schematic")
(forall (?a : (activation-of ?a setup-furnace-1))
(forall (?a : (activation-of ?a setup-furnace-1))
(exists (?p : (activation-of ?p make-gt350-proc))
"The occurrence of Analyze-Metal in the Dec-1 schematic")
(forall (?a : (activation-of ?a analyse-metal-1))
(forall (?a : (activation-of ?a analyse-metal-1))
(exists (?p : (activation-of ?p make-gt350-proc))
(and (doc melt-1 "The occurrence of Melt in the Dec-1 schematic") (forall (?a : (activation-of ?a melt-1)) (activation-of ?a melt))
(exists (?p : (activation-of ?p make-gt350-proc))
(and (doc wait-1 "The occurrence of Wait in the Dec-1 schematic") (forall (?a : (activation-of ?a wait-1)) (activation-of ?a wait))
(exists (?p : (activation-of ?p make-gt350-proc))
"The occurrence of Clear-Cavities in the Dec-1 schematic")
(forall (?a : (activation-of ?a clear-cavities-1))
(forall (?a : (activation-of ?a clear-cavities-1))
(exists (?p : (activation-of ?p make-gt350-proc))
(exists (?p : (activation-of ?p make-gt350-proc))
(follows j8 setup-racks-1 make-gt350-proc)
(and (and_split j8 make-gt350-proc)
(subactivity analyse-metal-1 j8) (subactivity melt-1 j8)))
(exists (?p : (activation-of ?p make-gt350-proc))
(follows setup-furnace-1 j7 make-gt350-proc)
(and (and_split j7 make-gt350-proc)
(subactivity analyse-metal-1 j7) (subactivity melt-1 j7)))
(exists (?p : (activation-of ?p make-gt350-proc))
(follows j6 setup-furnace-1 make-gt350-proc)
(and (xor_split j6 make-gt350-proc)
(exists (?p : (activation-of ?p make-gt350-proc))
(and (xor_split j5 make-gt350-proc) (subactivity j6 j5)
(follows remove-racks-1 batch-complete-1 make-gt350-proc))
(and (doc l122 "L122") (follows pour-1 remove-racks-1 make-gt350- proc))
(and (doc l124 "L124") (follows setup-racks-1 pour-1 make-gt350-proc))
(follows batch-complete-1 wait-1 make-gt350-proc))
(follows wait-1 clear-cavities-1 make-gt350-proc))
"The occurrence of Setup-Racks in the Dec-1-1 schematic")
(forall (?a : (activation-of ?a setup-racks-1))
(forall (?a : (activation-of ?a setup-racks-1))
(exists (?p : (activation-of ?p make-gt350-proc))
(and (doc pour-1 "The occurrence of Pour in the Dec-1-1 schematic") (forall (?a : (activation-of ?a pour-1)) (activation-of ?a pour))
(exists (?p : (activation-of ?p make-gt350-proc))
"The occurrence of Remove-Racks in the Dec-1-1 schematic")
(forall (?a : (activation-of ?a remove-racks-1))
(forall (?a : (activation-of ?a remove-racks-1))
(exists (?p : (activation-of ?p make-gt350-proc))
"The occurrence of Batch-Complete in the Dec-1-1 schematic") (forall (?a : (activation-of ?a batch-complete-1))
(forall (?a : (activation-of ?a batch-complete-1))
(exists (?p : (activation-of ?p make-gt350-proc))
Appendix B: Mapping PSL Concepts to the EXPRESS
Mapping the PSL Ontology to EXPRESS
Within the architecture, there are five basic concepts; all the concepts in the EXPRESS
[20] presentation of PSL will fall into one (or possibly more, in the case of multiple inheritance) of these categories.
Entity activity defines a PSL activity specification, serving as a template for potential subactivity occurrences An activity is primarily characterized by its identity and a human-readable name, with minimal direct information associated with it Additional details are derived from the context of its occurrences and the relationships it maintains.
The entity occurrence refers to a specific instance of a PSL activity, ranging from abstract events that could occur at any unspecified time in the past, present, or future, to concrete events that take place at defined times and locations.
Occurrences represent specific instances of an activity specification and are always situated within the context of a broader activity Essentially, these occurrences are tied to subactivities of a higher-level activity By default, occurrences only include a human-readable name and do not contain additional information The relationships between occurrences of common subactivities are used to capture important details such as their ordering.
ENTITY occurrence; name : STRING; occurrence_of : activity; context : activity;
The entity relation serves as an abstract supertype within the PSL ontology, linking various concepts, primarily involving activities or occurrences For instance, it can represent the necessity for specific subactivities to occur in a designated sequence.
The entity object embodies the PSL concept of an object, encompassing anything that is not classified as an activity, occurrence, relation, or data value This includes physical items like an NC milling machine, individuals, and even abstract concepts such as facts pertaining to specific situations Furthermore, PSL allows for the refinement of the fundamental object concept through the use of subtyping extensions.
The fifth fundamental concept is the data value, which represents various numeric data types, such as time points and durations Data values are not standalone entities; they always appear as attributes of other concepts, typically within relations or more specific subtypes of activities, occurrences, or objects While the EXPRESS model does not formally relate the different concepts of data values, it is practical to consider them as interconnected.
TYPE timepoint = SELECT (finite_value, infinite_value);