The Maintenance Planner Manual describes how set up a Maintenance Catalog for planning and managing maintenance tasks for your machines.

1. Introduction

The Proemion Maintenance Planner is used for planning maintenance tasks for the machines.

It uses a YAML file format for defining maintenance schedules and tasks specific to each machine model.
These YAML files allow users to set up a "Maintenance Catalog" that defines the maintenance tasks, including task names, descriptions, intervals and related actions.

The Maintenance Catalog can be then displayed and managed in a graphical overview within Maintenance in the DataPortal.
For more information, see Maintenance Tasks in the DataPortal User Manual.

The YAML configuration includes specifying triggers for maintenance events based on machine operating hours or specific service intervals, which can support in automating task scheduling based on machine-specific requirements.

This guide provides a structured approach to creating a YAML file for the maintenance planning.
It’s important to adapt the content to the specific needs and specifications of your maintenance system.
Regular reviews and updates to the YAML file might be necessary to align with changes in maintenance strategies or machine models.

1.1. Service and Support

The latest versions of the drivers, software, firmware, and documentation are available in our Document Library.

Do you need help or want to report a bug?
Visit Proemion for more information, or raise a ticket at Support.

1.1.1. Firmware Updates and Support

Firmware Updates and Support

To ensure the best performance and security of your devices, we strongly recommend always installing the latest firmware provided by Proemion.

Please note:

We do not provide technical support for issues caused by outdated firmware.
Errors resulting from outdated firmware are considered non-qualified errors and are not covered by warranty or support.

Regular firmware updates are essential to maintaining the functionality of your devices. If you need assistance with the update process, please contact our Service and Support.

2. Set up Maintenance Planner

To set up the Maintenance Planner in your DataPortal, follow the steps:

  1. Generate a Purchase Order: Begin by generating a purchase order for the required services. This purchase order will outline the scope and cost of setting up the Maintenance Planner.

  2. Create an issue: As part of this setup process, create an issue in the corresponding customer collaboration project in JIRA.
    In this issue, you should include the YAML file containing all your maintenance schedules and configuration.

  3. Inform the FAE: Once the issue is created and the purchase order is generated, it’s essential to inform the assigned FAE about the setup process.
    The FAE will play a key role in coordinating the implementation of the Maintenance Planner.

By following these steps, you initiate the process of configuring the Maintenance Planner in the Proemion DataPortal, ensuring that your maintenance tasks are effectively managed and scheduled.

Next, let’s delve into the steps for configuring this YAML file.

3. YAML file configuration

YAML files are used for the configuration and should be written in a clear, structured format.
Familiarize yourself with the YAML syntax: key-value pairs, lists, and nested structures.

3.1. Catalog Configuration Example

The following example shows the configuration of the catalog for "Operating Hours Maintenance".

---
task:
  name:
    en: "Maintenance at $target hours"
  description:
    en: "A generic description which is added to every task."
  source: "customer_name.maintenance"
settings:
  base: "hours"
  advance: 25
  set_checklist_activities: False
  set_description_activities: True
  sort_description_activities_by_text: False
  sort_description_activities_by_cycle: True
  group_root_activities: True
  set_activity_cycle: False
signals:
  operating_hours:
    key: "operating_hours_signal_key"
    mandatory: true
  service_counter:
    key: "service_counter_signal_key"
    mandatory: true
models:
  Example Model:
    links:
      en:
        link name: "href 1"
        link name 2: "href 2"
    unique_activities:
      250:
        en:
        - control part A
        - check part B
      5000:
        en:
          Special Engine Maintenance:
            - setup OEM appointment
            - check part K
          Special Module Maintenance:
            - setup OEM appointment
            - perform action L
    cycle_activities:
      500:
        en:
          - Clean component Q
          - Perform activity R
          - Replace:
            - part D
            - part E
          - Check:
            - liquid P
      1000:
        en:
        - inspect component X
        - report machine state

