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:
- 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);
- 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;
- 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';
- 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;
- A PhysicalObject participates in an Activity in a defined Role;
- An Activity is the resultant of the interaction between the applicable BEHAVIO(U)Rs of the participating objects;
- The BEHAVIO(U)R of that object in that Role is defined by a ClassOfFunctionalMapping that can take the form of a BOOLEAN LOGIC FUNCTION or MATHEMATICAL EQUATION.
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:
EndedParticipationOfIndividualInActivity
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.
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
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:
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.