Templates for Activity

latest update: 2018-12-26    

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:


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

Actually we needed an explicit ClassOfParticipation in order to classify the Participation relationship for an individual PhysicalObject. But modelingwise reference should have been made to the ParticipatingRoleAndDomain, and that is unpractical because it would lead to combinatory explosion in the RDL. So it has been decided to address the defining Role and ClassOfPhysicalObject.

Therefore the template at individual level is as follows:

ParticipationInActivity

That tells that VESSEL V-101 participates in the Role of 'TESTED OBJECT'

It is also possible to further specialize the template at class level in order to define your design.


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

Here again the same rational as above for Participation applies.

Therefore the template at individual level is as follows:

Individual is involved-by-reference in Activity

and

Class is involved-by-reference in Activity

 


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:

and:

Some things shall be noted here:

  • The models at Class level and at Individual level are not mirror image because ClassOfTemporalBounding is missing in Part 2..
  • The relationship CauseOfEvent is uninformative, unless it is classified by either an instance of ClassOfCauseOfBeginningOf ClassOfIndividual or ClassOfCauseOfEndingOfClassOfIndividual;
  • 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.