Industrial Automation and Machinery with Matrix Req
Functional safety evidence for machinery and process control, held as one traceable chain. Matrix Req links hazards to safety functions, SIL and performance level targets, design and verification results, so the safety case is assembled rather than reconstructed.
Functional safety evidence spread across three teams and a shared drive
One safety argument, traceable end to end
IEC 61508 runs a full safety lifecycle. Hazard and risk analysis, safety requirements allocation, realisation and verification each produce evidence that has to connect, and the SIL claimed for a safety function has to be traceable to the analysis behind it.
Machinery adds a parallel standard. ISO 13849 works in performance levels and ISO 12100 in risk reduction, so many machines carry both a functional safety argument and a machinery risk assessment that have to agree with one another.
The EU Machinery Regulation raises the bar. Regulation 2023/1230 applies from 20 January 2027 and brings software, cybersecurity and autonomous behaviour further into the technical file, which means more evidence and more traceability, not less.
Security has become a safety concern. IEC 62443 requirements for industrial control systems increasingly sit alongside safety requirements, owned by a different team and tracked in a different place.
Variants multiply the work. A machine family with options and configurations means the same safety argument has to be maintained across derivatives without copying it by hand each time.
Model your own safety lifecycle. Hazards, safety functions, safety requirements with their SIL or performance level, design elements and verification results are item types you define and link in both directions.
Risk management in the same structure. Hazard, cause, risk control and residual risk are first class items rather than a spreadsheet beside the requirements, so a control traces to the requirement that implements it and the test that proves it.
Coverage before verification closes. See which safety requirements have no verification evidence behind them, and which controls are still unproven, while there is time to act.
Reuse across a machine family. Baseline a configuration and branch it for a derivative, keeping the trace intact instead of copying documents between projects.
Full audit history and electronic signatures. Every review, approval and version is retained against the item, which is what an assessor or a notified body asks to see.
Functional safety evidence spread across three teams and a shared drive
IEC 61508 runs a full safety lifecycle. Hazard and risk analysis, safety requirements allocation, realisation and verification each produce evidence that has to connect, and the SIL claimed for a safety function has to be traceable to the analysis behind it.
Machinery adds a parallel standard. ISO 13849 works in performance levels and ISO 12100 in risk reduction, so many machines carry both a functional safety argument and a machinery risk assessment that have to agree with one another.
The EU Machinery Regulation raises the bar. Regulation 2023/1230 applies from 20 January 2027 and brings software, cybersecurity and autonomous behaviour further into the technical file, which means more evidence and more traceability, not less.
Security has become a safety concern. IEC 62443 requirements for industrial control systems increasingly sit alongside safety requirements, owned by a different team and tracked in a different place.
Variants multiply the work. A machine family with options and configurations means the same safety argument has to be maintained across derivatives without copying it by hand each time.
One safety argument, traceable end to end
Model your own safety lifecycle. Hazards, safety functions, safety requirements with their SIL or performance level, design elements and verification results are item types you define and link in both directions.
Risk management in the same structure. Hazard, cause, risk control and residual risk are first class items rather than a spreadsheet beside the requirements, so a control traces to the requirement that implements it and the test that proves it.
Coverage before verification closes. See which safety requirements have no verification evidence behind them, and which controls are still unproven, while there is time to act.
Reuse across a machine family. Baseline a configuration and branch it for a derivative, keeping the trace intact instead of copying documents between projects.
Full audit history and electronic signatures. Every review, approval and version is retained against the item, which is what an assessor or a notified body asks to see.
Core Features
What Matrix Req does for machinery and process safety programmes.
FAQ
No. Matrix Req is configurable rather than preloaded. You define the item types, attributes, workflows and trace rules that match your safety lifecycle, usually with our team during onboarding.
If you need a tool that arrives with a machinery safety process already modelled out of the box, we will tell you honestly that we are not that tool.
No. Matrix Req records the SIL or performance level you determine and keeps it traceable to the analysis and the verification behind it.
Quantitative calculation of failure rates, diagnostic coverage and architectural constraints belongs in a dedicated functional safety calculation tool. Use that for the numbers and Matrix Req for the requirement, risk and evidence chain.
It helps with the evidence, not the interpretation. Regulation 2023/1230 applies from 20 January 2027 and widens what the technical file has to cover, including software and cybersecurity aspects.
Matrix Req holds requirements, risk records, verification results and the trace between them, which is most of what a technical file is assembled from. What the regulation requires of your specific machine remains your regulatory assessment to make.
Yes. IEC 62443 security requirements can be an item type alongside functional safety requirements, traced to the same system and to their own verification evidence.
Keeping them in one structure is usually the point, because the two arguments have to stay consistent with each other as the design changes.
Not in numbers we would point at, and we would rather be straight about that. Matrix Req's customer base is concentrated in regulated product development in life sciences.
The mechanics the platform provides, configurable item types, bidirectional traceability, risk records, coverage analysis and audit history, are not sector specific. IEC 61508 is the parent standard that both the medical and automotive functional safety standards derive from, so the evidence logic is familiar ground for us. If you are evaluating us early, we will be clear about what is proven and what is not.