Emerging Trends in Smart Device Safety: Adapting IEC 62368 for IoT Products

Emerging Trends in Smart Device Safety: Adapting IEC 62368 for IoT Products

Introduction

The Internet of Things (IoT) is no longer a futuristic concept; it is the fabric of modern life and industry. From smart speakers and connected thermostats to industrial sensors and medical wearables, billions of devices are constantly collecting, transmitting, and acting on data. This hyper-connectivity, however, introduces a complex web of safety risks that traditional product safety standards were never designed to handle.

For decades, the electronics industry relied on standards like IEC 60950-1 for IT equipment and IEC 60065 for audio/video gear. These prescriptive standards were excellent for their time but operated on a fundamental principle: defining specific requirements to prevent historically known hazards. They were reactive, not proactive.

The new benchmark, IEC 62368-1, represents a paradigm shift. It is a hazard-based safety engineering (HBSE) standard, originally conceived for audio/video, information, and communication technology equipment. But its core principles make it uniquely adaptable to the novel and evolving risks presented by IoT products.

This article delves into the critical emerging trends in smart device safety and provides a practical framework for adapting the forward-thinking principles of IEC 62368-1 to ensure the safety and reliability of IoT products in an interconnected world.

Understanding the Fundamental Shift: From Prescriptive to Hazard-Based

To appreciate why IEC 62368-1 is suited for IoT, one must first understand its philosophy.

Prescriptive Standards (IEC 60950-1/60065): These standards function like a detailed recipe. They state: "Use a component with a 5mm creepage distance here," or "Install a fuse of this specific rating there." They are based on past failures and are excellent for well-understood product categories. However, they struggle with innovation. What happens when a new technology or use case emerges that the standard's writers didn't anticipate?

Hazard-Based Safety Engineering (IEC 62368-1): This standard functions not as a recipe, but as a guidebook. It doesn't start with solutions; it starts with potential harms. The core process involves:

    1.  Identifying Energy Sources: Classifying all energy sources within the product (Electrical, Chemical, Mechanical, Thermal, Radiation).

    2.  Classifying Energy Levels: Assigning these sources to one of three classes:

        Class 1: Energy levels that are not painful or injurious. (e.g., low-voltage circuits).

        Class 2: Energy levels that can be painful but not injurious. (e.g., higher voltages that cause a shock but are not lethal).

        Class 3: Energy levels that are injurious. (e.g., hazardous voltage, high heat, large moving parts).

    3.  Applying Safeguards: Implementing measures to prevent that energy from causing harm to people. Safeguards can be:

        Primary (Instructional): Warnings and labels that tell a person how to avoid the hazard (e.g., "Do not open!").

        Secondary (Technical): Physical protective measures that prevent access to the energy without special tools (e.g., enclosures, interlocks).

        Inherent: Design measures that make the hazard impossible by nature (e.g., using safe, low-voltage power throughout).

This methodology is inherently flexible, making it perfect for the diverse and innovative world of IoT.

Why IoT Safety is a Different Beast: Beyond the Plug

IoT products introduce unique safety challenges that stretch far beyond the traditional concerns of electric shock and fire.

1.  The Convergence of Energies: An IoT device is rarely just electrical. A smart kitchen appliance combines electrical energy with thermal energy (a heating element), mechanical energy (a motor), and often chemical energy (a battery). IEC 62368-1's holistic approach to classifying all energy types is critical for evaluating such products.

2.  The Software and Connectivity Hazard: This is the most significant paradigm shift. In IoT, software and connectivity are not just features; they are potential energy sources that can create functional safety hazards.

    A corrupted firmware update could disable a thermal safeguard in a connected heater.

    A malicious cyber-attack could command a smart lock to engage while occupants are inside, creating an entrapment hazard.

    A network latency issue could delay a critical shutdown command to an industrial robot.

    IEC 62368-1, particularly in its newer editions, begins to acknowledge these risks by considering software as a safeguard. If software is controlling a Class 3 energy source, it must be developed with rigorous processes to ensure its reliability and freedom from unacceptable risk (e.g., following IEC 62304 for medical software or other best practices).

3.  Novel Use Cases and Environments: A traditional laptop is used in an office or home. An IoT device could be a wearable on a sweating athlete, a sensor on a vibrating industrial machine, or a gadget in a child's toy box. These environments introduce new stresses (moisture, impact, contamination) that can lead to unforeseen failures. The HBSE process forces designers to consider these environments during the hazard identification phase.

4.  Complex Supply Chains and Integration: Many OEMs build IoT devices using modules from multiple suppliers (Wi-Fi, Bluetooth, sensors). The safety of the final product depends on the safe interaction of these modules. A power management IC from one vendor might behave unpredictably with a communication module from another. The hazard-based approach provides a common framework for evaluating the safety of these interactions based on energy, not just on prescriptive pass/fail criteria for individual components.

