CEBuddy
Sign in Register

Help & module guide

What every part of CEBuddy is for. The tool walks one machine from classification through hazards, safety functions and documents to a tamper-evident audit trail — this page explains each step.

What is CEBuddy Register

Core workflow

Project overview

What it's for. One project is one machine (or partly completed machinery, or related product). This page is your home base — it shows how far you have got and what to do next.

What good looks like. Every step in the progress checklist below is green, and the documents you need have been generated and signed off.

  • Work top-to-bottom: Machine Model → Classification → Risk Assessment → EHSR → Standards → Functional Safety → Documents.
  • Nothing here is a substitute for engineering judgement — the tool assists, you remain responsible.

Regulation basis: Regulation (EU) 2023/1230, Art. 10 — manufacturer's obligations.

Team

What it's for. Record the people on the project and the part they play — the engineer doing the work, the person who identifies each hazard, and the authority who accepts residual risk and signs the declaration.

What good looks like. Every role that matters for the file is named, and the authority who signs off the declaration is the same person recorded against the signed documents.

  • A named 'identified by' on a hazard and a named person accepting residual risk are what an auditor expects — anonymous risk acceptance is a red flag.
  • A member's role decides what they can do: an engineer can edit the file, a viewer can only read it.

Regulation basis: Regulation (EU) 2023/1230, Art. 10 and Annex V — the manufacturer (or authorised representative) takes responsibility and signs the declaration.

Machine Model

What it's for. Describe the machine: what it is, who makes it, what it is for, and how it can foreseeably be misused. Almost everything else — classification, the risk assessment, every generated document — builds on what you enter here.

What good looks like. Intended use and reasonably foreseeable misuse are both written down concretely (not 'used as intended'); the manufacturer's name and address are complete; lifecycle phases and operator profiles are listed.

  • 'Reasonably foreseeable misuse' means the wrong-but-predictable things a real operator will do — reaching in, removing a guard, overloading it. Think about it now; it drives the whole risk assessment.

Regulation basis: Annex III §1.1.2 (intended use and reasonably foreseeable misuse must be considered); Annex IV (a) (general description).

Classification

What it's for. Work out which conformity-assessment route your machine must follow — i.e. whether you can self-declare, or whether a Notified Body (an independent third party) must be involved.

What good looks like. You have selected the correct Annex I category (or confirmed the machine is not listed), and the resulting route and Notified Body requirement are recorded with a rationale.

  • Annex I Part A: a Notified Body is ALWAYS required — you cannot self-declare.
  • Annex I Part B: you may self-declare ONLY if harmonised standards covering every applicable requirement are applied in full; otherwise a Notified Body is required.
  • Not listed in Annex I: you may self-declare (Module A, internal control).
  • If you are unsure whether your machine is listed, leave it as 'not listed' for now and revisit after the EHSR and Standards work — it is safer to over-involve a Notified Body than to under-involve one.

Regulation basis: Annex I (categories of machinery); Art. 25 and Annexes VI-X (conformity assessment procedures).

Risk Assessment

What it's for. Identify every hazard, estimate how serious it is, then reduce it using the three-step method: (1) inherently safe design, (2) safeguarding, (3) information for use. Re-check the residual risk at the end.

What good looks like. Every hazard has a category, an estimate, at least one protective measure, and — where risk remains — a written rationale for why the residual risk is acceptable. Each hazard links to the EHSR clause(s) it addresses.

  • Always try inherently safe design FIRST. A guard (step 2) or a warning in the manual (step 3) is a weaker measure than removing the hazard by design.
  • The S / F / P fields feed the required Performance Level of any safety function you build in Module 15 — estimate them honestly, not optimistically.
  • A hazard you cannot eliminate is normal; an undocumented residual risk is not.

Regulation basis: Annex III §1.1.2 (principles of safety integration); EN ISO 12100 (methodology).

EHSR Checklist

What it's for. Go through every Essential Health and Safety Requirement of Annex III and, for each, decide: does it apply? is it addressed? what evidence and which harmonised standard demonstrate that?

