Update profiles.md #1034
Update profiles.md #1034
Conversation
|
Two remarks:
EDIT: I can make this an issue. |
| ### Digital Twin Profile | ||
|
|
||
| Digital twins enable defining a model of a thing, person or process. They are used as digital proxies for counterparts in the real world to better understand situations in the real world and act on state changes. | ||
|
|
||
| Using a digital twin allows businesses to analyze their physical assets to troubleshoot in real time, predict future problems, minimize downtime, and perform simulations to create new business opportunities. A digital twin may also be called a twin or a shadow. | ||
|
|
||
| Digital twins have different roles. They could be models of individual discrete things, composite twins or organisational twins of more complex entities, such as factories or cities. | ||
| Some use cases for digital twins have been described in the **WoT use cases and requirements** document, e.g. for Smart Cities, Production Monitoring, Health and Agriculture scenarios. | ||
|
|
||
| The *Digital Twin Profile* enables using the thing description for defining digital twins that address these roles, use cases and requrements. | ||
|
|
||
| ### Cloud Profile | ||
|
|
||
| Large scale deployments, for example in production lines for industrial manufacturing consist of multiple machines, where each machine incorporates sensors for various values. A failure of a single machine can cause defective products or a stop of the entire production. | ||
|
|
||
| Big data analysis enables to identify behavioral patterns across multiple production lines of the entire production plant and across multiple plants. | ||
|
|
||
| The results of this analysis can be used for optimizing consumption of raw materials, checking the status of production lines and plants and predicting and preventing fault conditions. | ||
|
|
||
| The *Cloud Profile* enables large scale deployments of devices across different manufacturers. |
There was a problem hiding this comment.
How would the Digital Twin Profile and Cloud Profile differ technically from the existing HTTP Baseline Profile, HTTP SSE Profile and HTTP Webhook Profile? These descriptions explain what digital twins and cloud deployments are, but they don't explain why they need their own profiles.
Bear in mind that profiles improve interoperability within profiles, but not between profiles. Defining a profile specific to digital twins could have the effect of making them non-interoperable with Web Things which aren't digital twins. Defining a profile specific to cloud deployments could have the effect of making them non-interoperable with Web Things not deployed in the "cloud". That would not be desirable.
I am actually currently implementing a cloud-based digital twin which uses the existing HTTP-based profiles and I don't see a need for profile specific to those use cases. However, I do see requirements for cloud-based digital twins which could be applicable for other more horizontal profiles.
For example, when creating a digital twin of a whole building it would be useful to be able to subscribe to multiple events and observe multiple properties of multiple Things over a single network socket to an on-premises building management system. This is not possible with the current profiles but is not necessarily specific to digital twins.
I think rather than the vertical sounding "digital twin profile" and deployment model specific "cloud profile" it might make more sense to create a "WebSocket Profile" (or an updated version of the existing HTTP SSE Profile or HTTP Webhook Profile), which defines a protocol binding for subscribing to data from multiple Things at once.
That would be an example of a tangible requirement which cloud-based digital twins might have of other horizontal profiles, but I don't think profiles specific to digital twins or the cloud deployment model make sense.
There was a problem hiding this comment.
How would the Digital Twin Profile and Cloud Profile differ technically from the existing HTTP Baseline Profile, HTTP SSE Profile and HTTP Webhook Profile? These descriptions explain what digital twins and cloud deployments are, but they don't explain why they need their own profiles.
These are use cases and scenarios that require additional analysis and requirements work. As a starting point the use cases and requirements document describes already some. I agree with your point that we should create horizontal profiles that address the needs of several stakeholders and provide OOTBI interoperability among their implementations.
Bear in mind that profiles improve interoperability within profiles, but not between profiles. Defining a profile specific to digital twins could have the effect of making them non-interoperable with Web Things which aren't digital twins. Defining a profile specific to cloud deployments could have the effect of making them non-interoperable with Web Things not deployed in the "cloud". That would not be desirable.
This is not necessarily the case - If two profiles use the same baseline and just differ in the eventing protocol, the common baseline subset is still OOTBI. If these also put additional requirements and constraints on the baseline to satisfy accessibility requirements and enable an accessible UI, these will be compatible from a user's POV.
I am actually currently implementing a cloud-based digital twin which uses the existing HTTP-based profiles and I don't see a need for profile specific to those use cases. However, I do see requirements for cloud-based digital twins which could be applicable for other more horizontal profiles.
I agree, we should collect these requirements and define a common horizontal profile.
For example, when creating a digital twin of a whole building it would be useful to be able to subscribe to multiple events and observe multiple properties of multiple Things over a single network socket to an on-premises building management system. This is not possible with the current profiles but is not necessarily specific to digital twins.
This is an area, where composite and organisational twins have new requirements.
I think rather than the vertical sounding "digital twin profile" and deployment model specific "cloud profile" it might make more sense to create a "WebSocket Profile" (or an updated version of the existing HTTP SSE Profile or HTTP Webhook Profile), which defines a protocol binding for subscribing to data from multiple Things at once.
I never considered the digital twin profile as a vertical profile, in my view it is part of many vertical application domains among which agriculture, buildings, energy, healthcare, manufacturing, smart cities are the obvious ones.
That would be an example of a tangible requirement which cloud-based digital twins might have of other horizontal profiles, but I don't think profiles specific to digital twins or the cloud deployment model make sense.
Initially, I suggest we first discuss scenarios and collect the requirements before we discuss the protocols that may be part of a solution.
There was a problem hiding this comment.
@mlagally wrote:
These are use cases and scenarios that require additional analysis and requirements work.
The current text reads as though these are new dedicated profiles which should be defined. Perhaps it would be better to say that the group should explore how new or existing profiles could fulfil the requirements of digital twins, cloud deployments and constrained devices, without jumping to the conclusion that these would all need to be separate profiles. We've discussed an example above of a requirement to observe multiple Things over a single connection - that could be fulfilled by a new profile, or an extension of an existing one.
As a starting point the use cases and requirements document describes already some.
Those use cases are very high level and don't really answer my question. What I'm looking for are concrete technical requirements which come from these use cases that can not be fulfilled by the current profiles (or extensions of them), and rationale for why they require a dedicated profile (which by definition will not be fully interoperable with the existing profiles), as suggested here.
If two profiles use the same baseline and just differ in the eventing protocol, the common baseline subset is still OOTBI.
Perhaps this could be justified if there was evidence that an event emitted by a digital twin or a cloud service is fundamentally different from an event which is emitted directly by a physical device. What I'm saying is that I've not seen any evidence yet that they are fundamentally different and that they therefore justify a separate (and therefore incompatible) event mechanism.
I never considered the digital twin profile as a vertical profile, in my view it is part of many vertical application domains among which agriculture, buildings, energy, healthcare, manufacturing, smart cities are the obvious ones.
I agree that digital twins can span multiple vertical application domains. What I'd like to better understand is if and how a Web Thing representing a digital twin is different from any other Web Thing from a Consumer's point of view. Perhaps a digital twin is just one use case of a Web Thing, but a Consumer doesn't care whether that Web Thing represents a physical device or a simulation of one.
Initially, I suggest we first discuss scenarios and collect the requirements before we discuss the protocols that may be part of a solution.
That makes sense.
| The current WoT Profile specification contains a protocol binding for HTTP(s). | ||
| In an industrial environment individual actuators and production devices use several other protocols. Examples include MQTT, OPC UA, Modbus, and others. Gathering data from these devices, e.g. to support digital twins or big data use cases requires a protocol binding and additional semantic guarantees that enable them. | ||
|
|
||
| As part of the profile work item, other profiles may be defined, based on concrete use cases and requirements. |
There was a problem hiding this comment.
I support the idea of a separate profile for constrained devices which don't have the resources to implement the existing HTTP profiles.
However, I think including protocol bindings for four different protocols in a single profile would be too complicated and wouldn't actually help with interoperability since devices using the different protocol bindings wouldn't be interoperable with each other.
I instead suggest a single "CoAP Profile" which uses CoAP and CBOR instead of HTTP and JSON, for constrained devices.
There was a problem hiding this comment.
I support the idea of a separate profile for constrained devices which don't have the resources to implement the existing HTTP profiles.
However, I think including protocol bindings for four different protocols in a single profile would be too complicated and wouldn't actually help with interoperability since devices using the different protocol bindings wouldn't be interoperable with each other.
I instead suggest a single "CoAP Profile" which uses CoAP and CBOR instead of HTTP and JSON, for constrained devices.
There was a misunderstanding on that part of the proposal. It is not meant to combine protocol bindings for several protocols into a single profile. I'll improve the text.
There was a problem hiding this comment.
Given the current profiles we've landed on:
- HTTP Baseline Profile
- HTTP SSE Profile
- HTTP Webhook Profile
which are horizontal profiles specific to a protocol, I think that the profiles proposed here:
- Digital Twin Profile (specific to a use case)
- Cloud Profile (specific to a deployment model)
- Constrained Profile (covering multiple protocols MQTT, OPC, UA, Modbus...)
would be out of place.
I suggest it would make more sense to have profiles like:
- WebSocket Profile
- CoAP Profile
| * Cloud Profile (addressing requirements of large scale requirements) | ||
| * Constraint Device Profile (addressing requirements of devices with a small footprint) | ||
| * Profiles for other protocols (e.g. CoAP, MQTT) | ||
| In addition, specification work for other profiles will be carried out. |
There was a problem hiding this comment.
among the following may be
|
I'm not sure, if such specific profiles are really needed. However, if such activity should be started this should be done in collaborative manner with related SDOs or associations' such as with the Industrial Twin Association. |
I agree that we should not create non-interoperable silos. For the sake of the discussion, I believe we need to define what is exactly meant by subset, when the TD contains extension points. The TD has extension points and does not define behaviour. Various things in the TD are optional, which makes OOTBI harder. Can you please explain, what you consider beyond the scope of a subset?
The TD can not be used to describe the behaviour at the protocol level, since it is a different abstraction level. A few examples: How to describe the result of "writemultiple", when a few properties cannot be updated? There are different strategies that should be clearly defined and guaranteed to work identical among all OOTBI implementations. Other examples include setting a property to a value outside the min/max range. Howe to define the behaviour? |
I completely agree that we should collaborate with all relevant consortia and companies, among which we should consider IDTA, DTC, BDTA and others. |
Co-authored-by: Michael McCool <michael.mccool@intel.com>
Please see my comments above about the scope of the proposed horizontal profiles. Before we do a protocol oriented discussions, we first have to describe use cases and requirements. I agree that we should include a CoAP profile into the possible deliverables, but I'm not sure we have a use case that requires WebSockets at this point. |
|
I think the objective of the profile document should be clarified, not what should be written in the profile document. we should discuss what should be written in the profile document after the objective of the profile document has been clarified. I think it is important to clarified what be standardized in the profile document if the profile document is normative.if there is nothing to be standardized, the profile document should be note or guideline. I think we should discuss first. I think WebSocket profile and CoAP profile are Implementation guidelines. There are a lot of protocols, services and systems. It is hard to write each profile documents. these documents should be normative. If these documents are not normative, these documents should be notes or guidelines. I think WebSocket profile and CoAP profile is important to implement. So we should discuss what are normative core profiles and what are non normative profiles. |
|
I think what is meant by subset of a TD is that it should be possible to remove the |
|
@egekorkan wrote:
As far as I know this was never identified as a formal requirement during the use cases and requirements discussion for WoT Profile 1.0. Currently profiles define concrete protocol bindings which are intended to be assumed by Consumers when they see a particular value of the
I like this approach, and I have a detailed proposal for how this could work. However, this is not currently how profiles work in WoT Profile 1.0. Are you suggesting that this is how profiles should work in WoT Profile 2.0 (since it would be a breaking change)?
I think there was a mismatch of assumptions on both sides. On the profile side it was assumed that the Thing Description specification would fulfil the requirement set out in the charter of being able to describe complex interactions like action queues, but that didn't happen. On the Thing Description side it was assumed that profiles would only define protocol bindings which can also be described by a Thing Description alone, but that was never explicitly set as a requirement. I think this mismatch is something that could potentially be improved in TD 2.0 and Profile 2.0, by taking a different approach to profiles which leverages existing extension points in the TD (sub-protocols and semantic extensions) rather than the way the current profile mechanism works. I'm happy to provide a detailed proposal for that if people would like? |
I strongly support that TD 2.0 and Profile 2.0 go hand in hand in the future (meaning a stronger collaboration). |
I've submitted a proposal for a "Profile Mechanism 2.0" in w3c/wot-profile#285 which could help address some of the concerns with the current 1.0 version of profiles. Perhaps re-visiting the profile mechanism could be a topic for the next charter? |
I think that would be desirable. I think this whole discussion is partly due to the fact that we never tried profiles in a plugfest and got some experience on how it works in practice. |
In my opinion, this should be the first step to get in touch with these SDOs and discuss this topic together. This will also help to have the right experts and potential contributors on board. |
|
Let's discuss in the next main call, can allocate 10-15m. Comments from mtg: Digital Twins is a big topic.... |
Adding detailed description of the proposed profiles.