Cloud platforms have emerged as a powerful foundation for tracking IoT assets in real time. By combining IoT connectivity with cloud-based data processing and analytics, businesses can monitor device location, health, and performance throughout the entire asset lifecycle. This approach not only improves operational efficiency but also enhances security, reliability, and decision-making in increasingly connected environments. Here, DMC discusses various approaches for asset tracking in the field.

Options for Tracking Assets in the Cloud

A variety of tools exist to support an organizational strategy for cloud-based asset management. Since this is a broad solution category, with requirements differing from use case to use case, the best structure for a particular organization can vary. Different platforms present tradeoffs in how they model assets, where they run, and how much responsibility they place on engineering teams.

Open-Source and Self-Managed IoT Platforms

Open-source platforms sit at the foundation layer of IoT. They provide the essential capabilities—device connectivity, telemetry ingestion, rules engines, and dashboards—without prescribing how your asset tracking solution should look or behave.

These tools appeal to teams that want full control over their data, infrastructure, and deployment model. If your assets don’t fit neatly into predefined schemas or your workflows are non-standard, these platforms can provide the building blocks to model assets exactly the way your business requires. They’re also attractive for organizations that want to avoid vendor lock-in or support hybrid and multi-cloud deployments.

The upside of this flexibility is transparency and extensibility. You can inspect the architecture, customize nearly every layer, and keep licensing costs relatively low at small to medium scale. The trade-off, however, is ownership: scaling, securing, and operating the platform requires in-house expertise or professional support.

At their core, open-source platforms act as a foundation on which to build your solution, not a finished service you simply turn on.

Examples: Thingsboard, EdgeX Foundry, KubeEdge, and fully custom implementations.

Cloud Provider IoT Platforms

Large cloud providers offer IoT tooling that supports a different approach, with different trade-offs. Rather than focusing on the asset-focused elements of a solution, the core IoT offerings from these large providers tend to focus on doing a few things extremely well: secure device connectivity, massive-scale messaging, and deep integration with cloud services.

Asset tracking on these platforms emerges by composing multiple services together—IoT hubs, databases, analytics tools, visualization layers, and automation pipelines. This model works particularly well for large-scale deployments with unpredictable growth, especially when the organization is already heavily invested in a specific cloud ecosystem.

The strengths here are hard to ignore: proven global scalability, mature security and identity management, and seamless access to cloud-native analytics, AI, and automation services. The trade-offs are mostly architectural. Asset management is not turnkey, pricing models can be complex, and teams must make careful design decisions across many interconnected services.

In short, building your solution with these tools and infrastructure can provide a lot of power and configurability, but the usefulness of the asset tracking solution is defined by how thoughtfully you assemble the stack on top of it.

Examples: AWS IOT and Azure IoT Hub.

Edge-First and Hybrid IoT Platforms

It is also worth noting that there are both open-source and large cloud-provider-based options that focus on the edge elements of these solutions. These platforms shift asset tracking closer to where assets actually operate—factories, vehicles, and remote sites. Rather than relying on sending everything to the cloud, these systems enable local processing, decision-making, and resilience in environments with low-latency or intermittent connectivity.

This model is especially valuable for safety-critical systems, bandwidth-constrained scenarios, or assets that must continue operating when disconnected. By reducing cloud dependency, edge platforms align more closely with real-world operating conditions.

The trade-off is complexity. Edge deployments require device management strategies, careful orchestration, and are often paired with a cloud platform rather than used standalone.

Edge-first platforms ultimately redefine asset tracking as distributed by nature, not purely cloud-centric.

Examples: AWS Greengrass, Azure IoT Edge, and EdgeX Foundry.

Industrial and Enterprise Asset Platforms

Companies focused on manufacturing, industrial, or enterprise applications offer platforms for managing assets that are tailored towards the idea that assets are not just devices emitting data, but long-lived physical entities with maintenance histories, operational constraints, and regulatory requirements.

These platforms are common in manufacturing, utilities, energy, and transportation, where assets are expensive, critical, and expected to operate for decades. They excel at rich asset modeling and digital twins, and they often include built-in workflows for maintenance, reliability, and operations. Tight integration with ERP, EAM, and OT systems makes them especially powerful in asset-heavy enterprises.

That depth comes at a cost. Implementations tend to be expensive and time-consuming; the solutions are frequently limited in their application, with minimal or limited flexibility for experimental or non-industrial use cases.

Here, asset tracking is framed as part of operational activities, rather than merely a data collection exercise.

Examples: Siemens MindSphere, IBM Maximo, and ThingWorx.

Managed IoT and Asset Tracking

Finally, a wide range of companies offer SaaS or PaaS products in the asset management space. For the most part, these products focus on one thing above all else: reducing complexity. They aim to deliver end-to-end asset tracking solutions with minimal setup, prebuilt dashboards, and opinionated workflows that cover the most common use cases.

These tools are well-suited for teams that want faster time-to-value, small to mid-scale deployments, or lack the resources to manage complex cloud architectures. The experience is typically streamlined, pricing is clearer, and operational overhead is much lower than with self-managed platforms.

The pain points with these products show up as deployments grow or requirements become more specialized. Customization options can be limited, advanced analytics may be constrained, and vendor lock-in becomes a real consideration.

These platforms prioritize speed and reduced complexity over architectural freedom, which can be limiting depending on the application.

