At the same time, many organizations are expanding initiatives like predictive maintenance and real-time quality monitoring, which depend on reliable connectivity between industrial devices and the cloud.

This level of connectivity is a point where things can get complicated.

Unlike consumer IoT, industrial systems weren’t always designed to be connected to the cloud. Devices speak a wide range of protocols, networks can be slow or unstable, and shutting down operations to make fixes can be expensive. Connection to the cloud becomes an exercise in translation, normalization, and careful system design.

This blog focuses on one of the key components of that process: driver development.

Understanding Industrial IoT Connectivity

Historically, data produced by industrial equipment during manufacturing processes stayed local, stored on PLCs, SCADA systems, or proprietary vendor interfaces. This local storage provides a hurdle to implementing modern strategies for predictive maintenance, real-time quality monitoring, or the use of digital twins. There’s now a strong need to move machine data out of isolated systems and into centralized platforms where it can be analyzed and used to inform decisions or actions.

Centralizing data requires thinking about connectivity beyond simply networking machines together. To have an accessible, centralized system, one must ensure that each device can reliably and securely communicate with systems outside a traditional OT network.

Connectivity Challenges: From Plant Floor to the Cloud

On the plant floor, machines often communicate using standards like Modbus, OPC UA, or BACnet. These are well-suited for communicating with local devices but require translation when mapping onto cloud-native systems that rely on protocols like MQTT, HTTPS, or AMQP.

Take a legacy Modbus device, for example. It might provide a set of registers containing raw integer values. One number could represent motor speed; another might indicate tank level. But on their own, those values are just numbers; they don’t explain what they represent. A value of 4231 might mean 42.31°C, 423.1 psi, or something entirely different depending on scaling and encoding.

Cloud systems, on the other hand, are typically designed to expect structured, self-describing data. Timestamps, units, and data types may all be expected to come alongside the value for a datapoint.

This means there are two challenges to hooking industrial systems into cloud architectures. The first is extracting reliable data from industrial equipment by leveraging tools like serial connections, legacy backplanes, or proprietary APIs. The second is transforming that data into something the cloud can understand. Drivers act as a middle layer in the system to address these challenges.

Cloud-Focused Considerations in Industrial Connectivity

Once data is collected on the factory floor, the next step is sending it to the cloud safely, reliably, and with the ability to scale over time.

This adds a new layer of complexity at the edge. Practitioners now have to keep in mind things like communication, managing network interruptions, and efficiently moving large amounts of data without slowdowns. What previously worked for local devices and machines won’t always work when cloud platforms are involved.

From an edge perspective, this introduces a new set of design considerations.

Protocol Compatibility

Cloud systems typically rely on internet-friendly protocols. MQTT is often the default choice due to its publish/subscribe model and its efficiency, but HTTPS and AMQP are also common depending on the platform.

Drivers or gateways must translate industrial protocols into one of these formats, often while enriching and compressing the data.

Data Modeling and Normalization

Cloud platforms expect data to be consistent across devices and sites. That means:

• Clearly defined data types
• Standardized units
• Consistent naming conventions
• Structured metadata

Without normalization, every device can become a custom integration problem.

Security Requirements

Unlike a local OT network, cloud connectivity requires strong security controls:

• TLS encryption for all data in transit
• Certificate-based authentication for devices
• Managed identity and access control

In many cases, the gateway handles these responsibilities, but it’s essential that the driver integrates cleanly with that security model.

Reliability and Offline Operation

Industrial environments don’t always have the best connectivity. Networks fail, systems can be routinely interrupted for maintenance, and some locations have limited bandwidth.

Drivers and gateways need to buffer data locally, retry transmissions intelligently, and ensure that important data isn’t lost.

Edge Processing

Not all data needs to be sent to the cloud.

In many cases, it’s more efficient to process data at the edge by:

• Filtering noise
• Aggregating high-frequency signals
• Detecting simple events

This reduces bandwidth usage and keeps cloud systems focused on higher-value analysis.

Core Concepts in Building Industrial IoT Drivers

Developing a driver requires understanding both how devices represent data and how that data will ultimately be used.

