PaperlayerView exact revision on arXiv

Source-linked AI summary

A Roadmap Towards Resilient Internet of Things for Cyber-Physical Systems

Denise Ratasich, Faiq Khalid, Florian Geissler, Radu Grosu, Muhammad Shafique, Ezio Bartocci

arXiv:1810.06870v2cs.ETcs.LGcs.NI

TL;DR

Connected CPS face intertwined dependability and security concerns, while real-time operation, resource limits, and runtime verification constrain resilience approaches. The paper surveys runtime resilience methods, presents a roadmap and automotive case study, and reports that communication and power profiles can identify anomalous behavior.

  • Problem

    Connected CPS can face fatal accidents from failures or security vulnerabilities, and runtime verification of hyperproperties remains an open challenge.

    Source: §1.1 · p. 2, §4.1.2 · p. 11

  • Method

    The paper surveys runtime resilience methods and illustrates non-intrusive monitoring, redundancy-based recovery, and self-adaptation through a V2X smart-mobility case study.

    Source: §4.2.3 · p. 14, §5 · p. 15, §7 · p. 19

  • Results

    Communication behavior and power profiles in the MC8051 analyses distinguish attack-related anomalies, while the case-study approach uses redundant information to monitor, replace, or fuse information.

    Source: §7.1.3 · pp. 23–24, §8 · p. 26

  • Takeaways & Limitations

    SHSA can detect and recover permanent IoT faults when redundancy exists and failed components can be isolated and replaced by redundant information.

    Source: §8 · p. 26

    The techniques require reference behavior, shared understanding, or relevant redundancy; SHSA’s real-time suitability is conditional, scalability remains open, and device resources may be insufficient.

    Source: §8 · p. 26

Abstract

from arXiv · show

The Internet of Things (IoT) is a ubiquitous system connecting many different devices - the things - which can be accessed from the distance. The cyber-physical systems (CPS) monitor and control the things from the distance. As a result, the concepts of dependability and security get deeply intertwined. The increasing level of dynamicity, heterogeneity, and complexity adds to the system's vulnerability, and challenges its ability to react to faults. This paper summarizes state-of-the-art of existing work on anomaly detection, fault-tolerance and self-healing, and adds a number of other methods applicable to achieve resilience in an IoT. We particularly focus on non-intrusive methods ensuring data integrity in the network. Furthermore, this paper presents the main challenges in building a resilient IoT for CPS which is crucial in the era of smart CPS with enhanced connectivity (an excellent example of such a system is connected autonomous vehicles). It further summarizes our solutions, work-in-progress and future work to this topic to enable "Trustworthy IoT for CPS". Finally, this framework is illustrated on a selected use case: A smart sensor infrastructure in the transport domain.

1 Introduction

CPS connect computational entities to physical components through the IoT, making safety and security concerns increasingly consequential as connected systems grow. The paper surveys resilience methods, identifies IoT-for-CPS challenges, and presents a roadmap and automotive case study.

1 Introduction

  • CPS combine computational entities with physical components, communicating with each other and people over the IoT.Examples include UAVs, wireless sensor networks, autonomous cars, vehicular networks, and life-critical medical devices.Source: §1 · p. 1

1.1 Motivation for Resilient CPS

  • IoT growth can amplify cyberattacks: the paper cites a forecast of 75 billion devices in 2025 and the MIRAI botnet’s use of more than 400,000 devices.Failures and vulnerabilities in connected CPS can have fatal consequences, while resilience means trusted service persists amid changes and faults or threats.Source: §1.1 · p. 2

1.2 State-of-the-Art

  • Prior surveys often cover a single resilience building block or attribute, while IoT surveys had not, to the authors’ knowledge, addressed resilience, adaptation, and long-term dependability and security for CPS.The paper positions its review against this gap.Source: §1.2 · p. 3

1.3 Novel Contributions

  • The paper reviews fault detection, diagnosis, recovery, and mitigation, emphasizing non-intrusive methods for heterogeneous IoT architectures and outlining challenges, a resilience roadmap, and automotive solutions and ongoing work.Its stated focus is methods that reason and act in the communication network or at IoT-device interfaces.Source: §1.3 · p. 3

