Remote Services Overview and Key Concepts¶

Introduction¶

System Manual ¶

Remote Services (RS) is an Xcelerator cloud-based product, which provides IP-based network-to-network connectivity from one network, often termed as Service Network, which hosts the apps provided by the customer (e.g. engineering applications or remote control tools) to a separate network, often termed as Factory Network that hosts a number of field devices.​

It is also possible to connect two different Devices with each other which reside in two different Factory Networks.

For example, an HTTPS connection from a browser in a Service Network to a PLC in a Factory Network which hosts an embedded webserver. Both networks have no direct connectivity with each other. However, two tunnels can be established through which the HTTPS traffic can flow between the browser and the PLC.

These customer-owned apps may use their own specific IP-based protocols (for communication, data transfer, streaming, login, browsing or messaging) for such access. RS will route these protocols transparently from one network to another via encrypted tunnels.

Such network-to-network access is further protected by modern Fine-Grained Access Control (FGAC) mechanisms which defines which users can access which devices via which protocols in which targeted device networks.

Communication Infrastructure provided by Insights Hub¶

The separate networks are securely connected by a communication infrastructure provided by Insights Hub.

From each network, a secure websocket connection will be established as a tunnel to a backend service in Insights Hub that acts as rendezvous point that connects both the tunnels and hence, the networks.

Access endpoints to the tunnels¶

The key functionality of routing a customer app's IP-based protocols from one network to another is built on tunnels. Such tunnels need endpoints at either end, which allows to establish the tunnels.

Tunnel endpoints can be downloaded from Remote Services and are available for a number of operating systems and deployment scenarios (e.g. installable binary, docker image, IE application).

These endpoints are the only Remote Services components which need to be installed by the customers. The three different types of endpoints are as follows:

• Service Endpoint
• Device Endpoint
• Preinstalled Device Endpoints

Service Endpoint¶

The Remote User needs to install this endpoint once on the desired machine to use the applications. For example, TIA Portal, VNC, RDP, SSH clients and Web Browsers that remotely connects to the Devices. These applications need to communicate with the endpoint on ports that are defined by the Connector configuration. With different ports, it is possible to use different applications at the same time.

The download package of the endpoint also contains a unique user specific access key to the remote tunnel. It is automatically applied when the endpoint is installed.

It is possible to use the same download package on different machines, but not simultaneously.

Device Endpoints¶

These endpoints must be downloaded and installed on each Device of type Primary Target or Gateway. The download package contains a device specific access key which identifies the Device.

Devices behind a Gateway do not need an Endpoint as they are accessed through the Gateway.

The user can either manually start the Device Endpoint on the device or configure it in OS level to automatically start the device.

For more information, refer to the chapter Creating Device Endpoints.

Preinstalled Device Endpoints¶

There are also MindConnect Agents equipped with pre-installed Device Endpoints. These pre-installed endpoints are activated through the Agent UI. To faciliate this, the Agent Asset ID must be provided when the Device is created in Insights Hub. ​

Connectors as blueprints of communication tunnels¶

RS supports a number of communication protocols that can be routed through the tunnel. These protocols are called Connector Types.

A user can create blueprints that describe use case specific communication tunnels from a selected Connector Type. In RS, such a blueprint is called Connector. The Connector is pre-configured with use case specific parameters (for example, IP addresses, ports user names, passwords, etc).

It is possible to create multiple Connectors derived from the same Connector Type, but with different parameters in the same Organization. These Connectors can then later be assigned to concrete Devices to prepare them for establishment of a tunnel on demand.

For more information, refer to chapter Remote Services Connectors.

Users and Roles¶

Every Remote Services user is also a user within the Insights Hub tenant that has the Insights Hub role serviceowner or orguser.

Additionally, Remote Services has its own concept of Users and Roles. A user can be created from within Remote Services as member of an Organization. Each user can be assigned one or more Remote Services roles that control access to Devices and a defined subset of Remote Services functionality.

These user roles in Remote Services are defined as follows:

Organization Owner¶

The users who are not created in the scope of an Organization can be referred to become members of the organization. These users are known as External Users.

The Organization Owner has the authority to decide if the referral can be accepted or rejected. Additionally, Organization Owner can also suspend or remove the External Users from the organization when they are no longer required in the organization.

Organization Admin¶

This role enables a user to set up an Organization that contains all the infrastructure. This Organization can be later used by a Remote User to establish a connection between Service Network and Factory Network.

The Organization Admin has the rights to perform the following steps:

• Defines a logical structure of Nodes, Sites and Products and adds devices to that structure. The logical structure is used for Fine Grained Access Control.
• Creates Connectors with a use case specific configuration and assigns them as needed to the devices.
• Creates users within the Organization and assigns one or multiple Remote Services Role(s) to them.

Remote User¶

This role enables a user to select a device and establish a connection between that device and a Service network using one of the Connectors assigned by the Organization Admin. In addition, the Remote User has the File Transfer capabilities. File Transfers does not need connectors, but just need Device Endpoint.

Site Owner¶

A connector can be configured to require the consent of a user with Site Owner role to establish the tunnel.

Summary on Users and Roles¶

• The users with the roles Organization Admin and Remote User are the ones that perform the day-to-day work on Remote Services.
• The Organization Admin sets up the infrastructure and extends or removes elements as needed.
• The Remote User accesses the prepared sites and devices through the predefined communication tunnels to perform the business task.

Organizations¶

The functionality of Remote Services is built upon the concept of Organizations.

Users with the Insights Hub role Service Provider can create organizations as needed. The organizations are separated from each other.

An organization consists of the following:

• one or more nodes and sites
• a collection of one or more product types
• a collection of Connectors
• one or more devices which reside in a particular site
• a collection of users which can perform a various tasks within the organization

