[Feature]: Add Connector for Siemens SIMATIC S7

[derbl4ck]

Is your feature request related to a problem? Please describe.

Within our manufacturing company we have different protocols on the Shop-Floor like "S7", used by PLCs like S7-200, S7-300, S7-400, S7-1200 or S7-1500. The protocol is used by Siemens since the Simatic S7 product series was launched in 1994 and is still heavily in use in our industry. Our company has up to 150 PLCs using the S7 protocol per plant around the globe. The protocol is also used on top of other physical/network layers, like RS-485 with MPI (Multi-Point-Interface) or Profibus.

Protocol dependencies

S7 communication consists of (at least) the following protocols:

• COTP: ISO 8073 COTP Connection-Oriented Transport Protocol (spec. available as RFC905)
• TPKT: RFC1006 "ISO transport services on top of the TCP: Version 3", updated by RFC2126
• TCP: Typically, TPKT uses TCP as its transport protocol. The well known TCP port for TPKT traffic is 102.

Problem

Right now Azure IoT Operations does not have a connector for Siemens SIMATIC S7. Since our manufacturing engineers could use the Azure IoT Operations UI to connect more machines, we would like to see a Siemens SIMATIC S7 connector, which would help to get the high frequency data in the Azure Cloud / Microsoft Fabric in a harmonized way and protocol.

Describe the solution you'd like

We would like to see a new microsoft-managed connector for Siemens SIMATIC S7 to MQTT. Configuration is managed via UI and stored via K8s CRD-Object. Within the Azure IoT Operations UI we can see the status, e.g. "active".

Connection Settings:

• IP Adress or Hostname
• Port, default is TCP 102
• The Polling interval (time interval in which all variables will be read from the PLC) in ms
• Timeout (amount of time that the PLC may take to answer requests) in ms
• rack (int), default 0
• slot (int), default 2

Functions:

AG:

• Read/Write Data Block (DB)
• Read/Write Merkers(MB)
• Read/Write IPI (EB)
• Read/Write IPU (AB)
• Read/Write Timer (TM)
• Read/Write Counter (CT)
• Multiple Read/Write Area
• Get Block Info

PG:

• Get CPU of PLC status
• List available blocks in PLC
• Get CPU/CP Information
• Get/set value for a byte array for types: value(bit/int/word/dword/uint...), real, time, counter

Proposed implementation details (optional)

https://flows.nodered.org/node/node-red-contrib-s7 https://github.com/robinson/gos7 https://github.com/plcpeople/nodeS7 https://www.npmjs.com/package/napi-snap7 https://www.npmjs.com/package/s7-scl-gen

[ruonke]

As I understand it, IoT Operations functions as a data plane to relay your OPC formatted data(with optional processing) via MQTT into cloud. Having connectors to map "hardware x" into OPC wouldn't be in the scope of such product.

Your manufacturing engineers should connect the Siemens PLCs into Siemens Simatic OPC server to provide industry standard way for the PLCs to talk to other infrastructure via OPC.

