ISO/IEC 30178:2026

• Abstract:

  ISO/IEC 30178:2026 defines common formats, values, and coding for data interoperability and exchange among systems in the Internet of Things (IoT).

• Status: Published
• Publication Date: 29-Jul-2026
• ICS: 35.020 - Information technology (IT) in general
• Technical Committee: ISO/IEC JTC 1/SC 41 - Internet of Things and Digital Twin
• Drafting Committee: WG 4 - ISO/IEC JTC 1/SC 41/WG 4
• Current Stage: PPUB - Publication issued
• Start Date: 30-Jul-2026
• Completion Date: 14-Aug-2026

ISO/IEC 30178
Edition 1.0 2026-07
INTERNATIONAL
STANDARD
Internet of Things (IoT) - Data format, value and coding for interoperability
ICS 35.020  ISBN 978-2-8327-1410-2

ISO/IEC 30178: 2026-07(en)
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or
by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either
IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC copyright
or have an enquiry about obtaining additional rights to this publication, please contact the address below or your local
IEC member National Committee for further information.

IEC Secretariat Tel.: [phone]
3, rue de Varembé [e-mail]
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.

IEC publications search - IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Discover our powerful search engine and read freely all the
The advanced search enables to find IEC publications by a publications previews, graphical symbols and the glossary. With
variety of criteria (reference number, text, technical a subscription you will always have access to up to date content
committee, …). It also gives information on projects, replaced tailored to your needs.
and withdrawn publications.
Electropedia - www.electropedia.org
The world's leading online dictionary on electrotechnology,
IEC Just Published - webstore.iec.ch/justpublished
Stay up to date on all new IEC publications. Just Published containing more than 22 500 terminological entries in English
details all new publications released. Available online and and French, with equivalent terms in 25 additional languages.
once a month by email. Also known as the International Electrotechnical Vocabulary
(IEV) online.
IEC Customer Service Centre - webstore.iec.ch/csc
If you wish to give us your feedback on this publication or need
further assistance, please contact the Customer Service
Centre: [e-mail].
CONTENTS
FOREWORD . 5
INTRODUCTION . 6
1 Scope . 7
2 Normative references . 7
3 Terms and definitions . 7
4 Abbreviated terms . 10
5 Background . 11
5.1 Overview. 11
5.1.1 General . 11
5.1.2 Sensor-related data . 12
5.1.3 Source data collection . 13
5.1.4 Time-resolution and sample rate . 14
5.1.5 Signal-processing implications . 14
5.1.6 Low-power sensors . 14
5.1.7 Measurement data . 15
5.1.8 Numerical component . 15
5.1.9 Semantic component . 15
5.1.10 Unit . 15
5.1.11 Prefix . 16
5.2 Sensor value metadata . 17
5.2.1 General . 17
5.2.2 Resolution . 18
5.2.3 Precision (measurement) . 18
5.2.4 Sampling time (time resolution). 18
5.2.5 Sample rate . 19
5.2.6 Range . 19
5.2.7 Accuracy . 20
5.2.8 Unit . 20
5.2.9 Data type . 20
5.2.10 Physical quantity . 20
5.3 Physical quantities . 20
5.3.1 Overview . 20
5.3.2 Occurrences . 21
5.4 Examples of data models . 22
5.4.1 Overview . 22
5.4.2 Exchange formats . 22
5.4.3 File formats . 22
5.4.4 Information modelling formats . 23
5.5 Interoperability challenges . 23
5.5.1 System integration . 23
5.5.2 Maximizing the economic value of data through reusability . 24
5.5.3 Sensor lifecycle cost . 25
5.5.4 Sensor data capital value . 26
5.5.5 Scalability . 26
5.5.6 Semantics. 29
5.5.7 Symbol mapping . 29
5.5.8 Sensor semantics . 29
5.5.9 Representation versus presentation . 31
5.5.10 Human readability . 31
5.5.11 Resolving data points . 32
5.5.12 Type inference and casting . 33
5.5.13 Hard coupling . 34
5.5.14 Machine-to-machine exchange . 34
5.5.15 Representation . 34
5.5.16 Presentation . 34
5.5.17 Data translation . 35
5.5.18 Errors and quality . 37
5.5.19 Semantic mismatch . 37
6 Core profile . 37
6.1 Overview. 37
6.2 Sensor data parameters . 38
6.2.1 Unit . 38
6.2.2 The "unit-word" . 38
6.2.3 Dimensionless units . 39
6.2.4 Range . 39
6.3 Physical quantity . 40
6.3.1 Overview . 40
6.3.2 Canonical representation . 41
6.3.3 Operations . 41
6.3.4 Significance-based comparison . 42
7 High-level system design . 42
7.1 Overview. 42
7.2 Type safety . 44
7.3 Conversion mechanics . 44
7.3.1 Overview . 44
7.3.2 Single-step conversion . 44
7.3.3 Unit resolver . 44
7.3.4 Magnitude resolver . 45
7.3.5 Precision estimation . 45
7.3.6 Time-resolution and oversampling . 45
7.4 Sanity-check mechanisms . 46
7.5 Component manufacture . 46
7.6 Digitized specification . 46
7.6.1 General . 46
7.6.2 Measurement range . 46
7.6.3 Accuracy . 46
7.6.4 Precision . 46
Annex A (informative) Single-step conversion . 47
A.1 Overview. 47
A.2 Example 1: Forward temperature conversion (Kelvin to base SI units) . 47
A.3 Example 2: Forward energy conversion (nanojoules to joules) . 48
A.4 List of unit-word value examples . 49
A.5 Floating-point format . 51
A.6 Examples on data point expression . 53
Annex B (informative) Unifying sensor data and mapping with standards . 54
B.1 Unifying sensor data value metadata: the type of sensor, the measurement
type, and the unit . 54
B.2 Mapping with IEC 61360-4 [3] Common Data Dictionary (CDD) . 55
B.3 Mapping with ETSI SmartM2M SAREF [4] . 56
Annex C (informative) Contextualizing sensor characteristics . 58
C.1 Concerns in metrology . 58
C.2 Context . 58
C.3 Preserving data integrity . 59
C.4 Example of contextual data conversion . 59
Bibliography . 60

