To guide the design of the specification, here we have articulated the high-level goals of this protocol. Relevant Capitalized terms are defined in our {ref}glossary.md#glossary.
First and foremost, we want to enable various, existing solutions in the lab automation niche to interoperate, irrespective of programming language, application niche (GUI, driver, orchestration, data storage,...) or project origin.
In the past, we have observed that the lab automation landscape, at least in Python, is quite fragmented. As it has turned out unrealistic to unify/agglomerate these efforts into larger, and thus more resilient, projects, we have changed tack. We want to enable users to pick drivers from some instrument control libraries with a reasonably homogeneous/simple API, a nice GUI from another project, and a data storage solution from elsewhere, and tie them together to serve the needs of their setup.
PyMeasure is our project, so we know it best, and this will surely influence the design effort. Also, we plan a reference implementation in Python that will also probably be primarily tested with PyMeasure. However, we intend PyMeasure to be only one of many "customer" libraries that can interface with LECO.
This specification will be independent of the programming language its Components are written in, so it will be possible to mix-and-match. Instead of implementing all the necessary Components, we want to give the communication tools to connect everything, to balance on the shoulders of giants.
We want LECO to serve laboratory setups of up to approximately 50 participating Components on one or more computation Nodes (e.g. personal computers) on a common network. For example, you might have up to ~dozens of instruments, a few data acquisition Components, one or several GUIs, and control Components.
"LEGO"-like modularity is important. We want to reassemble, change the constellation of devices, easily adapt to changing experiments, data rate needs, etc.
We want people to easily be able to write their own software implementing (parts of) this protocol, for example to create just the GUI tool that they need.
We want LECO to be very lightly coupled to the used software (like instrument driver libraries) -- we want to thinly wrap these with some interface code that is written (ideally) once. Given some instrument control library with a reasonably homogeneous/simple API, it should be easy to write an Actor variant to connect that library's Drivers with our Actor interface.
You can send a message to any Component by specifying its (possibly human-readable) name or ID, similar to email.
We will have a default interpretation of the message content to implement remote procedure call (RPC), i.e. to set/read properties or call methods.
We want to communicate asynchronously and concurrently: The Director might want to send several commands to different devices at the same time, without waiting for the answer of a (slow) instrument before writing to the next one. This way, communication delays will be determined by the slowest instrument, not by the number of instruments.
Messages should be reliably delivered by the protocol and not lost (barring network problems, crashing Components, hardware failure, etc.).
A failing Component should not corrupt the measurement data acquired until then. That means that e.g. a failing Actor does not corrupt data of other Actors, and that a failing Observer has to have written the data to permanent storage before failing, e.g. by regularly writing instead of buffering a lot of data in memory.
We want to leave the entry threshold as low as possible, the learning curve flat, and the usability of LECO modular.
For simple measurements, a user should just need to download a package, write a little code to connect to the hardware with an Actor and a Driver from some instrument control library (e.g. a pymeasure.Instrument), and measure some things using the Actor interface.
This assumes that an Actor variant interfacing to the given instrument control library has already been implemented.
It should be possible to slowly scale up -- start with a single instrument that you exchange messages with, then add more Actors, a data sink, and a Director for control.
It's also important to be aware of what not to do. This is our list:
Huge setups: We don't want to scale to large setups above O(50-100) Components. Such deployments are probably better served by projects like Tango, EPICS, Sardana, Bluesky, etc..
Deployment of individual Components: We currently have no plans to specify how the various Components, possibly across multiple programming languages and operating systems, should be deployed/compiled/brought up. At first at least, this specification concerns itself with the interoperation of the various Components in the network.
Unit conversion: Getting involved with unit conversion or computations with units is out of scope. Propagating unit information is possible and optional, but the specification will not deal with unit conversion or computation.