Activity Modeling

latest update: 2015-09-29    

Introduction

This topic deals with activity modeling. Activity models are used to describe processes and also human activities in and around a plant, such as maintenance.

The Ur-model is the old IDEF0 model:

IDEF0 Model

This useful model is, however, too limited in expressivity. The activity model of ISO 15926 has enough expressivity for lifecycle information integration. In its basic form it looks like this:

Basic ISO 15926 Activity Model

The four relationships are:

  1. Participation - a subtype of CompositionOfIndividual that indicates that a PossibleIndividual is a participant in an Activity. EXAMPLE - Pump P-101 is participating in the Activity 'Pumping Boiler Feed Water to Boiler E-103' in the Role of 'Performer' of that Activity. (where the information about that Role comes from is discussed below).
  2. InvolvemenByReference - a Relationship that indicates that a Thing is referred to in an Activity and is not directly participating in that Activity. EXAMPLE A welding specification is involved-by-reference in the welding of a nozzle to vessel V-101.
  3. CauseOfEvent - a Relationship that indicates that the caused Event is caused by the causer Activity. EXAMPLE The relation that indicates that the tanker loading Activity caused the Event described as 'tank liquid level full'.
  4. Recognition - a Relationship that indicates that a Thing is recognized through an Activity. EXAMPLE Measurement activity #358 recognizes that the room is a member of the Property that is quantified as '20 degrees Celsius'. NOTE - In Part 2 the model shows 'Thing', but this incorrect as can be derived from the example given for ClassOfRecognition: EXAMPLE A measurement activity may result in the recognition of the Classification of a PossibleIndividual by a Property. This means that we recognize a state of that individual.

Detailed discussion

General

In general the following applies:

  • An Activity can be defined with a PROCEDURE, METHOD, ALGORITHM, or STRATEGY, or a combination thereof;
  • In an Activity one or more RULEs of some kind can be involved by reference;
  • An object participates in an activity in a defined role;
  • The BEHAVIO(U)R  of that object in that role is defined by a ClassOfFunctionalMapping that can take the form of a COMBINATORIAL LOGIC FUNCTION or MATHEMATICAL FORMULA.
  • An Activity is the resultant of the interaction between the applicable BEHAVIO(U)Rs of the participating objects.

Definitions

ALGORITHM - A self-contained step-by-step set of operations to be performed.

BEHAVIO(U)R - A specific response of a certain organism to a specific stimulus or group of stimuli.

COMBINATORIAL LOGIC FUNCTION - A concept in which two or more input states define one or more output states, where the resulting state or states are related by defined rules that are independent of previous states. Each of the inputs and output(s) can attain either of two states: logic 0 (low) or logic 1 (high).

MATHEMATICAL FORMULA - A rule or principle, expressed in an equation or a set of instructions that solves a certain type of problems in a prescribed manner. In a formula, the same set of inputs always produces the same output(s).

METHOD - An established, habitual, logical, or prescribed practice or systematic process of achieving certain ends with accuracy and efficiency, usually in an ordered sequence of fixed steps.

PROCEDURE - An orderly, logical, or systematic set of instructions to be followed in solving a problem or accomplishing a task.

RULE - A statement that establishes a principle or standard, and serves as a norm for guiding or mandating action. Rules are commonly published as recommended practices that allow some discretion with their interpretation and use.

STRATEGY - A plan of action designed to achieve a long-term or overall aim.


Participation

First a bit of filosophy: The reason why Participation is a subtype of CompositionOfIndividual is that an Activity can be seen as the result of an interaction between the behaviours of the participating individuals. That is why Activity is in the role of 'whole' and each participating individual, with its relevant behaviour, in the role of 'part'.

The participation model at class level, in the form of the applicable template, is shown below:

ClassOfParticipation

An instance of ClassOfParticipation is defined in this template and made explicit by means of the signature role 'hasDefined'. This is a case where the relationship at class level has to be made explicit in order to define the relationship at individual level. The reason is that in above template the role in which is being participated is defined. Therefore the template at individual level is as follows:

Participation

In this case the Particpation relationship is classified with the ClassOfParticipation instance at class level. That tells that Stream N-83 participates in the Role of 'PUMPED' (that explicit role name can be fetched with a SPARQL query).

It is also possible to further specialize the template at class level in order to define your design. Then PUMPING is specialized to PUMPING STREAM CLASS CO_N-83 and the STREAM CLASS is specialized to STREAM CLASS CO_N-83. This is the normal procedure of defining your design.  The Participation relationship at individual level is then classified with the instance of ClassOfParticipation in that design template.


InvolvementByReference

Things can be involved in an Activity without participating in its, i.e. without their behaviour playing a role. A good example for that is the involvement by reference of rules and regulations, progress reports, supervision, etc.

The involvement-by-reference model at class level, in the form of the applicable template, is shown below:

ClassOfInvolvementByReference

An instance of ClassOfInvolvementByReference is defined in this template and made explicit by means of the signature role 'hasDefined'. This is a case where the relationship at class level has to be made explicit in order to define the relationship at individual level. The reason is that in above template the role in which is being involved-by-reference is defined. There are two templates at individual level (of the Activity), one for the involvement of an individual, and one for the involvement of a class:

and

In these cases the InvolvementByReference relationships are classified with the ClassOfInvolvementByReference instance at class level. That tells that, in the lower example, Welding Instruction 12345 is involved-by-reference in the Role of 'Instruction' in the welding of line RZ17801 (that explicit role name can be fetched with a SPARQL query).


CauseOfEvent

An Activity can cause some Event, and that Event can be the beginning or the end of some Individual (bumping in a brick wall can cause the end of the driver). In short: cause and effect.

The models for ClassOfCauseOf(Event) and CauseOfEvent are not, like other releationship, similar.

The cause-of-event model at class level, in the form of the applicable templates, are shown below:

whereas for individuals these templates are:

Some things shall be noted here:

1) The relationship CauseOfEvent is uninformative, unless it is classified by either an instance of ClassOfCauseOfBeginningOf ClassOfIndividual or ClassOfCauseOfEndingOfClassOfIndividual;

2) These templates can only apply to instances of WholeLifeIndividual, since temporal parts thereof are not made explicit in the various template signatures, so we can't address them.

There are more templates with variations on the theme.


Recognition

Recognition is somewhat problematic. That already starts with the definition of the word in the various dictionaries. We use here the following definition: "Recognition is the result of deductive observation of some information". That information is represented by a template instance. So we get the following template:

and for an individual:

Note that the relationship Recognition is uninformative, unless it is classified by either an instance of ClassOfRecognition, that is defined above.