STIG and other engineering tools

Model types and consistency

✅ Kotlin compiler checks types and symbol references; model rules check engineering relationships.

✅ Structured engineering models with built-in consistency checks and configurable OCL constraints.

✅ A supplied engineering data model with automatic and configurable consistency checks.

Text-based specification authoring

✅ Semi-formal models in strongly typed .kt; informal content in Markdown, Mermaid, PlantUML, and text-based draw.io files. Syntax and model-rule feedback accompany authoring.

⚠️ Core authoring uses graphical/tabular project models; OCL constraints and MEL formulas supplement them. Git storage is not the same source-authoring workflow.

⚠️ Core authoring uses model files or a shared database and its editors; scripting and exports supplement that workflow.

Graphical architecture authoring

✅ Native IDEA Design editor and Code/Split views edit the same Kotlin model. Use GUI, code, or both; browser editing is on the way.

✅ Graphical SysML and table editors for architecture and functions.

✅ Architecture, software, hardware, network, and wiring diagrams, including SysML-based views.

Programmable construction and reuse

✅ Kotlin expressions, functions, libraries, and Gradle modules construct and reuse model content.

⚠️ Element libraries, OCL constraints, and mathematical expressions; these have different scope from general-purpose model construction.

✅ Custom metrics can read and write the model; components and model sections can be reused.

Supplied engineering rules and feedback

✅ CREATE rule catalog plus IDEA domain inspections and supported quick-fixes.

✅ Safety consistency rules, configurable constraints, and navigable problem markers.

✅ Automatic and editable consistency checks, with configurable model validation.

HARA and safety-goal development

⚠️ On the way: dedicated HARA and safety-goal workflows are planned.

✅ HARA, ASIL determination, and safety-goal derivation are supplied.

✅ Integrated HARA and safety-related architecture development are documented.

TARA — threat analysis and risk assessment

⚠️ On the way: dedicated TARA workflows are planned.

✅ Threat identification, TARA, and attack trees are documented for the cybersecurity feature set.

⚠️ Confirm the required TARA workflow and licensed scope with Vector; architecture support alone does not establish TARA coverage.

FTA — fault tree analysis

⚠️ On the way: dedicated FTA functionality is planned.

✅ Qualitative and quantitative FTA are supplied, subject to the licensed package.

✅ Model-based FTA is documented in Vector's safety workflow; confirm the selected package and analysis scope.

Failure-analysis methods

⚠️ Models failure propagation, measures, and rationale; this does not establish a quantitative FTA/FMEDA solver.

✅ FMEA, qualitative and quantitative FTA, and FMEDA; available methods depend on the licensed package.

✅ Integrated FMEA is documented; confirm the required FTA/FMEDA methods and package for the intended analysis.

Native C/C++ implementation evidence

✅ Optional LLVM/PhASAR analysis connects implementation observations to the engineering model and report.

⚠️ Architecture and safety analysis are documented; an equivalent C/C++ source-analysis pipeline is not established by these sources.

⚠️ Software architecture and test links are documented; an equivalent C/C++ source-analysis pipeline is not established by these sources.

Links across engineering artifacts

✅ Typed Kotlin references across files and modules.

✅ Requirement allocation, SysML relations, and traces between model artifacts.

✅ Bidirectional links across requirements, architecture, implementation, and test artifacts.

Navigation and change-impact review

✅ Declaration navigation, find usages, rename refactoring, and report links support impact review.

✅ Related-element navigation, trace matrices, and dependency visualization.

✅ Connected model views and cross-viewpoint change-impact analysis.

Product lines and variants

⚠️ Kotlin reuse can construct alternatives; variant governance needs a project-defined process.

⚠️ FMEDA supports variant metrics; broader product variability uses the pure::variants integration.

✅ A 150% product-line model supports configuration of individual product variants.

Generated engineering documentation

✅ stigGenerateHtml generates a linked report with configured analysis results.

✅ Customizable work-product reports, including reports from tables and trace matrices.

✅ Automated specifications and reports generated from the shared model.

Supplied decomposition structure

✅ Highway categories and parent/child relationships span systems down to software elements.

✅ SysML architecture and function models with safety requirements and analysis allocations.

✅ RFLP structure and an E/E data model spanning software, hardware, networks, and wiring.

Connected lifecycle viewpoints

✅ CREATE defines Context, Requirements, Design, Analysis, and Tests together.

⚠️ Strong safety requirements, architecture, and analysis integration; confirm the required test-management workflow.

✅ Requirements, architecture, implementation, and test specifications are linked; these are RFLP semantics, not CREATE.

Engineering traceability checks

✅ Rules check derivation, allocation, classification, and verification links.

✅ Allocation matrices, trace validation, dangling-trace detection, and configurable constraints.

✅ Cross-viewpoint traceability and configurable consistency checks; select the rules required by the project.

Exchange with existing engineering tools

⚠️ Native Highway JSON and SYML Context imports; other connectors need a defined conversion workflow.

✅ ReqIF and requirements-system integrations; supported systems and licenses depend on release and package.

✅ ReqIF and Excel requirements exchange plus domain-specific engineering exchange formats.

Plain-text Git review and merge

✅ Kotlin sources use ordinary Git diffs, branches, and code review.

⚠️ Projects can use Git with medini's external model diff/merge tool; this is not plain-text source review.

⚠️ Shared-model versioning and reviews are supplied; do not assume the model has ordinary text diffs and merges.

Unattended command-line CI

✅ Gradle wrapper tasks check models and generate reports without an interactive IDE.

