SISTEMA Alternative: A Practical Guide for Safety Engineers Ready to Move On

SISTEMA has been the standard reliability calculation tool for ISO 13849 and IEC 62061 safety work since 2005. It’s free, maintained by IFA (the German Federal Institute for Occupational Safety and Health), and it does one thing well: calculate performance levels and SIL values from component failure rate data.

That’s also its limitation. SISTEMA does one thing. Your safety process needs all the other things too.

When engineers start looking for a SISTEMA alternative, it’s usually not because the calculations are wrong. It’s because the tool exists in isolation. The calculation that proves your safety function meets PLd lives in a desktop file that has no connection to the hazard that required PLd in the first place, the requirement that specifies the safety function, or the test evidence that validates it.

What SISTEMA actually does well

Before naming what’s missing, it’s worth being clear about what SISTEMA delivers. The tool calculates reliability metrics for safety-related control systems using the methodology defined in ISO 13849-1. You build an architecture using categories (B through 4), assign component data from the integrated database or enter manufacturer values, and SISTEMA calculates the achieved PL.

The calculations are technically sound. The tool is free and widely accepted by assessors. For a team doing a straightforward machine certification, it works. That’s why it became standard.

The problem isn’t what SISTEMA calculates. The problem is everything that surrounds the calculation.

Why engineers start looking for an alternative

The file is static. SISTEMA outputs a calculation report. That report represents the system as it was when you ran the calculation. When a component changes, when the architecture changes, when the functional requirements change, the SISTEMA file doesn’t know. You re-open it, manually update the entries, and re-export. If you forget to update it, your safety case references calculations that no longer reflect your design.

It doesn’t connect to anything. The hazard analysis that determined you need PLd for this safety function lives in a spreadsheet. The requirement that specifies the function lives in IBM DOORS or a Word document. The SISTEMA file that proves you hit PLd is a third separate artifact. None of them link to each other. When an assessor asks “how does this calculation trace back to the original risk assessment?” someone has to manually reconstruct the answer.

It covers only one phase. Reliability calculation is one stage in the IEC 61508 lifecycle. SISTEMA handles it. But the lifecycle starts at concept and runs through commissioning and monitoring. A tool that covers one stage leaves the rest of the process (hazard analysis, safety requirements, system design, verification, validation, ongoing monitoring) in whatever combination of spreadsheets and documents the team was using before.

Collaboration is by file transfer. On a team with more than one safety engineer, SISTEMA files travel by email or shared folder. Version control is whoever renamed the file last. On a project with multiple contributors or a design that evolves over months, this produces exactly the traceability problems that generate assessor questions.

What a modern alternative actually delivers

A web-based reliability modeling tool that replaces SISTEMA’s core function isn’t just a different interface. It changes how the calculation connects to everything else in the safety process.

The calculation is linked, not standalone. When the reliability model is part of the same platform as the hazard analysis, the connection between “hazard H-012 requires PLd” and “safety function SF-005 achieves PLd via this architecture” is structural, not manual. The assessor can trace it in either direction without asking.

Design changes propagate. When a component gets replaced, the affected calculations are visible immediately. When an architecture change reduces PL, that impacts the requirement it was supposed to satisfy, and the gap is flagged before the assessor finds it.

Multi-user, browser-based. No file management. No version control by filename. Multiple engineers contributing to reliability analysis concurrently without merge conflicts or “which file is current” questions.

One platform for the lifecycle. Instead of SISTEMA for reliability calculations + a separate tool for hazard analysis + a separate tool for requirements + a separate tool for documentation, everything runs in the same environment. The 500-page technical file that an assessor reviews isn’t assembled from disconnected sources. It’s generated from a single workflow.

What ASAP specifically offers

ASAP’s reliability modeling module does what SISTEMA does (PL calculations per ISO 13849, SIL calculations per IEC 61508 and IEC 62061) and connects those calculations to the full safety lifecycle.

It runs in a browser. No installation. No Windows-only constraint. ASAP can import existing SISTEMA calculation files, which means teams don’t have to rebuild their prior work to get started.

The platform holds T2 tool qualification scope applies only to the specified ASAP tools and versions covered by TÜV Rheinland reports under IEC 61508-3:2010, Clause 7.4.4. It is not a blanket qualification of the full lifecycle or every module.

ASAP was built over five years inside Amazon Robotics, where it protected a large autonomous mobile robot fleet in continuous operation. The reliability modeling capability is one part of a platform that covers the entire V-Model: from hazard analysis through continuous monitoring. Amazon’s teams used it to reclaimed about six months of certification time and save $30M+ across programs.

If your current process is SISTEMA plus spreadsheets plus Word documents, the step isn’t to find a better SISTEMA. It’s to replace the whole workflow with one that holds together.