MindSphere Remote Services - Used Concepts¶
This section provides an introduction into the basic concepts used in MRS. They understanding provides a good foundation for taking the first steps using MRS.
Ways of Network-to-Network Access¶
MRS was designed in a way, that it supports parallel 1:many access from single Service Network into many Device Networks.
The same MRS mechanisms can be used for parallel many:1 access from multiple Service Networks into single Device Network.
Based on the above access modes, it is also possible to leverage 1:1 access or many:many access among networks.
Remark: when using setups with multiple networks,please consider, that these networks may belong to different (legal) entities, which may require an appropriate setup of users and access rights.
Typical Customers Working With MRS¶
MRS provides generic network-2-network access suitable for a large set of use cases such as remote maintenance, digitalization or integration of IoT apps or data storage.
This section outlines typical customers and their interests using the domain of remote servicing & maintenance as an example.
In this domain there are typically two types of parties: - Service Provider: quite often an OEM or specialized business partner delivering "remote servicing & maintenance", - Machine Operator: quite often the owner of a production line with machines (devices) procured from one or several OEMs
Under the assumption, that machines are linked to a computational and potentially embedded device, it is possible to access the status or wear or logs or business logic of such machines via a network interface.
In the first business scenario the Service provider subscribes to MRS: here a Service Provider services multiple Machine Operators either sequentially or in parallel. A Remote Service Technician uses his/her apps to supervise / diagnose / commission or maintain machines over a versatile secure network-to-network access mechanism.
For the Service Line Owner or CEO that has the advantage of reducing the need for their technicians travelling to Machine Operator sites, whilst also being faster at handling incidents such as unexpected machine behavior. If such travel is still necessary, upfront remote diagnosis helps to optmize the onsite-visit, e.g. by catering for replacement components.
In the second business scenario Machine Operator subscribes to MRS: here a Machine Operator receives services from multiple Service Providers, who are specialized on different kinds of machines on the factory floor. So it becomes possible to receive best-in-class services for heterogenous production lines with machinery purchased from different OEMs.
The benefit for the responsible Production Line Owner and the supporting CIO / CDO as well as the local maintenance experts on the factory floor are evident: the service providers deliver services specific to certain types of machinery such as faster incident resolution, update of IT security relevant software modules, etc. They might even receive upgrades of a machine's capabilities through such dedicated remote access channels.
Blueprint for MRS-Enabled Network-to-Network Access¶
This section outlines the key elements of a network setup involving MRS. Further information on the key functional elements of MRS can be found in the section Remote Service in a Nutshell
Note: administrative MRS user roles add a needed set of Protocol Applications to the MRS catalogue, such as the sample setups "VNC login Europe" or "DTT for Video Stream". Each Device must be assigned with one or several Protocol Applications from this catalogue in order to become accessible!
The key functionality of routing a customer app's IP-based protocols from one network to another is built on tunnels, which encrypt these protocols. Such tunnels need endpoints at either end, which allow for spawning them. Tunnel Endpoints are provided for download from within MRS. - one endpoint will be installed on a PC-type access device in the Service Network - complementary endpoints will be installed on a PC-type device in a primary network of a Device Network. That is a necessary pre-condition for establishing an encrypted connection using Web Socket Secure (WSS) tunnels between these devices. Endpoints may also be used in a gateway mode, so that connections to devices / apps / data residing in secondary networks can be established. Please note, that the network interfaces of the underlying devices must permit doing so.
It is also possible to use dedicated hardware routers supporting encrypted IPsec tunnels in the primary Device Network instead of using the provided software endpoints in gateway mode. Please note, that hardware routers are transparent network devices, so they do not host apps or data, which would be accessible on devices hosting a software endpoint.
MRS also supports the web versions of the popular pre-configured remote login protocols of Remote Desktop Protocol (RDP), Virtual Network Client (VNC) and Secure Shell (SSH) so that both Windows® and Linux® devices can be reached. Please note, that the web versions of these protocols involve a www-browser running in the Service Network and that these have functional limitations over the also provided native versions of these protocols.
Each device can be assigned with one ore more individual protocols, which paves the way for implementing a versatile set of use cases according to a customer's business needs.
Summarized, the provided software endpoints can be deployed on PC-type devices including selected Industrial Edge Devices (please refer to Appendix for Experts). Devices on secondary Device Networks do not require installation of an endpoint. Thus, devices in secondary networks can also be embedded devices, PLCs or SCADA systems, if they can be reached by a remote app via an IP-based protocol.
Note: Setup of networks with firewalls and proxies is typcially straight forward and outlined in section Appendix for Experts.
Fine-Grained Access Control for Many-to-Many Connectivity¶
So far we did outline how the encrypted tunnels, which route custom or pre-defined IP-based protocols, are being established. Now we introduce the important security mechanisms used in top, which ensure, that only authorized users may connect to authorized devices using the appropriate protocols - this concept is also known as Fine-Grained Access Control (FGAC) and a mandatory precondition for Zero Trust-driven setups as defined by NIST standard NIST.SP.800-207.
MRS uses a Device Tree for structured access to devices registered to it. As also depicted in Sample Setup Used in Documentation this tree has multiple layers, which could for instance by continents, countries, cities and campuses as indicated in the middle section of above picture.
- Root organizational or tenant level, e.g. "Europe" - Sub-organizational or regional level, e.g. "Germany, etc." and "Munich, etc." - Site level denoting a Device Network, e.g. "Brewery, etc." - Devices will be registed to sites, e.g. "Pump, Motor, etc."
As outlined in MRS in a Nutshell MRS is an add-on running on MindSphere. So once MRS is available in a specific MindSphere tenant, already registered Mindsphere uses can be assigned with additional MRS-specific user roles, which allow for a task-specific separation of access rights and responsibilities as shown in the left section of above picture: - Tenant Administrator: This MRS role is authorized to administrate (change, read, update, delete) MRS objects on organizational or tenant level. This responsibility includes onboarding of devices, definition of device-specific application protocols, definition of filters for device-types, assignment of MRS roles to users and more. An administrator is assigned to one tenant and may administrate only that tenant’s objects and grants. - Region Tenant Administrator: This role is basically a scoped tenant administrator, who is only responsible for regional sub-organizations. - Site Owner: This MRS role is dedicated to managing a "Device Network" and the devices it contains. This includes installation of downloadable MRS endpoints on devices. It has the authority to cut all connections to any device at their site anytime at once. - Remote User: This MRS role is meant for users, who use preconfigured connections for performing everyday remote access tasks, such as remote maintenance of connecting apps or data across network boundaries. These users' access is limited to devices, for which they were granted access by an administrative MRS role. - Power User: This is a Remote User who may also use the "On-Demand Device" capability for establishing temporary access to non-onboarded devices.
On top of that there is a Product Type filter shown on the right section of above picture. When Devices are onboarded to MRS they may be tagged with administrator-defined Product Types. That allows giving Remote Users access only to specific classes or types of devices. For instance, it is also possible to define families such as Product Type "PC" and below that you may have particular types such as "PC with Windows" or "PC with Linux". Where necessary, it is also possible to assign grants for individual devices.
The following table summarizes the permissions and grants associated with the MRS-specific user roles:
Please note, that the use of Tunnels in combination with Fine-Grained Access Control is an innovative approach, which lays the foundation for use cases not supported by classic permiter-driven or network-driven security approaches such as VPNs. For further details please approach a Sales representative.
User Interface for Easy Self-Administration¶
After subscription to MRS you will see two MRS-related icons in your MindSphere launchpad: - Remote Service V1 allows for anytime function calls and covers all MRS functionality for adminstration but also for everyday use, if a user was granted them via the respective MRS user roles - Remote Service V2 adds additional guidance via role-specific workflows including nested menus with a bread-crumb-style navigation across their call hierachy. So this is meant for everyday use by people with the MRS role Remote User
Menus have different appearances depending on their purpose and functionality. Below picture gives a first impression related to Remote Service V2: - icons to the very left allow for switching between different menu scopes such as configuration tasks or supervision of consumed contractual resources - the upper left bar shows the nested menu structure in a bread crumb style - users who bear multiple MRS-specific roles may switch them in the upper right bar - the left-hand tree structure shows the different organizations, regional sub-organizations, sites and devices registed to them - the key part is a workflow-specific edit and status area such as checking, which protocols were assigned to a particular device
Any questions left?
Except where otherwise noted, content on this site is licensed under the MindSphere Development License Agreement.