Add Product requirements

Thoughts

Currently there are some problems, where the current PN driver differs from other drivers:

1. The ip address of the connection string doesn't refer to a remote IP address, but a local one
2. The connection establishes a connection to multiple devices, which are identified by an array of "devices" in the connection string options

The main reason for this is that the current version of the driver needs to open a UDP port on port 32949 and it sets up for accepting incoming PN IO packets on the raw socket.

This results in only one connection being available on one computer and IP address.

I know there are other drivers where we have similar problems (BACnet)

I would like to introduce something like a "SingletonTransport" ... this would be one transport for which only one instance exists on a given system (Well we would probably only enforce one per VM as everything else would be very tricky).

So if a driver needs one of these SingletonTransports, it accesses that and registers itself as recipient together with a callback that allows for the SingletonTransport to decide if a packet is targeted at a given connection (I am sure every protocol that requires such a concept will also have connection information in the packet).

Assuming we had such a SingletonTransport, I would like to change the PROFINET driver to accept an IP of the remote device in the connection string and to use a set of default locations for gsd files (which can be overridden by the connection string ... something like "~/.gsd") ... the driver would simply initialize some local variables by creating the initial contact, getting the vendor-id and product-id and looking up the gsd-files, then getting the MAC addresses and all the stuff needed for establishing a connection. If this worked, the connection would be established, but no data would be exchanged.

As soon as the user executes a SubscriptionRequest, the driver would setup the PN IO connection and initialize the cyclic connection between the PN-Master and -Slave and data would start to be exchanged.

I would like to explore, if PN devices would gracefully handle changes to the subscriptions ... so whenever a new Subscription is added or something is unsubscribed, I would suggest to try disconnecting from the PN device first and then setting up a new connection with the updated fields.

When it comes to writing, the PN driver would need to work differently to the normal Write operation. In normal writes there is no real setup needed for writing, here however we would need to setup which parameters we want to write and they would need to be written on every cycle. I would therefore propose to add a Publish API that mirrors the Subscription API. Here a connection is prepared for allowing to publish values to the PN device and it would be initialized with fields and default values ... these would be kept in memory throughout the connection (or much more until an "Unpublish" operation is executed that removes them). On every cycle the PN IO Driver would take these values and publish them ... as soon as the client executes a Publish action, this internal memory would be updated and on the next publication the updated values would be sent.