Task Parallel Library – Internet of Things

We want to implement a energy monitoring system with the help of C# library which has interface with an Embedded System and relevant controllers attached to it. Its essential that we communicate with these devices and understand the data trends they provide. This would help to build the intelligence through some machine learning algorithms and there by improving the intelligence of these devices.Smart Home

The challenge in doing this is to have a master controller or a service which can talk to these devices are different intervals sequentially or parallel so that it can be more realistic and efficient. While I was looking at developing this kind of app I was looking at c# to implement a multitasking to communicate with these devices at different intervals in parallel. Thanks to TPL the Task Parallel Library of .NET Framework. Before I started writing these post I read about the TPL on  Introduction to TPL , Parallel Tasks in .NET 4.0 – Dotnetcurry and Understanding Task Parallelism Framework (TPL) using C#. These are really good articles to hit the ground pretty fast.

The rationale behind looking at this option is to evaluate how we can make best use of concurrency to collect data from devices and pass it on to the Message queues like Mqtt/RabbitMQ. This scenario would be very much helpful when you have the following scenarios with respect to M2M or IoT:

  1. Devices cannot be reprogrammed with the client to develop and deploy client app to the device.
  2. You have the exposure of data through connectivity means
  3. You can poll the devices for specific parameters through Usermanual
  4. You have connected your smart devices through LAN via Wi-Fi or Ethernet
  5. Communication can be done to the devices via standard protocols

Why TPL?

  • Need to interact with the devices concurrently
  • The topics needs to be monitored and can invoke parallel tasks based on the nature of message
  • The parallel tasks could be like sending Alerts, Notifications, Writing logs, etc.,
  • Tasks should all be done in an async manner

In the another post, I will try and see how we can accomplish this with the help of TPL.

Steps in reading a modbus register

Modbus.org has most of the information with respect to modbus. Modbus protocol has master/slave communication model. Master sends the queries to the slave to get a response. Masters have the capability to talk to individual slave or it can broadcast messages to all the slaves. Slave could be a Meter, Temperature reading device, etc.,  Modbus

It supports two modes of communication one is ASCII and another is RTU mode. Modbus ASCII vs Modbus RTU to know the differences between ASCII and RTU Mode. Any communication to modbus slave for reading the registers should have the following components with it.

  1. Slave Id
  2. Function Code
  3. Data address of the first register to read
  4. Total number of register to be read or length to be read
  5. CRC check

Typically holding registers will hold the data which will be available in the register value between 40001-49999.

Request:

Lets take an example of reading a value from the register 110. Slave Id could be 1. The function code would be 3 for reading the holding register. So the offset value added would be with 40001+110 which would be 40111.   Assuming we might need to  2 registers as the length. Maximum slave Id could be 247.

Important thing to understand while custom programming modbus devices is to ensure that modbus maps from the vendors are thoroughly read so that we can avoid overlaps.

Connectivity challanges with respect to IoT Devices

With the emergence of Internet of things there are various challenges exists with respect to aggregating data to a centralized data repository because of connectivity issues. This post envisages to outline the challenges in detail.IoT Unique Characteristics

1. Unable to connect to the internet because of limited connectivity or range in remote locations where manufacturing facility exists

2. Bandwidth available with 2G options such as GPRS is very limited for data transfer

3. Intermittent loss of connectivity would hamper the data communication process from the IoT devices to the Private or Public Cloud

4. It must be secure enough as it might pose a great danger if its not well controlled

5. Must have the capability to Poll or Push data