Custom Development Support for IoT Asset Tracking

There’s no single “best” IoT asset tracking platform—only platforms that align more closely with your organization’s scale, requirements, and data handling priorities. Additionally, regardless of the platform selected, some configuration and customization are required to make sure the solution works for your use case. In these cases, support from a team experienced in implementation can make all the difference in delivering a complete, useful tool for your business. 

Infrastructure and System Setup

Centralizing asset tracking requires setting up the necessary cloud infrastructure for managing telemetry from devices, running analytics, and providing user access to data. Working with a team familiar with the tooling and components required helps you to get up and running sooner, with a solution that balances robustness and cost considerations for your specific use case.

Dashboard Development or Configuration

Much of the value of cloud-based asset management comes from the ability to monitor device status and to run analytics on incoming telemetry. Visualization is an important component of making this data accessible to users, and working with a team familiar with a wide variety of available options ensures you get a result that matches your needs for user accessibility, brand look and feel, and ability to postprocess the data. This might include UI/UX support, customization of existing tooling, integration with other applications, BI dashboard development, or custom web portal development.

Edge Device Customization, Connectivity, and Firmware

Whether you are looking to expand your devices’ connectivity or update the capabilities to better support your centralized tracking and management, working with a proven team can ensure the effort is completed to a high technical standard without sacrificing cost and schedule efficiency. This could include hardware updates or a new design to improve device connectivity to the cloud, updating data reporting portions of device firmware to best take advantage of the configurability and visibility afforded by centralized asset management, or implementing Over-the-Air (OTA) updates for your device.

Explore more of our IoT resources:

• Custom IoT Development Services
• Custom Fleet Management Solutions

The post Smarter Asset Tracking with Cloud‑Based IoT Solutions appeared first on DMC, Inc..

IoT Solutions Overview

IoT solutions are typically comprised of a fleet of field devices, a cloud-hosted hub to which the devices communicate, and a user portal providing visualization and control. 

The field devices could be a wide variety of “things”, including single-purpose sensors, consumer electronics, manufacturing equipment, vehicles, or many more. Each device is provided with a way to identify itself as unique compared to the rest of the fleet and a protocol for communicating with the hub.

The hub system works to send and receive messages to the devices, and to process and save data for the portal to consume.

The portal provides an interface for a user to view, handle, and react to the data provided by the field devices and may take the form of a web interface, a mobile application, or both.

These solutions provide value for their end users through increased data availability and transparency, as well as convenient device management and control. On the reporting side, messaging from the devices can relay status, utilization, and data for aggregate reporting across the system. On the management side, the portal provides an easy way to view information about the devices, download updates to the devices, or control the configuration in the field.

Custom VS. Of-the-Shelf

There are existing solutions available for purchase for a number of use cases that benefit from IoT integration; the most familiar of these might be consumer systems like thermostats or security systems. Other places you might see an off-the-shelf IoT solution could be inventory tracking for retail, or “smart building” solutions that monitor energy use and HVAC conditions.

The alternative to an off the shelf is a custom-built solution, where the user application, cloud infrastructure, devices, or all three are self-managed. These solutions might provide a way to add additional visibility to an existing process or define a new system with unique reporting and management requirements, and can be applicable across any industry, with examples ranging from agriculture to logistics to consumer products.

As such, a necessary choice when deciding to incorporate IoT is whether to go with an off-the-shelf solution or to build a custom setup.

When to Build a Custom IoT Solution

Custom IoT Solutions provide advantages in flexibility and control over their off-the-shelf counterparts. Here are some cases where those advantages might make building a custom IoT solution the right choice:

Creating or Integrating a Custom Device

When working with a custom device, the ability to control the messaging capabilities, formatting, and frequency that a custom solution provides can be very useful. Additionally, setting up the cloud side of the system to work directly with the device allows for extended remote capabilities, such as Over the Air (OTA) updates to the devices and direct control of the device or device configuration.

Specific Management or Reporting Requirements

Making specific workflows or reports work with vendor systems can be a challenge. Therefore, custom solutions deliver value in this area by reducing or removing the dependency on external systems; if the solution is built custom, it can be built to match the desired workflows and provide the desired data from the end device without excessive configuration.

Maintaining Future Flexibility

Custom solutions can change as the system does; if components change or new requirements come up, the solution can be updated to match. In addition to uncoupling the solution from a vendor’s roadmap, this can also facilitate the agile development of new systems by allowing solution components to evolve together.

Infrastructure and Cost Control

Custom solutions provide direct access to and control over the associated cloud resources. This provides complete control over how data is routed, stored, and secured relative to other business data, rather than depending on a third-party cloud tenant. If a business already maintains a cloud tenant, the infrastructure required for an IoT solution can frequently be added in a straightforward way. Direct access to these resources can also provide better visibility and control over recurring hosting costs, rather than this information being obscured by a license.

Advantages of Working with a Software Engineering Firm for Custom IoT Solutions

If building a custom IoT solution looks like the right option for your business, a software engineering firm can help your implementation project run smoothly and be completed successfully. Working with a team of engineers experienced in custom specifications and implementing the necessary components brings a breadth of experience to building the solution that you may not otherwise achieve.

Technology Expertise