1.4 Organization of the Paper

  • The paper proceeds from resilience terminology and techniques to research challenges, a roadmap, a smart-mobility case study, and concluding discussion of solutions and future work.Sections 2–3 introduce terminology and building blocks; Section 4 surveys fault detection and recovery.Source: §1.4 · p. 3

2 Resilience

The section frames resilience as persistence of dependable service amid change. For IoT for CPS, this also requires dependability and security to scale across functional, environmental, and technological changes.

2 Resilience

  • The section presents resilience and its terminology, with system attributes related to resilience summarized in Figure 4.Dependability comprises availability, reliability, safety, integrity, and maintainability; security includes availability, integrity, and confidentiality.Source: §2 · p. 4, §2.1 · p. 4, Figure 4 · p. 4

2.1 Attributes of Resilience

  • Robustness extends dependability to continued proper functioning under stochastic faults and, in CPSoS, external faults including malicious actions.The section also describes fault tolerance as recovering from faults to ensure ongoing service.Source: §2.1 · p. 4
  • Resilience is the persistence of dependability when facing changes, defined for ubiquitous, large-scale, evolving systems.The section identifies dependability and security as desired throughout the IoT for CPS life-cycle.Source: §2.1 · pp. 4–5
  • A resilient IoT for CPS must scale dependability and security as functional, environmental, and technological conditions change.The paper calls this capability long-term dependability and security.Source: §2.1 · p. 5
  • Analyzing resilience requires considering both possible faults and available detection and mitigation methods.The section identifies these as the sources of dependability and security threats and the techniques and actions to apply.Source: §2.1 · p. 5

3 Faults, Errors, Failures and Attacks

The section distinguishes faults, errors, failures, and attacks, then surveys dependability and security threats across CPS layers. It also describes long-term changes and failure behaviors that complicate resilience.

3 Faults, Errors, Failures and Attacks

  • A fault can cause an error, which manifests as a failure when system behavior deviates from its intended behavior.Faults may be internal or external, transient or permanent; design faults are always permanent, while non-reproducible faults are intermittent and can lead to soft errors.Source: §3 · p. 5
  • CPS threats span physical, network, control, and information layers, with information particularly vulnerable to privacy and integrity issues.Figure 5 relates dependability failures and security threats to CPS layers.Source: §3 · pp. 5–6, Figure 5 · p. 6

3.1 Dependability Faults in IoT

  • IoT communication failures can arise as systems grow and evolve, including interference, collisions, protocol violations, deadline misses, and unavailability.The section also lists misusage and missing or mismatched device information among possible faults.Source: §3.1 · p. 6

3.2 Security Threats in CPS

  • Network threats include jamming via fake traffic, timing, power, or frequency manipulation that triggers metastable states leading to data collision or protocol violations, and routing manipulation causing data collision, flooding, or selective forwarding.Source: §3.2 · p. 7
  • A CPS threat model identifies its source or attacker, attack methodology, and consequences or payload [38].Possible consequences include compromised confidentiality, integrity, availability, privacy, or safety, as well as information theft [85] [86].Source: §3.2 · p. 7

3.3 Long-term Dependability and Security Threats

  • Long-term operation exposes IoT and CPS to environmental, functional, and technological changes that might trigger faults.Examples include material aging, changing applications or connected devices, component and protocol changes, and unknown attacks such as zero-day malware.Source: §3.3 · p. 8

3.4 Fault Behavior

  • Failures can involve wrong or mistimed service; fail-silent components suppress wrong outputs, fail-stop components halt, and erratic or Byzantine behavior can propagate failures.Byzantine behavior means outputs are inconsistent to different observers.Source: §3.4 · p. 8

4 Techniques for Resilient IoT for CPS

The section focuses on runtime approaches that detect and identify faulty, attacked, or failed components and autonomously maintain resilience. Its overview organizes prior methods around detection and diagnosis, and recovery or mitigation.

