Verification-Oriented Process Ontology

This paper presents the ontology of the concurrent processes close to Hoare communicating sequential processes. It is a part of an intellectual system for supporting verification of behavioral properties of such processes. Our ontological representation of the processes is oriented both to the application of formal verification methods and to the extraction of information from technical documentation (by our previously developed system of information extraction from a natural language text). We describe the ontology classes and domains that define communicating concurrent processes. These processes are characterized by sets of local and shared variables, a list of actions on these variables which change their values, a list of channels for the process communication (which, in turn, are characterized by the type of reading messages, capacity, modes of writing and reading, and reliability), and also a list of communication actions for sending messages. In addition to the formal mathematical definition of classes and domains of the ontology, examples of descriptions of some ontological classes, as well as typical properties and axioms for them, are specified in the editor Protégé in the OWL language with the use of the inference rules in the SWRL language. We define the formal operational semantics of communicating processes for their ontological representation. This semantics is a labeled transition system. It is reduced to the local operational semantics of separate process instances in the interleaving model. We specialize several types of processes from the subject domain of automatic control systems that model the typical functional elements of the automatic control system (sensors, comparators and regulators), as well as their combinations. The concepts of the specialized ontology are illustrated by the example of a control part of a bottle-filling system.


INTRODUCTION
Our long-term goal is a development of an integrated approach to ensuring the quality of systems of communicating sequential processes (further referred to as process systems) using formal methods, which includes extracting formal models and system properties from technical documentation texts, as well as verifying them. Our approach is focused on the use of model checking (and later deductive methods as well) as a means of formal verification. The disadvantage of the existing systems for supporting the development and verification of requirements is that they only offer a manual formulation of requirements and descriptions of the process systems [1,15,19,20].
The intelligent tool that we develop for formal verification of process systems will automatically extract and generate both the formal system description and requirements for the system. In this paper, we offer an ontology of process systems. Another key component of the system is the ontology of requirement patterns proposed in [5]. The content of these ontologies, i.e., the set of instances of their classes, are ontological descriptions of a certain system of processes and requirements for it. These descriptions are extracted from the corpus of technical documentation using our methods of information extraction from natural language texts [2][3][4]. The set of requirement descriptions can also be extended with descriptions of typical correctness requirements automatically generated from the ontological description of the system.
Ontological descriptions of the system and requirements are the basis for the formal verification. In order to verify a system of processes, it is necessary first to select a suitable verifier based on model checking, taking into account the formal semantics of the ontological presentation of ontology requirements. If such a verifier exists, the ontological description of the system is translated into the model specification language, and the description of the requirements into the property specification language (usually the language of temporal logic), which are the input languages of this verifier. If there is no suitable verifier, it is reasonable to develop a special verifier of requirement patterns based on the formal semantics of the corresponding ontology, which would use specialized simplified verification algorithms. If the semantics of the ontological representations of the system model and requirements for it, as well as the input languages of the verification tool, are strictly defined and the correctness of translation of these representations into the verifier input data is ensured, the correctness of the requirement verification is guaranteed.
Working with requirements deals not only with the formal semantics of requirement patterns, but also with the representation of these patterns both in natural language and in graphical form. These representations are important, since, due to the ambiguity of natural language, the extracted and generated requirements may not meet the expectations of the requirement engineer and may need to be manually adjusted. Ontologies of process systems and requirement patterns with their formal semantics are the basis for the development of a formal verification support system. Our approach allows modeling and verifying a wide range of systems: from software distributed systems to business processes. The main limitation of the approach is the complexity and, at times, impossibility of accurate extraction of information from technical documentation, and the extracted system models and requirements may require manual correction.
Our process system ontology defines a set of processes. The known approaches to the ontological description of processes usually solve modeling problems. The PSL [16], Cyc [18], SBPM [6,7] and GFO [9] ontologies focus on production planning, process planning, workflow management, business process reengineering, simulation, process implementation, process modeling, and project management. An important advantage of these approaches is that they take into account the concepts of subject domains when describing production, engineering, and business processes. Specifying the time and place of events and actions associated with these processes, in some of these approaches, makes it possible to describe planning ontologies that represent abstract and executable plans of process organization, which is another advantage. However, these advantages make it very difficult to verify the logic of the behavior of the processes underlying these ontologies. The close relationship of subject-oriented concepts with the logic of the behavior of processes leads to the complication of extracting the latter for use in verification systems based on model checking. Moreover, the extracted logic of behavior should still be translated into the language of the verification system; this language is based, as a rule, on transition systems that work with the concepts of state and transition. In particular, for planning ontologies, one should know how to express the specific time and place of events and actions in terms of states. In addition, these ontologies do not have formal semantics for the logic of the behavior of processes, which further complicates the task.
In Section 1 of this paper, we define ontological classes and domains that characterize the communicating processes of the system as a whole. In Section 2, we give the formal semantics of these classes, including their representation in the OWL (Web Ontology Language [13]) and the operational semantics of the actions of the system processes. The syntax of ontology representation languages, in particular, the OWL, is declarative, but the strictly defined operational semantics of our ontology make it easy to translate the representation of the process model into the input languages of verification tools, in particular, SPIN [11]. Section 3 outlines the methodology for using our ontology of abstract process systems for the specification of some components of automatic control systems (ACS). Section 4 contains the conclusions and plans for the development and use of the ontology of processes.

