It’s driving us: NATS – Modular system thanks to Message Broker

We need a con­nec­tion to our elec­tron­ic shift book. But this is an in-house development… 

(Cus­tom­er)

The research pro­ject to sup­port machine setup and main­ten­ance is going well. The res­ults could be well used in the future as an exten­sion of MADDOX… 

(Fraunhofer IVV research institute)

Cus­tom­er-spe­cif­ic wishes and the future integ­ra­tion of new, innov­at­ive solu­tions drive our product devel­op­ment right from the start. But how can we take these into account now, even though their exact require­ments are not yet known?

Our solu­tion is a mod­u­lar sys­tem based on a ser­vice archi­tec­ture. In our soft­ware, core mod­ules, exten­sion mod­ules and cus­tom­er-spe­cif­ic mod­ules run as largely inde­pend­ent sub-pro­cesses. This makes the over­all sys­tem resi­li­ent and very flex­ible. But how can this “zoo” be kept under con­trol? Much like a pro­ject team of human col­leagues: Each works largely inde­pend­ently. To keep each oth­er up to date on the over­all pro­ject, they use news­let­ters that can be sub­scribed to accord­ing to inform­a­tion needs.

We imple­ment the same prin­ciple tech­nic­ally with the mes­sage broker NATS. Our indi­vidu­al mod­ules send mes­sages to the cent­ral broker, to which the oth­er mod­ules can sub­scribe. This allows future mod­ules to simply plug in and sub­scribe to the mes­sages that are rel­ev­ant to them without requir­ing any changes to the exist­ing sys­tem. This enables effi­cient devel­op­ment des­pite unknown future requirements.

“But the new quasi-industry stand­ard is MQTT…”

That’s true, but we only use the mes­sage broker to com­mu­nic­ate between the indi­vidu­al pro­cesses on our machine. Here, MQTT’s typ­ic­al strengths, such as reli­able trans­mis­sion over unre­li­able net­works, don’t come into play, while NATS plays to its advant­ages. These include, for example, its enorm­ous speed, which we need for fast trans­mis­sion of large amounts of machine data. For extern­al com­mu­nic­a­tion, we rely – in keep­ing with the microservice archi­tec­ture – on inde­pend­ent, pro­tocol-spe­cif­ic mod­ules; for example, for OPC UA…and of course for MQTT if required 😉