About IEC 62368 Standard Introduction

Today, products reach the market equiped with different (communication) technologies. Checking whether those technologies and software are compliant and safe was unimaginable just 10 years ago.

Besides the fact that you might not need your smoke detector to start a conversation with you while you are at work, equipping traditional appliances with wireless tech or software has an effect on how product safety is assessed.

To explain that, let's take a look at product safety first. In general, we define safety as 'freedom from unacceptable risk' for people and for the environment.

Testing the safety of your products means you protect the people who use them and the environment in which it is used from any harm, like electric shock, fire, electromagnetic fields, and other harmful energy sources. Many traditional product safety standards set, separately, the requirements to prevent these types of hazards from happening.

For product safety, when audio, video, or information and communication technologies come into play a different, new standard applies: IEC 62368. This comprehensive standard is meant to be future-proof, because it is based on the principles of hazard based safety engineering, which is a different way of developing and specifying safety considerations than that of the current practice.

IEC 62368

IEC 62368 is an entirely new product safety concept: it isn't a merger of existing standards, but it does cover the older standards IEC 60065 and IEC 60950, which will be replaced in due time.

IEC 62368 supports the convergence of technologies and newer state-of-the-art tech. It is based on sound engineering principles, research, and field data. It takes a proactive risk-based approach by identifying hazards and testing the effectiveness of the safeguards instead of a reactive incident-based perspective (something went wrong) and is based on performance testing.

While the standard is different from traditional IEC safety standards in its approach, it provides a number of advantages useful to simplify problems created by the merging of different technologies we see in:

• The design of the electronic equipment

• The ecosystem (the connection to other systems)

• The installation and use of the equipment

• The system itself (its topology and configuration, for example)

Even though the adopted European version of the IEC 62368, the EN 62368-1 has been around since 2014, the date of withdrawal for the EN 60065 and EN 60950 is currently set for June 20, 2019. However, the European committee for electro technical standardization (CENELEC) recently agreed on a new date, December 2020, which is currently awaiting publication in the Official Journal of the European Union (OJEU). It means that EN 62368 will become mandatory under the requirements of the LVD and the RED.

The IEC 62368 safety standard makes your product future proof ensuring that all the possible hazards coming from the product have been taken into account. The scope of the standard excludes functional safety aspects, so where functional safety comes in other standards in addition apply.

Basic vs. functional safety

With the incorporation of different technologies, like the software in the smoke detector, products today are not just dependent on their physical components to work, but also on their software.

The safety of products goes beyond the physical layer, as mishaps in software performance can cause serious safety risks. In essence, this means that there are now two types of safety: basic safety and something we call functional safety.

Basic safety is what we define as freedom from unacceptable risk caused by physical hazards (fire, electric shock, environmental damage) as a result of a product's physical construction or design.

So, for a smoke detector to work, it needs to be designed and constructed in such a way that it monitors smoke when it rises up against the ceiling without it, for example, catching fire or falling apart. That's what it's for.

However, what if that new software on the smoke detector stalls or crashes? That could seriously hinder its functioning, since it might turn off, rendering it useless when there is a fire in the house.

Even though the software does not seem to add much to the basic functionalities of the smoke detector at first glance, it can seriously hinder its operation, because it has become a safety-related application.

Freedom from unacceptable risk?

A door lock on your oven that allows the oven door to open or close based on a temperature sensor inside and where correct functioning is based on programmable electronics, is also a functional safety application.

What if the software crashes, your oven doesn’t open anymore, and your turkey is reduced to ashes, or worse, fire, causing your oven to go up in flames (and possibly your kitchen, because your smoke detector wasn't working, remember)?

That is what we call functional safety: freedom from unacceptable risk caused by physical hazards that depends on a (programmable) electronic safety-related function.

In other words: how safe is a product when something fails? In this respect, we see that traditional product safety is moving from a focus on the hardware to a focus on the (embedded) software.

Safety standards that include requirements for functional safety such as IEC 60730 ANNEX H (electronic controls for household use) were developed to cater to the need of electronics that increasingly perform safety-related functions, like the lock on your oven door.

The mother standard of functional safety requirements is the IEC 61508 which provides the framework for many sector and application-specific functional safety standards.