ONTOLOGY
We consider an ontology as a structure that includes the following elements: (1) a finite nonempty set of classes, (2) a finite nonempty set of data attributes and relation attributes, and (3) a finite nonempty set of domains of data attributes. Each class is defined by a set of attributes. The data attributes take values from domains, and the values of the relation attributes are the instances of classes. An instance of a class is defined by the set of attribute values for this class. The information content of the ontology is a set of instances of its classes. The ontology population problem is to extract the information content of this ontology from the input data. In our case, the input data for populating the ontology of process systems is technical documentation. To populate this ontology, we use our methods of semantic information extraction from natural language texts [3]. It should be noted that some attribute values of extracted instances of ontology may be undefined. The set of instances of our ontology describes the process system. We consider a system of communicating sequential processes similar to Hoare's CSP [10]. The processes (described by the class Process) are characterized by sets of local and shared variables, a list of actions on these variables that change their values, a list of process communication channels, and a list of communication actions for sending messages. The process variables (class Variable) take values of basic types (Boolean, finite subsets of integers or strings for enumerated types). The initial conditions for the values of the variables are determined by comparing them with constants. The actions of processes (class Action) include basic operations on basic types. The enable condition of each action depends on the guard conditions (class Condition) for the values of the variables and the contents of the sent messages. The processes can send messages through channels (class Channel) when the guard conditions are satisfiable (class Condition). The channels are characterized by the type of message reading, capacity, modes of writing and reading, as well as reliability. In Fig. 1, the classes are shown with white ovals. The relationship between the classes is indicated by the arrows with names in gray ovals. These arrows are drawn with solid lines if the relationship is one-to-many and dashed lines if the relationship is one-to-one. The data attributes of the class placed in dash-dotted rectangles are linked to their classes by dash-dotted arrows.
In the following sections we describe in detail the classes and domains of our ontology and define their formal semantics. We will also give examples of descriptions of some ontological classes, their properties and axioms specified in the Protégé editor [14] by means of the OWL using the SWRL (Semantic Web Rule Language) inference rules [12]. These properties and axioms define the rules for the consistency of the values of attributes of different classes, as well as restrictions on the values, number, and type of the attributes of a particular class. We will list several typical properties and axioms for some classes. Using the SWRL rule set, we specify the conditions that ensure in Protégé the inference of new knowledge and the verification of the correctness and compatibility of the ontological description of the set of processes using the Hermit inference engine [8].

