IoTize architecture and concepts
IoTize product range
The IoTize offer is divided into two distinct product lines that correspond to their physical connections to target systems:
Technical versions and pre-requisites
The TapNLink to target board's MCU connection mode is either SWD or S3P:
- Pre-requisites for SWD mode
- Target board MCU: ARM® Cortex®-Mx
- Target board connectivity:
- Physical connector to access SWD port on your application board
- Enabled SWD port
- Pre-requisites for S3P mode
- Target MCU: no pre-requisite
- Target board connectivity
- Physical connectors to access the required GPIOs on your application board
- 2 GPIOs, one of them providing interruption (GPIO can be the SWD port of STM32)
The limitations cover several areas:
- The max number of variables (Bundles + Variables + Profiles + Users) is:
- Primer: 15
- Standard: > 15 (Memory Usage in IoTize Studio shows exact number).
- The minimum data logging interval is:
- Primer: 60 seconds for the Primer.
- Standard: < 60 seconds (possibly 1 second).
The Standard has better security than the Primer:
- Configuration reserved for administrator.
- Access limited to pre-defined variables, bundles and profiles.
- Passwords hashed with PBKDF2.
- IoTize firmware update encrypted with AES128.
- Variables, bundles and access/configuration rights are customizable.
- Passwords hashed with more secure hashing mechanism.
- Encrypted telephone / cloud / studio communications.
- Encrypted data packets (for transfer).
For TapNLink (standard or Primer) without WAN connectivity (WIFI, Lora...), the Tap and IoTize Studio connect through the ICS app on your smartphone (which communicates with the Tap in BLE). The connection between your Tap and the ICS app can be based on either:
- Whatever the variants, requires that the PC can access to a common network and can establish an end to end connection with the smartphone
- Advantages and disadvantages for smartphone connection types.
- WIFI infrastructure
- Pro: fast and simple
- Con: Requires access to an external WIFI AP 'access point
- WIFI in access point (AP)
- Pro: Fast and simple
- increase smatphone power consumptio ('more that 3G/4G service
- Requires the PC has a WIFI connexion
- Pro: avoid the constraints mentioned previously
- slower than WIFI
- Costs for the data service
- Possiblity to establish and end to end connection not guaranted (depend on Internal security policieies, firewall...°
- Requires internet access for both the PC and the smartphone (if the Broker is installed in the cloud)
- Suitable when the Studio and the smartphone cannot access a common network
- Slower than socket mode (reliability depends on the Internet access)
- For a TapNLink Primer it is simpler to connect in socket mode first, which allows to recovers the credentbroker (for the folllowing connections)
- For a TapNLink standard, you can install and use your own broker (see AN14) or ask IoTize.
The TapNPass supports physical connections on RS232, RS485, Ethernet, CAN, and USB (supporting FTDI232 and CP210x serial transceivers).
- If the system protocol is ModBus, the TapNPass line offers the same software features as TapNLink (equivalent features will soon be available for CANopen):
- configuration using IoTize Studio
- In this case, the mapping to select the variables and bundles is done from an XML file representing the ModBus registers
- This XML file has the same structure as SVD files
- accelerators to build monitoring application, based on ICS
- data logging and more globally connection to IOT cloud platforms...
- Otherwise, TapNPass is only a (transparent) serial channel