The first advantage a firm like DMC can bring to your project is expertise in the technologies underlying IoT solutions. This includes experience designing and writing firmware for custom devices, implementing cloud architectures, and developing custom web or mobile applications. This expertise enables the team to build system components efficiently and cost-effectively and implement the communication interfaces between them. Additionally, experience in the platforms used means implementation can avoid common pitfalls.

Thorough Design Process

Another advantage of working with a software firm to build out a custom IoT solution is the thorough design process. Since the team frequently works to customer specifications, there is an established process to make sure the solution is designed to best match all of your requirements.

First, engineers will work with you to refine your requirements into specifications for user workflows and device communication. Then, the UI/UX team can develop mock-ups of the project interfaces. After review, the team can begin building the components and regularly review them with the client team to ensure alignment.

Project Management

Finally, working with a software firm also brings the advantage of a dedicated project manager and an established project management process for your implementation. The project manager is familiar with the tasks required to deliver the solution successfully and is equipped with tools to track the schedule, budget, and requirements. A standard cadence of meetings and status updates keeps you involved in the development effort, able to provide feedback, ask questions, and guide the solution over the course of building the solution. Additionally, as the project evolves, the dedicated project manager can quickly reprioritize tasks and generate new specifications as needed.

Explore Our Work in IoT

The post Custom IoT Development Services appeared first on DMC, Inc..

How to Update Defender for IoT

1. Navigate to portal.azure.com and search for Microsoft Defender for IoT. 

2. Navigate to “Sites and Sensors.” 

3. In the “Site and Sensors” list, choose the sensor you want to update. 

4. You’ll have two options: “Remote update” (push an online upgrade) or “Download upgrade files” (manually upgrade from the local network). 

5. In our example we will update locally to 22.3.10 and push an online update to 24.1.3 after. 

6.1.1. If you select “Download upgrade files,” you need to choose your sensor version (in our case it’s 22.3.9) and if you have a local manager. 

6.1.2. From the “Available versions” list you need to choose what version you want to update. If you need to update to an older version, choose “Show more.” 

6.1.3. Navigate to your Defender for IoT internal IP address and login with CyberX credentials.

6.1.4. Navigate to system settings, software update, upload file. Choose the upgrade file you previously downloaded and click open. When it finishes uploading it will display “Status: Updated successfully (Agent will reboot in 30 seconds).” Note: it took ~5 minutes.

6.1.5. When it’s done, you can see that the version of the system changed.

6.2.1. Choose “Step one: Send package to sensor.” 

6.2.2. Choose the version you want to install (the latest available version will display). If you need an older version, click on “Show more” and choose the version you prefer to install. Then, click on “Send package.”

6.2.3 You should see the status under “Sensor version” tab.

6.2.4. When it’s done, the status will change to “Ready to update.”

6.2.5. Navigate to the “Remote update” and choose “Step two: Update sensor” and click “Update now”, “Confirm update.”

6.2.6. The “Sensor version” will change to “Installing.”

The post Updating Microsoft Defender for IoT appeared first on DMC, Inc..

Connecting IoT Devices to an IoT Edge device allows for data processing to be even faster since an IoT Edge device allows you to analyze data closer to your IoT devices. This gives you the advantage of preprocessing data prior to sending it to the cloud.  

In this article, we will review how we can get data running on an ASP.NET application of a child device to an OpenTelemetry Collector module running on an IoT Edge device up into Application Insights in the Azure cloud. Since the application is running on a separate device than the device running the OpenTelemetry Collector module, this example can be used to send trace and metrics data to Application Insights when an IoT device does not have direct access to the internet but the IoT Edge device does. 

OpenTelemetry is a framework and toolkit to manage telemetry data. It provides a protocol that specifies how telemetry should be formatted and set. OpenTelemetry is favorable to use since it is vendor and tool-agnostic and can be used with different Observability backends such as Jaegar and Prometheus. Additionally, OpenTelemetry provides SDKs to implement clients in different languages, including .NET. 

Prerequisites 

• Visual Studio 2022 Preview 
• Docker Desktop 
• Application Insights resource in Azure 
  • Application Insights is not a totally free service, but Azure offers a free account that comes with $200 in Azure credits.
• IoT Edge device to deploy modules 
  • The IoT Edge device will be used to deploy the OpenTelemetry Collector module. You can follow this tutorial to set up your IoT Edge device and example module. 

Implement the OpenTelemtry Exporter in ASP.NET Application 

To get started, I created an ASP.NET Core Web App (Razor Pages) project with .NET 8.0 from the Visual Studio project templates. 

Next, we will add an OpenTelemetry exporter to the service registration of our web application. There are a variety of exporters to choose from, but for this tutorial, we will use Prometheus to export metrics and OpenTelemetry Protocol (OTLP) to export application logs. 

I chose Prometheus for metrics since it is highly reliable when recording numeric time series data, and it has an easy plug-in to use with C# and ASP.NET. I chose OTLP for logs since it also has an easy plug-in for ASP.NET and Prometheus does not support exporting traces. 

The Prometheus Exporter relies on the following packages: 

• OpenTelemetry.Exporter.Prometheus.AspNetCore 
• OpenTelemetry.Extensions.Hosting 

The OTLP Exporter relies on the following packages: 

• OpenTelemetry.Exporter.OpenTelemetryProtocol 

Your Program.cs file should look like the following: 

