Open

Channel 0 - RTE Communication Channel

Is used to interface the specific protocol stack.

• By using the protocol stack API directly, the user can build quite any kind of application on the host CPU, benefit from low latencies, and use specific protocol services.

Channel 0 Configuration

• Communication channel is configured either by packet or database. Please refer to the related LFW documentation.

Channel 1 - Network Services Channel

Provides Network Services on the second communication channel in DPM and has two modes: raw ethernet (also known as NDIS mode) or socket interface.

• Raw Ethernet Mode uses the additional MAC address of the netX HAL to send and receive raw ethernet frames. The user can implement any kind of protocol on the top of this interface, e.g. connect their own TCP/IP stack.

• Socket Interface can be used via Socket API and uses the IP address of the netX. User can implement socket based protocols or functions such as connecting their own web server, FTP server, etc., or perform UDP communication.

• Additionally, an interface (called WebIF API) to the integrated Webserver can be enabled on this channel. The user can provide their own HTTP content, processing the HTTP GET, POST, etc.

Channel 1 Configuration

There is no configuration required. The channel behaves as the related LFW network services channel.

Channel 2 - IoT

Provides an interface to IoT protocols such as OPC UA or MQTT.

• netPROXY is used to provide a defined structured data interface to the user application. The user can transfer the IoT data via the netPROXY API.

• The firmware converts the data representation to the specific IoT protocol, such as OPC UA or MQTT, and handles the protocol requests on the network.

This allows the user to add easily add IoT functions to the device without needing to do a major rework of the already existing user application.
There will be no impact on the existing user application based on the standard "Protocol LFW with Network Services" if the third communication channel (IoT interface) is not used, so it is a backward compatible solution.

Channel 2 Configuration

• OPC UA Configuration is supported by the Communication Studio tool with added IoT Configurator.

  • User specific OPC UA Information Model can be imported as XML into Communication Studio.

  • User specific netPROXY object can be defined and instantiated in Communication Studio.

  • User can map OPC UA Information Model elements to the netPROXY objects.

  • Resulting configuration is downloaded to the Channel 2 of the device.

    • CONFIG.NXD - netPROXY object configuration database (same as for MQTT)

      • OPC UA Server configuration objects

      • User defined netPROXY objects

    • OPC_INIT.TLV - OPC UA Server Information Model configuration and netPROXY Object mapping information.

    • UACONFIG.NXD - Contains information for OPC UA Structures created/used/defined in Communication Studio.

    • UASERVER.CFG - Contains OPC UA Server configuration in relation to include the Application firmware during startup or not.

• Note: it is not intended to define and model the OPC UA Information model directly in CS.

  • There are third party tools available for this (i.e. see UaModeller or Siemens Siome).

  • Or existing well defined models shall be used.

    • https://opcfoundation.org/developer-tools/specifications-opc-ua-information-models

• No Web Server content builder supported - predefined WBM content is provided instead.

  • User can create own webserver content which uses mapping of netPROXY objects to webserver. E.g. the netPROXY Object data can be integrated into user specific WebUI.

• MQTT Client

  • User specific data are possible to publish or subscribe over the customers netPROXY objects.

    • CONFIG.NXD - netPROXY object configuration database (same as for OPC UA).

      • OPC UA Server configuration objects

      • User defined netPROXY objects

Technical Data

The technical data of the IoT Solution LFW include the properties defined by used RTE protocol stack components as well as the integrated OPC UA server and MQTT client and other components.

The description is made public with Technical Data - V2

FAQ

Is the usage of IOT without configuring RTE side possible/supported?

• To cover this use case, the firmware variant Open Modbus TCP can be used.

How configuration of webserver content is supported?

• The web server supports a number of features that are accessible though a dedicated API. Each feature is associated to a URL. (see documentation Web Server + REST API - Component Description)

• File System Access - This feature serves to read a file located in the /PORT_1/web/ directory of the file system using the requested URL. In addition to the possibility to serve the files stored in the file system directly, the file system may contain a file /PORT_1/web/content.tar (PORT1 relates to DPM Channel 1). If this file exists, the files stored in the file system are no longer considered resources, except for the file entries in the archive.

Target Products

IoT Solution LFW will be provided for the following netX90 based products.

Definition of Firmware Functions

Technical Data IoT Channel

IOT functions integrated OPC UA Server v2.x with netPROXY Adapter

• OPC UA Server

  • Node to netPROXY object mapping is limited to 1-to-1 read/write relation and netPROXY data types

    • mapping for the OPCUA methods supported

  • OPC UA strucutured data types

  • User Management (Role based authentication and access rights)

  • Support security via OPC UA Push Management

• MQTT Client

  • Topic to netPROXY object mapping is limited to 1-to-1 read/write relation and netPROXY data types

• Webserver (PSHTTP) Config Use Case C with netPROXY

  • User management (e.g. add user, change passwords) Authentification management only over HTTP (no DPM access)

  • support of HTTPS connections

• Authentication Manager

  • Centralized Username/password/role management

• NTP (Network Time Protocol) Client

  • for netX System time which will be used for OPCUA time stamps generation.

Firmware Security feature in detail

Security requirements

IOTLFW will be continuosly improved with security features.

• support secure boot (since release V2.3)

• support User Authentication and Management (User Database)

• support RBAC (role based access control)

Configurable (IoT)-protocols

OPC UA Server

• The OPC UA Server has to be activated for comminucation by the related netPROXY OPC UA Server configuration object. Other case the OPC UA Server does not open any TCP port. Furthermore it is possible to stop the communication and the TCP interaction during runtime.

MQTT Client

• The MQTT Client has to be activated for comminucation by the related netPROXY MQTT Client configuration object. Other case the MQTT Client does not open any TCP port. Furthermore it is possible to stop the communication and the TCP interaction during runtime.

SNMP

• The SNMP protocol component offers the possibility to be enabled/disabled at runtime.

Webserver

• The webserver offers the possibility to be enabled/disabled at runtime.

netIdent

• Can be disabled via taglist. It can not be enabled at runtime and no one requested this up to now.