⚠️ The documented desktop CLI opens windows for open/diff commands; unattended validation is not established by that interface.

⚠️ Scripting and an API-server component are documented; confirm unattended checks, licensing, and failure reporting for the selected deployment.

Incrementality and reproducibility

✅ Gradle incremental execution, declared inputs, and pinned toolchains/dependencies support reproducible builds; caching remains task-specific.

⚠️ Model versions and scoped validation do not establish a reproducible build or build-cache contract.

⚠️ Model versions and baselines do not establish a reproducible build or build-cache contract.

Linux desktop authoring

✅ JVM/Gradle model workflows; check supported hosts separately for optional native analysis.

❌ The cited desktop prerequisites list Windows 10 and 11, not a supported Linux desktop client.

❌ The 26.4 desktop client requires Windows 11; the requirements web client has a different authoring scope.

Team collaboration

✅ Git branches and reviews, shared Kotlin/Gradle modules, and CI support team work using the chosen Git hosting platform.

✅ Shared server projects, project versions, editing locks, and offline synchronization.

✅ A shared multi-user model with role-based access and version control.

Version baselines and review

✅ Git commit IDs and tags baseline the specification; merge/pull requests and CI provide the review workflow on the chosen Git host.

✅ Project versions and model compare/merge support baseline and change review; define the project's approval process.

✅ Model baselines, requirements lifecycles, reviews, and voting are documented.

Free use of the complete local toolchain

✅ All STIG features are free: code/IDEA editing, checks, CI, analysis, reports, and bundled skills. Only the optional browser-editing web server is a separate paid offering.

❌ Production use requires commercial licenses; editions determine available analysis methods and enterprise connectors.

❌ Production use requires commercial licensing; a free hosted trial is offered separately.

First working example

✅ Ready-to-clone stig-project and stig-robot examples: clone, run setup, then ./gradlew stigGenerateHtml.

⚠️ Install and license the desktop tool, then follow its getting-started workflow.

✅ A vendor-hosted demo model and guided RFLP trial are offered without local installation; access must be requested.

Tool qualification and certification

⚠️ Safety assessment scheduled for 2027. Intended scope includes ISO 26262 ASIL D development with TCL3 tool uses and military system safety under MIL-STD-882; qualification and certification outcomes depend on the assessment.

✅ The safety manual documents ISO 26262 TCL3 and IEC 61508 T2 offline-tool certificates and a qualification kit; apply their version/use-case scope.

⚠️ ISO 26262 workflow support is documented; a product-specific tool certificate and qualification scope need vendor evidence.

AI-assisted authoring and review

✅ Version-matched STIG skills let an AI coding agent author and review Kotlin/Markdown specifications, edit the source files, and run model checks and reports. Changes remain ordinary Git changes.

⚠️ Engineering Copilot is documented for learning and support and requires AnsysGPT AI+; this does not establish equivalent source-editing skills.

⚠️ PREEvision 26.3 documents AI technology previews, including MCP support; confirm available model operations and preview/deployment conditions.

Native JetBrains IDEA model editing

✅ A new 2026 native IDEA UI with keyboard navigation, clipboard operations, Undo/Redo, and the IDE's back/forward navigation.

❌ A separate modeling environment; it does not provide this native IDEA model-editing workflow.

❌ An Eclipse-based modeling environment; it does not provide this native IDEA model-editing workflow.

Code, Design, and Split on the same sources

✅ Work in Code, Design, or Split view; GUI and code edits share the same Kotlin sources and engineering checks.

❌ The primary specification is maintained through medini's own model editors rather than paired IDEA/Kotlin editing.

❌ The primary specification is maintained through PREEvision's own model editors rather than paired IDEA/Kotlin editing.

TRLC

✅ A requirements language with typed .rsl schemas, .trlc records, references, user-defined checks, a CLI, and Bazel integration.

⚠️ The project defines the engineering metamodel; IDE features, report conversion, and cross-tool traceability use additional components.

PTC Codebeamer

Commercial ALM with requirements, traceability, risk and test management, workflows, and product variability.

Central collaboration and lifecycle governance; compare concrete workflows, integrations, and deployment costs.

IBM DOORS classic

Requirements in modules and attributes, with baseline traceability and DXL extensions.

Existing module structures, baselines, and customization. Evaluate the chosen client/server release; DOORS Next is a separate product.

Sphinx-Needs

Typed documentation items and links in Sphinx, with schema validation for fields and relationships.

Integrating requirements with an existing documentation build. Its current type and constraint support deserves a direct trial.

StrictDoc

SDoc documents, requirement and source-code traceability, ReqIF exchange, and HTML/PDF export. The quickstart also offers a local web server.

Requirements documentation and interchange without adopting the Highway metamodel.

Doorstop

Text files under version control, hierarchical requirement documents, link validation and review, and HTML publishing. Its item format uses YAML.

A compact requirements workflow; evaluate schema needs and review of changed links on a representative document tree.

Eclipse Capella and Arcadia

A modeling tool and engineering method spanning operational analysis, system needs, and logical and physical architecture.

Graphical architecture work and method-supported decomposition. Arcadia's perspectives have their own semantics; they are not CREATE viewpoints.

SysML v2 from OMG

A systems-modeling language standard with a pilot implementation for textual notation and visualization.

Standardized systems-modeling semantics and tool interoperability. Select an implementation before comparing editor, deployment, or build features.

Mustard

The project describes its scope as tracking architecture, requirements, and design together.

A candidate for further evaluation; the project description alone does not establish current functionality, maintenance, or readiness.