Embedded Systems & ISO 13849: Electronics by Recipe?

Recently, we received a customer inquiry with an idea that seemed straightforward at first glance: several older or already ported embedded systems should be reused in a machine and enhanced with additional safety hardware according to DIN EN ISO 13849 to be supplemented. Therefore, the existing electronics should not be completely redeveloped. Instead, a new circuit board should redundantly read safety-related signals, monitor states, and control defined shutdown paths. Is this a viable approach? Let's take a look.

Basic Idea Embedded Systems & ISO 13849

The idea is understandable: Existing embedded systems continue to handle their operational and process functions. An additional safety board takes care of safety-related functions. This allows a machine to be technically upgraded without having to completely rebuild all existing control components.

Specifically looking at older machines, ported Controls and new regulatory requirements make this approach interesting. If existing embedded systems are not considered safety-relevant instances but are supplemented by a separate safety architecture, ISO 13849 can fundamentally be a suitable framework. The standard allows for a function-related consideration: What safety function is needed? What performance level is required? What sensors, logic, and actuators are involved? What category is aimed for?

This initially creates a plausible concept: legacy controls remain responsible for operation and the actual machine function, while new safety-related electronics take over the actual safety functions.

However, the critical point lies in implementation. This is because a safety function that seems trivial at the machine level – for example, reading input, evaluating state, switching off output – quickly becomes complex in embedded electronics. As soon as a Microcontroller The microcontroller that makes the safety-related decision must also be monitored. What appears to be a simple on/off function becomes a safety-related computing platform with core safety, diagnostics, validation, and documentation requirements. That sounds expensive.

Can a machine be brought to a safety level using discrete electronics and ISO 13849?

Basically, yes.

A machine can be enhanced with safety-related control functions through the addition of embedded electronics. This is particularly relevant for existing machines that already have legacy embedded systems developed according to earlier requirements. In light of the new Machinery Directive, such machines are coming into sharper focus: existing controls, existing mechanics, existing actuators—but new requirements for verification, state of the art, and functional safety.

A typical scenario involves an additional safety board that reads inputs redundantly, validates states, performs diagnostic functions, and activates defined shutdown sequences. The existing machine control system remains responsible for operational functions. However, the new safety logic takes over the safety-related functions.

Example:

A machine is equipped with an existing embedded controller. This controller remains unchanged and continues to execute the process logic. In addition, a safety board is integrated that reads safety doors, limit switches, enable signals, or speed signals via two channels. In the event of a deviation, a diagnostic error, or an open safety device, this board activates safe shutdown paths via redundant outputs, such as contactors, STO inputs, or valves.

From the perspective of ISO 13849, this is generally a reasonable approach. The key factor is that the safety concept is sound: What safety functions are required? What performance level is required? What sensors, logic, and actuators are associated with each safety function? What category is being targeted? How are MTTF_D, Washington D.C. and CCF? How is validation performed?

ISO 13849 is well-suited here as a machine-oriented assessment framework. The standard does not work abstractly at the product level but is function-oriented: define the safety function, determine the required performance level, design the architecture, evaluate diagnostics, and perform validation.

ISO 13849 as „Safety by Recipe“?

ISO 13849 is often viewed in the mechanical engineering industry as a relatively pragmatic approach to functional safety. That’s not entirely wrong. This is appealing to machine integrators because many safety functions can be built using familiar components.

In this sense, ISO 13849 is more like a recipe than IEC 61508. The standard describes a method for assessing and validating safety-related parts of control systems. This is particularly attractive for retrofits or expansions of existing machines because the scope can be limited. The entire machine does not have to be redesigned. Instead, specific safety functions are considered.

However, this shortens the development process only under certain conditions.

The advantage lies not in making.

It is worth taking a look at the declarations of conformity or type examination certificates for the relevant components:

The "forward-looking argument" applies here„: Since IEC 61508 sets higher or equivalent requirements for hardware fault tolerance and software lifecycles across all industries, it stands to reason that the device also meets the criteria for the Performance Level (PL).

When developing your own complex embedded electronics, this almost always entails the development and verification work required by IEC 61508.

The security feature is trivial. The secure execution platform is not.

Many safety features look simple at the machine level:

