A client currently has an ignition gateway running that's, amongst other things, used for simple authentication instructions (no security-level authentication, just user-level customization and function-access). This is to be extended to mobile and thus remote devices that'll have access to the gateway most of the time. They're to be connected through wifi, so continuous access to the gateway will be spotty at best. Especially with only partial coverage of access points on site.
Buffering and eventually storing field-data from the EDGE to the main gateway is covered, but as I briefly touched on, the gateway is also used for authentication. This authentication has to be accessable at all times, even when the EDGE is currently not able to retrieve data from the main gateway. Obviously db-access is not an option, but I was thinking storing snapshots to memory-tags. I'm currently not able to test this as I lack the hardware, so I figured I'd shoot a quick two-part question;
is this a viable solution?
if not, what could be a viable, ignition-based solution to the described usecase?
Emphasis on ignition-based. We've got a kind-of-hacky solution running right now to achieve this, but we're trying to migrate everything into ignition in an effort to maximize maintainability and minimize the complexity of having all kinds of different software running.
Authentication is something mobile clients have to do, and with user interaction.
A "mobile" Edge Ignition instance will connect via the Gateway Area Network using certificate-based identification. Any user interface associated with the Edge instance (presuming it is Edge Panel) will authenticate with the Edge Instance it is located with, not with the upstream gateway.
Alright, looks like I missed a few crucial points.
We're not talking about an Edge Panel, this node would be strictly for gathering local information and sending it to the main gateway during 'normal' behaviour.
The authentication used to access ignition clients will be based on roles. A user will be identified by their personal badge, a user will be linked to a role.
The node (Edge-gateway) needs to store a snapshot of a list of users and their roles (dataset in a memory tag).
To be a little more detailled than the OP;
The Edge-gateway will have a badge-reader connected. Whenever a badge is presented, the Edge-gateway will be prompted with the user-id, and needs to be able to tell what role is associated with the presented badge. Finally, the role needs to be written to an OPC-tag associated with a PLC operating the (mobile) machine. Ideally, any events that occur from that moment onwards can be logged with mention of the current operator.
I'm not trying to do anything crazy fancy, as far as I know, but a colleague warned me that storing data in a memory tag as a work-around to not having db-access might not be workable. I'd love to test it, but I sadly lack the hardware to do so at this moment.
An Edge gateway that is not an Edge Panel does not offer any user interface. An Edge Panel instance allows one built-in UI on the Edge device (localhost connection) and one external UI instance (at a time) via external browser or mobile device.
Having a static list of users in a user source in Edge is not a problem, in and of itself.
Having a badge reader complicates matters considerably. You may want to call in to IA for a discussion with sales engineering.
I am aware the 'regular' Edge gateway does not offer any user interface. Strictly speaking, for the envisioned usecase there is no need for a user interface. Everything should work seamlessly when presenting a badge to the reader. Any interfacing with the machine is done natively (through the PLC) and any interfacing of the data the machine transmits to the Edge can be done through the main gateway's clients.
Having a badge reader complicates matters considerably. You may want to call in to IA for a discussion with sales engineering.
What exactly prompts this response? There are more external devices to be connected with the client that'll run the Edge-gateway who'll all be supplying the gateway with information. My knowledge as of now doesn't extend much farther than OPC UA communication, and that's been a breeze. Is it that much harder to collect data from non-OPC clients?
Yes, you will need to maintain a memory tag with a dataset of allowed badges. Or maintain that list in the PLC. You won't be using Edge's security system at all if you aren't using any Ignition clients.
You could also maintain the list as a top level constant in a library script module, or load such a constant from the gateway filesystem during script initialization. (Perhaps using JSON format to produce a list of dictionaries.)
Please explain what you mean by this. I would expect you to use the GAN to interface between Edge and Main gateway, and use sync services to push the Edge history to permanent storage on the main gateway. That can leverage the store-and-forward system to ride through poor communications.
No, unless IA doesn't have a driver for the protocol.
I'm not familiar with the process and terminology yet, I'm just going off of what I can read on the product-page of the Edge-product. Based on what you've said here, this is what I'm looking for. We're just collecting data to be sent whenever communication to the main gateway is available. And the whole badge-reader shebang, which we've confirmed is possible.
Luckily we haven't locked in on a reader yet, so we've got room to adapt to what's workable.
Thanks for the answers, looks like Edge is perfect for what I'm looking for!
Consider using a reader that connects to your PLC. So the PLC knows the user's badge and can display it locally, and Ignition can just read and report it.
Funny you say that, that's exactly what I was considering to propose to the customer. They've provided us with a concept-drawing where the reader is connected to the PC. I think their main objection is that we don't necessarily have access to the PLC software, and I'm not sure to what extend we can request access/changes. Thanks for the idea though!