3.1.1. Explanation

Explanation of the keys used in the catalog configuration example above.

Note that a maintenance task may have the states deadline ("upcoming", "overdue") and progress ("unplanned", "planned", "skipped", "completed"), which are calculated and set by the Maintenance Planner.
With exception to "planned" and "completed" progress, which can be actively set by the user, e.g. service technician, in the DataPortal.
For more information, see Maintenance Tasks in the DataPortal manual.
Config Description

task

Task related configurations

name

Internationalized name used for every task, template string (e.g., $target $cycle)

description

Internationalized description for each task, template string (e.g., $machine_operating_hours)

source

Used internally to filter and identify tasks of the same machine’s sub-history

settings

Settings to steer task presentation and logic

base

Entry to define the base of the catalog (hours or dtc)

set_checklist_activities

Set activities as checklist items

set_description_activities

Set activities in the description field as a string

sort_description_activities_by_text

Sort top-level activities by text (relevant if set_description_activities is true)

sort_description_activities_by_cycle

Sort top-level activities by cycle (relevant if set_description_activities is true)

set_activity_cycle

Sets activity cycle in front of every activity string (e.g., '1000h inspect component X')

group_root_activities

Groups sub-activities if root activity has the same text (relevant for merged cycles)

advance

Hours in advance a task is opened, also defines the size window for detecting upcoming tasks

signals

Signal keys for querying last measurements and timeseries, filters machines based on the last measurement

models

Model machines that are maintained, filters machines to match configured model names

links

Internationalized links added to a task of a machine of that model

unique_activities

Internationalized activities that occur only once at the given operating hours

cycle_activities

Internationalized activities that repeat in a cycle every time a multiple of the operating hours is reached

3.2. Internationalized Configuration

If an item/configuration is [internationalized], then it needs to be configured with at least one language code [en, de, it, fr] etc., see also example above.

Completeness and Order matter!
If multiple languages are provided, all configuration items need to support all languages (task name, task description, links and activities).

The order of configuration with the same meaning but in different language does matter (for activities and links):

Wrong ordered example

en:
  - english activity A
  - english activity B
de:
  - german activity B
  - german activity A

A and B activity texts would be mixed up on task creation and show different meanings when switching the DataPortal’s language setting.

Correct ordered example

en:
  - english activity A
  - english activity B
de:
  - german activity A
  - german activity B

3.3. Additional Tips

  • Comments: Use # for comments to explain sections or parameters for future reference.

  • Indentation: YAML is sensitive to indentation; ensure consistent use of spaces (not tabs) for nested elements.

  • Consistency: Be consistent with naming conventions and structure throughout the document.

4. How to configure Activities

Activities are a checklist of single steps for completing the maintenance task, see also Maintenance Activities.

Activities can be configured in two ways:

4.1. Flat Activities List

the simplest way is flat as a list (lists are indicated with - in front of an element) of activity strings:

en:
  - control part A
  - check part B

4.2. Nested Activities List

Nested activities are configured as map (dict):

en:
  Special Engine Maintenance:
    - setup OEM appointment
    - check part K
  Special Module Maintenance:
    - setup OEM appointment
    - perform action L

4.3. Flat and Nested Activities Lists

If flat and nested activities appear together, then they need to be configured as a list of string and dict elements:

en:
  - Clean component Q
  - Perform activity R
  - Replace:
    - part D
    - part E
  - Check:
    - liquid P

5. Use Cases

In the following, different use cases for maintenance tasks/cycles and their catalog configuration are described.

5.1. Hours To Service

The simpler nature of this mode results in a simpler catalog.
There are no unique activities for now and only one cycle per model allowed which sits at a fixed 0 hours (hours to next service).

---
settings:
  base: "hours"
  advance: 25
signals:
  hours_to_service:
    key: "hours_to_service_signal_key"
    mandatory: true
  service_counter:
    key: "service_counter_signal_key"
    mandatory: true
