TapNLink Firmware Architecture

Request flow schematic

This schematic shows the main blocks implemented during a communication session with TapNPass. The main blocks are:

Host protocols (mainly wireless): receive requests from the outside world: a mobile phone or a remote device,
Command processor (lwM2M): processes lwM2M requests from a Host protocol,
JVM: processes an optional Java byte code. Note that the JVM is NOT available in all modules.
Control blocks: coordinate the protection of the system. They filter requests, code or decode them, validate or refuse them, and more.
Target protocols: link to the target system.

Host protocols

These protocols can receive requests via 2 channels:

Wire (UART). Mainly reserved for factory configuration (customization or provisioning), or test and development. It can be disabled by the configuration (like any protocols).
Wireless. NFC is available in all versions, and can be supplemented by BLE, WiFi, or LoRa.

Command processor (LwM2M)

This central element receives requests from Host protocols, processes them, and returns responses (at least a return code). These commands are always formatted packets:

They can be encrypted, in which case they are re-injected after decryption and the responses are encrypted before being returned.
They are usually commands available in high-level APIs, reformatted to be understood and decoded. These commands can be addressed to target protocols, or to security and configuration blocks.
Before being redirected to their destination, an authorization check is systematically performed. This usually involves determining whether the profile that issued the request is authorized to execute this command.

JVM (Java Virtual Machine)

The embedded JVM executes an (optional) embedded Java program that can:

read target or InTap variables,
triggers some event on complex conditions,
use the native classes such as String or JSON to format messages to any specific IoT platform.
use the MQTT interface to send direct messages to the Cloud (or through a LoRaWAN network).
drive directly the IOs, analog input, communication ports available on the extension and target connectors.
send commands to the lwM2M.

Target protocols

Target protocols allow for dialogue with an application:

SWD: Standard debug protocol for Cortex-M-based microcontrollers. Using this protocol allows you to build a PoC in a few minutes on an existing application. This protocol can still (when enabled) be used to perform a remote debug session.

S3P: filters addresses and secures communication to the target. It uses 2 GPIOs (like SWD).

On most Cortex-M microcontrollers it can be used on a debug port (that was disabled for protection).
On other microcontrollers (non-Cortex) it can be used on any pair of GPIOs as long as one of them is an interrupt input.

UART and modbus handler: UART is a configurable asynchronous serial I/O (baudrate, parity, handshake mechanism...). It can be used either to address Modbus variables (which are then subject to access control) or as a transparent serial channel.

Control blocks

All these blocks work together to coordinate the protection of the system and its data:

By validating that each order is compatible with the rights of the active profile.
By ensuring the security of end-to-end communications through authentication and encryption.

Other functional blocks

Not everything is represented on this diagram. It is necessary to mention in addition:

Singlepacket ⁽¹⁾ processing block transmits secure singlepackets in delayed time. They are used, for example, to transmit a firmware update or a temporary login token for an occasional user.
Data log processing block samples data from a bundle at a predefined time interval, stores it and then transmits it, in a singlepacket⁽¹⁾, from the Tap to a dedicated server.

(1) Singlepackets can contain one order, or a set of orders. They are like secure emails transmitted to, or received from, a remote interlocutor (usually a server connected to an MQTT broker).