SOT
    • Introduction
    • User manual
      • Basic operation
        • Create and delete a device as a favorite
        • Use the filter function
      • Process
        • Compare processes
        • Change axes in the diagram
        • Show and hide axis in the diagram
        • Show special values
        • Display measured values in the diagram
        • Display process data in the diagram
        • Displaying diagram content
        • Permanently highlight a process curve
        • Temporarily highlight a process curve
        • Monitoring processes
        • Configure columns
        • Export process data
    • Operations manual
      • Overview
      • System architecture and interfaces
      • System requirements
        • trinity/static-content
        • trinity/trinity-core-service
        • trinity/trinity-gateway-service
      • Migration from previous versions
        • Influx database migration
        • Deletion of an old CPM installation
      • Setup and configuration
        • AI add-on: Process Intelligence
        • Database configuration
        • Port configuration
        • HELM configuration
        • Application account roles provided
        • Relational database
        • General logging
        • General OpenTelemetry
        • trinity/static-content
        • trinity/trinity-core-service
        • trinity/trinity-gateway-service
      • Start and shutdown
      • Regular operations
      • Failure handling
        • Processes are not received
        • Module is not visible in the Web Portal
        • How to verify if the broker is out of sync
        • Devices are missing
      • Backup and restore
      • Logging and monitoring
        • Observability
        • Logging characteristics
        • Logging format
        • Logging level
        • Required monitoring
        • Request-based logging format
        • Security logging format
        • Lifecycle logging format
        • Health verification endpoints
      • Known limitations
    • API documentation
Process Quality
  • Smart Operations Toolkit
    • Deviation Processor
    • Multitenant Access Control
    • Notification Service
    • Ticket Management
    • Web Portal
  • Shopfloor Management
    • Andon Live
    • KPI Reporting
    • Operational Routines
    • Shift Book
    • Shopfloor Management Administration
  • Product & Quality
    • Process Quality
    • AI Services
  • Machine & Equipment
    • Condition Monitoring
    • Device Portal
  • Enterprise & Shopfloor Integration
    • Information Router
    • Master Data Management

SOT Learning Portal

  • Process Quality
  • Operations manual
  • Migration from previous versions

Migration from previous versions

Migration from 3.6.1 to 3.7.0

PQM deletes all RabbitMQ 0.9.1 classic queues. All data in the queues are deleted. PQM creates RabbitMQ 0.9.1 quorum queues.

Migration from 3.6.0 to 3.6.1

With the latest release, IAS supports authentication for the Deviation Processor (SMDP). When SMDP is enabled, the appropriate service account role needs to be assigned to PQM.

See section Service Account Roles for more information.

Migration from 3.4.0 to 3.5.0

The Ingress controller name changed from tgw-ingress to pqm-ingress. The old tgw-ingress is unused and usually cleaned up by HELM automatically. In case it’s not, the path conflict and the old ingress needs to be deleted manually.

Migration from 3.0.x to 3.1.x

We have renamed a couple of entities in RabbitMQ.

The following entities can be deleted if they are still visible after successful deployment:

Queues

  • q.pqm.mdm-integration-worker.new

  • q.pqm.mdm-integration-worker

  • q.pqm.mdm-integration-wait

  • q.pqm.mdm-integration-wait.new

  • q.pqm.contract-created-worker

  • q.pqm.contract-created-wait

  • q.pqm.tenant-removed-worker

  • q.pqm.tenant-removed-worker-new

  • q.pqm.tenant-removed-wait

  • q.pqm.tenant-removed-wait-new

  • q.pqm.dlq.integration-events

Exchanges

  • x.pqm.integration.new

  • x.pqm.dlq.integration

Migration from CPM 1.5.x to PQM 3.0.x

This step is relevant if you were a user of the Condition and Process Monitoring Module (CPM).

The migration is not a zero-downtime migration. Before starting the migration:

  1. Prepare the new PQM databases with the proper user/schema and access rights

  2. Add PQM 3.0.x to inventory and run the HELM deployment

  3. Make sure all necessary account roles are applied for all the tenants that should use PQM

  4. To check that the service account roles are properly setup:

    • Open the PQM UI and check (for every tenant that should use PQM):

    • that there are devices present - if there are no devices, stop the migration and check the PQM deployment state - check the PQM → MDM service account roles.

    • check that PQM receives data (Processes and Machine data) by looking at a device that should receive data from Connectivity, if there is no data coming in, stop the migration and check the PQM deployment state - check the Connectivity → PQM service account roles.

  5. Remove CPM from inventory and run the HELM deployment (uninstall it).

  6. Execute the Influx database migration steps described in the following sections. No migration of the relational database needed.

    • Influx database migration

    • Deletion of an old CPM installation

Contents

© Robert Bosch Manufacturing Solutions GmbH 2023-2026, all rights reserved

Changelog Corporate information Legal notice Data protection notice Third party licenses