Understanding Device Data Structures

Industrial devices commonly expose data through:

• Registers (e.g., Modbus)
• Tags or variables (PLCs)
• Objects (BACnet, OPC UA)
• Vendor-specific memory maps

Interpreting these correctly is critical. A single value can represent very different things depending on scaling, encoding, and byte order.

Drivers must apply the correct transformations to ensure accuracy.

Timing and Polling

Devices often expect communication at specific intervals. Poll too quickly and you risk overloading the device or network. Poll too slowly and you may miss important changes.

Drivers need to balance these constraints while also considering how frequently data should be sent to the cloud.

Event-Driven vs. Polled Data

Some systems support event-driven communication (such as OPC UA subscriptions), while others rely entirely on polling.

Supporting both approaches allows for more efficient and scalable designs.

Essential Components of an IoT Driver

A production-ready driver includes several key components beyond basic protocol handling:

Protocol Parsing: The process that translates raw bytes into structured values. It includes handling message formats, checksums, and protocol-specific logic.

Transport Layer Handling: Drivers often interact with multiple transport layers such as serial communication (RS-232, RS-485), TCP/UDP networking, and fieldbus interfaces. These layers must be resilient to noise, dropped packets, and physical issues.

Configuration Models: Scalability depends on structured configuration. Drivers typically support:

• External configuration files
• Dynamic updates via APIs
• Metadata definitions for signals

This avoids hardcoding logic for each deployment.

Error Handling and Recovery: Reliable operation requires robust handling of timeouts, invalid responses, and disconnections. Drivers should automatically retry and recover without manual intervention.

Logging and Diagnostics: Remote troubleshooting depends on visibility. Drivers should expose logs, communication traces, and status information that can be accessed remotely.

Best Practices for Cloud-Focused Driver Development

Several patterns consistently improve reliability and maintainability.

Use Abstraction Layers: Separating protocol logic from device-specific mappings makes drivers more reusable and easier to extend.

Support Simulation and Testing: Simulated devices allow for faster development and safer testing, especially when physical hardware is limited.

Control Data Volume: Sending too much data is a common mistake. Drivers should support filtering, aggregation, and event-based reporting.

Prioritize Security: Drivers should align with secure communication practices and integrate with certificate-based authentication and encrypted transport layers.

Choosing the Right Connectivity Approach

There is no one-size-fits-all architecture for industrial IoT. The right approach depends on a mix of technical and operational factors.

Data volume, update frequency, and real-time requirements all influence how much processing should happen at the edge versus the cloud.

Network reliability plays a major role—especially in environments where connectivity is intermittent.

Security requirements can further shape architecture, particularly in regulated industries.

When it comes to implementation, most teams choose between building custom solutions, buying commercial products, or combining both. Custom development offers flexibility but requires ongoing maintenance. Many commercial tools enable faster deployment but come with limited customization options. In practice, many organizations take a hybrid approach, using standard tools wherever possible and customization where necessary.

The key is to start with a reliable foundation and evolve the architecture as requirements become clearer.

Conclusion

Connecting industrial devices to the cloud is not a single step—it’s a layered process that starts with reliable data extraction and ends with meaningful insights.

Drivers play a very central role. They translate raw machine data into structured, usable information and ensure it can move reliably between systems that were never designed to work together.

By combining well-designed drivers, thoughtful edge architectures, and scalable cloud platforms, it becomes possible to unlock the full value of industrial data.

As technologies continue to evolve—through digital twins, edge computing, and next-generation networking—the importance of this foundation will only grow.

The post How Drivers Enable Industrial Cloud Connectivity appeared first on DMC, Inc..

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..

Integrating SharePoint into Ignition can reduce friction between organizational teams without compromising system reliability. The core draw is bringing enterprise information closer to operations and reducing manual work like exporting reports, emailing files, hunting for the latest SOP, or duplicating data across systems.

In some organizations, SharePoint may already be the system of record. As part of the Microsoft suite of tools, it is depended on for document management and collaboration. In this case, integrating SharePoint into Ignition can expand system capabilities to leverage the strengths of each tool and reduce separation or duplication between operation/production and other teams.

