Digital Transformation is the new game in town for many industries. The concept comes in many shapes and forms for the target industry/consumer where the essential goal is to improve efficiency, value, or innovation by adoption of digital technology.
At Solulever, an Industry 4.0 based Dutch Software Startup, we have built a unique platform for the effective transformation of manufacturing operations. The platform is built to make the Digitization of Manufacturing operations simple, fast, affordable and fun.
Some of the concerns around the alternative approaches that the platform solves are:
Product Fitment
Every provider starts with its own interpretation of the problem, then solves it using its own opinion of what the correct solution should be. However, based on customers’ feedback, the provider generalizes that solution, starting by being configuration oriented, and later evolving it into another product with customized interface. A good example is Amazon, which started as a bookstore and later generalized to e-commerce and then evolved to customized category management.
However, to implement on scale, with more generalization or abstraction in each iteration, biases introduced due to opinions of product management and engineering teams can lead to predetermining product behavior on behalf of the customer. Such predeterminations can lead to gaps between the behavior of the solution expected by the customer and the actual behavior of the solution offered by the provider.
Technical Fitment –
Most IoT stacks are opinionated by the needs of the company building the IoT stack. For example, Cloud Hyperscalers are quite heavy on the cloud compute, and they assume that the end device will be very low in compute, memory etc. This opinion strongly correlates with the devices they provide in the B2C or B2B space. However, in cases where the edge devices are powerful or in situations where connectivity itself is not given, a cloud centric approach can be a misfit. Instead, a powerful edge with capability to compute, should be utilized for analytics, advanced workloads such as machine learning, and training models.
Also, it is worth noting that while these providers are experimenting with edge based analytical innovations for their own products & devices, these providers are not amenable to exposing these capabilities fully to communities for open integration. A non-committal approach towards Open-Integrations by these providers amplifies this problem even further, where even credible System Integrators struggle to use the offerings of these providers.
Total Cost of Ownership
Most cloud models are very cost friendly towards ingress, but charge a lot more towards egress, which means that while it is very easy to get your data in, it is much harder to get it out. Similarly, design of such managed databases (particularly timeseries databases), is oriented towards charging the users on both the data kept in the table, as well as on the data scanned in each query and/ or query processing time. While this model gives very benign costs initially, it leads to an explosion of cost, with gradual but considerable scale-up of the costs involved, not just over number of devices but also over time. This leads to solutions being deemed not worthy of the cost they’re incurring and hence getting ditched.
To solve the above pain points, we identified the need for a platform like Brabo Edge Platform®.
We started by working on the following:
Platform Thinking
Instead of just thinking about a particular use case, we started by acknowledging the vast technology landscape involved. We wanted to build a platform that not only supports cloud but also on-premises deployments. In essence, a platform capable of consuming multiple data sources from Informational Technology and Operational Technology landscape was identified.
Also, a device framework service formed an essential ingredient to support device provisioning and device management across multiple protocols like OPC-UA, Modbus, Ethernet/IP etc. And of course, state-of-the-art analytics and dashboarding capabilities were a must-have too. We also architected for Cost Efficiency, Open-Integration philosophy, High Availability, Load-based scaling, state-of-the-art security implementation etc.
Finally, we wanted to include an option for our customers to procure an Optimized Engineered Appliance and hence avoid the hassles of fine-tuning the hardware for performance on their own. To achieve this tall order, we started by focusing on the right architecture and technology stack.
Focus on the Right Technology
We started by defining key technical components. On Infrastructure, since we had multiple deployment scenarios and an extensive breadth in technologies used, containers were essential. We use microservices written in Java, Python, JS etc. We use Kubernetes to manage our deployments both in cloud, as well as on our own Edge appliances, while gateways run Docker based services. We used Linux everywhere as much as possible, but wherever needed, our microservices were nimble enough to allow us to use Windows as well for supporting legacy integrations. We also provide a restricted sandbox for our customers, where they can deploy their services and can interact with our microservices as well.
Next, we focused on data pipeline using Kafka, which acts as a message queue & broker for our services, while also providing a wide ecosystem of allied solutions. This further helps in the development of our data processing services and analytical engine, and we also allow our customers to connect and consume Kafka topics, thus truly being on an Open Architecture. We also switched to gRPC, which though seems to be a highly opinionated move initially, but is a well suited one, as it enables bi-directional streaming APIs, along with the ability to generate client code.
While code generation is possible on REST using technologies like OpenAPI, bi-directional streaming support with fast serialization is a game changer, which is not efficiently possible in REST.
For timeseries and relational data, we use TimescaleDB, which allows us to use SQL everywhere, enabling superior performance and supporting scale of a million data points per second. TimescaleDB provides great support for continuous aggregation, data compression, data retention policies, and even hybrid data storage. We also use multi-node deployments in extremely high throughput scenarios to achieve the desired performance. We use Redis and MongoDB in various use cases as well.
Cost Efficiency
We have a multi-pronged cost rationalization approach. Not only do we use leverage the relevant Open-Source developments to reduce our costs, but we also make use of containers and Kubernetes, to increase our compute density and achieve high utilization of resources.
Further, we prefer commodity hardware servers, designing reliability into the services and software rather than the hardware, thus reducing our cost footprint on the hardware. Finally, our open data platform ideology allows us to reuse data between services using Kafka and gRPC, and we prefer stream processing over batch processing to reduce peak utilization and hardware requirement ceiling further.
Additionally, TimescaleDB allows us to compress data more than 20X in our real-world observations while improving the performance at the same time.
Conclusion
By learning from the shortcomings of other platforms and adopting the best possible technical solutions currently possible, we’ve built a platform that is capable of successful digital manufacturing operations transformation delivery at a substantially low cost. In future, we’d like to discuss further in depth how Brabo handles OT-IT Data integrations and mashups, & what technical challenges we’ve overcome to realize this platform. Stay tuned!
