By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.

Three approaches to Connect your Factory Systems

Looking to connect your factory systems efficiently? Discover three proven approaches—using databases, direct service calls, or message brokers. Learn which method suits your setup best and why a UNS might be the best choice.

Three approaches to Connect your Factory Systems

Inspired by Martin Kleppmann's - Designing Data-Intensive Applications book, we discuss the three primary architectural approaches to connecting factory systems: Dataflow Through Databases, Dataflow Through Service Calls, Dataflow Through Asynchronous Message Passing

Option 1: Dataflow Through Databases

In this model, all your factory systems write to and read from a central database—often something like a Historian. It's a straightforward setup where the database acts as the hub for all data storage and retrieval.

Pros:

  • Simplicity: Easy to implement and manage.

Cons:

  • No Real-Time Processing: It can’t handle real-time data streams effectively.

Option 2: Dataflow Through Service Calls

This approach involves direct communication between systems using synchronous calls (like RESTful APIs or RPCs). It allows immediate data exchange between services.

Pros:

  • Real-Time Interaction: Supports instant data sharing.
  • Ease of Connection: Easy to set up.

Cons:

  • Complexity: Can lead to a tangled web of connections, especially as the system grows.
  • Maintenance Issues: Harder to debug and maintain at scale.

Option 3: Dataflow Through Asynchronous Message Passing

Here, a message broker like Kafka or RabbitMQ is used to manage data flow. Systems send and receive data through the broker, allowing asynchronous communication.

Pros:

  • Real-Time Processing: Efficiently handles real-time data.
  • Decoupling: Systems work independently, making it easier to scale.
  • Flexibility: Adding or removing components is simpler.

Cons:

  • Added Complexity: Requires managing the message broker.
  • Risk of Failures: More components mean more potential failure points.

Trade-Offs to Consider

While message brokers offer great flexibility, there are trade-offs:

  • Complexity vs. Evolvability: More components mean more things to monitor and maintain, but they also make the system adaptable.
  • Failure Risk: More parts can lead to more possible failures, so solid monitoring is crucial.

Conclusion

Each approach has its strengths and weaknesses, but in my opinion, using a Unified Namespace is the best way forward for most factories. It provides the flexibility, scalability, and real-time capabilities that modern manufacturing systems need.

💡
If you are looking for the best MQTT broker for your IoT or IIoT project, check out this blog article.

Read next

Can Unified Namespace replace your MES?
·

Can Unified Namespace replace your MES?

The MES has been THE place to integrate data on the shop floor for many years, and the UNS challenges this MES-centric approach and pushes it from infrastructure into the application category. Watch this video to know about Alex view.

Share, Engage, and Contribute!

Discover how you can share your ideas, contribute to our blog, and connect with us on other platforms.