Other organizations may be looking to move away from paper-driven or manual processes. In these cases, the combination of Ignition and SharePoint can allow the concerns of both manual production or record keeping and old-fashioned document storage and sharing to be addressed in a way that sets teams up for lower overhead.

What Ignition and SharePoint Each Do Best

As a SCADA platform, Ignition excels at real-time and near-real-time operations. It connects to control system components, surfacing information to users in a way that is conducive to effective and efficient decision-making during operation. Additionally, it’s built around SQL database connectivity rather than proprietary data storage formats. It natively integrates with databases such as PostgreSQL, Microsoft SQL Server, and MySQL, enabling robust historical data logging, reporting, and analytics. This makes it well-suited for data-driven applications and integration with other data analytics tools. Ignition also supports Python scripting throughout the platform, allowing engineers and developers to build custom logic, automation routines, and integrations. Its API-driven design and flexible UI development tools enable deep customization, making it adaptable.

SharePoint, on the other hand, is designed for document handling and collaboration. At its core, SharePoint provides a centralized and structured environment for storing, organizing, and managing digital content across an organization. Unlike traditional file servers, it layers document management capabilities such as version control, metadata, and permissions directly onto cloud-based storage, making information both more accessible and more governable. Its built-in search engine further strengthens this by allowing users to retrieve relevant documents and data across sites, libraries, and even connected Microsoft 365 services. Procedures, manuals, reports, and audit artifacts all fit naturally into SharePoint’s structure and methodology. Beyond document storage, SharePoint serves as a flexible platform for building internal portals and collaborative workspaces, with sites acting as hubs for departments or projects and Power Automate integration providing options for automating workflows like approvals, document routing, and notifications.

The value in integration between these two systems comes from exposing information between them, while allowing each to preside over the scope of work it was designed for. When humans are in the loop doing document management, approvals, or reviewing reports, integrating SharePoint into Ignition provides benefits in terms of transparency between teams and the reduction of duplicated data.

Common Integration Use Cases

Publishing Reports

One common pattern for integration is publishing content out of Ignition. Scheduled reports, batch summaries, or downtime logs can be automatically uploaded to a SharePoint document library where supervisors and engineers already expect to find them.

From a technical standpoint, this typically involves formatting data into a document and then using Ignition’s scripting capabilities and SharePoint’s APIs (such as Microsoft Graph or SharePoint REST endpoints) to programmatically upload the files to the appropriate SharePoint site, folder, or document library. Metadata — such as production line, batch ID, timestamp, shift, or product type — can be attached to each file on upload, making the content easier to search, filter, and organize.

This allows other organizational teams or team members – such as engineers or managers – to access the latest production summaries, downtime logs, or performance reports directly from SharePoint, alongside other operational and business documents. This creates a more unified information flow between OT (operational technology) and IT systems, which reduces separation or duplication between plant-floor data and enterprise documentation.

Additionally, storing Ignition-generated content in SharePoint enables downstream workflows. For example, the arrival of a new batch summary could automatically trigger a review or approval process via Power Automate, notify stakeholders in Microsoft Teams, or be archived according to corporate retention policies. Over time, this turns SharePoint into not just a storage location, but an active collaboration and governance layer for industrial data.

Document Display in Ignition

Another high-value use case for integrating SharePoint with Ignition is using SharePoint as the authoritative source of documentation and then surfacing that information directly within Ignition’s operator interface. In many facilities, critical operational information — such as standard operating procedures (SOPs), wiring diagrams, and manuals — requires formal version control, approvals, and periodic reviews, making SharePoint a natural system of record. However, operators and technicians typically spend most of their time inside Ignition HMIs rather than browsing SharePoint sites. If they must leave the HMI to search for documents, it can cause frustration and increase the likelihood that outdated or unofficial copies will be used.

Through integration, Ignition screens can dynamically link to or embed documents that reside in SharePoint. Technically, this can be accomplished by storing document URLs or metadata in Ignition and using web views or API calls to retrieve the correct file from SharePoint in real time. The system can also be designed to filter documents, so users see only the most relevant information. For example, when an operator selects a specific piece of equipment in Ignition, the screen could automatically display the latest approved maintenance checklist associated with that asset.

