MRO (Plugin)
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.
![]() | 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 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).
MRO Implemented Objects
A set of specific objects extending functionalities of existing MRO elements.
For Task Objects, Value properties are assigned by default and implement necessary classifications.
Procedure Workpackage
A Procedure Workpackage is a specialized type of Work Package designed to model complex workflows. It consists of sequential tasks that can include branching logic, modular structures, and references to linked data. Procedure Workpackages allow the execution of structured processes that may adapt dynamically depending on conditions. They support both online and offline execution, with certain steps (e.g. data exchange) triggered once connectivity is available.
Switch Start Task
A Switch Start Task is a type of sequential task used within a Procedure Workpackage to define branching logic. It evaluates a predefined (boolean) condition, which can be checked by the client, to determine which branch (true or false) of the workflow will be followed. Each branch represents a different execution path composed of its own set of tasks. A Switch Start Task always requires a corresponding Switch End Task, where all branches converge and the unified procedure continues.
Switch End Task
A Switch End Task marks the end of a branching structure initiated by a Switch Task. It is a sequential task that connects the different branches back into a single workflow path. Each Switch End Task is directly linked to its respective Switch Task and ensures that, regardless of which branch was taken, the overall procedure continues in a consistent and controlled manner.
Check Task
A Check Task allows the user to check the task as completed or Not Applicable.
Numeric Task
A Numeric Task allows the user to input a numeric value (double). It includes a defined value range, and if the entered value falls outside this range, the task is visually marked as problematic.
Inspection Task
An Inspection Task presents the user with two customizable buttons representing different inspection outcomes, along with a Not Applicable option. The labels of the buttons can be defined during the procedure creation.
Text Task
A Text Task provides a text input field for the user to enter free-form information. This task is useful for capturing qualitative data or comments during the procedure.
Picture Task
A Picture Task enables the user to take and attach one or more photos. It includes a button to initiate the camera and another to confirm the task. The confirmation button remains disabled until at least one picture has been successfully captured.
Dynamic List Task
A Dynamic List Task presents a button that, when clicked, displays a list of selectable options. These options are defined by the procedure creator and can vary depending on the context. This task is ideal for scenarios requiring user selection from a predefined but flexible set of choices.
Supervisor Task
A Supervisor Task includes a button for NFC reading. If a supervisor successfully authenticates, it enables confirmation buttons, input fields, or other interactive elements.
Interface Task
An Interface Task performs a REST API request automatically when it becomes active. It does not include any visible buttons or user interaction. Once the server responds, the task is automatically confirmed based on the response.
Calculation Task
A Calculation Task is automatically confirmed if a predefined logical or mathematical expression—based on the values of previous tasks—evaluates to a positive result. This allows for conditional automation and validation within the workflow.
See also
- MROCLS MRO TASKOWNER (Classification)
- MROCLS MRO WORKPACKAGE (Classification)
- MROCLS MRO TASK (Classification)
- MROCLS MRO MEASUREMENT TASK (Classification)
- MROCLS MRO PROGRESS TASK (Classification)
- MROCLS MRO CHECK TASK (Classification)
- MROCLS MRO INSPECTION TASK (Classification)
- MROCLS SEQUENTIALTASK (Classification)
- MROCLS GROUPEDTASK (Classification)
- MROCLS PROJECT (Classification)
- MROCLS PROJECTINFORMATION (Classification)
- MRO Objects (Client)
- MRO Implemented Objects
- MROCLS PROCEDURE (Classification)
- MROCLS SWITCH START TASK (Classification)
- MROCLS SWITCH END TASK (Classification)