1. Configure logging to log to the console and to the OpenTelemetry OTLP Exporter. The IP address used for the OTLP Exporter endpoint should be the IP address of the IoT Edge Device. The default HTTP port is 4318 with the relative path of “v1/logs” as described here. 

2. Configure OpenTelemetry to use the Prometheus Exporter to export metrics. This example configures built-in metrics for “Microsoft.AspNetCore.Hosting” and “Microsoft.AspNet.Diagnostics.” It also configures metrics, for example, custom metric “HatCo.HatStore.”

3. Configure the web application. 

4. Configure the web application to use the Prometheus scraping endpoint. Run background, test logic to generate logs and custom metric data for “HatCo.HatStore”. Run the application. 

Add the OpenTelemetry Collector Module to your IoT Edge Device 

We are going to test running the IoT Edge Modules in the simulator. This will allow the modules to run on your local Docker container registry. 

Within your IoT Edge VS project, we will edit the “deployment.template.json” file to add the OpenTelemetry Collector module. The “modules” section should look like the following example. 

The image name should match the desired image name when we create the OpenTelemetry Collector image in Build the Module. The $APPI_CONNECTION_STRING is an environment variable on your local computer that can be set in a .env file within the VS solution. APPI_CONNECTION_STRING sets up an environment variable within the OpenTelemetry Collector module, and this variable is used in the config.yaml file for configuring the module which I’ll detail in the next section.  

Once the deployment file is edited, right-click the Edge project and select “Generate Deployment for IoT Edge.”

Create the Configuration File for OpenTelemetry Collector

Before running the OpenTelemetry Collector module on our IoT Edge device, we will want to configure how the OpenTelemetry Collector module will receive data from exporters in our ASP.NET application and configure how the OpenTelemetry Collector should export the data it receives. The configuration for the module goes into a .yaml file. Your configuration file should look similar to the example below. You can add this config.yaml file into your IoT Edge solution that was created in the IoT Edge tutorial. 

In this example, we have configured the OpenTelemetry Collector module to use a Prometheus receiver to scrape metrics. The Prometheus receiver on the OpenTelemetry Collector module has to actively scrape the endpoint where the child device is running the ASP.NET application. We then use Azure Monitor to report those metrics to Application Insights. For the “scrape_configs” section, the “targets” are the endpoints where you would like to scrape metrics from. You can have multiple “scrape_configs”. Note that as configured, Prometheus will scrape only from HTTP endpoints. If your ASP.NET project uses different ports for HTTP and HTTPS, ensure to provide the HTTP port. 

We have also configured an OTLP receiver to retrieve logs. The default endpoint for the OTLP receiver using the HTTP protocol is https://static.dmcinfo.com/v1/logs which is what is configured for the OTLP exporter on the ASP.NET project. “Localhost” here references the Edge device. The logs are also exported to Application Insights via Azure Monitor. Note: the “localhost” link is part of the tutorial and can only be accessed locally as part of running the tutorial itself.  

Build the Module 

To build the module in Docker Desktop, we will utilize the public OpenTelemetry Collector module image, and then we will copy our configuration file into it to modify the agent behavior. Create a Dockerfile to pull the OpenTelemetry Collector module image and copy over your configuration file. In the Dockerfile, we expose 4318 so that the ASP.NET application can push logs to our OTLP endpoint. The example Dockerfile below assumes that the Dockerfile and the config.yaml file are in the same directory. 

Within a command prompt, navigate to the directory where your Dockerfile.amd64 file lives. Run the following command to build and push your image to your local Docker container registry. 

docker build -t localhost:5000/opentelemetrycollector:0.0.1-windows-amd64 -f Dockerfile.amd64 . 

docker build -t localhost:5000/opentelemetrycollector:0.0.1-windows-amd64 -f Dockerfile.amd64 . 

Deploy the Edge Device and Collect Logs and Metrics 

After generating your deployment file for the Edge device, right-click the Edge project and select “Build and Run IoT Edge Modules in Simulator.” This will run the OpenTelemetry Collector module from your Edge device on your local instance of Docker Desktop. You should see the logs for the OpenTelemetry Collector module trying to scrape your application metrics. 

View Metrics and Logs in Application Insights 

Once the Edge device is running, run your ASP.NET project. Navigate to your Application Insights resource in Azure Portal. In the left-hand navigation bar within the Application Insights resource under Monitor, select Logs. Query the logs for “traces” and “customMetrics.”  

Under traces, you will see your application logs appear. 

Under “customMetrics”, you will see your application metrics which includes the example metric “hat_sold_Hats_total.”

Conclusion 

With this tutorial as an example, you now have the ability to collect metrics and logs via an IoT Edge device from multiple applications! 

The post How to Integrate Azure IoT Edge, .NET, OpenTelemetry Collector, and Application Insights appeared first on DMC, Inc..

At DMC, we offer a wide range of software consulting services, and our experience with ThingsBoard is just one part of our extensive toolkit. Whether you need help with IoT solutions, custom software development, or anything in between, we’ve got you covered. In this post, we’ll explore the capabilities of ThingsBoard and how you can leverage it to build a professional IoT solution.

What is ThingsBoard?

ThingsBoard is an IoT platform that stands out for its versatility in device management, data visualization, and customer management. These features are all available out of the box and can be set up with minimal overhead. It supports multiple device protocols, including MQTT, CoAP, HTTP, and others, making it compatible with a wide array of hardware and software systems.

