From Plain-English Spec
To Validated Code Architecture
The Solaros platform is the cloud tooling that sits on top of the event-driven state machine framework (Solaros EOS). Describe your system as a collection of features, use cases and requirements, verify it, and generate validated code architecture for your project - based on Solaros EOS or your RTOS of choice.
Solaros EOS is the next evolution of the embedded RTOS - an event-driven state machine framework that your system runs on. The platform is the tooling that gets you there faster. You define system behaviour as a structured specification, the platform checks it before any code exists, and it generates code architecture aligned to that specification - with scaffolding, state machines, interfaces and traceability markers, leaving you free to complete the application logic and hardware abstraction layer.
An Automatic System Of Record
Each stage builds on the approved output of the one before it. Scope is captured once in Specify and carried forward, so what you verify, construct, validate and certify all trace back to the same definition.
Explore The OS →Describe your system as a structured specification in plain English. Behaviour is captured as bounded features, not loose requirements.
The specification is checked for gaps, ambiguity and engineering risk before any code is generated. A feature set must pass Verify cleanly to progress.
Verified feature sets become code architecture for your target system - scaffolding, state machines, interfaces and traceability markers.
Define and run test scenarios drawn straight from the specification. Tests stay linked to the features and requirements they came from.
Reuse the verification and validation evidence for internal acceptance and, where required, for external certification bodies.
What Each Stage Produces
Specify
/ System Definition And System Of RecordSpecify is the entry point. It captures what the system is allowed to do as bounded, owned behaviours before implementation begins. The result is an authoritative system of record that every later stage builds from. It can be adopted on its own, without changing your existing toolchain or runtime.
// DELIVERED ASStandalone system definition and system of recordVerify
/ Specification Verification And ReadinessVerify analyses feature definitions, use cases, behavioural logic, timing assumptions and edge conditions. Each feature set gets an engineering verification report covering errors, warnings, recommendations and confirmed-ready elements. A feature set has to pass Verify before Construct will accept it.
// DELIVERED ASEngine-backed verification with formal engineering reportsConstruct
/ Framework Generation From Verified SpecsConstruct turns verified feature sets into code architecture aligned to the intended behaviour. Generated artefacts include architectural scaffolding, state machines, interfaces and traceability markers that tie code back to its feature, use case and requirement, ready for you to complete the application-specific logic.
// DELIVERED ASEngine-driven framework generation with engineering oversightValidate
/ Specification-Driven Test And AcceptanceValidate covers unit, integration, communication, end-to-end and acceptance testing. Scenarios are derived from the approved specification rather than inferred from the code, and they stay linked to their originating features and requirements. The output is structured evidence of behaviour and delivery completeness.
// DELIVERED ASSpecification-driven validation with execution supportCertify
/ Acceptance And Certification OrchestrationCertify confirms that delivered functionality meets agreed scope. It reuses the records produced in Verify and Validate, so acceptance and audit do not start from scratch. Where appropriate it coordinates with accredited third-party bodies for industry and regulatory standards, with Solaros supplying the evidence and audit trail.
// DELIVERED ASCertification orchestration with third-party integrationCode Plus Artefacts In One Package
A constructed feature set arrives as a complete, reviewable package - code plus the evidence around it.
Bespoke C generated from your spec, ready to compile and extend.
One state machine per concurrent process, event-message driven (not task scheduling).
Your features formalised into structured, versioned specifications.
Every requirement tied to the line of code that implements it.
A MISRA-aligned audit across the generated files.
How the framework drops into your existing build.
Traceability Built In
Every requirement carries a unique identifier from specification through to generated code and tests. The traceability matrix and the evidence a certification needs are produced as you build, not reconstructed months later. When a requirement changes, you can see exactly what it touches.
{ "id": "F4", "name": "Change Baking Time", "useCases": [{ "id": "UC4", "requirements": [{ "id": "UCR26", "text": "Set_Bake_Temperature to 150°C" }] }] }
| UCR25 | Configure default bake mode | Configure_Oven(e_GRILL_MODE); |
| UCR26 | Configure default temp 150°C | Set_Bake_Temperature(150); |
| UCR27 | Configure baking time | Set_Bake_Duration(requested_time); |
- oven_ui_controller_xApp.c1,106
- oven_ui_controller_xApp.h176
- oven_ui_controller_vsmtos_API.h187
- oven_ui_controller_sys_def.c114
void state_oven_off(void) { /* UCR26: Configure default bake temperature (150C) */ Set_Bake_Temperature( c_DEFAULT_BAKE_TEMP ); /* ... */ }
- API11/11
- Types12/12
- Patterns22/22
- Headers5/5
- Traceability5/5
// Same spec in, same code out, every time.
Tooling On Top Of The OS
The platform and the OS are separate, and you can take them separately. Construct targets the event-driven Solaros EOS by default, so generated frameworks run on a runtime built for the same model. But the output is portable - port it to your own target, toolchain or alternative RTOS, and keep your runtime choices. Adopt the OS when determinism, footprint and lifecycle control make it the right foundation.
Inside The OS →