Notes

Link to Digital Twin Ecosystem Capabilities Periodic Table?

• DS.AI: Data Acquisition and Ingestion: The purpose is to acquire data from the physical world, engineering technology systems, and information technology systems to support subsequent processing and insight generation.

• DS.ST: Data Streaming: The purpose is to acquire fast continuous packets of information which is changing at high speed to be able to get near real-time insights.

• DS.BP - Batch Processing: The purpose is to provide is an efficient way of processing high volumes of data in batches or groups

• DS.RT - Real-time processing: The purpose is to support immediate insights from the data.

• DS.AS - Data PubSub Push: The purpose is to provide information to to subscribed digital twin consumers

• DS.AG - Data Aggregation: The purpose is to gather data from multiple sources with the intent of combining these data sources into a summary for data analysis

Capabilities

• Link to Digital Twin Ecosystem Capabilities Periodic Table?

  • DS.AI - Data Acquisition and Ingestion: The ability to configure and acquire data from different data sources including control system, historians, IoT sensors, smart devices, engineering system, enterprise systems etc.

  • DS.ST - Data Streaming The ability to transfer of large volumes of data continuously and incrementally between a source and a destination without having to access all data at the same time.

  • DS.BP - Batch Processing: The ability to execute against previously collected data in bulk form

  • DS.RT - Real-time processing: The ability to manage and act on the captured data with minimal latency

  • DS.AS - Data PubSub Push: The ability to package filtered data to different services based on publish / subscribe model

  • DS.AG - Data Aggregation: The ability to gather raw data and express in a summary form

• Other?

Requirements

Link to Living-in.EU LDT procurement templates for IoT Devices?

• Functional requirements:

  • Provide accurate measurements within specified tolerance levels, allowing for reliable and consistent measurements over time without frequent failures or malfunctions

  • Be able to measure values with a high degree of precision, ensuring high levels of repeatability and reproducibility

  • Be able to measure a wide range of values for the parameters it is designed to detect, be sensitive enough to detect changes in the parameter being measured.

  • Have sufficient resolution to distinguish between small changes in the measurements

  • Have a swift response time, providing measurements after changes in the parameter that is being measured

  • Enable some level of calibration when required to ensure accurate measurements and account for deviations from ideal performance over time

  • Be able to perform consistently over time over a range of different weather and temperature conditions, environmental factors (e.g. moisture, dust, electromagnetic interference) without significant degradation in performance. Specifically, conformance with the IPxx code level

  • Be compatible with all [OASC, DS4SSCC and/or Interoperable Europe ... compliant] system or platform of any city or community it is intended to be integrated with, this includes electrical interfaces and communication protocols

  • Consume minimal power as possible

  • Have self-built-in diagnostic features to detect and report faults or abnormalities in its operation

  • Allow for flexibility for customisation or configuration to adapt to specific application requirements, i.e., in relation to accommodating growing device networks and scalability

  • Meet relevant safety standards and regulations, especially in case of usage in safety-critical applications.

• Technical requirements:

  • Interface compatibility: have compatible interfaces for integration with the system or platform of a city or community it intends to use. This can be either analogue, digital or wireless interfaces

  • Data transmission: supporting reliable data transmission protocols up to high speeds. High speeds depend on how often and quickly you need to send and receive data. Examples are MQTT, REST, I2C, SPI, UART, Serial Communication protocols or wireless communication standards like Bluetooth or Wi-Fi

  • Data output format: provide data in a (human and/or machine-readable) format compatible with the system or platform of a city or community it is interfacing with. Examples using data standards such as JSON, XML, AMQP, M2M, and Protobuf

  • Data elasticity: allows for handling of elasticity, meaning deal with fluctuation in data load to expand and reduce capacity as needed.

  • Data connectivity:

    • Bandwidth: supports enough data to be transmitted over the existing network connection per unit of time. Sufficient bandwidth is determined by the volume of data being transmitted and the speed at which it needs to be transmitted.

    • Latency: low latency to ensure real-time applications

    • Security: measures to protect data from sensors from unauthorised access, interception, and tampering during transmission through solutions such as encryption, authentication and access control mechanisms

    • Interoperability: interpreting data seamlessly through the usage of (open) standardised data formats

    • (Open) standards: adherence to relevant industry or open standards such as TCP/IP, Ethernet, Wi-Fi, and Bluetooth. Please refer to MIM1 for interoperability requirements

    • Semantic model: using a semantic model for IoT sensor data is advisable to support a common understanding of inherent information (i.e. origin, value ranges, etc.)

    • Scalability: the ability of the data connectivity component to accommodate increasing data volumes or expanding network infrastructure without degradation of performance or additional complexity.

  • Operating voltage: the sensor should operate within a specified range compatible with the power supply available in the system

  • Integration support: provide support through comprehensive documentation, software libraries and technical support to facilitate integration into existing systems of cities and or communities to streamline development

  • Response time: provide prompt changes in the parameter being measured if a change is captured, thus having a fast response time

  • Authentication and authorisation: provide mechanisms to enable authorised access to data [of the IoT sensor]

Mechanisms

• APIs

• [Linked Data] Event Streams

• Publish-Subscribe

• Web sockets

Link to Living-in.EU LDT procurement templates for IoT Devices?

The technical specifications of an IoT sensor serve a purpose and act as enablers to collect data that can act as input for a city’s data platform, which is depicted in Figure 1 below:

1. An IoT sensor is a device or component of physical hardware that enables data collection from physical assets or environments.

2. Connection to a (edge) computer enables the processing and storage of data close to where it originates (i.e. IoT sensor) to accommodate real-time data processing and low latency. This processed information can then be routed to a city’s data platform for more comprehensive analysis or act as input for LDTs.

3. Connectors encapsulate automated and timely data sharing in a trusted and secure way from one or more upstream data sources from IoT sensors to, in this case, a city’s data platform.

Figure 1: Generic overview of the IoT sensors within a LDT system

See paragraph Requirements above.