Meeting minutes
Logistics
seb: thanks for joining this joint meeting, it has been a couple of months
seb: agenda for today - welcome/scope/intros; technical discussion of OPC UA binding; next steps
seb: intros to focus on new people: Bernd Fiebiger
… from Kuka
… have been involved in OPC UA information models, asset administration shell
… common approach for representing interfaces of entities
… Heiko Fessenmayr
… have been working on analytic instrumentation - Agilent
seb: also Dave Raggett
… was involved in early work in WoT and OPC UA
technical discussion
seb: want to show you a first draft of what we would like to work on
… https://
… then later we need to discuss logistics, perhaps set up a regular meeting
karl: missing installation or initialization of WG
… for that we need a cooperation agreement
mm: I think the purpose of this meeting though is to get the charter of such a WG defined
seb: and also need a smaller group, there is a doodle, to get the chairs together to sort that out
<sebastian> https://
seb: will now open tech_req.md
seb: OPC UA already has a long journey, we've been talking about doing an OPC UA binding in WoT for at least a year
… and also many use cases that overlap with OPC UA
<mlagally> https://
<kaz> OPC UA use case
seb: including a manufacturing scenario explicitly including OPC UA
… including integration with other standards such as MODBUS
… we need and OPC UA binding so we can onboard OPC UA endpoints
… as described in the scenario
… back to tech description, there are different aspects
… so that a WoT Consumer can treat OPC UA binding as a WoT Thing
mm: also two points to resolve: 3, reverse binding; 4 binary or going through a gateway (e.g. HTTP protocol translator)
kaz: agree with mm, need to discuss also PoCs but more important issue is W3C and WoT providing binding template specification
mm: again, this doc is what the technical goal is and what needs to be done, separately we can decide who does what organizationally
hf: in asset administration shell there is useful information about and OPC UA shell
… what is the communication protocol used? Is there a service in between that uses definitions out of submodel of AAS?
… context data, how to access a server, how to get the right nodes
… get an overview of what is means to bring OPC UA devices to a WoT Thing
mm: we have to think about how the information models map onto each other, and whether we want to represent relationships using links, etc.
seb: these are among the kinds of things we have to decide
… coming back to Bernd, what was mentioned in the activity in OPC UA; hopefully we can reuse some of this
… the main deliverable we need is an RDF standard defining the terms needed for the binding: content types, node types, security modes, etc.
… this is conceptually a generic activity; once it exists, a WoT TD binding can just use it
mm: I also think we should reuse as much as possible of the AAS concepts
… so it is compatible conceptually
bf: OPC UA cloud library would provide a dictionary about the concept of the nodeset
… AAS would describe which nodesets are available in a server
… on the other side, description in AAS, how to find security, endpoints, hints regarding cloud libraries
<McCool> s/jl:/bf:/
mm: I would like to reiterate that we should focus on the high-level technical goals so we can establish the charter
kaz: agree with mm; also, jim luth attended our meeting yesterday and we discussed ontologies
<kaz> Web-based Digital Twins for Smart Cities session
ml: since AAS has been called out twice, would like to understand how OPC UA uses it
… could someone explain?
bf: if I can present I can show some figures
… common area of OPC UA and AAS
seb: ok, if it is fast, we only have 20m left
bf: (shows diagram)
… stores information about an asset, might have a submodel template for an OPC UA
… any application can then discover this information
… can implement in advance applications that use an asset before it arrives
… asset integration can be defined in a standardized way
mm: is AAS currently being used by OPC UA?
bf: there is a companion spec
<kaz> ("AAS" stands for "Asset Administration Shell")
seb: AAS is a data model, has submodel for many different kinds of information; and definition of how to access AAS from HTTP and from OPC UA
mm: would like to suggest we defer discussing AAS for now, but return to it later
… and would still like resolutions on the two points I mentioned
seb: agree, and think that AAS is not inventing something new, but is using definitions from OPC UA
proposal: to explictly declare point 3 (reverse OPC UA to WoT binding) as being out of scope
kaz: ok with narrower scope here, but situation with OPC UA is similar to ECHONET, binary vs. http translator
mm: agree, but let's do that next
seb: any concerns with the proposal?
mm: hearing none
RESOLUTION: to explicitly declare point 3 (reverse OPC UA to WoT binding) as being out of scope
mm: are we doing a binary binding or a translator?
seb: need to be careful, there are different OPC UA protocols
… probably want to start with classic one, which is client/server
mm: ok, so there are three options: Soap, client/server, pub/sub
… maybe we can have several stages, but it sounds like priorities should be client/server, pub/sub
mm: we can put it into the scope but not necessarily having a resolution today
jl: I guess it depends on what the philosophy of the current bindings are
… for example, does MODBUS binding use binary binding or HTTP bridge?
ege: right now we are doing the first: what IP, port, what data structure, etc.
… but can translate that in a gateway to another
jl: but the ultimate receiver does not know what the binary protocol looks like?
ege: gateway could be interoperable
jl: both top and bottom are specified
mm: maybe this is something we defer to the actual spec
kaz: agree with Jim that we need to specify enough content for the actual binding; perhaps we should gather some best practices
… for example, Takanaka is already using WoT for MODBUS
seb: out of time, need to organize next meeting
… suggestion is to have a once-a-month meeting until this is resolved
mm: personally feel that if we can keep the discussion high level, we really only need one more meeting to define the charter scope
kaz: agree, and would suggest we start with clarifying our expectations and requirements for that purpose
bf: seems there is enough discuss to describe a common working group
mm: technically, it will probably be a pair of groups, one on each side, that are working together
seb: so, another meeting to define the abstract charter
seb: suggest then another, small meeting among the chairs
<kaz> [adjourned]