AVEVA™ Products Feedback Portal

Welcome to our new feedback site!


We created this site to hear your enhancement ideas, suggestions and feedback about AVEVA products and services. All of the feedback you share here is monitored and reviewed by the AVEVA product managers.

To start, select the product of your interest in the left column. Then take a look at the ideas in the list below and VOTE for your favorite ideas submitted by other users. POST your own idea if it hasn’t been suggested yet. Include COMMENTS and share relevant business case details that will help our product team get more information on the suggestion. Please note that your ideas will first be moderated before they are made visible to other users of this portal.

This page is for feedback for specific AVEVA solutions, excluding PI Systems and Data Hub. For links to these other feedback portals, please see the tab RESOURCES below.

Add a new idea Subscribe
Portfolio area Device Integration
Created by Deon van Aardt
Created on Oct 25, 2024

RELATED IDEAS

Proper MQTT Support

Note that I am no MQTT expert, but theses are the things I have picked up.

We need to embrace MQTT in a generic way from the Operations Control Portfolio. We need to be able to adapt to a variety of of topic name space structures and to many different JSON payload structures.

  1. Publish capability must have a configurable topic structure. This should default to the name space of the source. I.e. System platform model name space. BUT you must have the capability to modify the topic hierarchy to suit the destination broker name space.

  2. Publish capability must have a customisable JSON message structure for payloads. A default JSON structure should be provided, but the user must be able to modify this format to suit the destination system requirements.

  3. Publish capability should have the ability to roll up data points in to higher level topics. I.e. InTouch might have a number of tags associated with a device. The requirement might be that all these tags must be packed in to the payload of a topic and not be exposed as seperate topics.

  4. Subscribe capability must have the ability to unpack complex JSON payloads and distribute to tags or datapoints. This is required so that we can integrate in to any payload structure.

  5. Publish capability should include an "auto" publish option. I.e. if new tags or objects are added in an AVEVA application, it should automatically start publishing. These should be controlled by pre-defined rules.

  6. Keep support for plain text payloads for subscribe and publish

  7. Keep support for Sparkplug subscribe and publish, but available for all apps

  8. Keep support for store and forward

  9. Have a configuration for items like last will/testament and birth

  10. We need to provide users the option to use our own broker - AVEVA needs to provide a broker (On prem as a start as there are many cloud brokers available)

  11. We need to provide a broker browsing facility so that the user can browse the broker namespace and link topics to tags or data points.

  12. InTouch and System Platform must be able to have these capabilities - hence one driver or platform

These are just some I know is required - there may be lots more requirements. So it would be good that you get some seasoned MQTT people involved.


  • Attach files
  • Admin
    Rickard Norin
    Reply
    |     Nov 26, 2024

    That is a fantastic list of suggestions . I cannot commit to everything at once so I'll comment on each of the points.

    1. Point taken. Our primary focus is to complete the existing topic formats and to embrace standards where applicable, but we may also look at some of the vendor specifics such as the various MQTT-ish interfaces in Azure.

    2. I acknowledge the need for payload composition/intepretation capability. We likely need to address this beyond MQTT since also REST APIs require JSON formatting/mapping capabilities.

    3. For InTouch, this will likely tie in with UDTs, at least for our own JSON-VTQ2 format.

    4. Same as 2) but inbound.

    5. This will likely be part of UDTs, where instances will publish automatically if configured to do so in the template.

    6. Agree.

    7. Agree, and underway.

    8. A must.

    9. Under consideration

    10. Under consideration

    11. Planned for InTouch, with the aim to apply across portfolio over time.

    12. We're aiming for common and consistent functionality across the products.