• Safety door open → Machine stops.
• Non-halt activated → Power is shut off.
• Limit exceeded → Movement is stopped.
• Authorization missing → Drive remains locked.

In discrete or electromechanical systems, such a function can be implemented relatively straightforwardly. In an MCU-based solution, the complexity shifts to the electronics and software. This is because the microcontroller is not merely a passive signal path; it is the component that makes the decisions.

A safety-critical embedded system must therefore not only provide redundant input channels and shut down outputs; it must also monitor its own computing platform. Here are a few examples:

• CPU and core monitoring,
• Watchdog concept,
• Clock and PLL monitoring,
• Monitoring of the interrupt controller and NVIC,
• Program Flow Monitoring,
• Stack and memory monitoring,
• RAM tests,
• Flash tests and CRC checks,
• Register and CPU self-tests,
• Brown-out and voltage monitoring,
• Reset concept,
• secure initialization,
• Perimeter monitoring,
• GPIO and ADC plausibility check,
• Fault reaction and safe state.

This is the part that is often not visible from the outside. The customer sees inputs, outputs, and shutdowns. In reality, however, one develops a safety-related computing platform with core safety, diagnostic mechanisms, and documented error response.

One example is functional safety libraries from microcontroller manufacturers. ST, for instance, offers Functional Safety Libraries for STM32 which, among other things, provide mechanisms for monitoring and testing the CPU, memory, clock system, interrupt structures such as the NVIC, and other safety-relevant MCU functions. MCU manufacturers typically protect themselves through safety manuals, stating that certain development steps are necessary to achieve a SIL level.

The key point here is always this: An application cannot simply assume that a microcontroller is functioning correctly. It must define measures to detect or control errors. This is precisely why the effort involved in developing custom embedded electronics increases rapidly, even if the actual machine function appears simple.

The Safety Manual as a Central Link

In safety-related electronics, the Safety Manual becomes an important document. It describes the assumptions under which a component or platform may be used in a safety function.

A safety manual typically contains information about:

• permissible operating conditions,
• Assumptions for system integration,
• Diagnostic mechanisms,
• necessary external measures,
• Error responses,
• Limitations of Use,
• security-relevant configuration settings,
• known limitations,
• Assumptions about clock, supply, reset, watchdog, and peripherals,
• Notes on FMEDA, FIT values, or Failure Modes.
• And especially: Software requirements during operation and initialization

For purchased safety components, the safety manual is often the basis for integration into a machine. For in-house embedded electronics, a comparable justification must be created. It is then not enough to develop a circuit board and subsequently calculate a PL. It must be described how this circuit board may be used in a safety-related context, what assumptions apply, and what measures are absolutely necessary.

The Safety Manual thus connects product development and machine integration. It doesn't automatically turn an electronic component into a safe one, but it documents the conditions under which it can be used in a safety function.

This is particularly crucial for reusable safety control boards. A control board designed to perform safety functions in multiple machines requires clear integration boundaries. Which inputs may be used for which signals? Which output paths are suitable for which shutdown functions? Which diagnostics must be enabled? Which errors lead to shutdown? Which external tests are necessary? What response times apply? What assumptions have been made regarding the environment, wiring, and maintenance?

Validation according to ISO 13849-2: The underestimated effort

With a view of the machine, ISO 13849-2 can be used. It must show that the safety-related parts of the control system meet the specified requirements. This involves slightly less documentation effort compared to IEC 61508, but a large number of procedural evidences still remain.

This includes, in particular:

• Validation of security functions,
• Validation of performance levels and categories,
• Validation of category definitions,
• Validation of MTTF_D, DC, and CCF,
• Validation of measures to prevent systematic failures,
• Validation of safety-related software,
• Verification and validation of the achieved performance level,
• Environmental requirements validation,
• Validation of maintenance requirements,
• Validation of technical documentation and user information.

For safe embedded electronics, the entire process of IEC 61508 can actually be outlined: It requires specifications, architecture, tests, and evidence. The safety function must be specified. The hardware must be specified. The hardware architecture must be traceable. The software must be described.

For more complex systems, software architecture and module specifications are required. Tests must be planned, executed, and documented.

Typical evidence includes:

• Software module tests,
• Software integration tests,
• Comprehensive hardware and software tests,
• Functional tests,
• Failure analyses,
• Tests of the diagnostic mechanisms,
• Failure reaction tests,
• Safe state testing,
• Restart condition tests,
• Test reports,
• Validation Report.

This brings the practice closely in line with what is known from IEC 61508 or IEC 62061. Sometimes, overall validation and similar processes are reduced because it can be argued that they take place during overall integration. Thus, standalone certification of individual electronics may be omitted. However, IEC 61508 must be applied mandatorily.

But the last word always goes to the Notified Body. Even though ISO 13849 seems more pragmatic at the machine level, a complete development and verification process arises with complex embedded electronics.

ISO 13849, IEC 62061, and IEC 61508: What's the difference?

ISO 13849, IEC 62061, and IEC 61508 are compatible in many respects, but they have different focuses.

ISO 13849 is machine-oriented and technology-neutral. It can consider electrical, electronic, mechanical, hydraulic, and pneumatic components in safety-related control parts. The evaluation is performed via Performance Level.

IEC 62061 is more strongly oriented towards electrical, electronic and programmable electronic control systems in mechanical engineering. Assessment is carried out via SIL.

IEC 61508 is the generic basic standard for the functional safety of E/E/PE systems. It provides a more comprehensive view of the safety lifecycle and is particularly relevant when reusable safety electronics or safety platforms are to be developed.

For the specific machine, ISO 13849 can be very suitable. However, for the development of a complex embedded safety board, an IEC 61508-oriented approach might be cleaner, even if the later machine integration is performed according to ISO 13849 or IEC 62061.

This leads to an important distinction:

• When concrete safety functions are added to an existing machine, ISO 13849 is often the obvious framework.
• When reusable safety electronics are developed for use in different machines, development should be more aligned with IEC 61508.
• When a machine with E/E/PE safety functions is to be considered holistically via SIL, IEC 62061 is the obvious choice.

In practice, these approaches can be combined. Safety-related parts of a machine control system can be assessed according to ISO 13849 and at the same time include components developed according to IEC 61508 or IEC 62061.

For the described use case, the described approach from ISO 13489 and IEC 61508 is therefore applicable to the overall electronics

ISO 13849 under the Machinery Directive

The Machinery Regulation (Regulation (EU) 2023/1230) will be binding in the European Union from 2027 and will replace the previous Machinery Directive. For manufacturers, operators, and integrators, this means: safety functions, software, safety components, and technical documentation will come under greater scrutiny.

ISO 13849 is harmonized under the Machinery Directive. Harmonization under the Machinery Regulation is considered likely. For practical purposes, the standard thus remains an important way to design and validate safety-related control parts of machines in a verifiable manner.

This creates a typical use case for legacy machines: existing machine controls can continue to be used if they are not considered safety-relevant. Safety functions are supplemented by additional hardware, safety sensors, safe shutdown paths, and a documented safety concept.

This is not a retroactive legalization of unsafe technology. It is a technical and normative decoupling: The existing control remains process control. The new safety architecture assumes the safety functions.

Conclusion

ISO 13849 is a suitable framework for enabling machines through additional safety functions. The safety function itself may seem very simple. However, technically, a safety-related computing platform is created.

For individual electronics, the principles of IEC 61508 must apply. The microcontroller must be monitored. Memory, clock, interrupts, program execution, supply, and peripherals must be considered. Functional safety libraries can provide support in this, but they do not replace the safety concept, safety manual, validation, and system proof.

Standalone certification of individual electronics is not mandatory if the electronics are assessed exclusively within the context of the specific machine and validated as part of the safety-related control system according to ISO 13849. Safety is then demonstrated not as an isolated product characteristic of the circuit board, but within the respective safety function of the machine.

However, this does not reduce the technical requirements for development. For complex embedded electronics, the development process must still incorporate the mindset of functional safety: systematic error prevention, diagnostic concept, safe error reaction, software architecture, testing, change management, technical documentation, and safety manual. An IEC 61508-oriented development can be the more sensible internal benchmark for this, even if the formal machine approval is obtained via ISO 13849.

In short: ISO 13849 can provide the proof framework for the machine. Individual electronics do not necessarily have to be certified independently. However, they should still be developed with the discipline of safety electronics.