5.  Product Lifespan and Security Updates: A product's safety can change over its lifespan. A vulnerability discovered after sale could turn a safe device into a hazardous one. While not explicitly covering cybersecurity, the principles of IEC 62368-1 support the need for a secure, updatable design to maintain safety safeguards throughout the product's life.

A Practical Framework: Adapting IEC 62368 for Your IoT Product

Here is a step-by-step approach to applying the standard's principles to an IoT device development cycle.

Step 1: Expanded Hazard Identification Workshop

Go beyond the standard electrical review. Assemble a cross-functional team including hardware, software, cloud, and security engineers. Brainstorm all potential energy sources and failure modes, including:

What happens if the OTA update server is compromised?

What if the device receives a malformed data packet that causes a buffer overflow and reboot loop?

What if the battery management system (BMS) software fails to terminate charging?

What if a sensor providing input to a safety-critical function is blinded or provides erroneous data?

Step 2: Classify Every Energy Source with IoT in Mind

Electrical: USB-C Power Delivery can negotiate voltages up to 48V. Is this Class 2 or 3? Classify it correctly.

Thermal: Identify all heat-generating components (processors, power amplifiers, motors) and classify their accessible surface temperatures.

Radiation: Classify lasers in lidar sensors or VCSELs in facial recognition systems.

Software/Connectivity: Treat faulty or malicious commands as an "energy" source that can lead to a hazardous situation. Classify the potential outcome.

Step 3: Design and Validate Robust Safeguards

Technical Safeguards: Use hardware interlocks for moving parts, thermal fuses as a backup to software controls, and robust enclosures to protect against ingress and physical damage.

Software Safeguards: This is critical. Implement software with integrity checks, watchdog timers, and fail-safe states. If software is the primary safeguard against a Class 3 energy source (e.g., it controls a heater), it must be developed to a high Safety Integrity Level (SIL) or similar rigor with extensive verification and validation testing.

Instructional Safeguards: Clearly warn users of risks. "Ensure software is kept up to date to maintain safety features."

Step 4: Treat Security as a Prerequisite for Safety

While IEC 62368 is not a cybersecurity standard, safety is contingent on security for IoT.

Implement secure boot to prevent unauthorized firmware from running.

Use encrypted and authenticated communications for all OTA updates and critical commands.

Conduct penetration testing to identify and remediate vulnerabilities that could be exploited to create a safety hazard.

Adopt a secure development lifecycle (e.g., Microsoft SDL, OWASP SAMM).

Step 5: Documentation and Compliance

The hazard-based approach requires thorough documentation. Your technical construction file (TCF) must tell the story of your safety analysis:

Hazard Identification records.

Energy classifications.

Rationale for why chosen safeguards are effective.

Evidence of testing for all safeguards, including software and system-level tests.

The Future is Adaptive: Staying Ahead of the Curve

The standards themselves are evolving. IEC 62368-3 is in development, specifically aimed at aspects of IoT and edge equipment. Furthermore, other standards like UL 4600 for autonomous vehicles are pushing the boundaries of evaluating safety in complex, adaptive systems.

The key takeaway for IoT developers is that a checklist mentality is obsolete. Adopting the hazard-based engineering philosophy of IEC 62368-1 is not just about passing certification; it is about building a culture of safety that is as innovative and resilient as the products themselves. It is the most effective way to navigate the unknown hazards of tomorrow and ensure that the smart devices we come to rely on are not only intelligent but also inherently safe.

FAQ Section

Q: My IoT device is low-voltage and battery-powered. Does IEC 62368-1 still apply?

A: Absolutely. While the electrical shock risk might be low (Class 1 or 2), other hazards like fire from a lithium-ion battery, burns from a hot surface, or mechanical hazards from moving parts must be evaluated. The software and security-related hazards are also critically important.

Q: How does IEC 62368-1 relate to cybersecurity standards like IEC 62443?

A: They are complementary. IEC 62368-1 considers security as a means to ensure functional safety safeguards remain effective. IEC 62443 provides the detailed technical requirements for achieving security in industrial automation and control systems. For a comprehensive approach, an IoT product may need to demonstrate compliance with both, using IEC 62443 processes to fulfill the security aspects required to support safety safeguards in IEC 62368.

Q: Who is responsible for safety in a cloud-connected device: the device maker or the cloud service provider?

A: This is a complex question. The responsibility is shared. The device manufacturer is responsible for the safety of the physical product, including its response to lost connectivity or malicious commands. They must define the safety requirements for the cloud-to-device interface. The cloud service provider is then responsible for ensuring their service meets those security and reliability requirements. This should be formalized in a partnership agreement.

Q: Is compliance with IEC 62368-1 legally mandatory?

A: It has become the required standard in many regions under the CB Scheme and national regulations (e.g., it replaced IEC 60950-1 and 60065 in the EU and US). For any product falling within its scope, which broadly includes ICT and AV equipment—a category many IoT devices fit into—compliance is effectively mandatory for market access.