From: Peter Bergström
[mailto:peter.bergstrom@eurostep.com]
Sent: 09 January 2007 10:49
To: plcs-dex@lists.oasis-open.org
Subject: [plcs-dex] Reporting
activities
|
*** WARNING ***
This mail has originated outside your organization,
either from an external partner or the Global Internet.
Keep this in mind if you answer this message.
|
There are two capabilities (at least) that cover the
reporting of activities using Activity_actual, Representing_activity and
Representing_work_done. When working with templates in this area, I’ve
found that there is reason to separate two types of activity reports, for
maintenance activities and operational activities. Theoretically we might need
something for design (or production) activities as well, but I don’t know
how far we should take this.
Activity_actual’s for maintenance always have a relation
to directed_activity, they have inputs (PAI or PAR) and sometime outputs (PAR).
It is sometimes important to see the status of the activity, i.e. how far into
completion is it. They may also be used to track configuration changes. They
typically have both a start_date and an end_date, but the end_date must be
optional. A Directed_activity has an Approval, but an Activity_actual does not
(it is a report of what was done). Activity_actuals probably have a responsible
or executing organization assigned to it, and it may be further characterized.
Activity_actual’s for operation may have a relation to
a planned activity, but not to a Directed_activity (which always is accompanied
by a Work_order). They always have a relation to one product (PAI), which is the
product used, and there is no input or output. They have at least a start_date,
and optionally an end_date. An operational Activity_actual could have an
Approval assigned to it, if the usage of the product requires an approval.
However, I would prefer to assign the approval to a planned Activity in that
case (using Activity instead of Activity_actual).
The biggest reason for separating out maintenance from
operation is however that business people work in either domain, and they have
probably difficulties in understanding how a generic capability should be used,
if it is explained to cover both aspects.
I propose to do the following, based on the above:
1. make sure that capability Representing_work_done is
described as valid for Maintenance (and design), and develop the template
representing_work_done.
2. Make sure to make distinctions in cap
Representing_activity between Maintenance activities and Operational
activities, and rename the template representing_activity_actual into
representing_product_usage, and pointing to repr_work_done for maintenance (and
design) activities.
3. Develop a template representing_planned_activity within
cap Representing_activity based on entity Activity, that covers the needs for
operational planning of activities where no Work_order is used.
4. Develop a template representing_typical_activity within
cap Representing_activity based on entity Activity_method, to meet the business
requirement to be able to set up typical activities or missions within
operation. This would be similar to ‘tasks’ for maintenance
activities.
Before I do this I would like to have your input on my
thoughts, especially from projects with operational needs. The alternative to
the above is to make generic capabilities and templates that covers both design,
maintenance and operation, and I think they would be quite complicated to sort
out.
Peter
This message contains information that may be privileged or
confidential and is the property of Eurostep Group. It is intended only for the
person to whom it is addressed. If you are not the intended recipient, you are
not authorized to read, print, retain, copy, disseminate, distribute, or use
this message or any part thereof. If you receive this message in error, please
notify the sender immediately and delete all copies of this message.