Because the documents remain managed in SharePoint, this approach preserves strong governance without sacrificing usability. SharePoint’s built-in versioning ensures that only the most current, approved documents are presented, while historical versions remain available for auditing or reference. Approval workflows, document review cycles, and change tracking can all continue to operate in SharePoint, independent of Ignition. From the operator’s perspective, however, they simply see the right document in the right place at the right time, embedded seamlessly within their normal workflow.

This integration also improves consistency and reduces risk. Instead of multiple copies of procedures floating around on local drives or printed binders, there is a single, controlled source of truth in SharePoint that is directly connected to the HMI. If a procedure is updated due to a safety change or process improvement, the new version becomes instantly available to all operators through Ignition without requiring manual redistribution.

Exception Log Tracking

Some teams leverage SharePoint lists as a lightweight mechanism to capture operational information that is important from a business, quality, or compliance perspective but not critical to real-time control. Instead of pushing everything into an industrial database or embedding every data-capture requirement directly into Ignition, teams use SharePoint as a parallel system for structured tracking of contextual or administrative records that surround plant activity.

In practice, this often includes exception logs, operator notes, minor deviations, near-miss reports, shift comments, maintenance observations, or non-critical audit records. These are pieces of information that benefit from being organized, searchable, and reviewable across departments, but do not require the speed, determinism, or reliability guarantees of a control system database. SharePoint lists are well-suited for this because they allow teams to define custom fields, validation rules, and views without requiring a dedicated application.

Integration with Ignition in this scenario usually takes the form of one-way or loosely coupled data exchange. For example, Ignition might provide an operator interface that allows users to submit an exception entry or add contextual notes about a process event. Behind the scenes, Ignition scripts or API calls then create or update corresponding entries in a SharePoint list via Microsoft Graph or SharePoint’s REST endpoints. Alternatively, Ignition could automatically log certain classes of events — such as repeated minor alarms or operator overrides — into SharePoint for later review by supervisors or quality teams.

The critical design principle in this pattern is that SharePoint remains outside of the control loop. Ignition continues to handle all real-time monitoring, interlocking, alarming, and automation logic, while SharePoint serves as a complementary system with improved visibility for team collaboration. Operations teams retain a responsive, high-performance control environment in Ignition, while IT and quality teams gain structured, shareable records in SharePoint that can be integrated with broader business processes. Over time, this creates a balanced ecosystem where industrial data and human-centered documentation coexist without overloading the control system with non-operational responsibilities.

Integration Approaches and Architecture

Most SharePoint integrations with Ignition are built around API access using either the SharePoint REST API or Microsoft Graph API, which are invoked directly from Ignition scripting. SharePoint’s APIs expose a robust integration surface that allows external systems to programmatically interact with SharePoint as a structured content and data platform. Through standard web-based endpoints, external applications can create, read, update, and delete sites, document libraries, files, and list items, and manage metadata, permissions, and versioning. All interactions are secured through Entra ID authentication and role-based access controls, ensuring that integrations follow the same security policies as human users.

Within Ignition, this connectivity is implemented through its Python-based scripting environment, which can issue HTTP requests to these APIs. Using built-in networking functions or third-party libraries, Ignition scripts can transmit data and handle responses in real time. This enables Ignition to reliably read from and write to SharePoint while staying tightly aligned with Ignition events, tags, and transaction logic.

Generally, a middleware layer that handles authentication and API complexity is also required. This can take the form of a simple web service, server-less compute function, or gateway-hosted service and helps to manage authentication tokens and segregate concerns. As an example, this might take the form of a Python application that runs on the ignition gateway, with the following flow:

Integration Considerations

Governance and Ownership

As is common when tools are bridging the gaps between organizational teams, it is worthwhile to consider who is responsible for maintaining each part of the solution long-term. In the case of this integration, it is likely that the controls or operations team will own the Ignition side of the system, including screens, control logic, and scripts, while IT will own the SharePoint side, including permissions/authentication and structure. Defining the boundary and interface between these two sides to the integration explicitly can reduce friction and maintenance overhead down the line. Things to consider:

