• State Not Answered
  • Replies 4 replies
  • Subscribers 17 subscribers
  • Views 245 views
  • Users 0 members are here
Options
Related

Does OMI require a connection with the System Management Server to run correctly?

Patrik Bodelid

Hi,

In a distributed solution we have made an architecture where the main servers are running in a virtual environment. But some remote sites are connected with 4g and on these sites we have a local computer with a platform deployed with application objects, an OMI application and an OI server connected to a local PLC. This platform is part of the same galaxy and the System Management Server is the GR node.

The plan was that if the 4g connection goes down the objects and OMI application and OI server would continue to run locally and historian data would be buffered in store forward. However what we experience when the connection goes down is that OMI gets bad quality on all attributes. However, objects are having good quality on its attributes, so it seems the issue is OMI getting data via PCS from the objects.

So the question is: Is OMI reliant on connection with the GR node/System Management Server to be able to run? Is there a way to make this "island mode" work in case of lost connection. Or do we need to make a separate galaxy with a local System Management Server for it to work?

  • 0

    It should only be reliant on the SMS server connection for its original setup and delivery of the certificate.  It should then be able to talk to other nodes using that certificate.  Are the objects that OMI is pointed to on that platform?  Your description makes it sound like they are.  In this situation, on the OMI machine, can you open the Object Viewer and see the data?  If you are able to see it in ObjectViewer, and OMI still indicates it cannot, I would recommend calling into your local support provider and getting a case created.

  • 0

    It seems to be an architecture related issue. In your configuration, all OMI clients on remote sites are getting data from AOS servers hosted in the virtual environment via the 4g connections. The OMI clients will lose the connections to the AOSs when the 4g network is unavailable. An OMI client cannot directly talk to an OI server even they are running on the same node. So, to have the "island mode", each remote node should be configured with

    • Platform
    • OMI client
    • OI server (communicated with a local PLC)
    • AppEngine (configured to talk to the local OI server. It also possible to have a redundant AppEngine in the virtual environment)

    In this architecture, an OMI client on a remote site will be able to receive the data from its local AppEngine when the 4g network is down.

    Hope this would help.

  • 0 in reply to Jacky Lang

    The setup you mention is the one we are using with a platform and local appEngine and viewEngine on the remote node.

    So I can verify that objects can receive data from the local OI server, but the OMI application cannot get data from the objects. This is also apparent when store forward data to the historian is coming in once the connection is restored.

    What I could see in the logger is that the component ArchestrA.RuntimeData.PcsRuntimeClientDataProvider reports the warning "Failed to get endpoint for connectionString: [Galaxyname]

  • 0 in reply to Patrik Bodelid

    The warning indicates that aaMXDataProvider service is not available on this node. To verify if this service is deployed,

    • launch IDE with the deployed galaxy
    • Go to Galaxy\Configure\System
    • Click on Services
    • Configure Services Window will be launched
    • Click on the tab of Nodes at bottom
    • Locate the target node and confirm if Default_[Galaxy Name]_MxDataProvider is deployed

    Also it is worth checking PCS configuration with Common Services Portal (SCAN)

    Your environment is configured with dual networks. So, DNS names should be used in Platforms' network addresses instead of IPs

    If the problem cannot be resolved, you should reach out to the AVEVA technical support for further troubleshooting.

© 2025 AVEVA Group Limited or its subsidiaries. All Rights Reserved.