Merge pull request #225 from w3c/ege-meetup29

Meetup 29

Author: egekorkan

Meetups/29/2025-10-16-minutes.md

@@ -0,0 +1,216 @@
+Meeting Minutes
+===
+
+:::info
+
+:date: **Date:** 16 October 2025
+
+### :bust_in_silhouette: Participants
+
+<!-- This list will copied over from the meeting tool -->
+- Ege Korkan
+- Erich Barnstedt
+- Abiodun Busari
+- Yagiz
+- Piotr Sowiński
+- Danilenka Anastasiya
+- Muhammad Ashfaq
+- Kunihiko Toumura
+- Tomoaki Mizushima
+- Kerem Coban
+- Wolfram
+- Jens Henninger
+- dsr
+- Niko D’Agostino
+- Manuel Weber
+- Henk
+- Prerna Juhlin
+- Wouter Bunthof
+- Gregor Schuetz
+- Jens Henninger
+- Karl Ledermann
+- Alexander Schmidt
+- Sebastian Kaebisch
+- York Schmidtke
+- Matthias Meier
+- Yusuf Koç
+- Mehmet Barış Yaman
+- Daniel Peintner
+- Klaus Hartke
+
+### :scroll: Agenda
+
+:writing_hand: **Scribe:** Ege
+
+----
+
+### Introduction
+
+Ege: Welcome Everyone! we are at Meetup 29th! All slide are public
+Ege: You can find us in different places on the web
+
+### News
+
+Ege: New tutorials, new event in Japan.
+
+### Meetup Presentation
+
+#### Intro
+
+Ege: Welcome everyone. With us here today is, first of all, Erich Barnstedt, who works at Microsoft. Erich started in the Windows team and later joined the Azure team, where he worked in the automotive and manufacturing verticals. He founded the Windows and Azure Industrial IoT teams, and if you’ve encountered any industrial IoT product from Microsoft, you’ve probably seen his name.
+
+Ege: Erich has also been deeply involved in industrial standards and their use within Microsoft, as well as in the company’s commitment to open source. Currently, he serves as a Senior Director and Architect at Microsoft’s Corporate Standards Group. So, welcome Erich.
+
+Ege: On the other hand, we also have Sebastian Kaebisch, who is a Principal Key Expert at Siemens in Munich, Germany. He focuses on the efficient realization and use of standardized Internet and web technologies across the industrial IoT domain.
+
+Ege: You’ve probably seen Sebastian’s name in various strategic initiatives, research efforts, and development projects within Siemens’ business units and beyond—especially in industrial and building automation domains. He’s also the co-chair of the W3C Web of Things Working Group and the OPC UA binding initiative at the OPC Foundation.
+
+Ege: And with that, we’ll start today’s presentation. The topic, of course, is the Web of Things. So, Erich and Sebastian, the floor is yours.
+
+#### Erich's Presentation
+
+Erich: Thank you so much, Ege. I’m going to focus my presentation on the mapping from the Web of Things to OPC UA, while Sebastian will focus on the mapping from OPC UA to the Web of Things.
+
+Erich: You already heard where I work. I’m also the chair of the Cloud Initiative inside the OPC Foundation. What you’re seeing here today is a major part of that Cloud Initiative, which brings together all cloud-related technologies within the OPC Foundation.
+
+Erich: One thing we constantly hear from members is that their biggest challenge is vendor lock-in, which can come in many forms. You might be forced to use a specific SDK, interface, communication protocol, or data model—but you can also be locked into certain software platforms or even specific hardware.
+
+Erich: To avoid vendor lock-in, we need four things: a standardized interface, a standardized data format, a standardized data model, and standardized semantics. These four elements together enable interoperability and freedom from proprietary ecosystems.
+
+Erich: OPC UA, as the leading industrial interoperability standard, places interoperability at its core. For example, if you buy a modern industrial robot that supports OPC UA, you’ll find that it exposes a client-server interface, uses a binary data format defined by the OPC UA standard, and provides a powerful information model for describing data and relationships.
+
+Erich: The OPC UA modeling language is extremely capable and extensible, allowing for inheritance and complex relationships beyond simple parent-child hierarchies. It also includes companion specifications that define shared semantics for different asset types—such as robotics.
+
+Erich: This means that if your robot supports OPC UA, you can use it without being locked into the manufacturer’s ecosystem. However, not every industrial device is a robot. If you’re working with a smaller device, like a Siemens energy meter, you might find it only supports simpler interfaces such as Modbus.
+
+Erich: In those cases, you’re often stuck with a PDF manual describing register mappings, data formats, and semantics. This is exactly where the Web of Things (WoT) can help—because WoT covers that gap by defining machine-readable descriptions of devices and data models.
+
+Erich: In WoT, we use JSON-LD as the data format. The data model is defined in a Thing Description (TD), and the semantics are provided through protocol bindings. Together, these make devices self-describing and interoperable.
+
+Erich: Ideally, the Thing Description would be provided by the asset vendor. In fact, Siemens has already published a Thing Description for their SENTRON PAC energy meter on GitHub. But for the many devices that don’t have OPC UA built in, manufacturers often need to map each asset to a common interface such as OPC UA.
+
+Erich: Many companies do this using industrial connectivity software—software that connects to proprietary devices and translates their interfaces to OPC UA. Our idea was to feed that connectivity software directly with a Thing Description to automate the mapping process.
+
+Erich: So, why is OPC UA so important? It’s because it’s open, interoperable, and globally adopted. The OPC Foundation has over 1,000 members now, and OPC UA’s success is driven by three key properties: interoperability, open-source reference implementations, and scalability from sensor to cloud.
+
+Erich: The data modeling language is powerful yet simple. Everything is a node, and the overall structure forms a graph—allowing for flexible relationships and references between nodes. OPC UA also offers best-in-class security for operational technology, including certificate-based authentication and built-in authorization.
+
+Erich: Security standards in OPC UA continue to evolve to stay ahead of emerging threats. The semantic layer—defined through companion specifications—has grown massively, with the German Machine Builders Association (VDMA) leading efforts to create semantic models for hundreds of asset types.
+
+Erich: As new asset types appear, new companion specs are created or updated, ensuring continuous evolution and broad coverage across the industrial domain.
+
+Erich: Now, let’s talk about industrial connectivity software—these are the tools used to connect proprietary assets and expose them via OPC UA. They act as translators, with a northbound OPC UA interface to clients and a southbound interface to various device protocols.
+
+Erich: These software solutions—sometimes called protocol drivers or protocol bindings in WoT terminology—allow interoperability across many vendor ecosystems. Our vision is that all of them will eventually support Web of Things Thing Descriptions as input for automatic configuration.
+
+Erich: The scale of the challenge is huge. Roughly 10% of industrial assets are discoverable, meaning they can self-describe their data models. However, around 90% of assets are not discoverable, which means we need external descriptions like Thing Descriptions to onboard them.
+
+Erich: Of that 90%, about two-thirds are fixed-function devices, meaning their data models never change. For these, you can create a Thing Description once and ship it with the product. The remaining third are programmable assets like PLCs, whose data models change with every software update.
+
+Erich: For programmable devices, the only way to generate a Thing Description is to extract it from the engineering project used to program the PLC. Siemens, for instance, is working on generating Thing Descriptions directly from their TIA Portal engineering tool, and similar capabilities are being explored by other vendors.
+
+Erich: Technically, this is fully possible—it just needs to be integrated into engineering software. Customers will ultimately need to demand this functionality from vendors to make it standard.
+
+Erich: You’re probably already familiar with what a Thing Description looks like, so I’ll skip the basics. What we’ve done is create an interface that allows industrial connectivity software to accept a Thing Description and automatically map an asset to OPC UA.
+
+Erich: Implementing the interface was relatively straightforward. All these connectivity platforms already expose an OPC UA server, so we extended that interface to allow uploading Thing Descriptions.
+
+Erich: We then explored whether Thing Descriptions could be generated automatically. When we started this work, large language models like GPT-3.5 were just emerging, and later GPT-4 significantly improved results. We found that GPT-4 could generate Thing Descriptions with about 90–95% accuracy using simple prompts.
+
+Erich: We shared this on LinkedIn and received a strong response, which led us to start a working group inside the OPC Foundation to define a standardized interface for this capability. We also launched a second group focused on improving large language models for generating accurate Thing Descriptions.
+
+Erich: The result was a new companion specification, not for a specific asset type, but defining the interface for uploading Web of Things files to industrial connectivity software. In version 1.0, we introduced two main methods: CreateAsset and DeleteAsset.
+
+Erich: CreateAsset creates an endpoint in the connectivity software and uploads the Thing Description via OPC UA’s existing file transfer mechanisms. DeleteAsset removes the asset definition. This was sufficient for version 1.0, along with an open-source reference implementation on the OPC Foundation’s GitHub.
+
+Erich: Feedback came quickly. Users wanted more functionality, so we released version 1.1, which added optional convenience methods such as connection testing, asset discovery, configuration, and licensing support.
+
+Erich: For discoverable assets, Thing Descriptions can now be generated automatically during discovery. You can also download an existing Thing Description, modify it locally, and re-upload it—enabling two-way synchronization.
+
+Erich: The specification is available for free download on the OPC Foundation website, and you don’t need to be a member to access it.
+
+Erich: As part of this, we created an open-source project on GitHub called UA Edge Translator, which serves as a reference implementation. Alongside it, we developed a simple UI tool to test the interface and onboard assets in three steps using ChatGPT.
+
+Erich: In the workflow, you enter the make and model of the asset, generate the Thing Description via ChatGPT, optionally edit and validate it using Siemens’ WAT Editor (hosted at the Eclipse Foundation), and then upload it to UA Edge Translator via OPC UA.
+
+Erich: Once uploaded, the asset appears in the OPC UA address space and can be viewed using the standard OPC UA client. The system already supports mapping Siemens’ SENTRON PAC energy meters and many other device types.
+
+Erich: The UA Edge Translator fits into the broader OPC Foundation Cloud Initiative architecture. It provides on-premises connectivity and integrates with cloud and enterprise systems. It now supports 11 southbound protocols—from Siemens, Rockwell, and Beckhoff PLCs to Modbus and experimental BACnet implementations—and even work on Matter is underway.
+
+Erich: As we add more southbound protocol drivers, we’re also working to define consistent WoT protocol bindings so Thing Descriptions remain uniform across implementations.
+
+Erich: With that, I’ve reached the end of my presentation—right on time, about 30 minutes. Thank you, and I’m happy to take any questions in the chat.
+
+#### Sebastian's Presentation
+
+Sebastian: Thank you, Ege, and a warm welcome to everyone. I’m excited to introduce another companion specification from the OPC Foundation, called the OPC UA WoT Binding. I’ll start with an overview of how this works and the motivations behind it.
+
+Sebastian: Typically, as Erich mentioned, devices on the shop floor provide runtime data to a server. That server then makes the data available to different applications, including monitoring, control, or cloud services. The onboarding of these devices can be a challenge, and the OPC UA WoT Binding addresses that by enabling plug-and-play integration of these devices into the OPC UA ecosystem.
+
+Sebastian: A common scenario is when OPC UA is just one endpoint among multiple other endpoints that speak different protocols, such as BACnet or HTTP. The challenge is to make interfaces more usable for cross-IoT applications, simplifying integration and reducing complexity.
+
+Sebastian: Currently, OPC UA descriptions rely on XML NodeSet files, which are complex and not always user-friendly for integrators who may not be OPC UA experts. Often, they only need a few data points for their target applications. The OPC UA WoT Binding simplifies this by using Thing Descriptions to expose only the necessary information.
+
+Sebastian: I lead this group together with Erich Barnstedt. We’ve just completed the technical review of the specification and addressed comments. We expect the official 1.0 release in the next few weeks.
+
+Sebastian: The key idea is that OPC UA interfaces can now be described as WoT Thing Descriptions, making it easier to integrate and use across different applications.
+
+Sebastian: A Thing Description can represent a single data point from an OPC UA server, typically called a UA variable. It includes endpoint information (e.g., opc.tcp), location, port, and security information. OPC UA has its own handshake mechanisms, and clients must select channels appropriately for secure communication.
+
+Sebastian: Beyond that, the description contains the data point’s details, such as data type, unit, range, and the Node ID encoded in the href field. OPC UA experts can use this Node ID to map the variable within drivers and applications.
+
+Sebastian: Our specification also covers namespace handling. OPC UA servers often have multiple namespaces, and the Thing Description preserves the correct order and mapping of Node IDs to ensure accurate communication with each endpoint.
+
+Sebastian: Another key feature is the WoT ontology, which defines terms that can be used for mapping. For example, voltage values from different phases can be linked to a predefined OPC UA model from a companion specification. Most terms are optional, so you can provide minimal or enriched descriptions depending on your use case.
+
+Sebastian: We also describe how to generate Thing Descriptions from browsed or discovered OPC UA nodes. Using the browsing service on the server, you can create Thing Descriptions for entire subtrees, or even generate them from XML NodeSet files. This allows flexible and automated creation of descriptions for integration.
+
+Sebastian: For implementation, Siemens has a prominent internal platform called One Connectivity, which integrates the complete Web of Things stack and the OPC UA binding. It’s used extensively across Siemens enterprise products for integration purposes.
+
+Sebastian: For open-source implementations, the Eclipse Foundation Sync Web project includes the latest OPC UA binding, enabling experimentation and adoption outside Siemens.
+
+Sebastian: Let me give an example. Imagine an IoT application monitoring a pump’s speed every five seconds. If the pump exceeds a threshold, the application increments a counter. Using Thing Descriptions, the implementation requires only a few lines of code, without dealing with protocol-specific details.
+
+Sebastian: By abstracting protocol specifics, you can focus on business logic and reuse it across different devices and protocols. This is one of the major benefits of the Web of Things approach.
+
+Sebastian: In a live demonstration, an OPC UA client connects to the OPC UA server and subscribes to variables using the Thing Description. All runtime data, such as voltage and current, is displayed in real time. This shows how easily Web of Things can unify heterogeneous systems.
+
+Sebastian: For anyone interested in experimenting, the Node-WoT implementation on Eclipse is available. If you want more industrial-grade examples, Siemens’ One Connectivity platform is also accessible, and I’m happy to provide guidance.
+
+Sebastian: That concludes my part of the presentation on the OPC UA WoT Binding. We now have time for questions and answers.
+
+#### Q&A
+
+Kerem Coban: What is the relationship between AAS and WoT?
+
+Sebastian: There is a specific AAS Submodel called asset
+
+Ege: Do you see the willingness from manufacturers to provide their protocols' binding specs?
+
+Erich: That would be ideal indeed.
+
+Erich: Prosys supports WoT connectivity in their Forge product.
+
+Jens: Can I use the AAS Templates AID or AIMC for directly sending opc-ua to mqtt, kafka, etc. ?
+
+Erich: Yes you can. The client I have shown can send to mqtt or kafka too
+
+Ege: Any features you want to see in the standards?
+
+Erich: We will add new affordance types like actions and events. More adoption is needed. More should ask for WoT TD files. I am working on getting people to adopt wot connectivity.
+
+Erich: More bindings are needed too. But it is easy to write them yourself.
+
+Erich: I needed help with lorawan though. That was a bit tricky with some fields like doing bit masking and endianness. Also the Matter spec is huge.
+
+Abidoun: Physics student here. As frontend developers are building tools around WoT Thing Descriptions, what are the current limitations or gaps in the TD specification that we should be aware of when designing UIs or developer tools?
+
+Sebastian: You can build UIs based on the different affordances. Like widgets-based. For more advanced UIs, you need to leverage more semantics. Like to build a timeseries graph, you need more information.
+
+Matthias Meier: W3C is working on a profinet binding. Does your LLM also support profinet too?
+
+Erich: LLMs we use are generic. If you do prompt engineering, like saying make sure to include this binding. You need to experiment though. OpenAI provides the tools. You need to be specific though.
+
+Erich: It would be more interesting to use RAGs together with LLMs. That would be more interesting.
+
+Erich: UA Edge Translator can be improved upon. Feel free to add more protocols. You can use a simple interface to add more protocol driver implementations.

