Sample Applications
A few case studies are being considered as sample applications to run on top of Renelick. They will be going through various implementation stages, at the moment they are only ideas or early experiments.
Weather Watchdog
Purely about data processing, this involves periodically receiving updates from weather stations and forecast services, updating internal data, generating charts and reports.
The generated data could be used to trigger other tasks with other applications, for example a solar panel or wind turbine could adjust their profiles depending on weather data - which leads us to the next example.
Nanogrid
What is a nanogrid? As per Wikipedia:
Very small microgrids are called nanogrids.
And, what is a microgrid? A standard electricity grid typically covers a whole country, with many large power generators and millions of users. A microgrid is based on the same technology but with a much smaller scale, to maybe cover a small town. Then a nanogrid is typically able to produce just enough energy for a house or a hamlet, typically disconnected from the main grid in isolated areas. It might also be called Off-Grid.
As such, this case study is about hardware automation: IoT sensors, power generators, electrical loads and various other entities which create signals and need to be controlled as a result. A lot of data can be generated from this, and events too. There is also a real-time dimension although the timescales are typically measured in days, hours or minutes, for example when some power sources become offline or online and the grid needs to route electricity differently.
Kernel Testing
As explained in the README, Renelick was derived from a system originally aiming at testing the upstream Linux kernel. It's interesting to keep this type of application on the radar, first of all because it's still very useful and also to be able to measure how much it has changed from the revision picked for the initial fork. This may also be used as a comparison point for KernelCI.
The use-case is a mix of abstract data handling and hardware orchestration. Typically, trigger events are either new commits on a Git branch and patch files sent to a mailing list. Then some I/O and compute-heavy tasks are required such as getting the source tree, running static linters, builds and tests on VMs. The hardware dimension comes in later when running tests on real devices.
Interoperability
The real benefit of having a generic system which can do all these things is that it provides a way to build more advanced applications with loosely-coupled components. It's also a good way of collating data from various users running similar applications.
Taking the case studies mentioned above, one could imagine a standalone datacenter powered by a nanogrid with an energy profile changing according to the weather: build more kernels on a sunny day... Users need reliable data and predictable test coverage so this may not be a real scenario, unless some other datacenters are available to bridge the gaps. Regardless, it's a nice illustratiion and these case studies are only examples to demonstrate the system's full potential.