4 Techniques for Resilient IoT for CPS

  • Runtime detection and identification of faulty, attacked, or failed components is intended to support maintaining or recovering a healthy system state and correct services.This is requirement R1.Source: §4 · p. 8
  • Autonomous resilience requires maintaining functionality in dynamic, heterogeneous systems and recovering from failures automatically.This is requirement R2.Source: §4 · p. 8
  • The overview organizes methods into detection and diagnosis, and recovery or mitigation, covering surveys, recent approaches, and examples.The collection and distribution of work is summarized in Table 6.Source: §4 · p. 8, Table 6 · p. 9

4.1 Detection and Diagnosis

Detection and diagnosis identify abnormal behavior and relate it to faults, using behavioral comparisons and methods that range from formal specifications to learned models and data instances.

4.1 Detection and Diagnosis

  • Fault detection compares observed behavior with a specification, model, or replica, while root-cause analysis seeks the reason a fault occurred.Expected or faulty behavior may be represented by formal specifications, attack signatures, learned models, clusters, or data instances.Source: §4.1 · p. 9

4.1.1 Redundancy

  • Explicit redundancy can verify messages by plausibility checks or voting, but its cost makes it a typical last resort; lockstep runs two units in parallel.Three replicas can mask a fault by majority voting when at most one component fails at a time; implicit redundancy can also combine anomaly detection with sensor fusion.Source: §4.1.1 · pp. 9–10

4.1.2 Specification

  • Hybrid-system verification uses flow-pipe over-approximations to check unsafe-region intersections, but available methods are limited to small-scale models and modeling errors can reduce fidelity.Runtime verification monitors observed traces against formal requirements, but provides limited execution coverage; single-trace monitoring also remains a challenge for hyperproperties.Source: §4.1.2 · pp. 10–11
  • Quantitative Signal Temporal Logic robustness replaces binary satisfaction with a signed measure of distance from satisfying or violating a specification.Minimizing robustness searches for counterexamples, while maximizing it can tune system parameters to improve resilience.Source: §4.1.2 · p. 11
  • Signature-based intrusion detection compares runtime behavior with predefined signatures, but requires precise calibration and typically cannot detect unknown zero-day attacks.It may be combined with anomaly detection.Source: §4.1.2 · p. 11

4.1.3 Anomaly-based Detection

  • Statistical anomaly methods flag low-probability data, use empirical distributions or hypothesis tests, project correlations with PCA, or threshold entropy.Statistical models can be parameterized when the data distribution is known; empirical representations such as histograms or kernels can be used when it is unknown.Source: §4.1.3 · pp. 11–12
  • Data-driven methods learn normal classes or prediction errors, while nearest-neighbor, density, and clustering approaches identify outliers by distance, rarity, or cluster fit.Machine-learning methods can be used without domain knowledge and may be updated during operation.Source: §4.1.3 · p. 12

4.1.4 Fault-Localization

  • Spectrum-based fault localization ranks program components by their likelihood of responsibility, and specification-based monitors can add diagnostics such as the fault's time segment.Localization can help isolate a failed hardware or software component to avoid fault propagation or trigger recovery.Source: §4.1.4 · p. 12

4.2 Recovery or Mitigation

Recovery and mitigation adapt component settings or system structure to respond to faults. The approaches include re-parameterization, runtime enforcement, and structural changes that may rely on redundancy.

4.2 Recovery or Mitigation

  • The paper groups structural adaptation into re-instantiation, rewiring, and relocation, alongside re-parameterization; the structural actions require some redundancy.These changes can apply at different architectural levels, from device hardware settings to process-level connections.Source: §4.2 · p. 13

4.2.1 Re-Parameterization

  • Re-parameterization changes component settings, often trading quality of service for a non-optimal configuration; adaptive Kalman filters can adjust parameters as input quality worsens.Parameter changes require knowledge of the component's underlying algorithm and may be selected by optimization, rules, or control-theoretic estimators.Source: §4.2.1 · p. 13

4.2.2 Runtime Enforcement

  • Runtime enforcement combines verification with adaptation by changing a component's inputs or outputs to satisfy formal properties.An enforcer uses an automaton, rules, or both to correct I/O when faults occur.Source: §4.2.2 · p. 13

