Jump to: navigation, search

Difference between revisions of "MRO (Plugin)"


m
(See also)
 
(9 intermediate revisions by 3 users not shown)
Line 1: Line 1:
The MRO plugin provides a set of {{UBIK}} objects which allow to represent and document maintenance, repair and operations work on the mobile client.  
+
The MRO plugin provides a set of {{UBIK}} objects which allow to represent and document maintenance, repair and operations work on the mobile client. An respective implementation of this set of features is available on {{UBIK WinX}}.
  
== Status Information ==
+
== Basic Features ==
 
Objects classified as MRO objects in general provide a technical and organisational status as well as the overall work progress based on the underlying data branch.
 
Objects classified as MRO objects in general provide a technical and organisational status as well as the overall work progress based on the underlying data branch.
  
 
=== Technical Status ===
 
=== Technical Status ===
The technical status indicates whether all tasks from subsequent objects in the underlying data branch have been finished. Also other information is included in this status, e.g. if a inventory object is reported as damaged, its parent objects will receive a certaub status indicating that a problem was reported in the child items.
+
The technical status indicates whether all tasks on this or on subsequent objects in the underlying data branch have been finished. Also other information is included in this status, e.g. if a inventory object is reported as damaged, its parent objects will receive a certaub status indicating that a problem was reported in the child items.
  
 
=== Organisational Status ===
 
=== Organisational Status ===
The organisational indicates the amount of confirmed work done in the data branch. It can include a work package already confirmed or tasks that are already locked by their owning workpackage.
+
The organisational status indicates the amount of confirmed work done in the data branch. It can include a work package already confirmed or tasks that are already locked by their owning workpackage.
  
==Prerequisites==
+
=== Work Progress ===
[[File:UI_OPCUA_Certificate.png|border|thumb|Export Certificate]]
+
The work progress is calculated from the current work progress and from the progress cumulated from subsequent objects in the underlying data branch. This indicator shows the amount of work done in the data branch.
The {{UBIK}} OPC UA components are acting as an OPC Client, therefore a secure connection to the respective OPC Server needs to be established in order to be able to communicate. The security standards that need to be applied are highly dependent on the server configuration and security infrastructure, but normally at least a client certificate needs to be issued that has to be trusted by the server:
+
  
# Open a command box on the {{UBIK}} server with administrator privileges (''"Run as administrator..."'')
+
== MRO Objects ==
# Run the program ''CreateCertifcate.exe'' from the archive {{FileLink|CreateCertificate.zip|CreateCertificate.zip}}
+
A set of specific objects can be used to provide the required structure for MRO:
# Open the program ''Manage computer certificates'' (typically ''C:\WINDOWS\System32\certlm.msc'')
+
# Navigate to ''Personal - Certificates'' and find the certificate named ''UBIK OPCUA Interface''
+
# Export the certificate and trust it on your OPC server
+
  
=={{UBIK}} Activities==
+
=== Task Owner ===
{| class="wikitable sortable" | width = "50%"
+
A [[MROCLS_MRO_TASKOWNER|Task Owner]] is an object having a substructure of jobs to be done. It can have a tree of other task owners or work packages underneath that will update the status of the task owner. This status consists of technical, organisational and progress information. With a task owner a user can get an overview of all the work to be done in the underlying job structure.
|-
+
! Activity!! Category !! Purpose (Short)
+
|- align="left"
+
| [[Activity:CreateOPCUAConnection (Activity)|CreateOPCUAConnection]]|| UBIK OPC UA Interface  || Creates a new connection to an OPC UA data source
+
|- align="left"
+
| [[Activity:ConfigureOPCUAVariable (Activity)|ConfigureOPCUAVariable]]|| UBIK OPC UA Interface  || Configures a single OPC variable in a connection for later access
+
|- align="left"
+
| [[Activity:CreateOPCUAScope (Activity)|CreateOPCUAScope]]|| UBIK OPC UA Interface  || Defines a scope in an OPC UA connection wherein variables can be accessed
+
|- align="left"
+
| [[Activity:AccessOPCUAVariable (Activity)|AccessOPCUAVariable]]|| UBIK OPC UA Interface  || Reads or writes a single configured OPC UA variable
+
|- align="left"
+
|}
+
  
==Examples==
+
=== Work Package===
Download example workflow {{FileLink|OPCReadVariables.uwf|OPCReadVariables.uwf}} for use against the OPC Quickstart Data Access Server.
+
A [[MROCLS_MRO_WORKPACKAGE|Work Package]] is a collection of objects to collect and summarize other task owning objects, workpackages, or tasks. A simple workpackage has a certain amount of tasks that have to be finished in order to confirm the workpackage as done. More complex workpackages can also own other underlying workpackages that have to be confirmed.  Confirming a workpackage itself requires a progress of 100% of all related tasks, as well as 100% confirmed sub work packages.
 +
 
 +
=== Task ===
 +
A [[MROCLS_MRO_TASK|Task]] is an object reporting a certain progress to the owning workpackage. There are several specialized types of task objects. All kinds of tasks have a property called '''VALUE''' in common. It is very important, that this property is able to be validated. Therefore, a MetaAttribute (providing a validation timestamp by default) has to be attached on the used MetaProperty.
 +
 
 +
{{Attention|The MetaProperty ''VALUE'' has to use [[Attributes]] in order to be validated. Otherwise, the calculation of work progress will not be possible.}}
 +
 
 +