What good looks like. Every applicable clause is 'addressed' with an evidence reference; every 'not applicable' clause has a written rationale; the gap list at the top is empty.

  • Do not mark a clause 'not applicable' just to clear the gap list — a rationale-free N/A is exactly what a market surveillance auditor looks for.
  • Invoking a harmonised standard gives you 'presumption of conformity' for the clauses that standard covers — record which standard, in the field provided.
  • Clauses tagged 'new under 2023/1230' (cybersecurity, software, AI) are easy to miss because they were not in the old Directive — check those carefully.

Regulation basis: Annex III (Essential Health and Safety Requirements), all six sections.

Standards Register

What it's for. List every standard you applied, with its edition and where on the machine it applies. Applying a harmonised standard in full gives presumption of conformity for the requirements it covers.

What good looks like. Each entry has a designation, edition and scope; no entry triggers a 'superseded edition' warning; the harmonisation status is recorded honestly.

  • Edition matters: citing a withdrawn edition (e.g. ISO 10218-1:2011 instead of :2025) does NOT give presumption of conformity.
  • The harmonised list under 2023/1230 is still being published, so 'pending' is a normal and honest status, not a defect.

Regulation basis: Art. 20 (harmonised standards and presumption of conformity).

Functional Safety

Functional Safety

What it's for. Calculate the Performance Level (PL) actually achieved by each safety-related control function, and compare it against the level the risk assessment requires (PLr). This is the SISTEMA-style EN ISO 13849-1 engine.

What good looks like. Every safety function shows 'achieved PL >= required PLr' (PASS), the CCF score is at least 65 for Categories 2/3/4, and the calculation chain is complete and auditable.

  • Model a function as subsystems in series: typically Input → Logic → Output. Each subsystem has a Category (B, 1, 2, 3, 4).
  • Element reliability comes either as MTTFd directly, or as B10d + nop (operations per year) — the tool derives MTTFd from those.
  • For Categories 2, 3 and 4 the Common Cause Failure (CCF) score MUST reach 65 points or no PL can be claimed — fill in the Annex F checklist.
  • The calculation chain at the bottom of each function shows every step — if an auditor asks 'how did you get PL d?', that is the answer.

Regulation basis: EN ISO 13849-1:2023; EN IEC 62061 (the SIL track).

Tools & calculators

What it's for. Quick, standards-anchored calculators for sketching: light-curtain and reach safety distances, crushing-gap clearance, cobot PFL / SSM checks, and functional-safety conversions. Results update live as you type.

What good looks like. You used a calculator to size a safeguard, then captured the final figure as evidence in the module that owns it — the calculators are a scratch-pad, not a record.

  • A calculator result is not a record. Once you settle on a number, write it into the relevant module so it becomes part of the technical file.
  • Every result shows the formula with your numbers substituted — that is what an auditor will want to see.
  • The reach (EN ISO 13857) and crushing-gap (EN ISO 13854) calculators need licensed standard tables; until those are loaded they show a 'data pending' notice rather than a guess.

Regulation basis: EN ISO 13855 / 13857 / 13854 (safety distances); EN ISO 10218-2 (robotics); EN ISO 13849-1 / IEC 62061 (functional safety).

Documents, markings & audit

Documents

What it's for. Generate the Technical File index, the Declaration (of Conformity or of Incorporation), the Instructions for Use, and the PL/SIL verification report.

What good looks like. Every document you need is generated, reviewed, and signed off by the signoff authority. No document was produced with gaps — if generation is blocked, the reasons are listed and you fix them first.

  • If a document is blocked, that is the tool protecting you — a Declaration with missing fields is worse than no Declaration.
  • A partly completed machine (or a bare industrial robot) gets a Declaration of INCORPORATION, never a Declaration of Conformity — the tool enforces this.
  • The signature is what counts. Generating a document is not signing it off.

Regulation basis: Annex IV (technical documentation); Annex V (declarations); Annex XI (instructions); Art. 11 (10-year retention).

Notified Body