4.2.3 Redundancy

  • Redundant components support availability and reliability through restart, spares, voting or fusion, rewiring, and relocation.Restart can use periodic checkpoints; triple modular redundancy masks failures with a voter but can incur substantial area and power overhead.Source: §4.2.3 · pp. 13–14
  • Structural adaptation can replace a failed component using implicit redundancy, while task relocation uses optimization, multi-agent systems, or reinforcement learning to find a new configuration.Tasks may also be migrated in advance when platform health declines.Source: §4.2.3 · p. 14
  • Replicas can detect and tolerate Byzantine failures through agreement or consensus, while blockchains provide hash-linked records but currently impose costs in complexity, energy, and latency.Those costs limit blockchain use for real-time anomaly detection and simple, resource-constrained nodes.Source: §4.2.3 · p. 14

5 Long-Term Dependability and Security

Long-term dependability and security are difficult because system changes and emerging threats can outlast design-time assumptions. The paper identifies challenges and directions including dynamic assurance, intelligent adaptation, and robustness of the resilience mechanisms themselves.

5 Long-Term Dependability and Security

  • Design-time planning cannot anticipate all future system and environmental changes, vulnerabilities, or attacks, motivating runtime self-adaptation and self-healing.Self-aware systems learn models of themselves and their environment and continuously update them to act toward higher-level goals such as availability.Source: §5 · pp. 14–15
  • The roadmap highlights open questions about separating subsystem failures, preserving resilience with machine learning or self-adaptation, and recovering compromised components with low performance and energy overhead.It also asks how to learn from unknown attacks online and ensure resilience mechanisms remain robust.Source: §5 · p. 15

5.1 Verification and validation

  • Formal models support verification, but model accuracy and test coverage limit assurance; data-driven subsystems add uncertainty because their behavior depends on training data.Proposed directions include learning how to respond to attacks, or using runtime decision modules to regulate autonomy according to safe and secure operating conditions.Source: §5.1 · p. 15

5.2 Intelligent and Adaptive Systems

  • Many existing techniques do not address evolving systems, while machine-learning approaches must account for IoT limits in computation, complexity, interoperability, and real-time operation.The paper calls for scalable or distributed techniques and for models that can be updated or reconstructed as the system changes.Source: §5.2 · pp. 15–16

5.3 Robustness

  • Resilience mechanisms must withstand system dynamicity, but current black-box neural-network decision systems cannot be analyzed and rectified, and safety-critical industrial AI is expected to explain decisions.Neural networks also face data-related security and reliability vulnerabilities, including poisoning, model stealing, and adversarial examples.Source: §5.3 · p. 16

6 Roadmap

The roadmap targets resilient IoT for CPS through anomaly detection and self-healing, with goals spanning runtime verification, low-overhead detection, and recovery. It identifies resource, interoperability, and real-time constraints and outlines milestones for developing and integrating these methods.

6.1 Goals

  • The research goals combine scalable resilience architectures, energy-efficient verification and threat detection, and self-healing for IoT.The work also targets low-power, ML-based runtime anomaly detection and runtime safety and security properties.Source: §6.1 · p. 16

6.2 Challenges

  • Resource limits force trade-offs among resilience, power, time, and cost, while heterogeneous devices may lack behavioral specifications or familiar interfaces.Proposed responses include lightweight, distributed, layered, or clustered services.Source: §6.2 · p. 17
  • Runtime resilience must preserve CPS timing, scale across distributed devices, and cope with unpredictable faults that remain after design-time planning.The roadmap also raises questions about scalable reference behavior, labeled training data, and anomaly-model coverage.Source: §6.2 · p. 17

6.3 Milestones

  • For fail-operational behavior, the roadmap uses implicit information redundancy for adaptive detection, diagnosis, and recovery based on what is currently available.Mechanisms may run in fog or cloud, or on an IoT device when performance permits.Source: §6.3 · p. 18
  • The anomaly-detection plan combines vulnerability analysis with low-power and ML-based detection, using communication behavior and power as signals.Formal verification is proposed for vulnerability analysis, followed by online detection based on identified communication and side-channel parameters.Source: §6.3 · pp. 18–19
  • The roadmap culminates in collecting architectural requirements for design guidelines and demonstrating the mechanisms in a case study.Figure 9 depicts the roadmap milestones against the evolution of embedded systems.Source: §6.3 · pp. 18–19, Figure 9 · p. 18

