“…The first difference is that our method does not need the activation condition for each fault to be specified. Jayakumar and Elks manually modeled state conditions that indicate an error or a system failure as assumptions and used model checking to identify fault activation conditions [38]. They used these conditions to activate faults to verify safety properties.…”
Section: Discussionmentioning
confidence: 99%
“…The second difference is that the proposed properties are, in principle, general to all RISC-V processors. Other works are either application-specific [38] or software-specific [30].…”
Section: Discussionmentioning
confidence: 99%
“…However, the applicability of the proposed approach to a wider set of safety mechanisms and complex designs was not discussed. Jayakumar modeled faulty states/outputs as assumptions and used Simulink Design Verifier to find faults that meet those assumptions [38]. However, complex properties and assumptions may lead to a state space explosion.…”
Reliability has been a major concern in embedded systems. Higher transistor density and lower voltage supply increase the vulnerability of embedded systems to soft errors. A Single Event Upset (SEU), which is also called a soft error, can reverse a bit in a sequential element, resulting in a system failure. Simulation-based fault injection has been widely used to evaluate reliability, as suggested by ISO26262. However, it is practically impossible to test all faults for a complex design. Random fault injection is a compromise that reduces accuracy and fault coverage. Formal verification is an alternative approach. In this paper, we use formal verification, in the form of model checking, to evaluate the hardware reliability of a RISC-V Ibex Core in the presence of soft errors. Backward tracing is performed to identify and categorize faults according to their effects (no effect, Silent Data Corruption, crashes, and hangs). By using formal verification, the entire state space and fault list can be exhaustively explored. It is found that misaligned instructions can amplify fault effects. It is also found that some bits are more vulnerable to SEUs than others. In general, most of the bits in the Ibex Core are vulnerable to Silent Data Corruption, and the second pipeline stage is more vulnerable to Silent Data Corruption than the first.
“…The first difference is that our method does not need the activation condition for each fault to be specified. Jayakumar and Elks manually modeled state conditions that indicate an error or a system failure as assumptions and used model checking to identify fault activation conditions [38]. They used these conditions to activate faults to verify safety properties.…”
Section: Discussionmentioning
confidence: 99%
“…The second difference is that the proposed properties are, in principle, general to all RISC-V processors. Other works are either application-specific [38] or software-specific [30].…”
Section: Discussionmentioning
confidence: 99%
“…However, the applicability of the proposed approach to a wider set of safety mechanisms and complex designs was not discussed. Jayakumar modeled faulty states/outputs as assumptions and used Simulink Design Verifier to find faults that meet those assumptions [38]. However, complex properties and assumptions may lead to a state space explosion.…”
Reliability has been a major concern in embedded systems. Higher transistor density and lower voltage supply increase the vulnerability of embedded systems to soft errors. A Single Event Upset (SEU), which is also called a soft error, can reverse a bit in a sequential element, resulting in a system failure. Simulation-based fault injection has been widely used to evaluate reliability, as suggested by ISO26262. However, it is practically impossible to test all faults for a complex design. Random fault injection is a compromise that reduces accuracy and fault coverage. Formal verification is an alternative approach. In this paper, we use formal verification, in the form of model checking, to evaluate the hardware reliability of a RISC-V Ibex Core in the presence of soft errors. Backward tracing is performed to identify and categorize faults according to their effects (no effect, Silent Data Corruption, crashes, and hangs). By using formal verification, the entire state space and fault list can be exhaustively explored. It is found that misaligned instructions can amplify fault effects. It is also found that some bits are more vulnerable to SEUs than others. In general, most of the bits in the Ibex Core are vulnerable to Silent Data Corruption, and the second pipeline stage is more vulnerable to Silent Data Corruption than the first.
“…This ensures that the car's throttle is not engaged when the brake is engaged by the AEB, Hazard Injection and Monitor Detection. Using a model-based fault injection toolbox [12], faults and attacks were injected strategically to simulate the loss scenarios 1 and 2. STPA provides a systematic method to analyze the system and identify loss scenarios.…”
Section: Loss Scenarios and Causal Factors As Design Guides For Multi...mentioning
confidence: 99%
“…STPA provides a systematic method to analyze the system and identify loss scenarios. After identifying loss scenarios, we explore sufficiency of causal factor analysis by property-based hazard injection [12].…”
Section: Loss Scenarios and Causal Factors As Design Guides For Multi...mentioning
Runtime verification or runtime monitoring equips safetycritical cyber-physical systems to augment design assurance measures and ensure operational safety and security. Cyber-physical systems have interaction failures, attack surfaces, and attack vectors resulting in unanticipated hazards and loss scenarios. These interaction failures pose challenges to runtime verification regarding monitoring specifications and monitoring placements for in-time detection of hazards. We develop a well-formed workflow model that connects system theoretic process analysis, commonly referred to as STPA, hazard causation information to lower-level runtime monitoring to detect hazards at the operational phase. Specifically, our model follows the DepDevOps paradigm to provide evidence and insights to runtime monitoring on what to monitor, where to monitor, and the monitoring context. We demonstrate and evaluate the value of multilevel monitors by injecting hazards on an autonomous emergency braking system model.
scite is a Brooklyn-based organization that helps researchers better discover and understand research articles through Smart Citations–citations that display the context of the citation and describe whether the article provides supporting or contrasting evidence. scite is used by students and researchers from around the world and is funded in part by the National Science Foundation and the National Institute on Drug Abuse of the National Institutes of Health.