If you need support for multiple types of PLCs, you might want to consider other OPC server products from other vendors, like Kepware, Prosys or Matrikon. (there's at least 20 others to choose from, depending on your use case)

[derbl4ck]

@ruonke I understand your point of view, but I believe that Azure IoT Operations could create more value than in the current version with a focus on data plane to relay OPC Data.

In our company, the reality is that OPC UA / MQTT is a clear requirement for new machines. However, the majority of plants consist of machines that do not yet support OPC UA or do not have an activated OPC UA server or are not yet in the right network. Some manufacturers offer retrofit packages with hardware and software to activate an OPC UA server, but these usually cost more than €1000 per PLC. Even if OPC UA is activated, every plant manufacturer and PLC programmer has their own peculiarities in how attributes are named and it takes some time to find out exactly what is behind which attribute. This is only possible with considerable travelling costs for the respective experts. In addition, there are many machines that write data to a "host computer", often as an .XML file or, more rarely, to an SQL database. Overall: The mapping of attributes takes some time and could be assisted with AI! (@DittmannAxel Im thinking about a SLM for this 😉) From a plant manager's point of view, such an investment is not always tangible, because "the machine is running and the production looks good".

deviceWISE, Kepware, Prosys or NODE-RED are certainly valid solutions for managing this situation, but integration into the Azure or Fabric world could be better and sometimes they are running on vms instead of k8s. Monitoring is difficult, patching or trust in NODE-RED packages, for example, could be way better and seamless management with Entra identities (Managed Identity ❤) is a long way off. Apart from that, it takes several IT experts to customise these respective solutions and keep them alive. Use cases in which own machine learning models are trained or integrations for older protocols are built are running in docker containers but without a clear interface standard. So how to provide a proper IoT Operations? --> With Azure IoT Operations running inside of Arc-enabled k8s 🙌🏻.

As we have the option of using Arc-enabled Kubernetes clusters at each location, we envisage maintaining all machines as Azure IoT assets in the respective custom location. Ideally, newly installed machines can be automatically created as an IoT asset and, depending on the tag/status, a suitable expert is notified for review. We can display the tenant's / subscription's IoT assets in the Web of Things (WoT) protocol. With the IoT Operations interface, we have a way of managing these assets that does not require our manufacturing engineers to have any knowledge of Kubernetes or e.g. Go-Programming. They want to be able to maintain their machines easily and directly and integrate relevant data via drag-and-drop while not using ten different tools.

Based on this story, here are adjustments that increase value of IoT Operations in my opinion:

• Custom Connectors that can be managed via IoT Operations UI: As an individual, I have no problem deploying docker containers running GoLang, which creates the necessary integration with older protocols. However, the specific values and parameters need to be managed by the Manufacutring Engineers. This works well for the currently existing connectors, so why not offer the possibility to manage custom connectors via the interface as well! This may even open up a new market for Microsoft, as Siemens and others are offering their own connectors for the respective products, which run on the powerful platform of Azure IoT Operations, just like it went with Power Apps / Logic Apps / Copilot Connectors / ....
• MES Integration: I think a connector to a product like SAP DM would help to create a standardised data highway, while different use cases can work with this data without additional effort.
• Monitoring: I find it difficult to view the status of assets in the current IoT Operations UI. I get annoyed after just a few seconds and open the console with kubectl. A Manufacturing Engineer does not have this option. They should at least be able to see something like "last message recieved 5 minutes ago" or "230 messages per hour in the last 24 hours". Of course, a live view of the topics with a web-based MQTT client or OPC UA client integrated in Azure IoT Operations UI would also be nice.
• PKI: Vision: Azure IoT Operations offers a PKI that can be used to issue certificates for the machine interfaces, such as OPC UA. This would certainly increase security on the shop floor, while management is solved in cloud-native style.
• Digital Twins: How many machines do we have at the individual locations, how many machines from manufacturer X, which machines do we currently already have connected? Which commands to they offer? What data do they send over time? What is the state of the machine? Where to put the IoT operations data? Rather in the direction of Azure Digital Twins or in OneLake within Fabric? How does this fit in with Web of Things? A clear statement and concrete example would help me here 🙂 (@barnstee Can you situate Web of Things in the context of Azure IoT Operations?)

I hope I have been able to describe the situation a little better and I am very curious to see how Azure IoT Operations positions itself, as I am convinced of the powerful technical basis, but believe that you can get much more out of the product than is currently the case.

[barnstee]

@derbl4ck, Web of Things (WoT) Thing Descriptions (TDs) can be used to describe non-OPC UA-enabled assets as well as their mapping to OPC UA. WoT TD files can therefore be sent to industrial connectivity software to configure connected asset in them. Now that the WoT-Connectivity standard spec has been released (see https://reference.opcfoundation.org/WoT/v100/docs), I am working with our industrial connectivity partners to get this integrated.

Regarding your feature request: It is our strategy NOT to provide industrial asset connectivity and data mapping/normalization services (to OPC UA) but instead partner with industrial connectivity software providers to do this for us and our customers.

We did however contribute an open-source reference implementation to the OPC Foundation (see https://github.com/OPCFoundation/UA-EdgeTranslator) to show the industry what we believe industrial connectivity software should provide, i.e. it implements the aforementioned WoT-Connectivity spec and it allows mapping of industrial assets to specific OPC UA asset types defined in OPC UA Companion Specs directly loaded from the UA Cloud Library. Since this is supposed to be a reference implementation only, it currently supports Modbus assets only.

However, feel free to add support for Siemens PLCs! :-)