In Practice

Common use cases for the Downtimes module — from manual stop logging and reason qualification to OEE tracking, camera integration, and PLC event mapping.

Downtime tracking in Maecos is built around reason trees — hierarchical code structures that guide operators to classify every stop event. The use cases below show how different production environments map their downtime scenarios to the platform. Each requires configuring equipment, reason trees, and categories in Settings.

Complexity indicators: Start here = straightforward to configure, suitable for initial rollout. Intermediate = requires cross-module integration or advanced reason tree design. Advanced = depends on PLC integration, API event mapping, or mature platform usage.

Manual downtime logging

Unplanned stops with reason qualification

Start here

Scenario: A production line stops unexpectedly — a jam, a sensor fault, a material shortage. The operator needs to log the stop, assign a reason code, and resume production. The qualified reason feeds into OEE reporting and trend analysis.

How Maecos supports this: Configure equipment in Settings and build a reason tree per equipment item. When a stop occurs, the operator selects the equipment and navigates the reason tree to classify the cause. The tree guides qualification — from broad category (Mechanical, Electrical, Process) to specific cause (Label applicator jam, Conveyor belt slip). Reason codes marked as "unplanned" feed into OEE availability calculations automatically.

Planned downtime (changeovers, cleaning, maintenance)

Start here

Scenario: Changeovers between products, scheduled cleaning, and planned maintenance are expected stops — but they still need to be logged and tracked. The distinction between planned and unplanned downtime is fundamental to OEE accuracy.

How Maecos supports this: Configure separate categories for planned downtime types. Reason codes under planned categories are excluded from OEE availability loss calculations (they affect OEE differently depending on your methodology). Operators select the planned reason code when logging — the system never guesses. If planned stops consistently exceed their expected duration, the trend data makes it visible.

Split reason codes for long stops

Intermediate

Scenario: A stop starts as one cause but evolves — an initial jam triggers a secondary electrical fault, or a breakdown extends into a planned maintenance intervention. The stop needs multiple reason codes to accurately reflect what happened.

How Maecos supports this: Reason codes can be configured with a "split after minutes" setting. When a stop exceeds the configured duration, the system prompts the operator to re-qualify with a new reason code. This prevents long stops from being misattributed to the initial cause when the actual root cause shifted during the event.

Investigation-linked downtimes

Downtime with mandatory issue creation

Intermediate

Scenario: Certain failure modes — repeated breakdowns, stops exceeding a threshold, safety-related events — require more than a reason code. They need a documented investigation with root cause analysis and corrective actions.

How Maecos supports this: Configure specific reason codes with a "requires issue" flag. When an operator qualifies a stop with one of these codes, the system prompts them to link the downtime to a new or existing issue. The downtime landing page highlights unlinked reason codes that require issues — making investigation gaps visible to supervisors. The issue carries both the quantitative impact (duration, equipment) and the qualitative context (what happened, why, what was done).

Grouping related stops into a single investigation

Intermediate

Scenario: Multiple short stops on the same line share a common root cause — a worn guide rail causing repeated jams, a batch of defective material causing intermittent rejects. Logging each separately fragments the picture. The team needs to consolidate them into one investigation.

How Maecos supports this: Multiple downtime events can be linked to a single issue. The issue aggregates the combined impact — total duration, affected equipment, all reason codes — alongside the investigation context. This makes the business case for corrective investment visible: not one 3-minute stop, but thirty 3-minute stops totaling 90 minutes per week.

Automated data capture

PLC event code mapping

Advanced

Scenario: Production equipment sends automated event codes when stops occur — fault codes from PLCs, status changes from SCADA systems. These events need to flow into the downtime system without manual operator entry, mapped to the correct reason codes.

How Maecos supports this: Event codes from external systems are mapped to specific branches in the reason tree. When an event arrives, the downtime is created and pre-qualified automatically. The operator sees the pre-qualified stop and can refine the reason code if the automatic mapping needs correction. This eliminates manual logging for equipment-generated events while preserving operator oversight.

Camera-assisted stop documentation

Advanced

Scenario: When a stop occurs, a camera captures what happened — the state of the line, the position of materials, the visual evidence of the fault. This image needs to be associated with the downtime record for investigation and training purposes.

How Maecos supports this: Camera integration captures images at stop events and attaches them to the downtime record. The operator qualifies the stop as usual; the camera image provides additional context that text descriptions alone cannot capture. The captured images are available in the linked issue for root cause investigation.

OEE and performance tracking

OEE availability tracking per line

Start here

Scenario: The plant needs to track OEE availability per production line — how much of the scheduled production time was actually productive. This requires accurate downtime data with clean planned/unplanned classification.

How Maecos supports this: Once equipment and reason trees are configured with correct planned/unplanned categorization, OEE availability is calculated automatically from downtime data. Native dashboards show availability trends over time. The data feeds into meeting dashboards for Tier 1 and Tier 2 performance reviews. For advanced OEE analysis, the Reporting Database provides full access to downtime data for custom analytics in Power BI or Excel.

Downtime Pareto analysis

Intermediate

Scenario: The reliability team needs to identify the top downtime contributors — which reason codes account for the most lost production time? The Pareto analysis drives prioritization of maintenance and improvement investment.

How Maecos supports this: Downtime data qualified with reason codes feeds into dashboards that can be embedded in performance meetings. The combination of reason code qualification, category structure, and equipment linkage enables Pareto analysis by cause, by equipment, and by time period. For deeper analysis, query the Reporting Database directly.

Maintenance integration

Linking downtimes to SAP maintenance notifications

Advanced

Scenario: A breakdown event should trigger a maintenance notification in SAP PM — without the operator needing to switch systems. When the maintenance work order is created in SAP, the status should reflect back in the Maecos issue linked to the downtime.

How Maecos supports this: When a downtime event is linked to an issue, and the issue category is configured for SAP PM integration, the issue can push a maintenance notification to SAP. The downtime provides the quantitative context (duration, equipment, timing); the issue provides the investigation context; SAP PM handles the work order. Status synchronization keeps all three systems aligned.

Downtime-triggered checklists

Intermediate

Scenario: Certain checks should only happen when a line is stopped — internal inspections, cleaning procedures, safety verifications. Running these checks during production would be impossible or dangerous.

How Maecos supports this: Checklist procedures can be configured for execution during downtime only. When the line status changes to stopped, downtime-specific checklists become available to operators. Uptime-only checks (parameter readings, production quality checks) disappear. This ensures operators see the right checks for the current equipment state.