Security
EOS Max gives safety- and security-critical embedded products a small, controlled runtime with bounded behaviour and a managed release path.
// 01 · Why it's secure
EOS Max runs each virtual state machine in response to events - one at a time, to completion. With no dynamic memory and no pre-emptive task scheduling, it removes dynamic-allocation failure modes and reduces shared-state complexity, keeping runtime behaviour bounded and easier to audit.
// 02 · A foundation you control
Solaros is developed in-house, with managed releases and commercial support. Regulated teams have a named provider and a versioned runtime they can review, license and maintain.
Developed and controlled in-house, with a clear owner for the runtime.
Defined releases with controlled updates and documented changes.
A commercial provider responsible for the runtime, licence and support.
Generated code is checked against MISRA C:2012 across the files produced.
The generated framework is checked against its source product definition.
A controlled architecture makes dependencies and release history visible.
// 03 · Who it serves
Across robotics, medical, automotive, energy and Edge AI, the same conditions raise the stakes - regulated work, multi-vendor delivery, high-security environments, and systems that have to last for years.
Medical, automotive and automation systems where behaviour has to be predictable and accountable. Deterministic execution and no dynamic memory remove dynamic-allocation failure modes and make runtime behaviour easier to review.
A common, versioned runtime gives every supplier the same execution model and makes accountability clearer at system boundaries.
Controlled, auditable software for high-assurance and restricted environments, with a small codebase and a named provider behind it.
A small deterministic core with controlled releases, so teams can review changes and maintain the system long after delivery.
// 04 · How traceability works
Requirement identifiers are retained when the code framework is generated, so engineers can follow a requirement from the source definition into the files and lines produced.
Each feature, use case and requirement receives its identifier in the product definition.
Those identifiers are written into the generated project structure and source files.
Engineers can move from a requirement reference to the generated file and line that carries it.
Generate again from the current definition and the references are carried into the new output.
// See it work
See a reference project get built from specification to code architecture.