We hear the word "resilience" a lot these days. It's a word that's ripe for misuse and vagueness.
There
is a general agreement that resilience is the intrinsic ability of a system to
resist disturbances. Another equivalent definition
of resilience is the ability to provide required capability in
the face of adversity (sometimes referred to as disaster recovery). Resilient design is about managing the ubiquitous
uncertainties that constrain current design practices as well as finding ways to
overcome an imperfect understanding of system requirements that lead to fragile
and ineffectual system designs.
The definitions above are fine, but the real question is what is the “scope” of the
system – and this is where views vary. In this blog we focus on electronic products and systems, however, the concepts of resilience and resilient design are more prevalent in the building construction, architecture, and communities design space.
When you talk about resilient systems, several disciplines
think they have a handle on the problem.
The control systems folks think that this is their domain, the
optimization folks, the PHM (system health management) folks, the reliability
engineering folks, sustainability folks, the system engineering folks, machine
learning, artificial intelligence, … In my experience, none of these disciplines
(with the possible exception of some system engineers) really grasps the total scope
of resilience. Every discipline wants to
gather resilience under their umbrella and grant themselves ownership of the
problem space based on their narrowed definition of what a system is.
In
my opinion, designing resilient hardware and software (which is the focus of
most resilient system design activities) is necessary but not sufficient for creating
resilient systems. For a system to be
resilient requires:
- reliable (or self-managing) hardware and software
- a resilient logistics plan (including supply chain and workforce management)
- a resilient contract structure
- resilient legislation or governance (rules, laws, policy)
- a resilient business model
One might also include within all of the above aspects, a resilience to changes in the end-of-support for the system. For many systems, the end-of-support is a moving target that is extended ("life extensions") during the use of the system.
This represents a somewhat broader scope than what is generally articulated in the engineering literature, however, in practice, neglecting any of these elements potentially creates a legacy system with substantial (and potentially untenable) life-cycle support costs.
Although the discussion in this blog has an electronic product/system focus (our "scope"). Resilient design can certainly be applied to other things, e.g., buildings, communities, furniture, information technology, websites, health care, etc. In this broader world one could consider adding the following to the bullets above:
This represents a somewhat broader scope than what is generally articulated in the engineering literature, however, in practice, neglecting any of these elements potentially creates a legacy system with substantial (and potentially untenable) life-cycle support costs.
Although the discussion in this blog has an electronic product/system focus (our "scope"). Resilient design can certainly be applied to other things, e.g., buildings, communities, furniture, information technology, websites, health care, etc. In this broader world one could consider adding the following to the bullets above:
- culturally resilient (does the system transcend cultures and culture changes)
- environmental resilience (sustainability)
- resilience to climate change
