Templates for Activity

latest update 2022-04-11


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


In general the following applies:


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:


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:


That tells that PROCESS LINE RZ17801 participated in the Role of 'HYDROSTATICALLY TESTED OBJECT'

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


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:


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

Class is involved-by-reference in Activity


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:

There are more templates with variations on the theme.


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.