The platform offers flexible hosting options—whether you prefer cloud-based solutions on Azure or AWS, or a self-hosted environment. This flexibility allows you to scale your IoT projects as needed, making ThingsBoard a strong choice for businesses of all sizes.

How DMC Leverages ThingsBoard for IoT Success

At DMC, our software consulting services encompass a wide range of technologies, and ThingsBoard is one of the many tools we use to deliver top-notch IoT solutions.

AirVac Vacuum Sewer Systems

For AirVac, a subsidiary of Aqseptance Group, we utilized ThingsBoard to develop a custom IoT dashboard for managing vacuum sewer systems. The project involved real-time telemetry data and a detailed vacuum station dashboard, demonstrating ThingsBoard’s robust visualization capabilities.

The Device Map Dashboard allows an operator to easily view all their deployed devices and any active alarms or relevant telemetry on them.

Live telemetry plots with adjustable time ranges are incredibly simple to implement in Thingsboard as shown below.

More Traditional SCADA style dashboards can be implemented as well as shown below.

Why Choose ThingsBoard for Your IoT and Software Development Needs

Data Visualization

One of the key strengths of ThingsBoard is its powerful data visualization tools. The platform’s built-in widgets and customizable dashboards allow for real-time monitoring and analysis, making it easier to gain actionable insights from your IoT data. Check out the live demo to see ThingsBoard in action (see it in Dark Mode by clicking the icon in the top right).

Asset and Device Management

ThingsBoard makes asset management straightforward with its built-in user access controls. Whether managing a handful of devices or thousands, the platform’s scalable architecture ensures that your IoT solution grows alongside your business. 

Alarm and Notification Handling

ThingsBoard’s alarm handling features are another highlight. With trigger-based alarms linked to device telemetry, you can integrate notifications via services like Twilio to stay informed about critical events in real-time.

Partner with DMC for Your Next Software Project

Whether you’re exploring the potential of IoT with ThingsBoard or need a partner for a complex software development project, DMC is here to help. Our team of experts is ready to guide you through every step of your project, ensuring that you achieve your goals efficiently and effectively.

If you’re searching for a reliable partner to implement an IoT solution or any other software project, look no further. Let’s collaborate to bring your vision to life with a platform and a partner that understands the full spectrum of software development needs.

The post Exploring ThingsBoard: An IoT Platform for Your Next Project appeared first on DMC, Inc..

Before we discuss the functionalities of Node-Red, it's important to address one question: when would I use Node-Red? Node-Red is most commonly used in the following cases:

1. A client wants to store PLC data in the cloud. This could be logging data in an Azure Hub database and then using that data to generate PowerBI models.
2. A client wants to be remotely alerted when something in the PLC logic occurs. Perhaps they want to be notified when a temperature sensor reads a certain value and take action accordingly.
3. Both of the above!

There are edge cases where Node-Red is used to remotely control PLC tags, but this is typically not recommended. In short, any time you have PLC data that you want to process and send to the cloud (whether to store it in a database or notify you directly), Node-Red will do the job.

It's important to note that Node-Red needs some hardware to connect to your PLC. This could be a PC or IoT device that is connected to your network. In my case, I used a Siemens IoT2050 Advanced that came with Node-Red pre-installed.

The overall layout of the Node-Red is relatively simple. On the left, you have your toolbox of "nodes". Each provides a different functionality, and there is a large library of community-made nodes that you can import using the "manage palette" option in settings.

In the center, you have your working area. This is where you will drag in nodes to write your processing logic. Notice the tabs at the top of the working area; each tab is called a "flow". These are like pages in an Excel sheet or function blocks in a PLC program. Each flow can store tag data in its own memory, like the internal memory of a PLC function block.

The various icons on the top-right corner provide you with a variety of details about your project, but the most important one to have open is the debug window. The debug window acts similarly to the console window in any programming environment. This window is where you will see the outputs of your code. You can locate this by navigating to the beetle icon.

The last important feature of the Node-Red layout is the big red "Deploy" button. This runs your code. Node-Red behaves similarly to a PLC; once you deploy your logic, it will run continuously until you re-deploy the program with any changes.

Debugging: Inject Node & Debug Node

Before we can discuss some basic Node-Red logic, we should understand two essential debugging/early development nodes: Inject and Debug.

Node-Red logic is initiated by a message being sent. In practice, this might be a PLC Boolean flipping to "True". For troubleshooting purposes, it's useful to be able to inject a message whenever you want to initiate a flow. This is where the inject node becomes crucial for initial logic development.

While the inject node is essential for starting a flow, the debug node is essential for observing the output of a flow. It would be impossible to troubleshoot without knowing what your output is. Wiring your node logic into a debug node sends the message payload into the debug window. Any node's output can be wired into a debug node. This gives you the ability to observe your message payload at every stage of your processing logic.

Message Structure

There's one more topic I'd like to discuss before we get into some basic logic examples. I believe it's important to understand the structure of Node-Red messages. In the previous paragraph, I mentioned that a Node-Red flow could be triggered by a PLC Boolean flipping to TRUE. In Node-Red, the message would consist of two parts. The first is the "topic". When you configure your PLC tag import node, you'll assign a label for the PLC tag. Whatever you choose to label your tag will become the message topic.

