Hazard Source Separation in Software Design─Why Prioritizing Safety is Essential
Introduction
When working as an engineer, the most paramount priority at all times is the assurance of “safety.” To achieve this, what is particularly important is “hazard source separation” during the architecture design phase. However, why is this hazard source separation necessary? And how should hazard sources be separated? This article provides a detailed explanation of these fundamental questions.
Why Hazard Source Separation is Necessary
Numerous software systems exist in our society, and some of these systems directly involve matters of life and death. Examples include autonomous vehicles, medical devices, and control systems for nuclear power plants. For these systems, it is required that even if some functions fail, such failures do not affect other critical functions, thereby maintaining the safety and integrity of the overall system.
This requirement is emphasized in various regulatory frameworks and international standards, including the quality management system specified in ISO 13485 (Medical Device Quality Management Systems), IEC 62304 (Software Lifecycle Process for Medical Device Software), and the U.S. FDA (Food and Drug Administration) Software Validation Guidance. Hazard source separation is also an important means of ensuring functional safety, as required by IEC 61508 (Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems) at the system design phase through hazard analysis and separation.
By effectively separating hazard sources and maintaining their independence, failures in one module can be prevented from cascading to other critical functions, enabling the achievement of a high level of overall safety. This is not merely a technical choice but rather a regulatory obligation imposed on organizations.
Hazard Source Separation by Safety Class
Definition and Classification of Safety Classes
A safety class is a classification system determined based on risk assessment and serves as an indicator of the magnitude of risk. International Standard IEC 62304 commonly divides medical device software into three classes: “Class A,” “Class B,” and “Class C.” “Class A” refers to the lowest-risk module, while “Class C” refers to the highest-risk module.
More specifically, IEC 62304 provides the following criteria for class assignment. Class C applies when a software failure could potentially result in serious injury or death to a patient—that is, when the severity of harm is high and the probability of occurrence is not negligible. Class B applies when a software failure could potentially result in non-serious injury to a patient, or when the severity of harm is high but the probability of occurrence is low. Class A applies when a software failure is unlikely to result in harm to the patient.
Hazard Source Separation Process
When implementing hazard source separation, it is important to separate modules according to safety class rather than by grouping similar functions together. From an implementation perspective, the procedure involves first separating the lowest-risk “Class A” modules, followed by the separation of “Class B” modules. By doing so, only the high-risk “Class C” modules remain, allowing for concentrated management of these critical components.
This separation process aligns with the software design specifications defined in IEC 62304 and is consistent with related international standards in IEC 61508. Regulatory authorities including the European Union Medical Device Regulation (MDR), the U.S. FDA, and Japan’s PMDA (Pharmaceuticals and Medical Devices Agency) all require the assurance of safety through such hierarchical approaches.
Practical Application Example
Consider the design of an autonomous vehicle as a concrete example. Classify “Class A” modules to include user interface-related functions such as “radio function” and “seat heater function,” “Class B” modules to include important monitoring functions such as “collision warning alert function” and “anomaly diagnosis function,” and “Class C” modules to include mission-critical functions such as “autonomous driving control function” and “brake system control.”
Should the radio function fail for any reason, the impact remains confined to the radio function alone, and other modules continue to operate independently. If each function is designed at the design phase to be independent of other functions, a failure in one function will not jeopardize the overall safety of the system. This design approach is equally important in the field of medical devices. For example, in a medical imaging diagnosis apparatus, by designing the image display function, signal processing function, and safety control function as independent modules, the impact of partial failures on diagnostic accuracy and patient safety can be minimized.
Regulatory Environment and Application to Organizational Design
Latest Regulatory Requirements and Industry Trends
From 2024 through 2025, regulatory requirements pertaining to medical devices and software are being strengthened at an accelerating pace. These developments include the strengthening of cybersecurity requirements under the European Union Medical Device Regulation (MDR), the issuance of FDA Computer Software Assurance guidance (CSA), and the full implementation of Japan’s PMDA transparency information disclosure system for medical devices. These evolving regulatory environments all emphasize the critical importance of multilayered safety assurance across organizations.
In relation to organizational restructuring, when organizations transition from traditional hierarchical structures to functional structures, hazard source separation becomes applicable not only as a software design technique but also as a fundamental principle in organizational design and management.
Application to Organizational Design
Specifically, separation by safety class becomes important in constructing organizational structures. Organizations must identify high-risk “Class C” components and establish appropriate organizational systems to manage them. In other words, hazard source separation is not merely one aspect of software design but rather a fundamental principle applicable across organizational design and management as a whole.
The goal is to ensure that individual modules and organizational units are not excessively interdependent while maintaining overall functionality. Achieving this balance represents the true meaning of “safety” as brought about by the principle of hazard source separation, and it is an emphasis that is reinforced in quality management systems.
Conclusion
Hazard source separation is not merely an aspect of software design but rather an important perspective for maintaining the safety of the entire organization. International standards, regulatory requirements across regions, and contemporary best practices in the medical device and software industries all emphasize the importance of this principle. For engineers today, the implementation and management of hazard source separation, including an understanding of the regulatory environment, represents an essential skill and responsibility.
