Where the framework comes from
ASKS has been around since 2018 – but the experience our framework is built on reaches back much further. More than 20 years of hands-on work with exactly these recurring tasks – data handling, logging, alarming, state management – grew across different projects and constellations: optimised here, adapted there for a specific customer, but never structured uniformly from the ground up.
In everyday project work this shows very concretely: a lot gets copied together from old, already-finished projects – the CSV logic from project A, the logging function from project B, adapted as well as possible. It works until it doesn't: bugs that were long since fixed reappear in the next project, improvements stay stuck in the original project, and with every copy the versions drift further apart.
This is exactly the fragmentation we're now fixing. We are consolidating the experience gathered over years into a single, shared code base – cleaned up and deliberately restructured – as the ASKS Application Framework. Not as a reinvention, but as the consistent evolution of something that has long proven itself in practice, now placed on a solid, unified foundation.
The benefit for you: one common, tested base instead of grown silo solutions – for every project, for good.
AS Data Manager – the first fully reworked module
With the AS Data Manager, the first module of this restructuring is finished and available now. It ensures that machine data is reliably stored, synchronised and made available through the operator interface – based on years of practical experience, but now uniform and usable the same way across all projects.
The effect for you: your development team no longer starts from scratch, but right at the actual task – the machine. That shortens the time to commissioning and ensures a consistent, reliable quality standard across all your projects.
AS Logger – in testing
Next comes the AS Logger: logging that still runs reliably even when a machine has been in the field for years and someone suddenly needs to know what actually happened at a specific point in time. In a service case in particular, this makes the difference between hours and days of troubleshooting.
What comes next
AS Data Manager and AS Logger are just the beginning. Further modules – for alarming, state management and I/O handling – will follow on the same common base.
For you as a decision-maker, that means: you're not just buying a single module, you're investing in a growing, coordinated platform. Every additional module fits in seamlessly, without having to rebuild what already exists.
The modules at a glance
Five building blocks on one common base: AS Data Manager (available), AS Alarm Handler (in development), AS Logger (in testing), AS Statemachine (planned) and AS Io Handler (in development).
What this means for your project
- Faster commissioning – the same recurring infrastructure work is already done.
- Lower risk – tested building blocks already in use, instead of project-specific one-offs.
- Predictable maintenance – all projects rest on the same base and can be maintained centrally.
- Future-proof – the framework grows with every new module, without you having to touch existing installations.
Technical details on the individual modules can be found in the Application Framework section.