Meetups/29/2025-10-WoTCG-Meetup29-AguzziKorkan.pdf

@@ -5,12 +5,23 @@ This readme contains the links to minutes, presentation files and the recordings
 
 Note: Presentation files use the pattern `YEAR-MONTH-WoTCG-EVENTNAME-PRESENTERNAME.FILETYPE`.
 
+## Meetup 29
+
+- Name: OPC UA and Web of Things
+- Presenter(s): Erich Barnstedt and Sebastian Kaebisch
+- Date: 16 October 2025
+- [Presenter Slides - Erich](./29/2025-10-WoTCG-Meetup29-Barnstedt-Microsoft.pdf)
+- [Presenter Slides - Sebastian](./29/2025-10-WoTCG-Meetup29-Kaebisch-Siemens.pdf)
+- Intro Slides: [Google Slides](https://docs.google.com/presentation/d/1SeGbmA9skmgVQEbsnO2904Lj8ztp-HsCX9M3MIxbSWc/edit?usp=sharing) | [PDF](./29/2025-10-WoTCG-Meetup29-AguzziKorkan.pdf)
+- [Video](https://youtu.be/PlY-ixquyZc)
+- [Minutes](./29/2025-10-16-minutes.md)
+
 ## Meetup 28
 
 - Name: An Open-source Software Stack for IoT Virtualization and Convergence with Edge Computing Technologies
 - Presenter(s): Dimitris Spatharakis and Nikos Filinis
 - Date: 17 July 2025
-- [Presenter Slides](./28/)
+- [Presenter Slides](./28/2025-07-WoTCG-Meetup28-VO-WoT.pdf)
 - Intro Slides: [Google Slides](https://docs.google.com/presentation/d/1iQjM7CGnVCx1XQCK2bi3iIfUCfIDwqTdjEng5ebfCEQ/edit?usp=sharing) | [PDF](./28/2025-07-WoTCG-Meetup28-AguzziKorkan.pdf)
 - [Video](https://youtu.be/EkeoQLWIhlI)
 - [Minutes](./28/2025-07-17-minutes.md)