What it's for. When your machine needs an independent third party (a Notified Body) to assess conformity, record which body, the procedure they ran, and the certificate or attestation they issued.

What good looks like. The notified body's four-digit identification number, the conformity-assessment procedure used, and the certificate reference are all recorded — and the number is shown next to the CE marking.

  • You only need this module if Classification said a notified body is required — most not-listed machines self-declare and skip it.
  • The notified-body number goes on the machine next to the CE marking and into the Declaration of Conformity.

Regulation basis: Art. 25 and Annexes VI–X (conformity-assessment procedures); Annex I Part A (a notified body is always required for those categories).

Noise & Vibration

What it's for. Record the machine's measured emissions — airborne noise, and hand-arm or whole-body vibration — at the operator position, each with the measurement standard and uncertainty.

What good looks like. Noise and (where relevant) vibration figures are recorded with their uncertainty and the standard used, ready to be stated in the Instructions for Use.

  • Even a low figure is declared — 'not measured' is not an option for the instructions for use.
  • Quote the measurement standard (e.g. EN ISO 11202) so the figure is comparable and defensible.

Regulation basis: Annex III §1.5.8 (noise) and §1.5.9 (vibration); Annex XI (the figures must be declared in the instructions).

Signs & Markings

What it's for. Plan the legally-required markings: the rating plate (manufacturer, model, year, CE mark) and the safety signs and pictograms the risk assessment calls for.

What good looks like. The rating plate carries every mandatory field, the CE marking is present (with the notified-body number when applicable), and every residual-risk warning from the risk assessment has a matching sign.

  • A warning on the machine is step-3 'information for use' — it never replaces a guard or an inherently safe design.
  • The rating plate must stay durable and legible for the life of the machine.

Regulation basis: Annex III §1.7.3 (marking of machinery) and §1.7.1 (information and warnings on the machine); Art. 4 (CE marking).

Inspector Pack

What it's for. A single index that pulls the whole file together for a market-surveillance request or a notified-body hand-off — pointing at the declaration, technical file, risk assessment, PL/SIL report and evidence.

What good looks like. The pack lists every required document and shows none are missing or blocked — the file you could hand to an inspector today.

  • The pack is an index — the canonical, portable bundle is the .mce export.
  • If the pack flags a gap, fix it in the module that owns it rather than papering over it here.

Regulation basis: Annex IV (contents of the technical documentation); Art. 11 (availability to authorities on request).

Audit Trail

What it's for. An append-only, hash-chained log of every meaningful change to the project — who did what, and when. It is the tamper-evidence behind the technical file.

What good looks like. The chain verifies as intact end-to-end, and the latest chain anchor has been archived externally (e.g. in a signed PDF footer or a register) so even a full-table wipe would be detectable.

  • You never edit the audit trail — it records itself. A broken chain means data was changed outside the app.
  • Copy the chain anchor into your signed documents so the on-screen value can be checked against an external copy.

Regulation basis: Art. 11 (technical documentation retained and available for 10 years); good practice for demonstrating file integrity to market surveillance.

Robotics

These modules appear for robot-cell projects (the exact set depends on the robot role and whether the application is collaborative).

Robotics hub

What it's for. The home for a robot-cell project: the robot profile, the application(s) and their safeguarding, and the entry points into the ISO 10218 checklists and the PFL biomechanical work.

What good looks like. Every robot application has at least one safeguarding measure, collaborative applications declare their method, and any power-and-force-limited contact has a validated contact point.

  • Set the robot role first (manufacturer vs integrator) — it decides which checklists you see.
  • A 'collaborative application' is a specific shared-workspace method you must validate, not simply 'a cobot'.

Regulation basis: EN ISO 10218-1 / -2 and ISO/TS 15066; the general 2023/1230 obligations still apply on top.

ISO 10218-1 checklist (robot manufacturer)

What it's for. For the maker of the bare industrial robot: work through the design requirements of EN ISO 10218-1 — stopping functions, speed and axis limiting, modes of operation, and electrical safety.