Figure 1 – Discrimination and reduction of uncertainty of each bit within the range of
an 8-bit ADC . 13
Figure 2 – Sampling resolution of a signal within a given range . 18
Figure 3 – Hypothetical physical entity possessing three physical quantities . 20
Figure 4 – Sensors measuring a physical quantity . 20
Figure 5 – Sensor attached to, and measuring, some aspect of a physical entity . 21
Figure 6 – Integration of sensor (data source) and data consumer is necessary for a
data stream to be possible . 23
Figure 7 – Sensor and consumer interfaces not compatible . 23
Figure 8 – Sensor and consumer interfaces are not compatible, but achieve
compatibility through a format adapter . 23
Figure 9 – Sensor and consumer already sharing the same exchange format and do
not require any further adaptation . 24
Figure 10 – Complete product lifecycle, from initial development to end-of-life . 25
Figure 11 – Two separate integrations are made to accommodate full availability of
interface A from interfaces B and C . 26
Figure 12 – Three and five interfaces being integrated, requiring 6 and 20 (one-way)
mappings, respectively . 27
Figure 13 – 16 individual interfaces require 240 one-way mappings . 27
Figure 14 – With half-step intermediary translations, the number of necessary
mappings grows linearly instead of exponentially – Here 16 individual interfaces only
require 32 one-way mappings . 28
Figure 15 – The text-based value of 100 µm (or 0,1mm) can be represented with a big
variation in both data type, value structure and scaling . 30
Figure 16 – Example of consequences from change in representation . 31
Figure 17 – Example of sensor measurement sample serialized as senML/JSON . 32
Figure 18 – Essential properties of a physical quantity . 38
Figure 19 – Sensor system overview, from electric measurement to pre-processing and
transmission over typical IoT protocols . 43
Figure A.1 – Breakdown and conversion of data points in a forward temperature
conversion . 47
Figure A.2 – Magnitude resolver parameters . 48
Figure A.3 – Breakdown and conversion of data points in a forward energy conversion . 48
Figure A.4 – Magnitude resolver parameters . 49
Figure A.5 – Combination of base units into derived units . 51
Figure A.6 – Floating-point format binary encoding . 52
Figure C.1 – When applied on contextual data, QUDT schema definitions can map to a
canonical representation of measurement/sensor data . 59