• Folder structures and naming conventions
• Retention and archiving rules
• The change management process

Authentication and Security

Ignition authenticates to SharePoint as an application (rather than receiving delegated permissions from a user log-in) using a dedicated service account. This requires setting up an app registration in Azure Entra ID, with the following basic steps:

1. Create a New App Registration in Entra ID via the Azure Portal
   • At this point, Entra ID creates the application identity with an Application (client) ID and Directory (tenant) ID. These values are important for later configuration.
2. Add a Certificate
   • You must prove the app’s identity when requesting tokens. Go to “Certificates & secrets” and upload a certificate; the thumbprint and private key for this certificate will later be used to authenticate.
3. Assign API Permissions (Scopes)
   • This defines what the app is allowed to do. Common examples include: Sites.ReadWrite.All (to create/update files and lists) or User.Read.All  (to read user profiles).
4. Grant Admin Consent
   • Most SharePoint/Graph permissions require tenant-wide approval. Without this, your app will not be able to access SharePoint in most enterprise tenants.
5. Use These Values in Your Integration
   • You will typically need the following to acquire access tokens from Entra ID:
     • Tenant ID
     • Client (Application) IDCertificate (thumbprint + private key)
     • Certificate (thumbprint + private key)
     • API Scopes (e.g., Graph’s User.Read or SharePoint’s Sites.ReadWrite.All)

In addition to setting up an app registration for Ignition, general security guidance, such as not hardcoding credentials and using the lowest permissions required are important for implementing the integration as securely as possible.

Expectations and Error Handling

Ensuring the usefulness of the integration depends on keeping expectations aligned with what each tool is good at and implementing robust error handling to account for connectivity issues. For instance, it is reasonable to expect SharePoint to handle files and metadata in a batched or event-driven way. SharePoint excels at handling files and list-formatted data, and API based access aligns well with low-frequency updates. However, it would not be reasonable to use SharePoint to store high-frequency operational data or to act as a data historian; it is not set up to handle streams of data, and it is not optimized for time-series information. Similarly, it is likely reasonable to expect that the normal operational state of the system would be Ignition and SharePoint communicating with relatively low response times, but likely not reasonable to assume perfect connectivity or 100% uptime.

To this end, it is valuable to implement handling to account for cases that would differ from the reasonable expectations for the system. This could include:

• Including timeouts to prevent calls from blocking indefinitely,
• Clear logging for failures,
• Retry logic; likely with limits on the total number of retries,
• Caching of queried data (like SOP’s or manuals) when practical

Considering these cases allows the overall system to continue functioning as smoothly as possible when something goes wrong, and forethought into failure handling allows for a simpler debugging process.

Building Your SharePoint and Ignition Integration

Integrating Ignition with SharePoint in a secure, scalable, and maintainable way is technically feasible for many organizations, but doing it well often requires a blend of OT, IT, and cloud expertise that rarely exists fully within a single team. For this reason, working with an experienced consulting partner like DMC can be highly valuable when undertaking this type of integration.

A knowledgeable partner brings deep, practical experience with both Ignition and the Microsoft ecosystem. This helps avoid common pitfalls around integration interfaces and authentication. Rather than learning through trial and error, organizations benefit from proven design patterns and best practices that have been refined across multiple projects and industries. DMC maintains Ignition Premier Integrator status and Microsoft Solutions Partner status and has extensive experience developing solutions in both Ignition and SharePoint. Additionally, DMC’s diverse experience across both manufacturing/OT and business-centric/IT projects enables us to facilitate conversations between organizational teams and stakeholders, ensuring the solution is designed in a way that works for all users. This cross-functional perspective is often just as important as the code itself.

Finally, working with a partner accelerates delivery. Instead of dedicating internal resources to building and troubleshooting unfamiliar components, teams can focus on their core responsibilities while the consultant handles the complexity of the integration. The result is a more robust solution delivered faster, with a clearer path for future enhancements.

The post Integrating SharePoint into Ignition: A Practical Guide 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..