The second part of the message is the "payload". This is the contents of the message. For a Boolean, this would be TRUE or FALSE. Node-Red message payloads can come in many forms. For more complex payloads, the payload is often a JSON object or JavaScript string. This message structure is important when trying to do message customization.

Each Node-Red message is a JavaScript "msg" object. Within various nodes, you'll frequently see "msg.payload" being referenced and/or altered. This should make some sense intuitively. The important contents of the PLC tag will live exclusively in the "payload" key of the "msg" object. Most data-processing logic will, then, deal exclusively with the message payload. So why do we need this "topic" element? Message topics can be very useful in data filtering contexts, and I will give you a simple example of such contexts in the following section.

Data Filtering: Switch Node

Now, we can finally get into some basic Node-Red logic.

The most basic level of data processing is filtering. In the first rung, I'm injecting the integer 3 to initiate my flow. The yellow node you see is a "switch" node. The switch node allows you to filter data based on conditions. In this case, I'm only allowing the payload to continue through the switch node if its value exceeds 1000. Clearly, 3 would not meet the condition and thus the debug node would output nothing to the debug window. 

The above image shows the configuration of the switch node. Note how I'm checking the property of "msg.payload" against the condition ">= 1000" — the second and third rungs of the data filtering logic add in an element of message topic filtering. In those examples, I only want data with topic "RPM" to pass. As such, I have added a switch node in series that is configured to check if "msg.topic" equals "RPM".

Payload Configuration: Change Node

While data filtering is the most fundamental data processing function, outputting a naked "TRUE" or "1032" to your database is not usually ideal. Typically, you want to take your PLC data and either combine it with other tags or transform it into a more human-friendly form. For example, instead of a contextless payload of "74," I might instead prefer the payload to say: "Room Temp (F): 74." The "change" node helps you do just that. 

In this flow logic, we have some Boolean input giving us a "TRUE" or "FALSE". We use a switch node to route the flow according to the payload value. If the value is "TRUE," we send the message through the first output. Otherwise, route the message to the second output. The change node looks very similar to the switch node, but its function is very unique. As the name implies, we are usually changing the payload itself.

The change node here is configured to change the value of the payload "TRUE" to the string "The motor is on". While this example shows a simple functionality, the change node is extremely powerful. This node enables you to save payloads to Node-Red memory, construct payload objects, and much more. I will provide an example of saving to Node-Red memory later on in this blog.

In Practice: S7-In Node & MQTT-Out Node

The inject and debug nodes are useful for troubleshooting, but they do not have any use during actual operation. In practice, we need to use a PLC tag-importing node and some network-out node. In this example, I've used the Siemens S7-In node and the MQTT-Out node. These are the entry and exit points of Node-Red. Raw PLC data comes in through the S7-In node, and processed payloads are sent out through the MQTT-Out node.

Instead of an inject node in the previous examples, you would use the corresponding PLC-In node for your system. The configuration of this PLC-In node is simple: fill in the IP-address of the PLC in the "Connection" tab and the PLC tag address(es) in the "Variables" tab.

When addressing PLC tags, you should reference this Node-Red documentation. You can configure this node to inject the PLC tag every so often or only when the tag changes value.

Additionally, you can configure the node to inject every configured PLC tag or one specific tag. Here, I've configured it to only inject the "bDMC" tag that sits in a PLC data block. It is worth noting that for a Siemens PLC, Node-Red can only pull tags from an unoptimized data block. 

The pink node on the right is the MQTT-Out node. Notice how it's wired in parallel to the debug node. This way, whatever is sent through the MQTT-Out node will also show up in the debug window. Each network protocol node is slightly different, so I won't dive into the MQTT node specifically. You shouldn't run into anything out of the ordinary when configuring these nodes.

Storing Data in Node-Red Memory

The last thing I want to touch on is the data storing functionality of Node-Red. Without the use of Node-Red's internal memory, the extent to which you could customize your payloads would be severely diminished.

Consider the following example: I have PLC tags that record the temperature and humidity of a certain room. I want to trigger a flow each time my temperature exceeds a certain threshold. Following the ideas so far, we could easily write a flow that sends the temperature payload to some online database, but what if I wanted the humidity to be sent along with the temperature data? Here, we would need to use Node Red's capability to store data into flow memory.

This is a basic flow that pulls in every configured PLC tag and stores it in "flow" memory. Node-Red has a "flow" and "global" object in which you can store your tags. These tags are persistent across executions of the program.

As the names imply, you can only access data saved within the "flow" object while inside your flow. Data saved within the "global" object can be accessed across all flows. Remember that "flows" are similar to pages in an Excel sheet. In this example, I'm storing every PLC tag within a "myData" object. This object is nested within the "flow" memory. To call the saved tags, I simply address them by appending their topic (whatever you named them) to the flow.myData address.

This is the configuration of the change node used to store data. Note the "flow." prefix is selected from the dropdown menu. It is defaulted to "msg.".

Now that you know how to filter data, configure payloads, and store data in Node-Red, you possess the fundamentals for any PLC data-processing needs. 

Learn more about our Industrial IoT Solutions expertise and contact us for your next project!

The post An Introduction to Node-Red: Processing and Sending PLC Data to the Cloud appeared first on DMC, Inc..

In this tutorial, I will show you how to programmatically create and save a global virtual channel in LabVIEW. I will tie it all together by generating the same signals from an IO sheet in Excel.

