One Platform. Parallel live Product Models
SystemWeaver helps large engineering teams work in parallel and move quickly without losing system integrity. Select any block in the platform map to see what it does.
Change under control, every day
Three services run underneath every other capability. They let a large team work in parallel without losing track of what changed, why it changed, and in which state the product is today.
Version management
Every element of the product model has a history. Engineers branch, compare and merge their work, and return to any earlier state of the model when they need to.
- Full history of every change
- Compare and merge parallel work
- Restore earlier states of the model
Issue and project management
Work items, change requests and reviews live next to the engineering data they affect. Teams plan, assign and follow progress without leaving the product model.
- Link issues to requirements and design elements
- Follow status across teams and suppliers
- Fit into the tools your teams already use
Configuration management
Baselines capture a consistent, reviewable snapshot of requirements, architecture, software and tests. A release is defined by what is in the baseline, not by memory.
- Create and compare baselines
- Manage configurations per variant
- Reproduce any released state
Compliance built into the way you work
Five disciplines run through the whole product model. They shape how work is organized, instead of sitting in a separate compliance step at the end.
ASPICE
Automotive SPICE assessments ask for evidence that your process is defined and followed. SystemWeaver keeps that evidence in the same place as the engineering work itself.
- Structure work to match the process areas
- Collect assessment evidence as you engineer
- Show bidirectional traceability on demand
Cybersecurity
ISO/SAE 21434 requires cybersecurity to be managed across the whole lifecycle. Threats, goals and controls are linked to the architecture they protect.
- Link threats to assets and architecture
- Derive cybersecurity goals and requirements
- Keep the analysis current as the design changes
Safety
Functional safety depends on a clear chain from hazards to safety goals, requirements and verification. SystemWeaver holds that chain as connected model elements.
- Trace hazards to safety goals and requirements
- Keep ASIL information with each element
- Prepare safety case evidence from the model
Product line engineering
Most vehicle programs share a common base and differ by market, option or generation. Manage that variation once, in the model, instead of copying whole projects.
- Define variants and the rules between them
- Reuse shared elements across programs
- See what differs between variants at a glance
Requirements management
Capture, structure and review requirements from customers, standards and internal teams. Each requirement stays connected to the functions, architecture and tests that satisfy it.
- Exchange requirements with partners through ReqIF
- Link to functions, design and tests
- Use AI assistance to draft and refine, with humans deciding
From feature to supplier, in one connected model
These are the engineering views that make up the product model. Each one is a different way of looking at the same live data, so a change in one place is visible in all the others.
Feature model
Describe what the vehicle or system offers as a structured set of features and options. The feature model is the starting point for variants and for scoping every other analysis.
- Mandatory, optional and alternative features
- Constraints between features
- Drive variants and configurations
TARA
Threat analysis and risk assessment shows what could be attacked, how, and how severe the impact would be. With LIVE TARA together with VicOne, the analysis follows the architecture as it evolves.
- Assets, threats and attack paths
- Risk rating and treatment decisions
- Cybersecurity impact whenever the product changes
HARA
Hazard analysis and risk assessment rates each hazardous event by severity, exposure and controllability to arrive at an ASIL. The result feeds directly into the safety goals.
- Structured catalog of hazardous events
- ASIL derived from the ratings
- Safety goals linked to functions
Function analysis
Break the system down into the functions it must perform and how they exchange information. Functions connect the requirements on one side to the architecture on the other.
- Function hierarchies and data flow
- Allocate functions to the architecture
- Reuse functions across variants
FTA
Fault tree analysis works backward from an unwanted top event to the combinations of failures that could cause it. It gives a safety argument a clear logical structure.
- AND and OR gate logic
- Basic events linked to components
- Evidence for ISO 26262 safety analysis
System analysis
Look at the system as a whole: its boundaries, its sub-systems and how they depend on each other. System analysis keeps early decisions consistent with the requirements behind them.
- Define system context and boundaries
- Decompose into sub-systems
- Check dependencies and interfaces
FMEA
Failure mode and effects analysis lists how each element could fail, what that would cause and how to detect or prevent it. Every row stays linked to the design it describes.
- Failure modes per element
- Effects, causes and controls
- Kept up to date when the design changes
Design architecture
Define the logical and technical structure of the system: components, ports, interfaces and their connections. The architecture is where requirements meet software and hardware.
- Components, ports and interfaces
- Several levels of abstraction in one model
- AI assistance to create and refine models
SysMI
SysMI connects the product model with other model-based systems engineering tools. Teams bring in existing system models and share results without redoing work.
- Import and share system models
- Work alongside existing MBSE tools
- Keep one source of truth
Parameter management
Parameters such as limits, gains and timing values are defined once and used wherever they are needed. Values can differ per variant while staying under change control.
- Central definition of parameters
- Values per variant and configuration
- Traceable changes and approvals
Hardware
Model electronic control units, sensors, actuators and the connections between them. Hardware design stays linked to the software and the functions that run on it.
- ECUs, sensors and actuators
- Physical interfaces and connections
- Allocation of software to hardware
Network design
Design the in-vehicle network of buses and gateways, and the signals that travel across them. Signals link back to the functions that produce and consume them.
- CAN, LIN and Ethernet networks
- Signals, messages and routing
- Export to DBC and ARXML
AUTOSAR
Model Classic, Adaptive and mixed platforms in one environment. Software components, interfaces and configuration stay connected to the requirements and to the rest of the architecture.
- Classic Platform and Adaptive Platform
- Mixed systems in one model
- ARXML import and export
Supplier management
Share exactly the right slice of the model with each supplier, and take their deliveries back in. Specifications and results stay traceable across company boundaries.
- Controlled sharing of specifications
- Exchange through ReqIF and ARXML
- Track deliveries against requirements
Open formats and open APIs
SystemWeaver fits into your existing toolchain. Industry-standard formats and an API-first architecture let data move in and out without lock-in.
DBC
DBC files describe CAN messages and their signals. Import them to bring existing network definitions into the model, and export them to supply downstream tools.
- Import CAN messages and signals
- Export for simulation and test tools
- Keep signals linked to functions
RIF/ReqIF
ReqIF is the standard format for exchanging requirements between companies and tools. Use it to receive specifications from customers or to send them to suppliers.
- Receive customer specifications
- Send requirements to suppliers
- Merge returned changes into the model
ARXML
ARXML is the AUTOSAR exchange format for software components, system descriptions and ECU configuration. Import and export keep SystemWeaver aligned with your AUTOSAR toolchain.
- Import and export AUTOSAR descriptions
- Share with configuration and generation tools
- Stay consistent with the model
Open APIs and MCP
Open APIs, including MCP, make the engineering context available to AI agents, automation and external tools, without tying your organization to one AI ecosystem.
- API-first architecture
- Governed access for AI agents
- Connect code repositories by pointer, not by copy
Test and verification
Plan, run and report tests in the same model that holds the requirements and the design. Every test case links back to what it verifies, and every result links forward to the release.
- Link test cases to requirements and architecture
- Cover every level, from unit test to system test
- Follow results and coverage as they happen
- Connect to your test tools and CI/CD pipelines
Proof that comes from the work itself
These five capabilities turn the product model into evidence. They run on live data, so what you show an assessor or a customer is always current.
Standards
Document how each applicable standard is addressed and show where the evidence lives. Fulfillment is visible in the model, not hidden in a separate spreadsheet.
- Standards documented in the model
- Fulfillment status per requirement
- Direct links to the supporting evidence
Process support
Process documentation and guidance help teams follow the agreed way of working, and help fulfill the process requirements of standards such as ASPICE.
- Process documentation next to the work
- Guidance for each role and step
- Help to fulfill process requirements
Consistency checks
Rules run across the model to find gaps and conflicts early: missing links, mismatched interfaces and changes that nobody has reviewed yet.
- Find missing links and conflicts early
- Check interfaces across components
- Review findings before they become rework
Traceability
Follow any element up or down the chain, from requirement to function, architecture, software, test and release. Impact analysis shows what a change touches before you make it.
- End-to-end links in one model
- Impact analysis for every change
- AI assistance to propose relationships, with humans approving
Documents
Generate documents from the live model, such as specifications, reports and assessment packages. They always reflect the current state and can be regenerated at any time.
- Specifications and reports from live data
- Assessment packages on demand
- Always matching the current baseline
One source, one environment, one repository
Everything above rests on three principles. They are what let a large team work in parallel without losing system integrity.
Single source
Every engineering artifact lives once, in one live product model. Teams work on the same data instead of exchanging copies that drift apart.
- One definition of every element
- Views, documents and reports derived from it
- No copies to reconcile
All in one collaborative environment
Architects, software engineers, safety and cybersecurity experts and project managers work together in the same model, in parallel, with access that fits each role.
- Parallel work without conflicts
- Role-based access and review
- Humans and AI agents on the same model
All in one integrated information repository
A scalable, graph-based repository holds requirements, models, variants, parameters and test data together, with concurrent access for large teams and large products.
- Graph-based modeling of the product
- Concurrent access at scale
- Distributed deployment when teams are spread out