Topics that we could potentially cover in the next round of Architecture:
Digital twins
Definition:
Should search/align with other standards, but what exists in Architecture 1.1:
A digital twin is type of Virtual Thingthat resides on a cloud or edge node. Digital Twins may be used to represent and provide a network interface for real-world devices which may not be continuously online (see also Shadows), may be able to run simulations of new applications and services before they get deployed to the real devices, may be able to maintain a history of past state or behaviour, and may be able to predict future state or behaviour. Digital Twins typically have more functionality than simple Shadows.
Behavior description/simulation
Formal simulation models
Annotation of physical behavior, e.g. safety, sensory mode
Historical databases, time series
Shadows
Unnecessary Limitations in above defn (strikeouts above):
may not be in an edge or cloud node, e.g. could run on a sufficiently powerful endpoint Thing
"before they get deployed" implies that they might not be used after deployment, but they can be
Smart Cars (Target Use Case)
Specific requirements
Dynamic location
Safety
Intermittent connectivity
Regulation
Mapping
V2V communication
Consumer Description vs. describing the contract between things and consumers in the TD
Should align defns of digital twin with what is used in other standards: DCA, CASME, ... (Seb/Lagally to investigate); also useful to ask members who are working in the area, e.g. Microsoft, Schaeffler
Ege - Restructuring, some "Pillars": Terminology; Deployment Patterns; then Building Blocks and Abstract Architecture. Feedback - bad, doc is too big, 6-7-8 are not synched well enough with other specs (impression from Luca B in TD call); good, appreciated 4 & 5 (use cases and domains), supported business use cases. Editor's call was useful for synchronizing various documents. Maybe have a TF (probably Arch) whose job it is too synchronize TFs, maybe doc to collect common specs.
Lagally: restructuring will be useful, can be improved in next charter, but more TFs may not be the solution
Link types need clearer semantics; more generic graph structure would be useful, similar to DTDL; related to Digital Twins
Digital twins connections to existing standards, e.g. 3D models, 2D maps, behavior description (e.g. state machines, W3C has prior work on that),
Internal links can however be used for additional structure, e.g. part architecture, TM/TD relations
Links for other things, e.g. documentation
See also breakout sessions at TPAC on Digital Twins; CG/breakouts to discuss? Smart Cities, collaborative discussion
Edge Computing
How can web of things be used in combination with other technologies - e.g. as part of another ecosystem, e.g. OPC UA based systems, BIM, GIS systems, etc. - where TDs are a component, not central
Better modelling, e.g. TM
User interface description and modelling - consider relationship to HTML; sensory modality annotation; MMI; existing standards
Topics that we could potentially cover in the next round of Architecture:
Digital twins
that resides on a cloud or edge node. Digital Twins may be used to represent and provide a network interface for real-world devices which may not be continuously online (see also Shadows), may be able to run simulations of new applications and servicesbefore they get deployed to the real devices, may be able to maintain a history of past state or behaviour, and may be able to predict future state or behaviour. Digital Twins typically have more functionality than simple Shadows.Smart Cars (Target Use Case)
Consumer Description vs. describing the contract between things and consumers in the TD
Time synchronization
Industrial applications
Microservices - state-model based controller
callback API description
stateful things