I’ve been reading through the Deployment Best Practices and trying to design our Ignition layout for the future.
One of the big challenges we’re trying to overcome is the lack of testing and dev environments thus far. Of course once we want to build environments, we need to figure out how to have the same tags(preferably in the same places and under the same names) available to the various gateways so that we can test against a config that represents Prod well.
As I’m considering options, the use of the Gateway Network seemed obvious, given it’s simplicity. But under the Deployment Environment section of the best practices, it’s listed as “not generally recommended” without much description of why.
It seems I’m to prefer the method using MQTT, but it will cost an additional $3200 per prod gateway and $1900 per test gateway. But I’m not sure what the primary benefit to be gained here is. I’ll also probably want to run a distinct MQTT broker just to avoid piling all the traffic onto an actual gateway.
Is this just a matter of MQTT being that much more lightweight or am I missing something at a higher level? It just seems odd to have a general recommendation in the best practices guide without a clear indication of why that is. Or maybe I missed it somewhere, I’m not the most thorough reader there ever was.
Ideally development environments are completey separated out from the production environments so there is no risk of affecting production. As we note in the guide, the development environment should have a dedicated SQL database, dedicated PLCs, and any other peripherals.
When it comes to the PLCs, most customers don’t have dedicated devices for testing. That leaves you with a few options:
Use Ignition’s Programmable Device Simulator - The device would have the same name but a different driver type. This allows you to simulate tags with the same OPC Item Paths as the real PLCs. This is the best method as you can test everything out without touching production. Especially, if you need to test recipes or any logic that writes back to the PLC.
Leverage the Gateway Network or OPC-UA - Connect the development environment to the production environment using our Gateway Network’s remote tag provider or OPC-UA. This works well but generally you want to ensure the connection is read-only so there is no chance of writing to a production PLC on accident. The real reason we don’t recommend these methods is because we are putting additional load on production system and if you don’t have the settings correct you can accidentally change a value in production.
Leverage MQTT - MQTT is a message oriented middleware protocol. The production system will publish tags to a MQTT server that the production environment can subscribe and the development environment could subscribe to. This allows you to get real time data in development without affecting production. However, just like the Gateway Network you want to ensure the tags are read-only. You can do that through ACLs on the broker or using MQTT Engine’s setting to block tag writes. This method only really works well if both sides are using MQTT. If your production environment is not using MQTT, I wouldn’t recommend this since the tag paths will be different on your screens in the two environments. Plus as you pointed out there is an additional cost.
So, it is not a matter of MQTT being more lightweight. It has to do with separation of concern. Hope this helps.
Last I checked, the programmable device simulator was woefully inadequate when simulating complex tag trees--not even supporting the full stop character as a folder separator (necessary for AB Logix and Omron NJ/NX emulation). Has this changed in recent months?
Simulation would be great, I imagine, if you had a lot of homogenous device types. Alas, I do not. I’m reasonably certain any solution along these lines is just impractical with the varied device types we’ll be supporting. I envy whoever can manage it.
As I understand it then, the suggestion is to have gateways(we have multiple locations) send their data to MQTT broker/s and then subscribe the gateway back to the same data in order to have “identical” connections between environments? I guess there are some wicked high-performance brokers out there so I’m not worried about breaking whatever VM that lives on, but it would seem an administrative burden to send every tag to a broker and back. I’ll have to dig into this a bit because it seems like it would also interfere with a how I structure tags and providers, since splitting stuff up just makes the config more complex.
I hadn’t thought of the Gateway Network increasing load on production, I assumed sharing those tags wasn’t significant relative to anything else I’d do with them. Bad assumption, glad I checked it.
Coming back about this after talking internally, I had a couple more questions.
In order for the MQTT suggestion to separate concerns, I would need to deploy a dedicated MQTT broker of some description, would I not? I’m not particularly bothered by that but we’re trying to make sure the idea we believe we have is consistent with the recommendation.
Because we have multiple production facilities, each of which we want to equip with an Ignition gateway to manage their needs, I’m inclined to think we’d want to deploy brokers at each location and then bridge them back to a central broker that the dev server could subscribe to. This would help avoid giving local applications trouble when the connection to the central broker is not stable. Does this sound reasonable? I’m trying to capture the benefits you’re espousing without losing some of our goals in the mix.
This would require MQTT Transmission on every Prod gateway and MQTT Engine on every gateway in the landscape, correct? I’ve had a hard time nailing down the distinction in terms of overlapping functions.
Yes, you are correct. You can use our MQTT Distributor or any 3rd party MQTT broker.
Yes, this is reasonable. In order to keep the solution isolated at the production facility you will have to have a local MQTT broker. You can leverage MQTT Transmission along with MQTT Engine to retransmit to a central broker.
Yes, correct. The MQTT Transmission module publishes tag values as they change. The MQTT Engine creates a tag provider, discovers the tags, and builds tags for you. That way you can use the tags for display or history or whatever. MQTT Engine can write back to tags but it doens’t transmit tag data. So, in this case MQTT Engine would discover the tags and you would use MQTT Transmission to retransmit them to another broker.