Background

I wanted to reuse a library DMC developed that controls relays and reads their feedback. I preferred not to modify this library because we were referencing the repo in another DMC project; modifying the library would change it for another team’s project. The inputs to this library were global virtual channels connecting to the control and feedback of each relay. I could have manually created global channels for our 100+ relays, but instead, I let LabVIEW do all the work.

NI Max Setup

In this example, I added a simulated cDAQ to NI Max. I also added two NI 9403 DIO module and gave it the names below:

The Code

The below code is what we will use to create 6 global virtual channels. This code will iterate between a relay control (Digital Control) and relay feedback (Digital Feedback).

First, I do modulo two to iterate between the control and feedback enum I made. I then use “format into string” to create the name of the channel. 

To prevent errors, clear the task name. I also like to delete the task in case it exists. If the task doesn’t exist, an error will be thrown, so make sure to clear errors coming out of that VI.

• Factoid: You can feed a string into a task name and it will typecast automatically for you.

Create the task by feeding the task coming out of the previous VI into the “New Task Name” input of “DAQmx Create Task”. 

• Factoid: You can feed a task into a string input as well*, and it will be typecast automatically.

Create the hardware line you want to connect the channel to. I do this by using format string again. Make sure to use the name of the module you have in NI Max.

• Factoid: If you want a list of all available channels, you can drop a “DAQmx Physical Channel” onto the block diagram and browse for available lines.

Create the DAQmx virtual channel. I use a Digital Output for the controls and Digital Input for feedback.

Save the global channel using "DAQmx Save Global Channel.vi".

Below, are the channels that were created in NI Max.

Reading From an IO Sheet

Now that you can programmatically create global virtual channels, you can take it a step further and create channels from information contained in an IO sheet like the one below.

You can read this information by using “Read Delimited Spreadsheet.vi” and removing the top row of headers. After that, feed the inputs into the code from before, like so.

And viola! Four new global virtual channels have been made from your spreadsheet.

Deleting Channels

You can delete the channels programmatically just as easy as you made them by using “DAQmx Delete Saved Global Channels.vi”. 

Why is this useful?

This is useful because you don’t have to manually type in global virtual channels to NI Max. This prevents fat fingering a wrong IO channel. This will also save you time depending on how many channels you have. It also prevents errors from happening by pulling straight from the IO list. When collaborating with coworkers on an IO list, you don’t have to worry about someone else making a change in the list that doesn’t get propagated into the code. The code will pick up on it!

Another benefit of note is you can decrease the amount of fluff in an NI Max file. All you will need in your NI Max file are the hardware and module names. If a coworker needs to add a channel, they can add it to the IO sheet, and it will automatically be imported into your code when you pull their code. No more pushing and pulling the NI Max file nor importing and exporting channels causing less committing and merging of NI Max channels between developers.

Learn more about DMC’s LabVIEW Programming and contact us today for your next project!

The post How to Programmatically Generate Global Virtual Channels with LabVIEW appeared first on DMC, Inc..

When dealing with several or millions of IoT devices the amount of data can quickly become overwhelming to your processing logic and storage solution. To begin reducing the complexity of dealing with the data, it’s helpful to group the data into one of two main categories: hot or cold. That is to say: does the data need to be analyzed immediately (hot), or can we look at the data at our own convenience (cold).

After the data is ingested and initial processing is complete, it needs to be stored. Is the data similar enough that it can be logged in a database (structured), or does it vary widely and needs more flexible data storage (unstructured). Also, how much data are you expecting to collect: petabytes, or megabytes? Who needs access to the data for analysis, and what if they’re located on the other side of the world? The delays in processing gigabytes of data while dealing with the latency of traversing the globe can quickly become frustrating.

These are all things that need to be thought through before you begin development. Hopefully, this helps provide some assistance with planning your IoT solution. If you have any additional questions or need help with your IoT solution, send us an email.

Data Processing

When your IoT nodes start producing data the server(s) need to be ready to handle that data as efficiently as possible, which means you need to determine if data is ‘hot’ or ‘cold’.

Hot Data

An example of ‘hot’ data might be motor speed. Perhaps the motor can run up to 110% of its nominal speed for up to 5 seconds without issue, but if it exceeds 115% for more than 5 seconds it needs to be disassembled and internal parts replaced. The motor speed information needs to be analyzed and acted upon quickly to avoid downtime and costly repairs.

Cold Data

‘Cold’ data, on the other hand, might be information like the volume of liquid pumped by the motor over the last 5 minutes. Knowing the exact flow at every given moment might not provide any valuable insights, so cold data can be batched and processed when reasonable.

To complicate matters more, hot and cold data is more of a sliding scale, with common nomenclature of ‘hot’, ‘warm’, ‘cool’, and ‘cold’. Data may not fall into a single category. Using the motor speed example from above; the motor speed may also need to be processed as cool or cold data because analysis has shown that motor speed tends to increase marginally day over day before motor failure. So, not only is the real-time data important but saving the data for later to identify trends may also be important. This dual processing path is quite common.

Structured vs Unstructured

Will all the IoT nodes produce data with the same type of structure or parameters; or is each node unique and there’s little to no overlap of the data structure between nodes?

Blob Storage

