Why Holarch
One connected engineering model.
The case for MBSEModel-Based Systems Engineering Systems engineering that keeps requirements, behavior, structure and tests in one connected model instead of separate documents. without the disconnected toolchain.
A system is one thing, but its engineering record is usually spread over many tools. Holarch keeps needs, requirements, functions, components, interfaces, tests, risks and decisions in one model, and produces every diagram, matrix and document from it.
The problem
Engineering truth split across tools
On many programs, each part of the systems engineering record has its own home. Each is reasonable on its own. Together they leave the team keeping copies in step by hand.
Requirements tool
The specification and its approvals. Links to the design are kept somewhere else, if at all.
Diagram tool
Functions and architecture as drawings. A renamed function has to be renamed again in the specification.
Spreadsheets
Trace matrices, budgets and interface lists, rebuilt from exports before each review.
Documents
ICDsInterface Control Document The agreed definition of an interface between two systems: what crosses it, how, and who owns it. Holarch also has an Interface Control Diagram., test plans and review packages written beside the design, and out of date after the next change.
Test records
Results and evidence that the requirements list cannot see, so coverage is counted by hand.
Risk and decision logs
Lists that name the items they concern in text, with no link that shows when those items change.
The cost is not the number of tools. It is the time spent finding what a change affected, and the reviews that judge a stale copy instead of the design.
The approach
One semantic model, every view a projection
Holarch is an MBSEModel-Based Systems Engineering Systems engineering that keeps requirements, behavior, structure and tests in one connected model instead of separate documents. workbench built on the Lifecycle Modeling Language (LMLLifecycle Modeling Language An open modeling language with a small set of classes and relationships that covers a system's whole lifecycle. Holarch models are LML models.). Every item has a class, attributes and typed relationships, so the model knows that a requirement is satisfied by a function, that a component performs that function and that a test case verifies the requirement.
Every view reads the same items
Documents, diagrams, matrices, boards and charts show the items of the model. Rename a function on an FFBDFunctional Flow Block Diagram A diagram of functions in the order they run, with branches, loops and parallel paths. and the specification shows the new name. There is no export step between them.
The model behind Holarch →Traceability is part of the model
Links are relationships with inverse names, not cells in a spreadsheet. When a source item changes, its links are marked suspect until someone reviews them.
See how it works: suspect links →Workflows follow SE activities
Pages are ordered by the lifecycle: needs and requirements, behavior, architecture, interfaces, verification, risk and decisions, plan and deliver. The SE Process guide reads the model and shows what each phase of ISO/IEC/IEEE 15288, NASA, DoDDepartment of Defense The US Department of Defense., Kossiakoff, MIL-STD-499B or the Vee model still needs.
See how it works: SE process guides →Change stays under control
Approvals, baselines, change requests and version history record what was agreed and what moved since. Every edit can be undone.
See how it works: change requests →Analysis and verification
Analysis and tests as evidence
Analysis and verification run on the same items the requirements describe, and their results attach to those requirements.
- Model checks. 70 rules find requirements without a test, functions nobody performs, interfaces that carry nothing and risks without a handling plan. They run again on every change.
- Simulation. Run an action flow as a discrete-event simulation or a Monte Carlo study, then check the result against a requirement's threshold and record it as a verification result.
- Budgets and TPMsTechnical Performance Measure A key technical parameter, such as mass or power, tracked over time against its target and threshold.. Mass, power, cost and data rate add up over the component tree, with the margin against each allocation. TPMs track measures against their thresholds by milestone.
- Test runs. Record each run with its step results, configuration and evidence file. The RVTMRequirements Verification Traceability Matrix A table of each requirement with how it is verified, the tests that verify it and their latest result. shows what is verified, what failed and what has no test yet.
Documents
Documents generated from the model
People still read and sign documents. In Holarch they are produced from the model instead of maintained beside it.
- A specification is a document in which every requirement is also a model item.
- Traceability, verification and interface matrices in a document are rebuilt from the model each time it is shown or exported to Word.
- ICDsInterface Control Document The agreed definition of an interface between two systems: what crosses it, how, and who owns it. Holarch also has an Interface Control Diagram., test reports, DoDAFDepartment of Defense Architecture Framework The US DoD framework for describing architectures as a set of viewpoints and products, such as OV-1 and SV-1. and UAFUnified Architecture Framework An OMG architecture framework that organizes views in a grid of viewpoints and aspects. It covers DoDAF and NATO needs. products and presentations come from the same items.
Reviews
Reviewers in the loop, free
Reviewers and viewers are free on every plan. Your customer and review board open the live model, comment and approve, instead of marking up an export.
- Roles per project: owner, editor, reviewer or viewer.
- Reviewers comment on items, documents and matrices, and approve or reject requirements. Each approval records the name and time.
- Nothing to install: the model opens in the browser.
Compared
How this differs from a traditional MBSE toolchain
Traditional MBSEModel-Based Systems Engineering Systems engineering that keeps requirements, behavior, structure and tests in one connected model instead of separate documents. tools are capable, and many teams use them well. The difference is where the record lives and how many people can reach it.
| Topic | A traditional toolchain | Holarch |
|---|---|---|
| The record | Requirements, architecture, tests and risks often sit in separate tools and are synchronized. | One model with typed relationships between every item. |
| Documents | Often written or assembled from exports before each review. | Generated from the model, with matrices rebuilt on every export. |
| Reviewers | Need a license or work from exported documents. | Open the live model, free on every plan. |
| Getting started | Desktop installs, often with a license server. | Runs in the browser. Import existing Word, Excel, CSV, ReqIFRequirements Interchange Format An OMG XML standard for exchanging requirements, with their attributes and links, between tools. or XMIXML Metadata Interchange An OMG XML format for exchanging UML and SysML models between tools. work. |
Every import and export format and its limits · How AI works on the model · What is MBSE?
See it for yourself
Getting started
Create a project and take a first requirement to a test case.
Learn more: getting started →