David Dierickx on , updated
In the ever-evolving landscape of industrial data management, keeping systems up-to-date is crucial for maintaining optimal performance, security, and reliability. At Factry, we understand the challenges that come with managing data collection processes, especially in environments where stability and security are paramount.
That’s why I want to dive a little deeper into one of our latest features: remote updates for Factry Historian data collectors.
Maintaining the latest version of software ensures that you benefit from the newest features, performance improvements, and security patches. However, updating data collectors across various systems can be time-consuming and prone to human error, especially when machines are not centrally managed and require complex login procedures.
By enabling remote updates, we aim to:
While systems residing in the IT domain of a company can leverage a myriad of tools and technologies, the same can’t be said for OT (Operational Technology) systems. OT systems typically reside in the process layer or technical layer of the network, which are parts of the network architecture designed to be isolated from the broader IT infrastructure for security and stability reasons.
These layers are often segmented to protect critical operational processes from external threats and to ensure continuous operation even if other parts of the network encounter issues. As a result, these layers are typically not accessible through standard IT management tools, making them very hard to reach and manage.
This isolation means that performing updates, troubleshooting issues, or even monitoring these systems requires specialized approaches and often involves navigating through multiple layers of security, such as firewalls, air-gapped networks, and stringent access controls. The complexity and critical nature of the processes managed by OT systems further complicate their management, as any disruption could impact the entire production process.
Our policy on where to install a data collector is to install it as close to the data source as possible. This ensures that data is collected in a timely manner and lowers the change of data-loss significantly by reducing the number of possible points of failures. . Some production environments can consist of many different systems, each with their own data source. This can make remote updates and management very challenging, especially for companies operating distributed assets.
The decentralized management of these systems underscores the importance of a robust and reliable remote update system that facilitates operator action from a distance.
In order to provide remote updates, we first needed to ensure that we can get our new data collectors out there. That is where our automated CI pipeline comes in.
Every time we make a change to our data collector, whether it is a bug fix, a new feature or a security update, we push the changes to our git repository. This triggers our CI pipeline which builds the new data collector, runs all our tests and packages the data collector in a distributable format. This distributable is then signed and uploaded to our cloud storage.
We’ve foreseen 3 different channels for our data collectors: stable, preview and dev. The stable channel is for our production ready data collectors, the preview channel is for data collectors that are almost ready for production and ready for field testing and the dev channel is for data collectors that are still in development.
By default, all data collectors are pushed to the dev channel. This way, we can test the new data collectors before pushing them to the preview and stable channels.
As the Factry Historian server is the central point of contact for all data collectors, it is the Historian server that is responsible for checking for updates. The Historian server maintains a list of all data collectors, including their versions, status, operating system and other relevant information.
The Historian server can then query the Factry portal (read more about the portal in our Factry Historian v6.1 release blogpost for the latest version of the data collector. If a new version is available, the Historian server can download the new data collector and verify it for integrity and authenticity. If the new data collector is valid, the Historian server can then notify the administrator that an update is available.
Once the administrator approves the update, the Historian server provides the update package to the data collector. The data collector periodically checks if the Historian server has approved an update. If an update is available, the data collector downloads the update package from the Historian server.
The update package is then verified for integrity and authenticity before being applied to the data collector. Once the update is applied, the data collector can restart itself to complete the update process.
In some cases, the Historian server may not be able to reach the portal to check for updates. This can happen due to network issues, firewalls, bandwidth limitations, or security restrictions. To address this, we have implemented a fallback mechanism that allows administrators to manually upload update packages to the Historian server, while maintaining the signature checks to verify integrity and authenticity.
This ensures that updates can be applied even when the Historian server cannot connect to the Factry Portal.
In some rare cases, an update may introduce new issues or incompatibilities that were not present in the previous version. To address this, we have implemented a downgrade mechanism that allows administrators to roll back to a previous version of the data collector.
This ensures that systems can be restored to a stable state in case of issues with the latest update. The downgrade process is similar to the update process and requires manual approval from an administrator.
For security reasons, downgrades are only allowed to previous versions that have been digitally signed by Factry. To make a downgrade possible, the previous version of the data collector must be manually uploaded to the Historian server.
Security is a top priority for Factry. Our remote update mechanism includes several features to ensure that the update process is secure:
The introduction of remote updates for Factry Historian data collectors is a significant step forward in enhancing the security, performance, and manageability of industrial data collection processes. We believe this feature will greatly benefit our users by reducing manual workload, ensuring up-to-date security, and improving overall system reliability.
As always, we welcome your feedback and are committed to continuously improving our products to meet your needs. Feel free to reach out to us here.
As a Data Engineer at Factry, I often face the challenge of guiding industrial companies along their Overall Equipment Effectiveness (OEE) journey. These projects have provided me with some interesting experiences and valuable insights, and I’m eager to share what I’ve learned so far.
Being part of Factry’s Data Engineering team means we’re spending a lot of time providing customer support and fixing specific issues in our clients’ setup. We’ve noticed that we’re frequently being asked similar questions and spend quite a bit of time helping users fix similar errors. In this blogpost, we’ll be going over some common OPC-UA and time synchronization errors and how to fix them.
When information is trapped in isolated systems across the production floor, getting valuable insights is increasingly difficult, and integration becomes fragile. The result? Wasted time, missed opportunities, and inefficiencies that eat away at the bottom line. In this article, we’ll explore the real costs of data fragmentation and how Factry Historian can bring clarity and efficiency to your operations.