Table 1 – Data source characteristics of a sensor . 12
Table 2 – Examples of historical units . 16
Table 3 – Prefixes of the Metric System . 16
Table 4 – Costs of sensor lifecycle. 25
Table 5 – Intermediary-representation design goals for physical quantities . 28
Table 6 – JSON payload broken down into first-level objects . 32
Table 7 – Data point breakdown . 33
Table 8 – Semantic data points . 36
Table 9 – Normalized data points . 36
Table 10 – The "unit-word" is a compact way to store base SI unit exponents . 38
Table 11 – Basic data types of a physical quantity . 42
Table A.1 – List of unit-word value examples . 49
Table A.2 – Examples on different representations of the physical quantity 0,000 1 m . 53
Table B.1 – Subset of the sensor dictionary for energy (classification of sensor name,
sensor measurement name, and unit) . 54
Table B.2 – Sensor dictionary for energy mapped to IEC 61360 Common Data
Dictionary . 55
Table B.3 – Subset of the sensor dictionary for energy mapped with ETSI SmartM2M
SAREF-Core and its extensions (SAREF4BLDG, SAREF4ENER) . 57

Information technology - Internet of Things (IoT) -
Data format, value and coding for interoperability

FOREWORD
1) ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission)
form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC
participate in the development of International Standards through technical committees established by the
respective organization to deal with particular fields of technical activity. ISO and IEC technical committees
collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental,
in liaison with ISO and IEC, also take part in the work.
2) The formal decisions or agreements of IEC and ISO on technical matters express, as nearly as possible, an
international consensus of opinion on the relevant subjects since each technical committee has representation
from all interested IEC and ISO National bodies.
3) IEC and ISO documents have the form of recommendations for international use and are accepted by IEC and
ISO National bodies in that sense. While all reasonable efforts are made to ensure that the technical content of
IEC and ISO documents is accurate, IEC and ISO cannot be held responsible for the way in which they are used
or for any misinterpretation by any end user.
4) In order to promote international uniformity, IEC and ISO National bodies undertake to apply IEC and ISO
documents transparently to the maximum extent possible in their national and regional publications. Any
divergence between any IEC and ISO document and the corresponding national or regional publication shall be
clearly indicated in the latter.
5) IEC and ISO do not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC and ISO marks of conformity. IEC and ISO are not
responsible for any services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this document.
7) No liability shall attach to IEC and ISO or their directors, employees, servants or agents including individual
experts and members of its technical committees and IEC and ISO National bodies for any personal injury,
property damage or other damage of any nature whatsoever, whether direct or indirect, or for costs (including
legal fees) and expenses arising out of the publication, use of, or reliance upon, this ISO/IEC document or any
other IEC and ISO documents.
8) Attention is drawn to the Normative references cited in this document. Use of the referenced publications is
indispensable for the correct application of this document.
9) IEC and ISO draw attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). IEC and ISO take no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, IEC and ISO had not received notice of
(a) patent(s), which may be required to implement this document. However, implementers are cautioned that this
may not represent the latest information, which may be obtained from the patent database available at
https://patents.iec.ch and www.iso.org/patents. IEC and ISO shall not be held responsible for identifying any or
all such patent rights.
ISO/IEC 30178 has been prepared by subcommittee 41: Internet of Things and Digital Twin, of
ISO/IEC joint technical committee 1: Information technology. It is an International Standard.
The text of this International Standard is based on the following documents:
Draft Report on voting
JTC1-SC41/597/FDIS JTC1-SC41/620/RVD

Full information on the voting for its approval can be found in the report on voting indicated in
the above table.
The language used for the development of this International Standard is English.
This document was drafted in accordance with ISO/IEC Directives, Part 2, and developed in
accordance with ISO/IEC Directives, Part 1, and the ISO/IEC Directives, JTC 1 Supplement
available at www.iec.ch/members_experts/refdocs and www.iso.org/directives.