FORMAL SEMANTICS OF THE ONTOLOGY
We consider a concurrent system, which is a set of sequential processes that interact through shared variables and channels of finite capacity. The values of shared and local variables associated with a process define its local state. Depending on the subject domain, the features of interaction between processes (synchronous, asynchronous) and channel characteristics (FIFO, LIFO, reliable, limited, etc.) are specified. The states of the channel are defined by the set of messages stored in it.
The ontological description of the process system is a set of ontology instances that represent processes, channels, and other elements of the system . We define the operational semantics for using the standard model of labeled transition systems , where is the finite nonempty set of states, is the nonempty set of initial states, is the transition relation between states, and is the finite set of transition labels describing the actions of the system. The semantics of the model of the . Let for be the content of the th message of the channel in the state . The initial state of all channels is an empty tuple. The set of states of the system is a Cartesian product of the values of local and shared variables of the processes and states of the channels. The set of initial states is a Cartesian product of the initial states of the variables of the processes and states of the channels. We assume that the operational semantics of the system is the interleaving semantics; i.e., its state can be changed only by one process of the system. Therefore, the set of the system actions is . Due to the interleaving, the transition relation is specified by the local operational semantics of individual instances of the processes , which is defined further. Let us describe the classes of our ontology. Further, for all classes, the attribute Name String specifies the name of the class instance. The attribute names with multiple values end with a character *. The class Process describes the system processes using the following attributes: -Type: {sensor, valve, ...} String contains the process specifier. -: lists the variables visible only in the actions of the processes. -: lists the variables visible to the processes sharing them. -: lists the actions of the process on its variables. -: lists the channels connecting the processes. -: lists the actions that send messages.
In this class, it is not necessary to specify the values of all attributes. However, if and are not specified, the value of is also not specified. If the value of is not specified, the value of is also not specified. If the value of is specified, then or should be determined. If neither , nor , nor values are specified for the process, this passive process is considered an object. It is convenient to distinguish such objects for clarity of the description of the system and validation of its ontological consistency; however, in the process of formal verification, the properties of the objects' behavior are not formulated or checked. Figure 2 illustrates a hierarchy of classes of the process ontology and a fragment of the description of the class Process made using the Protégé editor. To the left, the "Class hierarchy" tab shows the hierarchy of the classes defined in the ontology. The tab "Usage: Process" for a selected class in the hierarchy describes a list of its properties and relations with other classes and ontology instances defined by attributes. For example, for the class Process, the fragment of the list contains the name of the process Name-Process, relations with variables and actions (localVar, actions, comActions), as well as relations with the classes Channel, ComAction, and Variable, which are specified in Process with the corresponding attributes fromChannel, fromComActions, and owner. The tab "Description: Process" shows additional class characteristics. For the instances of the class Process, the requirements for the number of concepts associated with this class are defined by setting restrictions on the relation attributes: assigning exactly one name nameProcess and process type typeProcess. In addition, using the following SWRL rules, one can specify the requirement of the actions a or communication actions ca of the process p being defined if the channel ch of this process is defined: For the process , formal operational semantics of its ontological description is defined by the formal semantics of the ontological description of its attributes: local variables , shared variables , actions , communication actions , and channels . The process can be uniquely represented in through these semantics. Let us define the following sets for the process : , , , , . Further, we sequentially define the semantics of these attributes. The class Variable describes the process variables using the following attributes: -Type: Domains describes the type of the variable. -: refers to the processes that have access to the variable. The values of all attributes of this class except must be specified. Below is a fragment of the OWL description of the localVar relation in Turtle format. In this example, for the relation attribute localVar, the inverse functionality property InverseFunctional-Property ensures that the variable Variable is local for only one process Process: The semantics of the variable v of the process is set as follows: String, Domains, . If   -Head: the message index after reading becomes equal 1; -Some: the message index after reading becomes arbitrary. The values of the attributes and must be specified. We set the following attribute values by default: Type = FIFO, Capacity = 1, Write = NSent, Read = Del, Reliable = . If the channel has a process in the attribute or , this channel should be in the attribute of this process.
The semantics of the channel of the process is defined as follows: String, , and . The semantics of the local states of the channel and their changes is defined further in the descriptions of the classes of actions and communication actions.
The class Action describes the action performed by the process.
-: points to the process that performs the action. -: refers to the variable whose value may change as a result of the action. -: describes the expression whose value is assigned to the variable from . -: describes a Boolean formula that sets the condition for performing the action in the local state.
The values of the attributes , , and must be specified. If is not specified, this means that the action can be performed in any local state of the process. The values of the attributes and can only use the variables of the process and messages from its channels. That is, if the variable is used in the expressions from and (possibly at some nesting level), this variable must be present in the attributes or of this process . If the content of the channel is used, this channel must be in the attribute of this process. The following SWRL rule specifies the requirement that if the attribute what of the action a of the process p includes the variable v, its attribute owner includes p: Let us define the semantics of the action of the process . Obviously, String, , and . Let be the variable that should be changed by the action , and are the process channels, the messages from which are read by the action. The transition relation between the local states of the process and its channels is defined as follows. If the local states of the process and of each channel are such that the condition is satisfied ( ), and the action expression has the value ( ), then after the action is performed, the new local states of the process and its channels are such that , and the new state of each channel from corresponds to the semantics of the read operation for the channels (see the next section). It should be noted that in the process of calculating and , the states of the channels do not change. If or , all states remain unchanged: and . The class Expression describes expressions whose values are assigned to the process variables as a result of actions, and contains the following attributes.   describes the guard condition for sending a message. It should be noted that our process interaction model implements the receiving of messages as needed, i.e., reading from the channel is performed only when the process computes a guard condition or action expression. The values of the attributes , , and must be defined. If is not specified, this means that the communication action can be performed in any local state of the process . The values of the attributes and can only use the variables of the process and messages from its channels. If the content of the channel is used, this channel should be in the attribute of this process.
The semantics of the action of the process that sends a message in the state is defined as follows: String, , and . Let be the process channel for sending the message, is its local state, and are the process channels from which the message is read. Let , and . The local operational semantics of sending messages is defined as follows. The local states of the process and unused channels do .  -Some, then , . If the local semantics of actions and communication actions of each process is known, the transition relation can be uniquely determined.