7 Case Study: Resilient Smart Mobility

The case study applies resilience methods to collaborative radar tracking for automated driving. It uses a knowledge base of information relationships for redundancy-based monitoring and substitution, alongside communication- and power-based anomaly detection.

7 Case Study: Resilient Smart Mobility

  • The highway use case connects roadside radars and vehicle sensors through fog nodes to track vehicles, but noisy, dirty, or compromised sensors can corrupt tracking.Explicitly replicating sensors is costly, motivating the use of available information redundancy.Source: §7 · pp. 19–20

7.1.1 SHSA Knowledge Base

  • SHSA uses a knowledge base of relationships among system variables to monitor failures and find substitutes from implicit redundancy.Its graph has variable and relation nodes, with edges describing relation inputs and outputs; domain experts can define it or it can be learned.Source: §7 · p. 20, §7.1.1 · p. 21

7.1.2 Fault Detection by Redundancy

  • The monitor maps available information atoms into a common variable domain, compares them, and assigns fault status or confidence values.Confidence can be based on distance or error, with a threshold sustained over time used to classify an information atom as failed.Source: §7.1.2 · pp. 21–22, Figure 14 · p. 22

7.1.4 Fault Localization [135]

  • When a relation’s output mismatches, the monitor marks all its inputs faulty, so fault localization is needed to identify the responsible component.The paper also reviews an STL-guided approach combining trace diagnostics, model slicing, and spectrum-based ranking for Simulink/Stateflow debugging.Source: §7.1.2 · p. 22, §7.1.4 · pp. 24–25

7.1.3 Anomaly Detection

  • Communication assertions offer a low-power, low-area anomaly-detection approach, while ML is proposed to extract features from communication and power behavior at larger scale.The authors identify reference-behavior discovery, statistical modeling, and measurement overhead as challenges.Source: §7.1.3 · pp. 22–24
  • Intrusions changed MC8051 power distributions across pipeline stages, while denial-of-service reduced output traffic and flooding, jamming, and information leakage increased it.These observations support power profiling and communication behavior as signals for identifying abnormal behavior.Source: §7.1.3 · pp. 23–24, Figure 15 · p. 23, Figure 16 · p. 24

7.2 Recovery or Mitigation

  • Recovery replaces failed information with a function of related information atoms found through the knowledge base.The paper’s broader roadmap treats recovery as a response to failed components responsible for wrong network information.Source: §7.1.4 · p. 24, §7.2 · p. 25

7.2.1 Replacement

  • A valid substitution is an acyclic knowledge-base subgraph whose sources are available; its relationships are concatenated into a substitute that publishes replacement outputs.The search starts from the failed variable and may stop once unprovided variables are substituted; the failed component should be shut down to limit inconsistency and fault propagation.Source: §7.2.1 · p. 25, Figure 17 · p. 25

8 Conclusion

The conclusion summarizes IoT-for-CPS resilience methods and their challenges, then describes the automotive case study’s redundancy-based detection and recovery. These methods depend on available information, interoperability, and suitable system resources.

8 Conclusion

  • The paper identifies limited computation and power, incomplete device semantics, real-time preservation, long-term dependability, and method robustness as resilience challenges.These constraints cover runtime data acquisition, reference behavior, and changes in the system environment or technology.Source: §8 · p. 25
  • The SHSA knowledge base represents redundancy that can support monitoring, replacement, or fusion, and can address permanent faults when redundancy exists and failed components can be isolated.The stated scope includes physical, development, and interaction faults manifested at component interfaces.Source: §8 · p. 26
  • Monitors detect faults by comparing redundant information or reference behavior; localization triggers disconnection, and substitution replaces failed information with redundant information.These mechanisms correspond to the paper’s R1 detection and R2 recovery requirements.Source: §8 · p. 26
  • The techniques require reference behavior, shared information semantics, or accessible redundancy; real-time SHSA also assumes a bounded or static knowledge base and estimated relationship execution times.The paper identifies scalability and device-resource limits as unresolved and proposes distributed mechanisms as future work.Source: §8 · p. 26
Loading 1810.06870v2…