INTRODUCTION
Digital transformation depends strongly on data. Within the field of Internet of Things (IoT),
many leading organizations try to model physical entities and environments with structured data.
Digital twins, city and building information models, process industry, automation, automotive
and even healthcare, are all technologies or fields in which data models are developed to
accommodate domain-specific needs.
Sensors form the backbone of live data generation and help synchronize the digital world with
the real world. Numerous data and information models occur in the Information Technology (IT)
and Operational Technology (OT) landscape, at various layers in digital systems. Some are
verbose, text-based formats (e.g. XML or JSON) that come with more or less rich metadata,
while some formats contain only minimal metadata.
The huge variability in how sensory data are represented poses a problem for all parties in the
value chain – not least for the data producers themselves. This variability not only affects
interoperability but also has significant economic implications. This often puts the economic
viability of data collection out of reach, since low data accessibility for data consumers also
means poor return of economic value for the data producer.
This has often limited large-scale data collection to domains in which there is a strong need for
very specific data collection (such as the automotive industry), and favoured applications where
a single data producer has a direct business agreement with the data consumer, and full control
over the data model. The design of the data gathering process has often been guided by a
single customer's need, with one fixed requirement for data quality.
General purpose data collection remains challenging in the context of Big Data.
The variability in format and inconsistency in data quality are issues that undermine new
stakeholders' trust in third-party value chains. Where data might have been accurate enough,
an insufficient amount of consistent data-source documentation dissuaded any potential new
data consumers – further limiting the capital value of data.
In the end, it has proven difficult for data producers to generate data that is cost-effective to
produce and consume – especially with data about physical environments.
This document provides guidance by outlining principles and technical solutions for overcoming
this variability and proposes a fundamental representation of data points for sensors and
physical quantities that can be used everywhere in the digital landscape to improve the
consistency of how both data and metadata are to be interpreted by application logic. When
applied correctly, with an agnostic attitude towards application requirements, these principles
also help form a baseline for data quality and accessibility.
With the perspective taken in this document, sensory data (after their collection) are regarded
as descriptions of a physical entity. This also includes any other physical measurement, such
as the physical parameters of real-world objects and systems. The intention is to allow for
sensory data to be possible to integrate seamlessly with other data points in physical models
under a shared, homogeneous interpretation.

