i4Q Trusted Networks with Wireless and Wired Industrial Interfaces¶
General Description¶
i4QTN is a software-defined industrial interface for data communication, characterized by predictability and determinism, high reliability, trustability and low consumption while reducing the cost of new communication infrastructure. i4QTN ensures high-quality data collection, providing connectivity to industrial data sources through Trusted Networks able to assess and ensure precision, accuracy and reliability.
Features¶
Provide a reliable and secure communication infrastructure.
Low Latency communications.
High availability, scalability and flexibility using private infrastructure.
Wired and wireless interfaces.
QoS guarantees, orchestrating network resources using a SDN controller.
ScreenShots¶
Comercial Information¶
License¶
One-time purchase license for individual part of the solution (Wired and Wireless).
Associated i4Q Solutions¶
Required¶
i4Q Trusted Networks with Wireless and Wired Industrial Interfaces solution has no dependency on another i4Q solutions and none of the i4Q solutions are dependent on i4QTN.
Optional¶
System Requirements for Wireless interfaces¶
IWSN Node: hardware platform based on CC2538 TI transceiver for each node to be deployed.
IWSN Gateway: SBC with IEEE 802.15.4 interface (i.e Raspberry Pi 4 with CC2538 transceiver using a tunslip6)
Different industrial or IoT sensors to be connected to the HUB platform (4-20mA, 0-10V, 24V DI, Modbus/RTU, i2C)
System Requirements for Wired interfaces¶
TSN Nodes: hardware platforms (switches, bridges, end systems) supporting collection of standards from IEEE 802.1 TSN (e.g., IEEE 802.1Qbv, IEEE 802.1Qcc, IEEE 802.1AS)
Data transfer via Ethernet
Windows 10 or Linux Ubuntu 18.04 for running the offline TSN Network Configuration Tool
API Specification for the IWSN Gateway¶
Resource |
POST |
GET |
PUT |
DELETE |
---|---|---|---|---|
/api/v1/login |
Supported |
Not Supported |
Not Supported |
Not Supported |
/api/v1/refresh |
Supported |
Not Supported |
Not Supported |
Not Supported |
/api/v1/gatewaystatus |
Not Supported |
Supported |
Not Supported |
Not Supported |
/api/v1/wsn |
Not Supported |
Supported |
Not Supported |
Not Supported |
/api/v1/<int:nodeid>/sensors |
Supported |
Supported |
Supported |
Supported |
/api/v1/wsn/upload |
Not Supported |
Not Supported |
Supported |
Not Supported |
/api/v1/config/network |
Supported |
Not Supported |
Supported |
Not Supported |
/api/v1/config/database |
Supported |
Not Supported |
Supported |
Not Supported |
/api/v1/config/mqtt |
Supported |
Not Supported |
Supported |
Not Supported |
/api/v1/config/opcua |
Supported |
Not Supported |
Supported |
Not Supported |
/api/v1/config/kafka |
Supported |
Not Supported |
Supported |
Not Supported |
Installation Guidelines¶
Resource |
Location |
---|---|
Last release (v.1.0.0) |
|
Video |
Installation of the IWSN system¶
The complete installation of the IWSN subsystem, included in i4Q Trusted Networks with Wireless and Wired Industrial Interfaces solution, requires the compilation and installation of different software componentes in different hardware platforms. First, the firmware compilation and updload for the Wireless Sensor nodes, based on Contiki NG OS, SDN-Wise and the needed developments to combine the use of Time-Slotted Channel Hopping (TSH) medium access method with the proper functions to support SDN scheduling rules and quality reports to the SDN controller. All the components requires specific hardware platforms, and the subsystem can not be virtualized or containerized, since the different platforms requires a direct connection with different physical interfaces, such as the 6LoWPAN network interface or the local system configuration to set up the WiFi AP or the Avahi mDNS services.
Uploading the firmware to the nodes¶
To upload the firmware to the nodes it is necessary to set up the Contiki-NG Toolchain, either through a native installation (Linux) or using the official Docker images. The easiest and fastest way is to use the official Contiki-NG images. For further information regarding the native or Docker installation, please follow the steps of the official Wiki.
$ docker pull contiker/contiki-ng
Instead of clonning the official repository (ContikiNG), download the compressed ZIP file with the i4Q ContikiNG and start docker with the following options:
$ docker run --privileged --sysctl net.ipv6.conf.all.disable_ipv6=0 --mount type=bind,source=<absolute-path-to-the-downloaded-i4q-contiking>,destination=/home/user/contiki-ng -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix -v /dev/bus/usb:/dev/bus/usb -ti contiker/contiki-ng
Finally, to build and upload the firmware, the IWSN node must be attached to the contiki-ng docker container, and the serial device must be specified to properly upload the firmware to the IWSN node (the following example shows the /dev/ttyUSB0
serial device). The TARGET=zoul
variable must be included, since the hardware platform developed is based on CC2538 TI transceiver and some other common components based on zoul platform pin assignment. To configure different node ids for each IWSN node, different hexadecimal numbers must be defined using the NODEID
inline variable.
$ cd examples/i4qtn-iwsn/
$ sudo make TARGET=zoul MOTES=/dev/ttyUSB0 NODEID=0x0001 i4q-node.upload
In case any problem occurs, the firmware can also be uploaded using the SmartRF Flash Programmer 2 from Texas Instrument and the .hex
firmware image of the i4q-node, using the TI XDS110 Debug Probe.
Start the SDN controller and the IWSN Gateway¶
The IWSN Gateway is based on a Single Board Computer (Raspberry Pi 4 or Tinker Board) that requires additional components to be able to interconnect with the 6LoWPAN IWSN nodes. Any mote with the CC2538 transceiver (Zolertia RE-Mote, Zolertia Firefly, Openmote or even the i4Q IWSN hardware developed) must be attached to the IWSN Gateway to define a new network interface to communicate with the IWSN nodes.
Since the IWSN Gateway requires different subcomponents to properly deploy the IWSN network, a bin bash script has been defined to schematically supervise the deployment process of each component of the IWSN Gateway. The official i4Q TN repository, with the developments up to M18, only host the components of the SDN controller and the backend subcomponent of the complete platform. The final version will explain in more detail the rest of the subcomponents.
sudo ./start.sh
This script supervise the deployment of each of the following subcomponents: mDNS Avahi service, 6LoWPAN network interface, local WiFi Access Point, local MongoDB database, Java SDN Controller, the backend service and the frontend service.
Installation of the TSN system¶
The complete installation of a TSN system is not a straight-forward task. It is more then just setting up the hardware with TSN IP, which is a first requirements for supporting TSN in the system. The setting up of such a system is application dependent, as it depends on the currently running application what kind of TSN schedule is required for sending messages. As this cannot be described in detail (as it is completely application specific), it is advised for the end user to get into contact with the technology provider (i.e., TTTech Industrial) for support on setting up the overall system.
User Manual¶
How to use the IWSN system¶
Once the firmware is uploaded to each IWSN node, these devices will connect automatically to the IWSN network, searching for beacons to detect the IWSN Gateway and providing quality reports to the SDN controller.
Regarding the IWSN Gateway, once the start.sh
bin bash script has been executed, all the system subcomponents should be available and interconnected. To configure the IWSN Gateway, before the definition of the frontend service, the following API/Rest examples must be used. The complete API/Rest specification will be defined in the final deliverable.
URL : /api/v1/login
Method : POST
Auth required : NO
Permissions required : None
Data constraints :
{
"username":"admin",
"password":"admin"
}
Success Responses:
Condition : User login success.
Code : 200 OK
Content :
{
"access_token":"token1",
"refresh_token":"token2",
"expires_in":300,
"token_type":"Bearer"
}
URL : /api/v1/gatewaystatus
Method : GET
Auth required : YES
Permissions required : None
Data constraints : {}
Success Responses:
Condition : IWSN Gateway information status.
Code : 200 OK
Content :
{
"ethernet": {
"dhcp": "Enabled",
"ip": "192.168.2.1",
"state": "connected",
"mDNS": "i4q-iwsn-16-38.local"
},
"wifi": {
"ip": "192.168.1.2",
"state": "disabled",
"ssid": "i4q-iwsn-16-38-wifi"
},
"sdn-controller": {
"state": "connected"
},
"lowpan": {
"ip": "fd00::1",
"state": "connected",
"conf_nodes": 5,
"unconf_nodes": 5,
"sensors": 8
}
}
URL : /api/v1/wsn/upload
Method : PUT
Auth required : YES
Permissions required : None
Data constraints : {}
Success Responses:
Condition : Upload SDN controller scheduling and sensor configuration to IWSN nodes.
Code : 200 OK
Content : {}
URL : /api/v1/config/kafka
Method : PUT
Auth required : YES
Permissions required : None
Data constraints :
{
"state":True,
"broker":"192.168.1.1",
"port":9092
}
Success Responses:
Condition : Kafka subscription success.
Code : 200 OK
Content : {}
To interconnect with this API REST the frontend service has been integrated to manage, configure and visualize all the system subcomponent with an user-friendly interface. Below some image of the web configuration interface are listed. Descriptions of the configuration process are included in final solution deliverable D3.12.
How to use the TSN system¶
As mentioned before, a TSN system cannot be used out of the box and much application specific information is required for setting up and using the overall system. A tool is available for configurating the overall network, enabling the user to define the following aspects of a TSN Network (which is application dependent):
Network topology
Planning of new components and data streams
Network configuration
The updated version of the solution will run directly on one of the devices inside the deterministic network. It is a network-wide scheduling and re-planning tools that is capable of identifying the needed quality of service configuration settings to achieve application specific latency and jitter requirements for the network layer. This configuration solution automatically sets up all standard network components (network switches and end systems) via a defined communication protocol (e.g., NETCONF) allowing to hide nteworking planning complexity from the user and enabling execution of (re-)configuration changes in an automated matter, e.g., dynamic addition/removal of publishers and/or subscribers in a system. The software does not required any user interface, it simply runs in a network device and facilites the planning of data streams according to the publisher/subscribed requirements.
Similar to the setting up of the TSN system, here much application and technology background is required. Therefore, setting up, configuring and deploying a TSN system can only be performed with the support of experts. For more information, please contact TTTech Industrial.