Skip to main content

Getting Started

Video transcript

00:03 — Create your system

Every project starts with a system. Open the System Hierarchy and click AI Generate. Describe your product in plain English — here, a smart door lock — and the platform interviews you with a few sharp questions, then proposes a complete breakdown: system, subsystems, boards, right down to components. Review it, and create it. In under a minute you have the skeleton a program normally spends weeks assembling.

00:36 — Generate requirements

Now give the platform something to work from. Open the Requirements tool — it is already pointed at your Main Control Board. Choose Generate with AI, describe what the board must do, and click Generate. In about a minute you get a structured, categorised set of requirements, each with a traceable ID and checked against design-input standards — a day of writing, in ninety seconds.

01:07 — Build it yourself, with the agent

You don't have to hand everything to the AI. Every tool has a build-it-yourself path — on this sub-board, start a blank Requirements document and add one by hand. And the agent is right there in the dock when you want it: ask it to draft a requirement, and to trace this sub-board up to its parent on the Main Control Board. That cross-level link is captured the moment you ask — so your requirements stay connected across the whole V-model, whether you write them yourself or with the agent.

01:43 — Run a trade study

Real design decisions are trade-offs, and reviewers want to see they were made deliberately. Open the Pugh trade study, describe the choice — here, which microcontroller to use — and the platform scores the options against weighted criteria and recommends one. A defensible decision, on the record, in a minute.

02:07 — Analyse failure modes

Next, surface risk. A design FMEA identifies how each part can fail, how severe it is, and what mitigates it — scored so the highest-risk items rise to the top. The safety analysis critical products need, generated from the same understanding of your board.

02:29 — Draw the architecture

Capture the architecture as a living block diagram. Describe the board and the platform lays out the blocks and the typed connections between them — power, data and control — that an interface control document is then derived from.

02:48 — Plan verification

Every requirement has to be verified. The design verification plan lays out the tests — functional, environmental, life and safety — each tied back to what it proves, closing the loop from what the product must do to the evidence that it does.

03:10 — See the whole program

Everything you've built is one connected model — and you can read it from both directions. Open a requirement and its traceability tells the whole story: this board requirement derives from its parent up in Core Electronics, and downstream it is implemented by a block, verified by a DVP test, and analysed in the DFMEA — full bidirectional trace, captured as you worked. And it all rolls up. Open your system root and the System Model tab, and refresh: verification coverage computed straight from those tests, the traceability matrix, and AI insights flagging exactly what still needs attention — the program picture that normally takes a dedicated tool and a team to maintain, ready to export for a review.

04:02 — Put the agent to work

And an autonomous agent can drive all of it. Open the Agent, start a session, and ask in plain English — here, to audit the requirements against the design FMEA. It reads your model, works across the tools, and brings back what it finds. When it changes a document, that change arrives as a proposal you review and merge — never a silent edit.

04:30 — The rest of the toolbox

And there's more in the toolbox. Management gives you a stage-gate checklist, a ConOps, a risk register and a SEMP to run the program. Requirements, to capture and flow down every spec. Concept — SWOT, Pugh trade studies, flowcharts and block diagrams. Preliminary design, with interface control documents. Detailed design — DFMEA and PFMEA, a design verification plan, root-cause analysis, and an implementation workspace that reviews your real schematics, simulations and PCBs. Fabrication and sourcing — BOM completion, procurement and Gerber analysis. Plus engineering calculators tied to your hierarchy. Same pattern everywhere — describe it, generate, review — and it all lands on one connected model.

05:24 — Every document, under control

And whatever tool you are in, the same controls sit on every document. Search and filter by keyword or ID. Export to PDF, Word or Excel for a formal deliverable. Branch a follow-on to explore a change without touching the main. And every save is a revision — open the history, compare any two, and the diff panel shows exactly what changed, added, removed and edited, line by line. Version control and change management, built in — you never leave the tool to manage your work.

06:01 — Review and baseline

Finally, lock it in. Every document uses the same change-controlled loop: submit it for review, route it to a teammate, disposition their comments, and baseline it. From that point the agent and your team work against a frozen reference — and your whole program stays traceable, from the first requirement to the last verification. That is a product, built end to end, in one afternoon.

Getting Started takes one example system — a smart residential door lock — from an empty page to a reviewed, baselined product with end-to-end traceability. In a single walkthrough you see every step of a real hardware development activity in Creopus, with AI that drafts and a workflow that keeps you in control.

What the walkthrough covers

  1. Create your system — generate a complete V-model hierarchy from a plain-English description.
  2. Generate requirements — a structured, categorised, traceable requirement set in about ninety seconds.
  3. Build it yourself, with the agent — the hand-authoring path, and the agent creating a cross-level traceability link on request (each change approved before it lands).
  4. Trade study — a Pugh matrix that turns a design choice into a defensible decision.
  5. DFMEA — failure modes, effects and mitigations.
  6. Block diagram — the system architecture.
  7. Design verification plan — how each requirement will be verified.
  8. Bidirectional traceability and the program rollup — one requirement traced up to its parent and down to the block that implements it, the test that verifies it and the FMEA that analyses it — then the live System Model / RTM / V&V dashboard.
  9. Put the agent to work — an autonomous agent working across your whole model.
  10. The rest of the toolbox — every tool, grouped by V-model phase.
  11. Every document, under control — search, export, follow-ons, revision history, compare and the diff panel that live on every tool.
  12. Review and baseline — the change-controlled loop that locks it all in.

Next steps

  • Why Creopus — what the platform replaces and why teams switch.
  • Features — deep-dives on the tools and workflows.
  • Tools — the full tool reference.