Bundle: Group of variables used for the monitoring and; optionally, for data logging.

  • You can add variables by dragging and dropping symbols in IoTize Studio (configuration software°
  • You can link profiles to bundles to manage access rights
  • You can define the related data logging settings (enabled or not, frequency)

CORTEX M - MCU technology - If your target system is based on CORTEX M MCU, you can use the SWD protocol for the connection with TapNLink - In this case, you don't need to modify your target application to use TapNLink - You can also upadte or even debug your target application with TapNLink

Data logging: "object to cloud" data transfer, implying the following operations.

  • Tap data acquisition: the variables values are retrieved from your target application (though SWD or S3P)
  • Tap data storage (in an external EEPROM) e.g. sensor demo application can store about 700 data packets

  • Tap to smartphone transfer (when a smartphone is used as a WAN gateway)

  • Cloud transfer: done by a smartphone (or directly by a Tap)
  • Message translation:

    • done in cloud gateway (or directly in IOT platform)
    • translates the IoTize specific format to standard JSON format used by the IOT platforms
  • Cloud storage: in the cloud IoT Platform

  • Data visualization: in the cloud IoT platform (IoTize Primer Cloud Platform for the Primer)


  • In IoTize context applies to TapNLink firmware or target application firmware

    • both are related to firmware update capability
    • these features will be available in coming versions (T3 2018)
  • Generic definition is code of an embedded application.

Host: mobile device or PC connected to a Tap)

HTML pages:

  • Refer the pages (or static web site) generated by the app Generator included in IoTize Studio
  • These pages contain JavaScript code, which provide access to the IoTize Tap firmware, through a LWM2M protocol.
  • These pages taking into account the variables you have selected and the access rights (their layout and global organization can be entirely refined and customized).

ICS: (IoTize Communication Service). - Obsolete, replaced by IoTize Tap Manager on TapNLinks after July 2018.

  • Generic smartphone application on top of which the monitoring and local gateway applications are built
  • Available for iOS and Android.

IOT Platform:

  • Set of components (broker, Security, data collection, data storage, data visualization).
  • These components can be developed from IoT platform vendors (such as IBM, Microsoft, Amazon etc) and IoTize APIs and plug-ins. IoTize offer dedicated IT services to help customers develop their IOT platform and integrate it with their Information System.

IoT Platform Gateway:

  • Optional component which can be placed between your "IoTized" devices and your IOT Platform to facilitate integration (see general architecture section).
  • Mainly based on a broker, a software translator and security components.

IoTize Primer Cloud Platform:

  • IOT platform provided and hosted by IoTize for the Primer.
  • A dedicated space is provisioned for each TapNLink Primer, and associated to quotas

IoTize Primer Cloud Services: Services provided by the IoTize Primer Cloud Platform.

"IoTized" application:

  • Upgrade of an electronic application (originally not designed for "IOT")
  • Set regrouping initial target application + configured Tap + monitoring app. + customized cloud services and gateway (optional)
  • Name of a related Main menu in IoTize Sudio

IoTize Terminal - Free app supplied with TapNPass - Allows to dynamically change the default settings of serial communications such as the baudrate, parity.... - This app is also to test serial communications


  • Lightweight Machine To Machine protocol defined by the OMA Alliance for M2M or IoT device management. Defines the application layer communication protocol between an LWM2M Server and an LWM2M Client, which is located in an LWM2M Device

MCU: Microcontroller.

  • The TapNLink product range is mostly designed for MCU based target application (as opposed to the TapNPass products, which connect to target system though an industrial bus and support physical connections such as RS232, RS485, Ethernet, CAN...)


  • R/W access in (pseudo) real-time to target application variables, from a "smartphone", through a Tap.
  • The monitoring application can be developed in 3 different ways:

    • from HTML/JavaScript pages which can be automatically generated from IoTize Studio '(these pages can further be customized)
    • from a generic application
    • from native application, using API provided by IoTize

