Versions Compared

Old Version 19

changes.mady.by.user Martin Lang

Saved on

compared with

New Version 20

changes.mady.by.user Martin Lang

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Section

Column
width70%

About

The IoT Solution LFW is available for netX90 based products. The IoT Solution LFW enables customers who have implemented the RTE protocols (PROFINET Device, EthernetIP Adapter, etc.) as main functionality to extend the device with new IoT functions in a compatible way.
This means that RTE functions are provided using the same RTE channel 0 in DPM and network services using the same channel 1 in DPM.
An additional channel 2 is provided to enable the use of IOT functions. The IOT functions are the integrated OPC UA server and MQTT client packages, which are able to represent the customer specific data model of the device.

The firmware described in the provided document offers various use cases through its integration of real-time Ethernet protocols (PROFINET and EtherNet/IP) and IoT protocols (OPC UA and MQTT). Here are the possible use cases and the resulting test cases:

Use Cases

The use cases describe the versatility and application potential of the firmware in various industrial sectors.

Asset Management: Manage and monitor physical devices and assets within a network. (e.g. https://opcfoundation.org/developer-tools/documents/view/339)

Condition Monitoring: Monitor the condition of machines and devices in real-time. (e.g. https://opcfoundation.org/developer-tools/documents/view/291)

Diagnostics:Diagnose errors and issues in machine control and communication. (e.g. https://opcfoundation.org/developer-tools/documents/view/213)

Extended Configuration & Parameterization: Advanced configuration and parameterization of connected devices and networks.

Visualization: Visualize data and statuses of connected devices via web applications.

Predictive Maintenance: Predict and plan maintenance activities based on data analysis. (e.g. https://opcfoundation.org/developer-tools/documents/view/316)

Data Logging and Analytics: Log and analyze historical data for performance trends and insights.

Remote Monitoring and Control: Monitor and control devices remotely through IoT protocols.

Energy Management: Monitor and optimize energy consumption of connected devices. (e.g. https://opcfoundation.org/developer-tools/documents/view/348)

Supply Chain Optimization: Optimize supply chain operations by tracking and managing logistics data.

Environmental Monitoring: Monitor environmental conditions (e.g., temperature, humidity) for compliance and safety.

Description

IoT-related communication protocols are becoming increasingly important for industrial automation devices. Device manufacturers, machine builders and system integrators need to add OPC UA or MQTT to their products. With the IoT Solution Loadable Firmwares, Hilscher offers a platform for such embedded developments at the field level. IoT protocols can be used in parallel to Real Time Etherent, over the same network cable.


Smooth integration

The different variants of Loadable Firmwares - LFWs - for netX 90 and netX 90 based products form a scalable range offering different levels of functionality. The IoT Solution LFWs are the full-featured Type 4 variants. They extend the standard protocol LFWs, such as PROFINET IO-Device V5, with IoT functionality. In addition to the Real-Time Ethernet protocol functions, these firmwares provide an OPC UA server and a MQTT client. The additional IoT functionality can be accessed by the application via DPM channel 2 (the 3rd DPM channel). This means that the new IoT Solution LFW will maintain the protocol and Ethernet functionality previously available on DPM channels 0 and 1. New IoT functions are added via DPM channel 2.

The IoT Solution LFWs require external SDRAM and serial flash for netX 90 due to the demanding resource requirements of IoT protocols.

Host Application access

Access to OPC UA or MQTT data is abstracted using netPROXY technology. Users don't have to bother with OPC UA or MQTT related details, they just have to access the data objects. Read and write actions to the user data objects (IoT data) can be performed from the host application using netPROXY Host API functions (Read / Write Object Element) serialised via DPM using acyclic messages. The "IoT functions" via DPM channel 2 (3rd DPM channel) are fully acyclic (no cyclic data mapping is supported) and have a lower priority than the real-time Ethernet communication/cyclic data of DPM channel 0.

In addition to the OPC UA server or MQTT client, user data objects (IoT data) can be published by the integrated web server in parallel (same data via Web server and OPC UA server/MQTT client). The data can be embedded in user defined web pages. Please refer to the Webserver API manual for further information.

The netPROXY Host API is based on the cifX API and is therefore on a higher abstraction level. It is an implementation of the netPROXY mailbox package API. Users don't have to deal with sending and receiving mailbox packets, but use simple Read/Write object functions. Alternatively, users can bypass the netProxy host API and use the mailbox packet interface directly. This can be useful for limited host resources and simple object models.

The netPROXY Host API component is provided in source code as part of the example projects for the IoT Solution LFWs. The component is not a product but a example implementation of the mailbox packet interface.

Configuration

The OPC UA server and the MQTT client component are configured using the PC-based engineering tool Communication Studio with the additional IoT Configurator extension. The tool supports the creation and import of OPC UA information models or MQTT client connection and topic settings. User Data Objects can be defined and instantiated. The OPC UA server and MQTT client configuration is exported from the tool as a config.nxd plus a *.tlv file and optionally a uaconfig.nxd. These up to three configuration files must be downloaded to the flash memory, directory PORT_2 (relates to DPM Channel 2 - IoT Services). The netHOST utility (part of the NXDIAG package) can be used to do this.

The RTE stacks can be configured via data base files (generated with Hilscher's Communication Studio) or via the DPM's mailbox interface (refer to the corresponding API manual). For more details see Firmware configuration.

Block diagram

The IoT Solution LFW with Network Services provides three communication channels in DPM. The Channel 0 and 1 maybe known from the protocol specific LFWs.
The IoT Solution LFW provides a third communication channel additionally, which adds an IoT interface.

Column
width30%


Panel
bgColor#FFFFFF
titleOn this page

Table of Contents


Block diagram

Image RemovedImage Added

Channel 0

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 1

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 2

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.

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.

Product

Reference board/module

LFW variants

netX90 SoC

NXHX 90-JTAG

  • SPM serial Dual Port Memory

  • Type 4, use case C firmware variant

  • external SDRAM and serial flash required

netRAPID90 module

NRPEB H90-RE

  • SPM serial Dual Port Memory

  • Type 4, use case C firmware variant

  • Type NRP H90-RE\F8D8 required

cifX M2 PC card

Definition of Firmware Functions

Firmware / Function

Channel 0 , Channel 1

Channel 2

PROFINET IO Device with IoT

same as PROFINET IO Device Technical Data - V5 (Use Case C)

see below

EthernetIP Adapter with IoT

same as EtherNetIP Adapter Technical Data - V5 (Use Case C)

see below

Open Modbus TCP Server with IoT

same as Open Modbus TCP Server Technical Data - V5 (Use Case C)

see below

EtherCAT Slave with IoT

same as EtherCAT Slave Technical Data - V5 (Use Case C)

see below

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.