1 Scope
This document defines common formats, values, and coding for data interoperability and
exchange among systems in the Internet of Things (IoT).
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies.
For undated references, the latest edition of the referenced document (including any
amendments) applies.
ISO/IEC 20924, Internet of Things (IoT) and digital twin - Vocabulary
ISO/IEC Guide 99, International vocabulary of metrology - Basic and general concepts and
associated terms (VIM)
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 20924,
ISO/IEC Guide 99 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following
addresses:
– IEC Electropedia: available at https://www.electropedia.org/
– ISO Online browsing platform: available at https://www.iso.org/obp
3.1
SI special names, pl.
names for compound SI units derived from the base seven SI units
EXAMPLE 1 Newton [N] equivalent to kilogram metre per second squared [kg∙m/s ].
EXAMPLE 2 Pascal [Pa] equivalent to newton per metre squared [N/m ] or kilogram per metre times second squared
[kg/m∙s ]
2 2
EXAMPLE 3 Joule [J] equivalent to kilogram metre squared per second squared [kg·m /s ].
th
Note 1 to entry: See BIPM [6] The international System of Units (SI) 9 edition (2019), 2.3.4 for further information.
3.2
data type
named category of data characterized by a set of values, a syntax for denoting these values,
and a set of operations that interpret and manipulate the values
EXAMPLE 1 uint16 – A 16-bit wide, unsigned integer capable of representing the whole-number range from 0 to
65 535.
EXAMPLE 2 bool – A Boolean value with only two states (true and false).
EXAMPLE 3 float – A 32-bit approximation of a real number.
Note 1 to entry: Standardized representation of data types is essential for cross-platform interoperability.
Note 2 to entry: The total number of bits determine the maximum number of unique values the data type can encode.
Note 3 to entry: For further information on data types see ISO/IEC 11404 [2].
[SOURCE: ISO/IEC 1539-1:2023 [1], 3.144, modified – the examples and notes have been
added.]
3.3
type safety
software design principle that protects against representation-related errors such as unintended
rounding or corruption of data by enforcing the consistent use of a data type (3.2) for some
variable
Note 1 to entry: Type safety allows scalability by decoupling the design of separate software components while
guaranteeing correctness within functional interfaces (such as APIs).
Note 2 to entry: Type safety is enforced by some programming languages.
3.4
floating-point format
digital data type (3.2) representing a fixed-precision approximation of a real number with a well-
defined range and precision, composed of an exponential and fractional component, and a sign
Note 1 to entry: Floating-point format is supported by all major programming languages.
Note 2 to entry: Depending on the variant, floating-point format typically features at least 6 to 7 significant decimal
digits for single precision, or 15 significant decimal digits for double precision.
Note 3 to entry: Definition based on ISO/IEC 60559:2020 [9], 3.6.
3.5
floating-point representation
unencoded member of a floating-point format, representing a finite number, a signed infinity, a
quiet not a number (NaN), or a signaling NaN
Note 1 to entry: A representation of a finite number has three components: a sign, an exponent, and a significand;
its numerical value is the signed product of its significand, and its radix raised to the power of its exponent.
Note 2 to entry: NaN means 'not a number' and is a special value of the floating-point representation that indicates
invalid number assignments, such as when dividing zero by zero.
3.6
physical quantity
property of some physical entity that can be measured in some physical dimension,
characterized by a number and a unit
3.7
serialization format
format of representing structured data in a serialized sequence of bits that can be exchanged
between two computer systems
EXAMPLE 1 XML – Extensible Markup Language , a text-based format using tags to encode nested elements and
structures.
EXAMPLE 2 JSON – JavaScript Object Notation , a format for representing basic values with named identities and
nested structures, in cleartext. JSON is considered a less verbose alternative to XML.
EXAMPLE 3 CBOR – Concise Binary Object Representation , a binary serialization format optimized for small code
size and message size.
Note 1 to entry: Serialization format is sometimes based on cleartext for representation, with a syntax to encode
structure.
Note 2 to entry: Serialization format is sometimes based on concrete data types for representation.
3.8
sensor
Internet of Things digital device that converts a physical measurement into a digital sample
carrying a quantity and a unit
Note 1 to entry: The sensor usually transmits the sample coded in some serialization format (3.7).
3.9
data point
datum that carries an individual meaning regardless of representation
3.10
release-time
period of time during which an instance of some software or hardware, such as an IoT sensor,
operates after deployment
Note 1 to entry: Release-time is typically separate from, and non-overlapping with, design-time.
Note 2 to entry: Release-time constitutes part of that instance's operational lifecycle.
3.11
design-time
period of time during which a piece of software or hardware is designed
Note 1 to entry: Design-time precedes, is typically separate from, and non-overlapping with, runtime.
Note 2 to entry: After the end of design-time, the design and its dependencies are not possible to modify.
___________
XML is an example of a suitable product available commercially. This information is given for the convenience of
users of this document and does not constitute an endorsement by ISO or IEC of this product.
JSON is an example of a suitable product available commercially. This information is given for the convenience
of users of this document and does not constitute an endorsement by ISO or IEC of this product.
CBOR is an example of a suitable product available commercially. This information is given for the convenience
of users of this document and does not constitute an endorsement by ISO or IEC of this product.
3.12
oversampling
action of collecting multiple measurement samples and averaging their values into a single
sample
Note 1 to entry: Oversampling typically decreases temporal resolution.
Note 2 to entry: The number of samples converted into a single sample is called OSR, or "oversampling ratio".
Note 3 to entry: Oversampling often implies sampling at higher rates than the Nyquist (IEV 723-10-28) rate to satisfy
the Nyquist criterion.
3.13
discrimination
measurement interval of a measured signal smaller than what a sensor is unable to uniquely
register
Note 1 to entry: Discrimination is often expressed interchangeably with measurement resolution, which means
segmenting a pre-defined measurement range into discrete steps.
3.14
context broker
middleware for exchanging contextual data
Note 1 to entry: A context broker is typically required for smart data standards like NGSI.
4 Abbreviated terms
ADC analog-to-digital converter
AI artificial intelligence
API application programming interface
BIM building information model
CBOR concise binary object representation
CPU central processing unit
DTw digital twin
GIS geographic information system
GNSS global navigation satellite system
I2C inter-integrated circuit
I3C improved inter-integrated circuit
IT information technology
IoT Internet of Things
JSON JavaScript object notation
LPWAN low power wide area network
LSB least significant bit
MEMS micro-electromechanical systems
ML machine learning
OPC open platform communications
OPC-UA OPC unified architecture
OSR oversampling ratio
OT operational technology
PCB printed circuit board
QUDT quantities units dimensions and data types
RMS root mean square
SenML sensor measurement lists
SI SI-unit (Le Système International d'Unités)
SiP system in package
SPI serial peripheral interface
XML extensible markup language
5 Background
5.1 Overview
5.1.1 General
Today's increasingly digitized technology is founded on sensory measurement. Among the
IT/OT environments underpinning an information-based society, there is a wide range of
structured and semi-structured data models that characterize the data shared between
IoT-based systems.
While the sensors that operate out in the field measure physical quantities according to
well-defined specifications, most often the measurements and the specification are not fully
available in the digital context.
Sensors operating in the field also have a limited interoperability with most other sensors –
either in other domains or other digital ecosystems. Sometimes this limited interoperability is
due to an inherent lack of data overlap, or even a lack of data completeness.
The range of IoT sensors varies in many respects, and a core assumption that can be made is
that, at runtime, no one sensor has complete compatibility with every other sensor. This is both
due to the actual information content (i.e. meaning) of data, and a lack of consistent
interpretation. When IoT sensors operate in separate ecosystems as individuals, they very often
adhere to different conceptual domains or product families. It is therefore necessary to ensure
that a baseline for interoperability can be created, and relied on, when embarking on system
or data integration projects.
Reducing the engineering cost revolves to a significant degree around predictability. Being able
to plan ahead allows system architects to reduce development and integration costs over long
timespans.
Many IoT-based exchange formats define semantics and data types to cover the most essential
primary data, and accompanying metadata to some degree. For sensory data, this often
includes some representation of the sensory value (magnitude) itself and its unit of
measurement, which can belong to any standard or non-standard choice of scale.
Variations in how data are encoded, structured, or serialized, bring with them a need for data
to be translated or adapted (through interpretation) before they can be used by a third party.
This is sometimes hampered by how data are recorded, which can limit how much useful
information it can carry.
Common drawbacks of many clear text-based serialization formats include arbitrary rounding
or truncation of measurement values (which can permanently strip away numerical precision),
and a lack of unambiguous representation of measurement units.
___________
In practice this means establishing a set of universally applicable principles that provide inherent interoperability
when adhered to.
Translating data between different formats therefore often requires ad-hoc integrations that
perform custom one-time conversion with or without safeguards for data integrity.
Variations in data representation in general can also constitute a challenge, since aggregating
a heterogeneous set of data sources (e.g. combining sensor data from weather stations and
traffic sensors with differing sampling rates and units) requires many separate conversions.
Taken together, it is therefore hard for IoT data models, which often are very well defined within
their own domain (or scope of application), to make assumptions about what data points:
a) it is necessary to provide to satisfy any future integration with a third-party data model,
b) will be available for import from third-party data sets,
c) meet the quality requirements for every specific implementation.
Essentially, the lack of universally available data points (e.g. unit, range, accuracy) in an
arbitrary sensor's data output is limiting its potential value to future applications. Consequently,
it will be necessary for any applications to which its data will be reusable to assess the data
sources' suitability – often through human intervention.
This is a costly process, and scales in proportion to the number of integrations with that data
source. For data with indefinite lifecycles (such as statistical, historic data about environments)
that should be kept for posterity, this is a cost that accumulates over time.
Reducing the cost of each integration beforehand is therefore in the interest of every involved
party.
5.1.2 Sensor-related data
While IoT data models vary greatly in characteristics and scope depending on domain and
application, every sensor with a digital interface that measures a physical quantity constitutes
a data source with some universally applicable characteristics, as summarized in Table 1.
Table 1 – Data source characteristics of a sensor
Sensor characteristic Data analysis impact Example
Sensors measure a physical Determines the dimension of A thermometer measures
quantity, which by definition will measurement in which an observed temperature in degrees Celsius,
include a numerical magnitude variable can vary Kelvin or Fahrenheit
and a unit
Sensors have an inherent Determines the minimum error of a A GNSS device with ± 3 m
accuracy of measurement sample's value from the actual value accuracy
Sensor measurement samples Determines the smallest possible A scale that records weight to the
are recorded with some
variation of a sample's value nearest 0,1 kg
numerical precision
Sensors are able to make Determines the measurement sample's A voltage sensor with an effective
distinct measurement samples highest sampling resolution measurement resolution of 0,5mV
by some minimum sensitivity
Sensor measurements are Determines the maximum time- A heart rate monitor collecting
a
collected over some period of data every second
resolution of the sample's value
time
Sensors output measurement Determines the time spacing between An accelerometer sampling at
samples at some maximum measurements 100 Hz (100 measurements per
sample rate second)
Sensors perform measurements Determines the range within which a A temperature sensor measuring
within some maximum sample's value can be considered valid from -50 °C to 150 °C
measurement range
Sensors transform the input The transformation outputs a scalar A pres
...