What good looks like. Each applicable clause is addressed with a note or evidence, and clauses that don't apply to your robot carry a rationale.

  • This checklist is for the robot manufacturer. If you integrate a bought-in robot into a cell, you mainly work in ISO 10218-2 instead.
  • A bare industrial robot is partly completed machinery — it gets a Declaration of Incorporation, not of Conformity.

Regulation basis: EN ISO 10218-1:2025 (safety requirements for the robot itself); harmonised under 2023/1230.

ISO 10218-2 checklist (system integrator)

What it's for. For the integrator of the robot application or cell: work through EN ISO 10218-2 — layout, safeguarding, the collaborative methods used, and validation of the installed cell.

What good looks like. Each applicable clause is addressed, and the safeguarding strategy (fencing, scanners, SSM, PFL) is recorded and validated against the standard.

  • The integrator places the complete cell on the market — it gets a Declaration of Conformity, even though the bare robot inside had only a Declaration of Incorporation.
  • Pick the collaborative method honestly: speed-and-separation and power-and-force-limiting need very different validation evidence.

Regulation basis: EN ISO 10218-2:2025 (robot systems and integration); ISO/TS 15066 for collaborative operation.

Biomechanical limits (PFL)

What it's for. For collaborative (cobot) applications: record the body-region force and pressure limits and check measured contact values against them, so any human-robot contact stays within safe limits.

What good looks like. Each possible contact point has a body region, a contact type (transient or quasi-static), and a measured value at or below the ISO/TS 15066 limit.

  • Quasi-static (clamping) limits are stricter than transient (a quick bump) — classify each contact correctly.
  • A measured value above the limit is not something to argue around: reduce speed, force or contact area until it complies.

Regulation basis: ISO/TS 15066 (collaborative robots — biomechanical limits); EN ISO 10218-2.

Cyber, Software & AI

Cyber, Software & AI

What it's for. Catalogue the machine's digital attack surface and its safety-related software, and — where present — any AI used in a safety function. These are new, explicit duties under the 2023/1230 regulation.

What good looks like. Threats that could defeat a safety function are listed with their protection measures and evidence that safety stays intact; safety-related software and any AI component are inventoried with their governance.

  • Cybersecurity is now a safety requirement: an attacker who can change the SSM zones or disable an interlock is a hazard, not just an IT problem.
  • If AI drives a safety decision, you must be able to explain its behaviour, its limits, and its safe failure mode.

Regulation basis: Annex III §1.1.9 (protection against corruption) and §1.2.1 (safety and reliability of control systems); the EU Cyber Resilience Act and AI Act where they apply.

Maintaining the file & assemblies

Line Composition appears for assembly-of-machinery (production-line) projects.

Change Control

What it's for. Track modifications after the file is built and judge whether a change is 'substantial' — significant enough to require re-assessment and a fresh conformity route.

What good looks like. Every change is recorded with its rationale; substantial modifications are flagged, and any document a change invalidates is re-generated and re-signed before the machine stays on the market.

  • Not every change is substantial — a like-for-like spare is not. A change that introduces a new hazard or raises risk usually is.
  • When a change invalidates a signed document, the tool blocks the stale version — re-issue it.

Regulation basis: Substantial-modification provisions (a substantially modified machine is treated as new machinery); Art. 10 obligations carry forward.

Line Composition

What it's for. For an assembly of machinery (a production line): list each constituent machine and confirm each carries its own Declaration of Conformity or Incorporation, so you can sign one line-level declaration.

What good looks like. Every constituent has supplier evidence (a DoC or DoI) on file, the interfaces between machines are assessed, and the integrator's line-level declaration references each one.

  • You are responsible for the hazards created at the interfaces between machines — not just for each machine on its own.
  • Keep each constituent's supplier declaration; the line-level DoC stands on them.

Regulation basis: Definition of an 'assembly of machinery'; Art. 10 and Annex V (the integrator declares conformity of the whole assembly).

CEBuddy is decision-support — it assists your work but does not certify conformity. The manufacturer remains solely responsible for the machine and its documentation.