SOT
    • Introduction
    • User manual
      • Getting started
        • Device registration overview
          • Registering a device
          • Self-registration of devices
        • Device claiming
          • Adding a ctrlX Core device
          • Adding a Rexroth connectivity unit device
      • Device overview
        • Setting the filter for the search
        • Device details
        • Edit device properties
        • Roll out artifacts on one or more devices
        • Rolling out a distribution
      • Device groups
        • Creating a device group
      • Machine overview
        • Create, edit and delete machines
        • Adding machines and devices via CSV file import
        • Structure of the CSV import file
      • Activity overview
      • Distribution overview
        • Managing distributions
        • Managing commands in a distribution
    • Operations manual
      • Overview
      • System architecture and interfaces
        • Element descriptions
        • Network connections overview
      • System requirements
        • General system requirements
        • Ingress controller
        • idm/idm-device-administration-app
        • idm/idm-software-management-app
        • idm/idm-device-monitoring-app
        • idm/idm-device-master-data-mgmt-app
        • idm/idm-device-app
        • idm/idm-solution-app
        • idm/idm-webapp-backend
        • idm/idm-device-tunnel-app
        • idm/idm-artifact-repository
        • bci-app/opensearch
        • bci-app/opensearch-dashboards
        • bci-app/valkey
        • bci-app/nginx
        • bci-kube/nexeed-ansible-operator
      • Migration from previous versions
      • Setup and configuration
        • Installation guide
          • How to initialize OpenSearch
          • How to create MACMA tenants with basic authentication
          • How to configure tenants for artifact-related use cases
        • Configuration
          • Detailed configuration parameters
          • Recommendations for service meshes
      • Start and shutdown
      • Regular operations
        • Whitelist new certificate
      • Failure handling
        • Device Portal data is out of sync
        • How to synchronize devices and machines to OpenSearch
        • Synchronize communication id mapping to key-value store (Redis/Valkey)
      • Backup and Restore
      • Logging and monitoring
      • Known limitations
    • Developer guide
      • Communication ID
      • Adding diagnostic functionality to devices
      • Add command processing to devices
      • Add the backup/restore functionality to devices
      • Reducing data consumption of device communication
      • Access through a custom application
    • Artifact Repository guide
      • Introduction
      • Providing artifacts for roll-out
        • Establishing a connection to the Device Portal
        • Uploading and managing artifacts in the repository
      • Downloading artifacts
      • Sending commands
    • API documentation
    • Glossary
Device Portal
  • 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

  • Device Portal
  • Operations manual
  • Setup and configuration
  • Installation guide

Installation guide

Use installation specific passwords and ensure that passwords are being stored in a safe place. In the following parts, the safe place is referred to as Keepass.

After the initial deployment, the Deviceportal components are started as Kubernetes pods. Please refer to chapter 2 for a description of the components.

The system can be accessed via the Nexeed IAS Portal:

Name Address Credentials Information

User interface

https://<NEXEED_HOST>

username, password and NEXEED_HOST are specified in the custom-values of the corresponding environment as macmaPortalAdminUser, macmaPortalAdminPassword and nexeedHost, respectively.

Interface to manage MACMA. This includes tenant and contract creation. Each created tenant needs to be further configured to have the appropriate users, groups and modules.

Prerequisites pre-deployment

These prerequisites can be taken care of before a deployment was done. These are required to have a fully functional Deviceportal.

  • Ensure that MACMA and Portal are either

    • part of the Nexeed deployment, or

    • that there are instances of these modules hosted elsewhere where the Device Portal can be integrated

  • A supported database is available. This could be part of IaC scripts or a manually booked database

  • Environment specific custom-values are prepared. See chapter configuration

  • A DNS record is booked for the mTLS endpoints and referenced in the corresponding Helm variable <.Values.global.modules.deviceportal.mtlsGateway.deviceDomain>

  • For OpenSearch, each Kubernetes cluster node is required to have the vm.max_map_count property set to 262144. See OpenSearch documentation. This could be part of IaC scripts or manually configured (requires cluster access)

  • The Ingress Controller must have the following configurations:

    • Enable Ingress to parse and add -snippet annotations/directives. ( e.g. Ingress Nginx Controller config)

    • Maximum allowed size of the client request body must be >= 100m. ( e.g. Ingress Nginx Controller config)

    • Timeout in seconds for reading a response from the proxied server must be >= 300. (e.g. Ingress Nginx Controller config)

    • Incoming X-Forwarded-* headers must be parsed to upstreams if the Ingress Controller is not directly exposed to the Internet. E.g. behind an Azure Application Gateway / WAF. (e.g. Ingress Nginx Controller config)

  • Helm version 3.10 or higher

  • Wildcard Server certificate is ordered. The server certificate must contain SAN entries for…​

    • Nexeed Portal domain

    • Wildcard domain for Nexeed modules (in case of subdomain deployment)

    • mTLS domain (for device access - only if needed to provide a stable environment agnostic endpoint for devices)

    • Wildcard tunnel subdomain (for user access)

  • If a subdomain deployment is used, the SAN names of the server certificate would be:

    • <NEXEED_HOST> (Nexeed Portal domain)

    • *.<NEXEED_HOST> (Wildcard domain for Nexeed modules including a subdomain certs for mTLS)

    • *.tunnel.dp.<NEXEED_HOST>

  • For an Azure cloud deployment it is necessary to activate HTTP/2 support (via PowerShell or the Azure UI: 'Application gateway'→'Configuration'→'HTTP2: enabled') - in case HTTP/1.1 support is not sufficient. This is e.g. the case for deployments where ctrlX CORE devices are used (as the remote access to the UI of the device will otherwise not work correctly).

Prerequisites post-deployment

These prerequisites can only be taken care of after a deployment was done. These are required to have a fully functional Device Portal.

  • Initialize OpenSearch as described in chapter How to initialize OpenSearch.

  • Create and configure MACMA tenants. See chapter How to create MACMA tenants with basic authentication for a setup with basic authentication.

  • Create a tenant configuration as described in chapter How to configure tenants for artifact-related use cases.

  • How to initialize OpenSearch

  • How to create MACMA tenants with basic authentication

  • How to configure tenants for artifact-related use cases

Contents

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

Changelog Corporate information Legal notice Data protection notice Third party licenses