models:
  Example Model:
    links:
      en:
        link_name: "example doc link"
    cycle_activities:
      0:
        en:
        - Replace:
          - part B
          - part C
        - Check:
          - liquid P
        - Clean component Q
        - Perform activity R

5.2. Default Maintenance

A special entry can be added to the catalog: default_maintenance.
This is a reserved name.
If this entry is found in the catalog, all machines/models of the customer’s fleet are used for maintenance.

For every model that has not an entry in the catalog already, see Catalog Configuration Example, the default maintenance entry is applied, with exception to the ignored_models list.
This list can be added to the default_maintenance entry, defined models will be ignored for the
default maintenance.
A model can’t be present in the catalog and in ignored_models list at the same time.

---
settings:
  base: "hours"
  advance: 50
models:
  default_maintenance:
    ignored_models: ['Ignore_Old_Model', 'Ignore_Broken_Model']
    cycle_activities:
      500:
        en:
          - A Default Activity
As soon as this entry is found, maintenance will be performed for all machines of the fleet, if the required data/signals/properties are given and the machine model is not present in the ignored_models list.

5.3. Multimodel Entries

If models share the same maintenance configuration, they can be set in a single entry by adding all model names to the key separated with ;.

Instead of configuring as follows:

Model_A:
  cycle_activities:
    1000:
      en:
        Replace:
        - Part X
Model_B:
  cycle_activities:
    1000:
      en:
      Replace:
      - Part X

The models can be configured together as follows:

Model_A;Model_B:
  cycle_activities:
    1000:
      en:
        Replace:
        - Part X

Which will result in the same configuration.

5.4. Complete Catalog Sample

In the following, you find a complete example for the Catalog regarding "Operating Hours Maintenance".
The following example also shows how to configure machine property keys and action ids, if they are required for the customers maintenance logic.

---
task:
  name:
    en: "english name"
  description:
    en: "english description"
settings:
  base: "hours"
  advance: 50
  set_checklist_activities: true
  group_root_activities: true
signals:
  operating_hours:
    key: "operating_hours_signal_key"
    mandatory: true
  service_counter:
    key: "service_counter_signal_key"
    mandatory: true

models:
  default_maintenance:
    ignored_models: ['Test Model', 'Ignored_Old_Model']
    cycle_activities:
      500:
        en:
        - default maintenance information

  Model A;Model B;Model C:
    links:
      en:
        Maintenance Information: "link to maintenance information"
    unique_activities:
      200:
        en:
          Check:
          - part x
          - part y
    cycle_activities:
      500:
        en:
          Replace:
          - part e
          - part f
          Refill:
          - liquid p
      1000:
        en:
          Check:
          - component d
          - part g
          - part h
          Refill:
          - liquid q

  Model D:
    links:
      en:
        Maintenance Information Model D: "link to maintenance information Model D"
    cycle_activities:
      2000:
        en:
          Replace:
          - part k
          - part l
          Refill:
          - liquid p
          - liquid q

6. Property and Action Key Configuration

---
task:
  ...
settings:
  ...
signals:
  ...
properties:
  equipment_id: "equipment_id_property_key"
actions:
  service_hours_reset: "action_id"
models:
    ...

6.1. Explanation

  • properties: (optional) key and value (property key) that are used for getting additional maintenance relevant machine properties.

  • actions: (optional) key and value (action key) that are used for executing an action.

6.2. Ignore Individual Machines Using Machine Properties

If a property configuration with the normalized key maintenance_service_excluded is defined
in the catalog, machines can be excluded from maintenance based on this property.

The following example shows how to configure the property in the catalog:

properties:
  maintenance_service_excluded: "maintenance_service_excluded_example_key"

All machines which have the property maintenance_service_excluded_example_key
configured and populated with the value true (case-insensitive)
will be excluded from maintenance, even if their model is present in the catalog.

The actual machine property key is free of choice for the fleet use.

Version: 11.0.950