Monitoring from remote location:

  • Monitoring is done from a Web application (which can be run from a PC, smartphone, tablet) through a network. -->

MQTT broker

  • 'Relay MQTT broker': connects IoTize Studio to the Tap (through a smartphone) at the design stage

  • 'Cloud MQTT broker': connects the Tap to the IOT platform (through a smartphone). Also referred as the 'cloud_IOT_platform' gateway

  • For the Primer:

    • these brokers are hosted and managed by IoTize
    • they are implemented on a unique Mosquito server
  • On the standard version, the  implementation can be customized (and can be different for the 2 brokers)


  • Short for "Personal Computer/Smart Card": specification for smart-card integration into computing environments
  • Used as the connection mode wasbetween IoTize Studio and your Tap (but is no more in use)

Primer Kit: Similar to "TapNLink Primer". Refers specifically to all the physical "components" included in the kit (the tap itself, the cable, the demo board, the blister...).

Sensor Demo application: Demo target application (and board) included in IoTize Primer Kit.

Smartphone: - In the IoTize architecture, refers to any Android or iOS device that can run the ICS and support monitoring and gateway functions. - More generally, it refers to a mobile device (Android, iOS or Windows 10)

Smartphone gateway

  • Application developed on top of ICS to add WIFI ou 3G/4G  connectivity in a cost efficient way
  • Can be used in a bidirectional way to exchange data, commands and events between a Tap and a remote appliance

Software: In IoTize context, applies only to IoTize Studio.

SVD: System View Description file.

  • Provided by MCU vendors.
  • Complies with CMSIS/ARM specification.
  • Can be obtained from the Arm® web site after (free) registration.
  • These files allow you to select MCU registers as variables when configuring your Tap with IoTize Studio.

SWD: Serial Wire Debug

  • Serial Wire Debug (SWD) is a debug port similar to JTAG for ARM Cortex  
  • Provides the same debug capabilities (run, stop on breakpoints, single-step) but with fewer pins. It replaces the JTAG connector with a 2-pin interface (one clock pin and one bi-directional data pin)


  • Short for TapNLink (module)
  • Includes Cap + Circuit board (with MCU + connectivity chips + EEPROM).
  • All IoTize products, including TapNPass products, contain a Tap (for NFC pairing)

to tap : - Refers to operation of tapping a mobile device next to NFC-enabled product (TapNLink, Tap) - An FAQ explains how to place your mobile device (so as to align the antennas)

Tap Manager:

  • Generic smartphone application on top of which the monitoring and local gateway applications are built
  • Available for iOS and Android.
  • Refer to Why do I need Tap Manager FAQ for more details.
  • Note: TapNLink Primers prior to July 2018 used ICS (refer to the FAQ for details).


  • TapNLink standard: Covers several models, based on connectivity and embedded MCU. TapNLink without suffix implies the standard model.
  • TapNLink Primer. Evaluation kit of the TapNLink range. Contains:

    • a Tap (preconfigured for the sensor demo app)
    • target board sensor demo app example
    • cable
  • TapNLink Primer limitations are: number of variables and bundles, limited duplications, data logging frequency.

TapNPass: The TapNPass range is intended for integration on a standard industrial bus that is already in the target system. They support RS232, RS485, Ethernet, CAN, and USB and Modbus connections and CANopen system protocols.

Target - Target system term to refer to your target system can be a MCU-based system or a bus system - Target application / Target code generally refer to the firmware (generally written in C or Asssembler) of your MCU-based system

TLV (Type-Length-Value)

  • Encoding scheme used for optional information element in a certain protocol.
  • The type and length are fixed in size (typically 1-4 bytes), and the value field is of variable size.
  • This format is used by the the Tap (IoTize module) to store and transfer the message data (in the form of packets).

Variables: Symbols that have been added to a Bundle; from:

  • Elf file (containing the variables defined in your source C or Assembler source code)
  • SVD file (peripheral registers of Microcontroller used)
  • User-defined list (in this case, symbols are attached to "absolute" address)