Own your vehicle software, from requirement to runtime.
SST is where your vehicle's architecture lives: requirements, safety analysis and design in one model you own. From that model it deploys to any execution environment: AUTOSAR, Linux, Android, or the SST Runtime.
Vehicle software has evolved. Your tools have not.
Architecture, requirements, safety analysis, network files and code sit in separate tools, linked by exports, spreadsheets and meetings. SST puts them in one consistent, versioned model and generates what each target needs from it.
Own it
Your schema, your model, your IP. Unlimited users in a browser, no seat rationing.
Integrate anything
Supplier ARXML, network specs, requirements, spreadsheets and sketches become one consistent, versioned model.
Deploy anywhere
The same model exports to AUTOSAR, Linux, Android or the SST Runtime, so the runtime decision stays open.
One model, every target
Your engineers write the functions; SST generates the interfaces and configuration that connect them.
What SST does today
Every capability marked demonstrated has been shown working. Every capability is demonstrated; we assemble the combination you need for a pilot in one to two weeks.
| Capability | What it does | Status |
|---|---|---|
| Customer-defined schema | Object types, properties, views and rules are configuration you own, edited without code | Demonstrated |
| Supplier ARXML round-trip | Imports an ECU extract into plain objects, preserves what it doesn't model, and exports a full extract | Demonstrated |
| Versioning and review | Element-level versions; branch, diff, review and merge; supplier updates land as versioned changes | Demonstrated |
| Rules at save | Referential integrity by construction; your rules run when data is created | Demonstrated |
| Network specifications | ARXML, DBC and LDF import | Demonstrated Export on roadmap |
| Requirements | Requirements as objects linked to design; Polarion-importable export | Demonstrated Coverage reporting on roadmap |
| Safety analysis | HARA, FMEA and FTA as linked objects, traceable to requirements and architecture | Demonstrated |
| Git traceability | Components pinned to the exact commits that implement them | Demonstrated Write-back on roadmap |
| AI assistant | Schema-aware; drafts ports and components; imports requirements and architecture sketches. AI drafts; your engineers review and approve. | Demonstrated |
| Export to Android, Linux | Generates matching interface artifacts, including Android VHAL configuration and SOME/IP services | Demonstrated |
| Export to AUTOSAR | Standard ECU extract (ARXML) out | Demonstrated |
| Export to SST Runtime | Generates RTE headers and static configuration tables | Demonstrated |
| Deployment | Browser-based, hosted on AWS, unlimited users | Demonstrated On-premises on request |
| Diagnostics authoring | Diagnostics follows the same model pattern as networking; it is on our roadmap | Roadmap |
| Tool connectors | Jira, Polarion and DOORS | Roadmap |
Four ways teams start with SST
An SDV ecosystem you own
One architecture model the OEM owns, holding requirements, safety analysis, design and links to code, deployed to every execution environment in the vehicle.
Start with: an architecture pilot on one vehicle domain.
Work with AUTOSAR customers without becoming an AUTOSAR shop
Keep one versioned model of your component. Import each customer's ARXML, keep what SST doesn't model untouched, and send a standard ECU extract back from the same source.
Start with: send us one customer interface set; we round-trip it and show you the diff.
Start with your architecture, not a vendor's stack
AUTOSAR at the boundary, your own platform inside. Buy only the part you need now, on one platform that grows with you.
Start with: a two-to-three-week discovery, then a pilot on one function or one supplier file.
Safety analysis inside the architecture, not beside it
Hazards, safety goals and requirements point at the exact components and commits they cover. A design change shows which safety artifacts it touches.
Start with: model one item's trace from HARA to code in a working session.
Demonstrated on automotive programs; other domains start with schema configuration and a pilot.
Discovery, then a pilot on your data
Discovery takes 2–3 weeks and the pilot 4–6 weeks as a starting point, adjusted to the domain in discovery. Your engineers work on your own requirements, interface files and network specs, and the pilot ends with a written result against criteria agreed up front.
Want to see it first? We run live demos and set up evaluation accounts for your engineers.
See SST on your own interface files.
Send us one supplier ECU extract or one item's HARA and we'll show you what it looks like as a model you own.