RE: Re[2]: Wen to use resource instead of simple assignment

["Barker, Sean (UK)" <sean.barker@baesystems.com>]

Lothar,
	There are some old notes on this in PLCS DEXLIB under the
capability Task_association (though these were written before Task
became Task_method, and the original Task_method was renamed to
Task_element.
	Essentially, the associations are used to link to other things
which affect the task definition, but which do not provide resources for
the task. Examples include documents such as safety instructions and
training videos, or regulatory authorities who need to approve the work
being done.
	There is a second group of usages which are used to define the
usage of the task. For maintenance tasks, the major one is the
product-in-focus - that is, the statement that this task on this engine
is valid/controlled-as-part-of the XYZ aeroplane. Other constraints
include Location, for example, tasks specialised to Artic conditions.
	With regards the quantity or resources, not all resources are
incorporated into the product. Examples include cleaning materials, fuel
(where the task is prepare for operation), number of people required,
number or tools required, etc.
	Agreed there are too many names, but the modules must allow for
naming things, but do not enforce the population of names. I expect the
next generation of data modelling technology will resolve this issue.


Sean Barker
0117 302 8184

-----Original Message-----
From: Lothar Klein [mailto:lothar.klein@lksoft.com] 
Sent: 15 June 2006 11:41
To: Barker, Sean (UK)
Cc: Eva Miliuniene; Thomas E Hendrix; Tomas Baltramaitis;
plcs-dex@lists.oasis-open.org; leif.gyllstrom@combitech.se
Subject: Re[2]: Wen to use resource instead of simple assignment

Sean,

Thanks for your real quick reply.
Could you please add some argumentation why the task_xxx_assignments
where then included at all - or give some guidance for which cases to
use them.

One comment to your arguments:

> 1) To quantify the resource usage;

In the case of task related to an assembly activity, the quantity is
given with the Next_assembly_usage or the
Product_occurrence_with_quantity (depends on whether this is a
AP214-S3 or S7 like structure). So we don't want to repeat this
information and also directly want to point out the occurrence and not
only the Part (-version).

Another issue is that we have to deal with an inflation of names
(Resource_item.name, Required_resource.name in addition to the item
name) when using the resource stovepipe solutions and the users I know
don't have this many names at hand.

Lothar

--
// Lothar Klein, LKSoftWare GmbH
// Steinweg 1, 36093 Kuenzell, Germany
// +49 661 933933-0, Fax: -2
// mailto:lothar.klein@lksoft.com   http://www.lksoft.com

Thursday, June 15, 2006, 11:36:39 AM, you wrote:
> Lothar,

>         Well, your suggestion is theoretically possible, given the 
> right reference data - it depends what you want to achieve. There are 
> several reasons for using the resource approach:

> 1) To quantify the resource usage;
> 2) To provide a functional specification of resource usage;
> 3) To define an effectivity of a resource usage - given the mess that 
> is effectivity, we should only make that mess in one place;
> 4) To link resource usage to resource management;
> 5) To have a way of linking resource requirement to actual resource 
> usage.

> Since these are fairly major requirements for the support domain, PLCS

> will use the resource model. Consequently, not using the resource 
> model will either create stovepipe solutions - in which case the aim 
> of AP interoperability is ignored - or require translators to work 
> with both approaches, and so increate then cost of translators and 
> their verification.

> My guess is that the approach you suggest would probably result sooner

> or later in the AP being sidelined for niche applications, and either 
> a new version being created using Resource, or a new AP being produced

> with broader scope, but including Resource.

> Sean Barker
> 0117 302 8184

> -----Original Message-----
> From: Lothar Klein [mailto:lothar.klein@lksoft.com]

> Sent: 15 June 2006 09:10
> To: Barker, Sean (UK)
> Cc: Eva Miliuniene; Thomas E Hendrix; Tomas Baltramaitis
> Subject: Wen to use resource instead of simple assignment

>                *** 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.


> Sean,

> Maybe you can give us some input on a particular problem.

> We have tasks_methods and various task_elements and need to assign 
> several kinds of items to these task (e.g. consumables, machines, 
> human resources etc.). The big question is whether we have to go 
> through the resource pipeline (Required_resource_assignment, 
> Required_resource_by_resource_item, Resource_item) and only then end 
> on the items of interest or if we can simply use 
> Task_element_assignment, Task_method_assignment, or 
> Task_method_version_assignment and assign the needed items directly in

> a particular role. What is in your opinion the key point whether to 
> make something a resource and go the complicated path instead of
having the simple assignment?
> Note that AP214 UOF Process_plan is using the direct way.

> Lothar

> --
> // Lothar Klein, LKSoftWare GmbH
> // Steinweg 1, 36093 Kuenzell, Germany // +49 661 933933-0, Fax: -2 //

> url: http://www.lksoft.com




> ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************