Components

==================

Anacleto:

Anacleto <br> Anacleto is ... blabla <br> alt text <br>

ExQLibre:

https://gitea.mildstone.org/mildstone/exq_libre <br> Log book application ExqLibre Icon <br>

HSP ( Hierarchical State Planner):

https://gitea.mildstone.org/mildstone/hsp <br>

Vortice VDI:

HookeWire

We definetly enterd the era of communication, but seems we have not entered yet in a spread of collaboration. Different kind of interfaces are needed to make the experimental sensors and devices available to the acquisition systems, to the control algorithms and eventually to the scientific community. All these targets require a specific way to organize and share information to be effective and efficient. There are two differen approach to this task: one is to make a simple protocol that is robust and easy to be implemented in any device. The other is to create a framework able to manage a flexible interface agreement between different ends of the acquisition chain. Hookewire implements a hybrid approach, combining a base interface definition with a flexible marshalling mechanism.

There are almost 6 elements in a standard acquisition chain for efficient data acquistion and data analysis:

  • Sensor Logic (the internal acquisition system composed of a buffer and trigger logic)
  • Acquisition device (the physical sensor device capable of transmitting data through the network)
  • Edge Online Broker (middleware for data exchange between the ancquisition device and the central storage)
  • Central Data storage (database server of any kind)
  • Data Distribution (messaging system capable to marshall data from the central storage to the specific application)
  • Client Scope (client application)

Some well known acquisition systems installations use to cover the steps 2 and 4. MDSplus. for instance, is a system capable of connecting device drivers to acquire data from a standard device media and store data in a central storage. The beauty of MDSplus is the possiblity to create a distributed acquisition that can be used to acquire data from multiple sources and store it in a distributed database, while at the same time be able to access it from a single client application. This makes MDSplus very effective in acquiring high volume of data from a wide range of sources, possibly distributed in different locations.

A well structured MDSplus implementation should then account the different flows of information dividing the so called "online" data acquisition to the "offline" data storage, i.e. the efficient throughput in data acquisition from the field, and the flexible data retrieval from the central storage. Even if MDSplus is actually capable of such implementation, this unfortunately is not usually the case in how it has been installed among many different experiments. The usual way of using MDSplus is to make use of the distributed client to connect to central storage and send data directly to a single server and then use the same data structure for the analisys. In particular the main reason comes from the fact that a prompt analisys has to be done just after or during the acquisition, and this leading the way of making the retrieval of data from MDSplus that becomes de facto the way of accessing it. In addition, even if a correct flow separation is implemented, when the data is not yet centrally stored the client application has to be able to access the data in a distributed way, which is not always easy or effective.

In a similar way also other kind of data acquisition frameworks use to create separate flow of information. For example the IOT systems use to separate Edge Computing and Central Data Storage (see for example the ThingsBoard project https://thingsboard.io/products/thingsboard-edge or Ignition https://inductiveautomation.com/ignition). In this case the purpose is quite different though, the Edge Computing mechanism is tailored to perform local operation and to maintain a persistent local storage of data, while the Central Data Storage is used to store data in a distributed way and allow a global access to analytics.

Again HookeWire comes to address both use cases, by providing a common structured way to write interfaces for the Edge Computing and the Central Data Storage. The main message indeed is that using a well defined interface to express the protocols of data exchange between different components of the acquisition we can create marshalling mechanisms that can be used connect components that may differ in their implementation. For instance we could thing of using MDSplus to store data and other SCADA systems to drive the experiment seamlessly, or we could also think of providing the same data to different end