To log unique (unstructured) data, Azure Storage Blob is likely your best option. It’s not as unmanageable as ‘blob’ makes it sound, that’s just referring to the fact that it’s meant to hold different types and models of data from videos and text, to pictures and audio recordings. Blob storage is pretty analogous to what you’re used to with your desktop or laptop computer with having different folders that contain other folders or files with lots of different file types. It’s the default storage option when creating a storage account.

Blob storage can be broken down into 3 types: Append, Page, Block.

• Append: Data can only be appended to the blob. Think a log file, new log entries are appended to the end and the blob continues to grow.
• Page: Good for data that needs frequent read/write access with high performance and low latency. General-purpose storage.
• Block: Block type storage is optimized for large data sets and provides parallel read/write to different blocks. It's for handling large (Gb’s) files over the network.

Page and Block type Blob storage can handle up to Terabytes of data, but there comes a point where an organization of ‘Big Data’ starts to become a limiting factor. Your data is worthless if you can’t efficiently query it. That’s when you need to consider a solution like Azure Data Lake. Data Lake provides additional organizational and security tools, as well as some built-in analytics.

CosmosDB

If the data is in a more consistent format, you may want to consider CosmosDB as the storage solution instead of blob storage. CosmosDB provides several features that may be beneficial for your organization and your data. Similar to SQL databases, CosmosDB provides the option to specify indexes on the data which can significantly improve query performance.

Also, CosmosDB was built with data sharing and replication in mind. A CosmosDB database can be configured to replicate data to multiple Azure regions around the globe giving employees in both North America and Australia, for example, access to the same data at the same time. It’s also possible for both regions to write data back into Cosmos at the same time. This is all in addition to a failover location which can be configured to take over operations in the event of a natural disaster or civil disturbance in the primary location.

Learn more about DMC's IoT solutions and Azure solutions. Contact us for more information. 

The post Azure IoT Hub Data Processing and Storage appeared first on DMC, Inc..

DMC is proud to announce that we have joined the MindSphere Partner Program, Siemens’ partner program for Industrial IoT solution and technology providers.

“I’m excited to continue DMC’s history of partnering with Siemens by joining the MindSphere partner community,” said DMC President and CEO, Frank Riordan “With over two decades of experience in factory automation, we are well-positioned to provide industry-leading IIoT solutions to our clients.”

About MindSphere

MindSphere®, the cloud-based, open IoT operating system from Siemens, connects products, plants, systems, and machines, enabling businesses to harness the wealth of data generated by the Internet of Things (IoT) with advanced analytics.

MindSphere Partnership

DMC recently completed a successful MindSphere project for a manufacturer that had no network connectivity. We were one of first integrators to use WinCC OA Connector to pull data from hundreds of standalone OEM machines and push it to MindSphere. DMC developed a comprehensive data aggregation system that provides valuable insight into operational data, highlighting inefficiencies and improving factory effectiveness.

As a MindSphere Gold Partner, DMC has technical staff trained by Siemens through the MindSphere technical curriculum, multiple MindSphere applications developed or being developed, and a joint go-to-market agreement to assist our customers in achieving substantial business value through IoT technology generally and MindSphere specifically.

Our partnership with Siemens demonstrates DMC’s continued commitment to providing industry-leading solutions for industrial manufacturing. As a result of the partnership, we will be able to augment our current IoT offerings with MindSphere and pass on the benefit of the latest in training and technology to our clients.

“Siemens welcomes DMC to the MindSphere ecosystem as it extends its long-standing partnership with Siemens,” said Rohit Khera, Global Vice President Strategic Alliances, Siemens Digital Industries Software.  “DMC’s deep industry expertise and its focus on providing IIoT solutions that pull and process data from systems with low connectivity, high complexity, and diverse platforms can provide our joint customers with great value in their digital transformation initiatives.”

DMC and Siemens

DMC has comprehensive experience with a wide range of Siemens technologies and hundreds of successful project implementations for customers around the world. Our expertise includes recognition as a MindSphere partner, a SIMATIC IT Partner, a member of the Siemens MEAC (MOM Expertise Alliance Center) Alliance Partner Network, Siemens Solution Partner certifications in WinCC SCADA, Industrial Communications, and Advanced Factory Automation, and having a very large number of Siemens S7 certified engineers in North America.

About DMC

DMC is a project-based engineering and software development firm focused on software development and control systems. We develop and implement solutions for a wide range of industries using a variety of technologies and platforms. Since 1996, DMC has succeeded in helping hundreds of clients increase efficiency and productivity by delivering world-class solutions throughout the globe.

###

Contact
Jessica Mlinaric
jessica.mlinaric@localhost
312.255.8757

The post DMC Joins Siemens’ MindSphere Partner Program as a Gold Partner appeared first on DMC, Inc..

About the Webinar

The IIoT Ready PLC- Your Journey From the Edge to the Cloud
DMC has been helping many clients make IIoT a reality for their business. Join us for an informational session on the IIoT of today, exploring platform options, PLC capabilities, and next steps toward bringing your cloud-connected applications to life.

Registration

There are two opportunities to attend the IIoT webinar:

Friday, May 8
2 – 3 p.m. CT
Register here

Wednesday, May 13
2 – 3 p.m. CT
Register here

Learn more about DMC’s IIoT expertise. 

The post DMC to Host IIoT Webinar appeared first on DMC, Inc..