==== Measurement Task ====
 +
A [[MROCLS_MRO_MEASUREMENT_TASK|Measurement Task]] inherits from [[MROCLS_MRO_TASK|Task]] and documents a measured value (e.g. read from a pressure gauge). Once a value has been entered, the task is finished. Alternatively, the task can also be closed by the option ''Not Applicable'' to document the situation of not being able to fullfill the measurement (e.g. the pressure gauge is broken).
 +
 
 +
==== Progress Task ====
 +
[[MROCLS_MRO_PROGRESS_TASK| Progress Task]] inherits from [[MROCLS_MRO_MEASUREMENT_TASK|Task]] and reports a certain progress while fullfilling a task. The progress will influence the overall progress of the owning workpackage. If the task cannot be fullfilled, it can also be finished with the option ''Not Applicable''.
 +
 
 +
==== Check Task ====
 +
[[MROCLS_MRO_CHECK_TASK|Check Task]] inherits from [[MROCLS_MRO_TASK|Task]] and is finished by reporting ''Done'' or ''Not Applicable''. This is intended for a simple To-Do task that is either done or not.
 +
 
 +
[[Category:Module|MRO (Plugin)]]
 +
 
 +
==== Inspection Task ====
 +
A [[MROCLS_MRO_INSPECTION_TASK|Inspection Task]] inherits from [[MROCLS_MRO_TASK|Task]] and is finished, when the user reports with a positive or negative answer or ''Not Applicable'' (e.g. reporting a yes/no answer for existing equipment).
 +
 
 +
[[Category:Module|MRO (Plugin)]]
  
 
== See also ==
 
== See also ==
Line 46: Line 51:
 
* [[MROCLS_MRO_CHECK_TASK#Check Task]] (Classification)
 
* [[MROCLS_MRO_CHECK_TASK#Check Task]] (Classification)
 
* [[MROCLS_MRO_INSPECTION_TASK#Inspection Task]] (Classification)
 
* [[MROCLS_MRO_INSPECTION_TASK#Inspection Task]] (Classification)
* [[MRO_Objects_(UBIK_WinX)]]
+
* [[MROCLS_SEQUENTIALTASK]] (Classification)
 +
* [[MROCLS_GROUPEDTASK]] (Classification)
 +
* [[MROCLS_PROJECT]] (Classification)
 +
* [[MROCLS_PROJECTINFORMATION]] (Classification)
 +
* [[MRO_Objects_(Client)]]
 +
 
 +
[[Category:Module|MRO (Plugin)]]

Latest revision as of 11:40, 10 July 2024

The MRO plugin provides a set of UBIK® objects which allow to represent and document maintenance, repair and operations work on the mobile client. An respective implementation of this set of features is available on UBIK® WinX.

Basic Features

Objects classified as MRO objects in general provide a technical and organisational status as well as the overall work progress based on the underlying data branch.

Technical Status

The technical status indicates whether all tasks on this or on subsequent objects in the underlying data branch have been finished. Also other information is included in this status, e.g. if a inventory object is reported as damaged, its parent objects will receive a certaub status indicating that a problem was reported in the child items.

Organisational Status

The organisational status indicates the amount of confirmed work done in the data branch. It can include a work package already confirmed or tasks that are already locked by their owning workpackage.

Work Progress

The work progress is calculated from the current work progress and from the progress cumulated from subsequent objects in the underlying data branch. This indicator shows the amount of work done in the data branch.

MRO Objects

A set of specific objects can be used to provide the required structure for MRO:

Task Owner

A Task Owner is an object having a substructure of jobs to be done. It can have a tree of other task owners or work packages underneath that will update the status of the task owner. This status consists of technical, organisational and progress information. With a task owner a user can get an overview of all the work to be done in the underlying job structure.

Work Package

A Work Package is a collection of objects to collect and summarize other task owning objects, workpackages, or tasks. A simple workpackage has a certain amount of tasks that have to be finished in order to confirm the workpackage as done. More complex workpackages can also own other underlying workpackages that have to be confirmed. Confirming a workpackage itself requires a progress of 100% of all related tasks, as well as 100% confirmed sub work packages.

Task

A Task is an object reporting a certain progress to the owning workpackage. There are several specialized types of task objects. All kinds of tasks have a property called VALUE in common. It is very important, that this property is able to be validated. Therefore, a MetaAttribute (providing a validation timestamp by default) has to be attached on the used MetaProperty.

IC Attention.pngThe MetaProperty VALUE has to use Attributes in order to be validated. Otherwise, the calculation of work progress will not be possible.

Measurement Task

A Measurement Task inherits from Task and documents a measured value (e.g. read from a pressure gauge). Once a value has been entered, the task is finished. Alternatively, the task can also be closed by the option Not Applicable to document the situation of not being able to fullfill the measurement (e.g. the pressure gauge is broken).

Progress Task

Progress Task inherits from Task and reports a certain progress while fullfilling a task. The progress will influence the overall progress of the owning workpackage. If the task cannot be fullfilled, it can also be finished with the option Not Applicable.

Check Task

Check Task inherits from Task and is finished by reporting Done or Not Applicable. This is intended for a simple To-Do task that is either done or not.

Inspection Task

A Inspection Task inherits from Task and is finished, when the user reports with a positive or negative answer or Not Applicable (e.g. reporting a yes/no answer for existing equipment).

See also