ONTOLOGICAL MODELING OF FUNCTIONAL ELEMENTS
OF THE AUTOMATIC CONTROL SYSTEM In this section, we model some typical functional elements of an ACS (sensors, comparators, and regulators) in our ontology and present an illustrative example of ontological modeling of an ACS. The state of the control object that is controlled by the ACS is characterized by the state variables, i.e., quantitative characteristics that change over time.
The sensor monitors the change of some state variable and sends information to other ACS elements. The sensor is modeled in the ontology by the process with the following properties. The attribute Type of this process is set to sensor. The attribute contains the variable which models the state variable monitored by the sensor. The attribute contains actions to transmit the value of the variable through the channels contained in the attribute . The comparator compares the value of its input parameter with a certain reference value. The comparator is represented in the ontology by the process with the following properties. The attribute Type of this process is set to comparator. The attribute contains the channels for transmitting the result of comparing the value of the input parameter with the reference value, as well as the channels through which the process receives the values of the input parameter. The attribute contains the actions for calculating the result of comparison and its transmission over channels.
The sensor-comparator, which combines the functions of a sensor and a comparator, is modeled in the ontology by the process whose properties combine the properties of the processes that represent the sensors and comparators. The attribute Type of this process is set to sensor-comparator. Since such a sensor itself monitors the value of the state variable, there is no need for special channels to transmit this value.
The regulator maintains some given characteristic of the control object. It directly affects the state of the control object, changing its variables in accordance with the values of the input parameters of the regulator. The modeling of a regulator in the ontology depends on the number of modes of its operation (for example, "on" and "off"). The ontological representation of the regulator with the number of operating modes is set by the process with the following properties. The attribute Type of this process is set to regulator. The attribute contains the variable , which models the modes of operation and takes the values of an enumerated type consisting of elements. The attribute contains the variables that model the control object variables that are affected by the regulator. The attribute contains channels through which the process receives the values of the input parameters of the regulator. The attribute contains actions that modify shared variables. The expressions that are set by the attribute of these actions and calculate new values of the specified variables depend on the value of the local variable and messages containing the values of the input parameters of the regulator. To illustrate how an ACS is modeled in our ontology, we present a subsystem of the bottling system from [17] described in a natural language. We consider the following simplified subsystem: the sensors of '  low and high liquid level are set by the processes and ; the inlet and outlet valves are set by the processes and . We assume that all channels are FIFO with a capacity of 1, and messages are deleted after reading. The low level sensor is modeled by the process = (Type: sensor-comparator,  :  ,  : , : ). The variable sets information on the current level of liquid. It takes integer values from to , where the constants and denote the levels when the tank is almost empty and when it is overfilled. The channels and connect the sensor with the valves and , respectively. The communication action sends the message "toOpen" to the inlet valve when the tank is almost empty: ( : , : , "toOpen", : ). The communication action is defined in a symmetrical manner.
The inlet valve is modeled by the process = (Type: regulator "toOpen"). The valve-closing action is defined symmetrically. The processes and are defined in a similar way.

CONCLUSIONS
In this paper, we present an ontology of process systems, which is one of the basic components of an intelligent verification support system. Our methods for information extraction from the technical documentation texts allow to populate this ontology with instances of processes that are found in these texts. The translation module should then translate the ontological representation of the system into the input language of a verifier. In order to ensure the correctness of translation and further verification, in this paper we define the formal semantics of our ontology by linking the labeled transition system by a set of rules with a set of process instances from the ontology. The formal semantics of the ontological representation of processes oriented to formal verification methods distinguishes our approach from other contemporary approaches to defining the processes ontologies.
In future, we intend to develop systems of ontological process patterns for various subject domains : automatic control systems, business processes, etc. As part of constructing our intelligent verification support system, we will also develop a method for extracting typical system requirements from an ontological representation of processes to populate the ontology of requirements.