1 / 20

Introduction to Embedded Systems Chapter 14 Reachability Analysis (14.1, 14.2.1 – 14.2-2)

Introduction to Embedded Systems Chapter 14 Reachability Analysis (14.1, 14.2.1 – 14.2-2). Hao Zheng U of South Florida. The Challenge of Dependable Software in Embedded Systems. Today ’ s medical devices run on software… software defects can have life-threatening consequences.

shadow
Download Presentation

Introduction to Embedded Systems Chapter 14 Reachability Analysis (14.1, 14.2.1 – 14.2-2)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Introduction to Embedded SystemsChapter 14 Reachability Analysis(14.1, 14.2.1 – 14.2-2) Hao Zheng U of South Florida

  2. The Challenge of Dependable Software in Embedded Systems Today’s medical devices run on software… software defects can have life-threatening consequences. [Journal of Pacing and Clinical Electrophysiology, 2004] “the patient collapsed while walking towards the cashier after refueling his car […] A week later the patient complained to his physician about an increasing feeling of unwell-being since the fall.” [different device] “In 1 of every 12,000 settings, the software can cause an error in the programming resulting in the possibility of producing paced rates up to 185 beats/min.”

  3. Is it possible for the trains to be on a collision path? [Moritz Hammer, Uni. Muenchen] Graph of FSM modeling 2 trains and a bridge traffic controller.

  4. Reachability Analysis and Model Checking • Reachability analysis is the process of computing the set of reachable states for a system. • all three problems can be solved using reachability analysis • Model checking is an algorithmic method for determining if a system satisfies a formal specification expressed in temporal logic. • Model checking typically performs reachability analysis.

  5. A General View of Model Checking Property  YES [proof] System S M Compose Verify Environment E NO counterexample

  6. Open vs. Closed Systems • A closed system is one with no inputs For verification, we obtain a closed system by composing the system and environment models

  7. Model Checking G p • Consider an LTL formula of the form Gp where p is a proposition (p is a property on a single state) • To verify Gp on a system M, one simply needs to enumerate all the reachable states and check that they all satisfy p. • The state space found is typically represented as a directed graph called a state graph. • When M is a finite-state machine, this reachability analysis will terminate (in theory). • In practice, though, the number of states may be prohibitively large consuming too much run-time or memory (the state explosion problem).

  8. Traffic Light Controller Example

  9. Composed FSM for Traffic Light Controller This FSM has 188 states (due to different values of count)

  10. Reachability Analysis Through Graph Traversal • Construct the state graph on the fly • Start with initial state, and explore next states using a suitable graph-traversal strategy. • A state is a collection of a FSM state and values of all variables. • initial state: (red, crossing, count==0) • A successor: (red, crossing, count==1

  11. Depth-First Search (DFS) Maintain 2 data structures: • Set of visited states R • Stack with current path from the initial state Potential problems for a huge graph? State explosion

  12. Explicit State Model Checking Example R = { (red, crossing, 0) }

  13. Explicit State Model Checking Example R = { (red, crossing, 0), (red, crossing, 1) }

  14. Explicit State Model Checking Example R = { (red, crossing, 0), (red, crossing, 1), … (red, crossing, 60) }

  15. Explicit State Model Checking Example R = { (red, crossing, 0), (red, crossing, 1), … (red, crossing, 60), (green, none, 0) }

  16. Explicit State Model Checking Example R = { (red, crossing, 0), (red, crossing, 1), … (red, crossing, 60), (green, none, 0), (green, none, 1) }

  17. Explicit State Model Checking Example R = { (red, crossing, 0), (red, crossing, 1), … (red, crossing, 60), (green, none, 0), (green, none, 1), …, (green, none, 60) }

  18. Explicit State Model Checking Example R = { (red, crossing, 0), (red, crossing, 1), … (red, crossing, 60), (green, none, 0), (green, none, 1), …, (green, none, 60), (yellow, waiting, 0) }

  19. Explicit State Model Checking Example R = { (red, crossing, 0), (red, crossing, 1), … (red, crossing, 60), (green, none, 0), (green, none, 1), …, (green, none, 60), (yellow, waiting, 0), … (yellow, waiting, 5) }

  20. Explicit State Model Checking Example R = { (red, crossing, 0), (red, crossing, 1), … (red, crossing, 60), (green, none, 0), (green, none, 1), …, (green, none, 60), (yellow, waiting, 0), … (yellow, waiting, 5), (pending, waiting, 1), …, (pending, waiting, 60) }

More Related