In order to place Devices into the Organization, at least one Site needs to be part of the Organization.

The definition of a Product Hierarchy is optional as each newly created Organization by default already contains the top-level Product All.

Service Provider Organization¶

This Organization is automatically created when the Remote Services is provisioned to the Insights Hub tenant. It is the home organization for all users with the Insights Hub role rsv2 serviceowner. It can be used like any other Organization.

Fine Grained Access Control¶

This concept allows to enforce separate access permissions to devices, information and Remote Services functionality for different users, even with a single tenant. This is achieved across four different dimensions of access permission.

Access Control through Organizations¶

Organizations provide separation of access to information and devices on tenant level.

Access Control through Remote Services Roles¶

The Remote Services roles control access to Remote Services functionality. Depending on the role, a user within an Organization can only perform specific tasks.

Access Control through Nodes and Sites¶

With Nodes and Sites, a tree structure can be defined. Devices are the leaves on that tree because they are directly placed under a specific site.

When a user is assigned a specific role, access has to be granted as well to specific branches of this tree. Hence, the user potentially gets access to all devices on those branches of the tree.

That concept provides an attribute that can be used to classify access to devices on an Organization Level.

The Nodes and Sites not necessarily have to represent geographical location, but can be used to express any desired logical structure, e.g. departments, teams etc.

Access Control through Products¶

Similarly, a tree of Product classes can be defined.

When a user is assigned a specific role, access has to be granted as well to specific branches of this Product tree. Hence, the user potentially gets access to all devices on those branches of the Product tree.

This concept provides an attribute for a Device within an Organization but independent of its relationship with Nodes or Sites and can be used to further classify access permission.

Products actually has no explicit meaning related to Product types as such, but could also be used to model any other logical grouping within the whole Organization independent of Nodes and/or Sites.

Combining the Dimensions Controls Access¶

When a user who is part of a certain organization is given a role, the user will also be assigned permissions to certain Products and Sites and/or Nodes.

It is the intersection of these two dimensions Nodes / Sites on one hand and Product on the other hand that controls the access within the organization.

Example Scenario¶

• There is an Organization X.

• Within that Organization X, there are users A, B, C and D.

• There is a Node Europe.

• There are the Sites Germany and Italy, which are placed under the Node Europe.

• There are the Products Pump and Heater.

• There are the following Devices:

  • K of Product Pump in Site Germany
  • L of Product Heater in Site Germany
  • M of Product Pump in Site Italy
  • N of Product Heater in Site Italy

User A has the role Organization Admin for Node Europe in the Organization and all Products.

User B has the role Organization Admin for Site Germany in the Organization and all Products.

User C has the role Remote User for Site Italy in the Organization and all Products.

User D has the role Remote User for Node Europe in the Organization and Product Heater.

Thereby, the following access grants are defined:

• All these users have access only for the Organization X.

• User A has access to all devices and can define and assign Connectors to them. A also can add or delete Devices on any Site within the Organization.

• User B has access to devices K and L and can define and assign Connectors to them. B also can add or delete Devices to/from Site Germany.

• User C has access to Devices M and N and can select an assigned Connector and establish a tunnel.

• User D has access to devices L and N and can select an assigned Connector and establish a tunnel.

Devices¶

Definition¶

The purpose of a Device is to provide certain functionality, e.g. a web server, a machine control system, a compute node etc. The purpose of Remote Services (RS) is to provide access to the Device from a network for which there is no direct IP connectivity.

In RS, a Device is the representation of a software process that operates as a Device Endpoint, i.e. terminates one side of a tunnel connection.

Often, it is a real piece of hardware, where a Device Endpoint executable is installed and running, but it could also be a Docker container on a Docker host.

Typically, the Device is part of a Factory Network that is connected through RS to a Service Endpoint in a Service Network. However, it is also possible to connect two Devices in two different Factory Networks via two different Device Endpoints using the DTT-R connector.

Device Types¶

There are three types of Devices:

• Primary Target, which has an IP address within the Factory Network and a Device Endpoint installed through which it is accessed by RS.

• Gateway, which also has an IP address within the Factory Network and a Device Endpoint installed through which it is accessed by RS.

  • The Gateway provides access to one or many Secondary Targets.
  • The Gateway is configured in RS with the IP addresses of the Secondary Targets. However, it is still required that on OS level in the Gateway, the required routing is defined.

• Secondary Target, which has an IP address in a network that is only accessible through the related Gateway. It has no Device Endpoint installed and is connected to RS only through the Device Endpoint on the related Gateway.

  • An example of Secondary Targets are PLCs that are connected to a MindConnect Nano which acts as a Gateway.

Defining Connectivity via Connectors¶

An Organization Admin defines the type of connectivity that will be available to Remote Users to a given Device.

This is done by assigning one or more Connectors to a Device.

An example use case is to provide SSH access to a MindConnect Nano through assignment of an SSH Connector to the MindConnect Nano, thereby allowing access for TIA portal to an S7-1500 that is connected as Secondary Target behind the MindConnect Nano which acts as Gateway. A Proxy Unaware Connector is assigned to the S7-1500. Additionally, it is possible to assign a Web Application Connector to the S7-1500 to provide access to an embedded webserver on the S7-1500.

The Connectors enable only the connectivity to a service on a Device but not the service functionality itself.

So in this example, it is the S7-1500 which hosts the control functionality which shall be provisioned by TIA portal and the embedded webserver.

Access Control¶

A Device is always created in a specific Site. As grants to access specific Sites are given to RS users, this implies that only those users which have grants for a specific Site can access the related Devices.

A Device is always classified as a specific Product. As grants to access specific Products are given to RS users, this implies that only those users which have grants for a specific Product can access the related Devices.

For more information on access control through Sites and Product Types, refer to the chapter Fine Grained Access Control.