There is No One-Size Fits All Approach to the CyberPhysicalHuman World

January 19, 2016
CyberPhysicalHuman: Post by Peter Sheingold, Bob Martin, Chris Folk, Emily Frye, and Bobbie Stempfley
CyberPhysicalHuman Authors

In our previous article we talked about the need, in a CyberPhysicalHuman world, to take an integrated and holistic approach to understanding risk that incorporates elements from both the digital world—confidentiality, availability, and integrity—and the physical world—safety and reliability. We then talked about how assurance, or the confidence that a device or system will perform as intended based on some level of evidence, can help us tie these different elements together. Today, we will explore the concept of assurance in more detail.

Many Devices, Many Intended Uses, Many Levels of Risk

The CyberPhysicalHuman world will contain countless devices, systems, applications, and services. Based on their differing functions and uses, they are not equally likely to put human safety or essential mission functions of critical infrastructure at risk.

To illustrate this, consider two examples related to food.

You can use a mobile phone application to identify nearby restaurants and submit an online food order. While there is risk to your privacy if the application is compromised, there is less risk that this compromised application could lead to food contamination. Contrast this with a computer-controlled refrigerated shipping container used to transport food. Compromise of the temperature, humidity, and other container conditions could potentially cause the container conditions to deviate from safe levels, leading to food contamination, potentially putting the safety of many people at risk.

As these two examples demonstrate, we do not need identical assurance regimens for all devices as their intended function, use, and associated risk will vary. Risk management approaches should align to specific risks associated with intended functions of specific devices or device categories, not a general risk associated with all possible devices.

Therefore, assurance norms should be established for related communities of devices or systems, with more rigorous norms for communities of devices or systems whose function have the potential to put human safety or essential mission function at risk. By way of example, how would you array the functions on the board below? Consider the level of assurance that associated CyberPhysicalHuman devices would require relative to their risk to human safety or mission function of critical infrastructure. Would you place a function differently based on situational context? For example, what level of assurance should a self-driving vehicle have if it is being used to transport a cabinet secretary? Drop us a note and let us know what you came up with.

Regardless of who develops the assurance norms, once the norms have been developed and validated, they can help support a level playing field where designers and developers within a community of device or systems could have a common understanding about the level of assurance their device or service would be expected to achieve.

Demonstrating Safety of CyberPhysicalHuman Devices Through Safety Cases

Let's assume that appropriate assurance standards can be created for CyberPhysicalHuman devices and systems that are likely to put human safety or mission critical functions at risk. How can designers and developers demonstrate the safety of these devices and systems?

Given the unanticipated behaviors of highly interconnected and interdependent CyberPhysicalHuman systems and devices, it might be overly expensive or impractical to formally model all possible risks to them. In part because of this challenge, several industries (e.g. nuclear, rail, defense, aerospace) throughout the world who must account for physical safety have adopted the use of Safety Cases as a way for system designers and developers to clearly present a structured, evidence-based, defensible argument that a system is safe to operate.

Safety Cases are not typically intended to respond to an externally prescribed safety solution; rather, they demonstrate how a system can reasonably be expected to meet an external safety goal. Safety Cases can be used with diverse stakeholders to clarify requirements and tradeoffs, and can be developed as part of the device design and development process, rather than as after-the-fact artifact. Once completed, the Safety Case can serve as the basis for external review, testing, and clear communication to the end user about the relative expected safety of a device.

In recent years, the fundamental rationale and approach behind Safety Cases has started to influence the world of software through Assurance Cases. The FDA's recent guidance to industry about the design of new infusion pumps provides an example of this approach in action. Infusion pumps are used to pump fluids into patients in a controlled manner and may be networked to other devices. The FDA asked manufacturers of new infusion pumps to provide a Safety Assurance Case to demonstrate, in part, that their particular device could address a common set of hazards relevant to all infusion pumps.

Making Assurance Clear and Understandable to the User

For some products, it is reasonably straightforward for the public to understand the product's safety and reliability and maybe even learn how the product was tested. Have you ever purchased a life jacket? We have, and none of us is interested in becoming a life jacket expert. All we want is to be confident that our life jackets will keep us afloat in the water should an emergency occur.

Fortunately, we only need to know how to read. When we purchased our life jackets we read the labels to understand what type of conditions (e.g., rough open water, calm inland water) were appropriate for each type of jacket. More importantly, we looked for a United States Coast Guard approval label which signaled that the jacket had been independently tested against a set of related safety criteria. As users, we felt informed to make a choice appropriate to the risk we were willing to take and based on a transparent level of assurance that the manufacturers produced a safe product.

This life jacket example demonstrates how assurance, which can seem like a very technical concept in a very technical field, can be done in a way that actually informs and empowers users. In fact, during 2014 the Coast Guard published a regulation intended to facilitate future adoption of new labeling standards. The new labeling standards are intended to even more effectively communicate safety information about life-jackets and all personal floatation devices (PFDs) to consumers. Similarly, when purchasing a CyberPhysicalHuman product, its label should clearly communicate in what situations it can be safely used and that it has been appropriately tested.

We hope you have enjoyed these additional articles about the CyberPhysicalHuman world. What steps are you taking? What are you thinking about? Let us know. We look forward to talking with you about it.

  1. The CyberPhysicalHuman World of Homeland Security
  2. Convergence: A Recent History
  3. Risk: Focus On Your Main Thing(s)
  4. Applying Ancient Wisdom to Help Manage Modern Risks
  5. Resilience Is a Team Sport
  6. Resilience, Moving Beyond Sectors
  7. Enabling Effective Collaboration with Shared Threat Information
  8. Wrapping It Up and Moving Forward
  9. Coming Closer and Closer to You
  10. More Ancient Wisdom for Today's CyberPhysicalHuman World
  11. There is No One-Size Fits All Approach to the CyberPhysicalHuman World