Motivation  Synthesis-based methodology for quick design space exploration enabled by automatic synthesis followed by analysis  Automatic synthesis:

Slides:



Advertisements
Similar presentations
Embedded System, A Brief Introduction
Advertisements

Copyright  2003 Dan Gajski and Lukai Cai 1 Transaction Level Modeling: An Overview Daniel Gajski Lukai Cai Center for Embedded Computer Systems University.
PROJECT RISK MANAGEMENT
ECOE 560 Design Methodologies and Tools for Software/Hardware Systems Spring 2004 Serdar Taşıran.
DETAILED DESIGN, IMPLEMENTATIONA AND TESTING Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
SOFTWARE TESTING. INTRODUCTION  Software Testing is the process of executing a program or system with the intent of finding errors.  It involves any.
Software Quality Assurance Plan
Background information Formal verification methods based on theorem proving techniques and model­checking –to prove the absence of errors (in the formal.
MotoHawk Training Model-Based Design of Embedded Systems.
Introduction Designing cost-sensitive real-time control systems for safety-critical applications requires a careful analysis of the cost/fault-coverage.
Abhijit Davare 1, Qi Zhu 1, Marco Di Natale 2, Claudio Pinello 3, Sri Kanajan 2, Alberto Sangiovanni-Vincentelli 1 1 University of California, Berkeley.
PTIDES: Programming Temporally Integrated Distributed Embedded Systems Yang Zhao, EECS, UC Berkeley Edward A. Lee, EECS, UC Berkeley Jie Liu, Microsoft.
1 DRAFTS DRAFTS Distributed Real-time Applications Fault Tolerant Scheduling Claudio Pinello
Designing the system Conceptual design and technical design
Causality Interface  Declares the dependency that output events have on input events.  D is an ordered set associated with the min ( ) and plus ( ) operators.
Presenter : Shih-Tung Huang Tsung-Cheng Lin Kuan-Fu Kuo 2015/6/15 EICE team Model-Level Debugging of Embedded Real-Time Systems Wolfgang Haberl, Markus.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
Design of Fault Tolerant Data Flow in Ptolemy II Mark McKelvin EE290 N, Fall 2004 Final Project.
System Partitioning Kris Kuchcinski
CSC 402, Fall Requirements Analysis for Special Properties Systems Engineering (def?) –why? increasing complexity –ICBM’s (then TMI, Therac, Challenger...)
Designing Predictable and Robust Systems Tom Henzinger UC Berkeley and EPFL.
Formal Service-Oriented Development of Fault Tolerant Communicating Systems Linas Laibinis, Elena Troubitsyna, Johan Lilius, Qaisar Malik (Åbo Akademi)
[ §4 : 1 ] 4. Requirements Processes II Overview 4.1Fundamentals 4.2Elicitation 4.3Specification 4.4Verification 4.5Validation Software Requirements Specification.
“Faultless to a fault.” - Robert Browning Albert Hsu
Software Dependability CIS 376 Bruce R. Maxim UM-Dearborn.
Dr. Pedro Mejia Alvarez Software Testing Slide 1 Software Testing: Building Test Cases.
1 EVALUATING INTELLIGENT FLUID AUTOMATION SYSTEMS USING A FLUID NETWORK SIMULATION ENVIRONMENT Ron Esmao - Sr. Applications Engineer, Flowmaster USA.
REAL-TIME SOFTWARE SYSTEMS DEVELOPMENT Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Objectives Understand the basic concepts and definitions relating to testing, like error, fault, failure, test case, test suite, test harness. Explore.
CMSC 345 Fall 2000 Unit Testing. The testing process.
1 Software testing. 2 Testing Objectives Testing is a process of executing a program with the intent of finding an error. A good test case is in that.
An efficient active replication scheme that tolerate failures in distributed embedded real-time systems Alain Girault, Hamoudi Kalla and Yves Sorel Pop.
CS4730 Real-Time Systems and Modeling Fall 2010 José M. Garrido Department of Computer Science & Information Systems Kennesaw State University.
Testing Basics of Testing Presented by: Vijay.C.G – Glister Tech.
Ch6: Software Verification. 1 Decision table based testing  Applicability:  Spec. is described by a decision table.  Tables describe:  How combinations.
FAULT TREE ANALYSIS (FTA). QUANTITATIVE RISK ANALYSIS Some of the commonly used quantitative risk assessment methods are; 1.Fault tree analysis (FTA)
Jon Perez, Mikel Azkarate-askasua, Antonio Perez
Secure Systems Research Group - FAU 1 Active Replication Pattern Ingrid Buckley Dept. of Computer Science and Engineering Florida Atlantic University Boca.
Historical Aspects Origin of software engineering –NATO study group coined the term in 1967 Software crisis –Low quality, schedule delay, and cost overrun.
C. André, J. Boucaron, A. Coadou, J. DeAntoni,
REAL-TIME SOFTWARE SYSTEMS DEVELOPMENT Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
1 Introduction to Software Testing. Reading Assignment P. Ammann and J. Offutt “Introduction to Software Testing” ◦ Chapter 1 2.
MODES-650 Advanced System Simulation Presented by Olgun Karademirci VERIFICATION AND VALIDATION OF SIMULATION MODELS.
Electrical and Computer Engineering University of Cyprus LAB 1: VHDL.
CS4730 Real-Time Systems and Modeling Fall 2010 José M. Garrido Department of Computer Science & Information Systems Kennesaw State University.
Software Engineering1  Verification: The software should conform to its specification  Validation: The software should do what the user really requires.
1 Fault-Tolerant Computing Systems #1 Introduction Pattara Leelaprute Computer Engineering Department Kasetsart University
Tolerating Communication and Processor Failures in Distributed Real-Time Systems Hamoudi Kalla, Alain Girault and Yves Sorel Grenoble, November 13, 2003.
Concepts and Realization of a Diagram Editor Generator Based on Hypergraph Transformation Author: Mark Minas Presenter: Song Gu.
Design-Directed Programming Martin Rinard Daniel Jackson MIT Laboratory for Computer Science.
Formal Verification. Background Information Formal verification methods based on theorem proving techniques and model­checking –To prove the absence of.
Motivation FACE architecture encourages modularity of components on data boundaries Transport Services Segment interface is centered on sending and receiving.
Quality Assurance in the Presence of Variability Kim Lauenroth, Andreas Metzger, Klaus Pohl Institute for Computer Science and Business Information Systems.
T imed Languages for Embedded Software Ethan Jackson Advisor: Dr. Janos Szitpanovits Institute for Software Integrated Systems Vanderbilt University.
Chapter 7 Part II Structuring System Process Requirements MIS 215 System Analysis and Design.
Testing Overview Software Reliability Techniques Testing Concepts CEN 4010 Class 24 – 11/17.
Network Management Lecture 13. MACHINE LEARNING TECHNIQUES 2 Dr. Atiq Ahmed Université de Balouchistan.
Week#3 Software Quality Engineering.
ASIC Design Methodology
Software Testing.
System Design and Modeling
Period Optimization for Hard Real-time Distributed Automotive Systems
Composing Time- and Event-driven Distributed Real-time Systems
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
Software Verification and Validation
Software Verification and Validation
Mark McKelvin EE249 Embedded System Design December 03, 2002
Transaction Level Modeling: An Overview
Software Verification and Validation
Anand Bhat*, Soheil Samii†, Raj Rajkumar* *Carnegie Mellon University
Presentation transcript:

Motivation  Synthesis-based methodology for quick design space exploration enabled by automatic synthesis followed by analysis  Automatic synthesis: 1) Designer specifies control algorithm, fault behavior, constraints, and selects architecture 2) Synthesis engine deduce necessary process replication, distribute each process onto architecture, and derives a fault tolerant schedule satisfying constraints  Analysis: 1) Timing verification/analysis (worst case execution time, time out values) 2) Dependability analysis (i.e. mean-time-to-failure rate, sensitivity, minimal cutsets, etc.) 3) Analysis metrics provide hints to the designer  Design flow is centered around Fault Tolerant Data Flow (FTDF) as the mathematical model (model of computation)  Fault trees are models commonly used to analyze dependability metrics  Typically generated manually from requirement documents  Manual process is time consuming, difficult, and informal  Increases turn-around time to analyze fault trees of different system mappings May 11, 2005 A Formal Approach to Fault Tree Synthesis for the Analysis of Distributed Fault Tolerant Systems M. McKelvin, G. Eirea C. Pinello (GMBL), S. Kanajan (GM) A. Sangiovanni- Vincentelli Revisit the Design ECU0 ECU1 ECU2 CH0 CH1 Sens Input Coarse CTRL Coarse CTRL Fine CTRL Arbiter Best Arbiter Best Output Act Mapping + Scheduling Fault behavior + Constraints Fine CTRL CoarseCT RL Sens Act Plant Input ArbiterBes t Output CH1 CH0 ECU0ECU1ECU2 Functionality (control algorithm using FTDF) Architecture Metric Scores Timing Analysis Other Analysis Techniques Dependability Analysis Fault tree synthesis Fault tree analysis Synthesis-based design flow with integrated analysis techniques to enable design exploration. Fault Tolerant Data Flow (FTDF)  A mathematical formalism (model of computation) for describing periodic feedback control systems  Synchronous Data Flow (SDF) variant  Deterministic behavior  SDF actor requires presence of all inputs to execute (fire), i.e. firing rule for a 3-input actor: U = {(*, *, *)}  Statically schedulable  Suitable for periodic algorithms  FTDF specific  Actors are typed and annotated with criticality level (i.e. sensor, input, arbiter, etc.)  Communication media are one-place buffers  May have fan-in (inputs) from redundant sources (replicas)  Manages redundant sources and destinations  An abstraction for error detection and recovery  Input and Arbiter type actors may have partial firing rules, i.e. for a 3-input Arbiter actor, firing rule U = {(*,*,*), ( ┴,*,*), (*, ┴,*), (*,*, ┴ )} specifies the actor may fire if 2-out-of-3 inputs are present (Note: “ ┴ ” means not present, “*” means present) Problem Statement: Given a redundant mapped FTDF schedule, generate a fault tree using fault event logic to analyze dependability metrics of the mapped system. Assumptions:  A fault event in nodes of a FTDF graph results in fail silence  Fail silence: produces correct results or produces no results at all  Fault events are generated due to:  ECU (electronic control unit) fault  Communication channel fault  Actuator or sensor fault (denoted as basic events) Fault Tree Analysis  Top-down approach to failure analysis using a tree model called a fault tree  Static fault tree components:  Top-level event: root of tree that represents an undesirable, unrecoverable system failure, as specified by designer  Logic gates: define Boolean relationships amongst input and output events  Basic events: leaves of tree that represents initiating events in the architecture (ECU, channel, sensor, and actuator faults)  A fault tree determines all the ways the top-level event may occur in terms of basic events  Common tools can be used to derive dependability metrics from a fault tree, i.e. Item Toolkit (Item Software), Galileo (Univ. of Virginia), Relex Fault Tree (Relex Software Corp), etc. Fault Tree Synthesis Fault Tree Generation Algorithm ECU0 ECU1 ECU2 CH0 CH1 Sens Input Coarse CTRL Coarse CTRL Fine CTRL Arbiter Best Arbiter Best Output Act Analysis Results* (Pendulum Case Study) Designer specified fault behavior for different mappings and dependability metrics. Minimal cutset for mapping 1. This analysis identifies the minimal combination of events that leads to a system failure. Mapped FTDF schedule of the pendulum example. Sensitivity metric (using Barlow Proschan Importance) for each basic event per mapping. Conclusions  Design flow enables design space exploration  Different designs can be quickly analyzed and offer hints to the designer  Enables formal specification and verification of fault tolerant systems using a correct-by-construction flow  Greater separation of concerns (application, architecture, fault behavior), hence model reuse * Graphical fault tree and analysis results were generated by the Item Toolkit courtesy of Rick Clemons and Joe Wysocki of Hughes Research Laboratory. specified to be the (P : 2) Missing input value (assuming fail silence) on input port ?i0 of actor c1actm0 located on ECU ecu0. (P : 2) Missing input value (assuming fail silence) on input port ?i0 of actor c1actm0 located on ECU ecu0. c1actm0(ecu0)HW_FAULT Basic event hardware failure of actuator c1actm0 located on ECU ecu0. IE c1actm0(ecu0)HW_FAULT Basic event hardware failure of actuator c1actm0 located on ECU ecu0. IE ecu0ECU_FAULT Basic event hardware failure of ECU ecu0. IE ecu0ECU_FAULT Basic event hardware failure of ECU ecu0. IE c1actm0(ecu0)Fault on ECU ecu0. c1actm0(ecu0)Fault Unable to deliver updated command to the plant from actuator driver c1actm0 on ecu0. c0ou1b(ecu2)Fault Cannot fire actor c0ou1b located on ECU ecu2. R c0ou1b(ecu2)Fault Cannot fire actor c0ou1b located on ECU ecu2. R c1actm1(ecu2)HW_FAULT Basic event hardware failure of actuator c1actm1 located on ECU ecu2. IE c1actm1(ecu2)HW_FAULT Basic event hardware failure of actuator c1actm1 located on ECU ecu2. IE ecu2ECU_FAULT Basic event hardware failure of ECU ecu2. IE R ecu2ECU_FAULT Basic event hardware failure of ECU ecu2. IE R c1actm1(ecu2)Fault Unable to deliver updated command to the plant from actuator driver c1actm1 on ecu2. c1actm1(ecu2)Fault SystemFault specified to be the failure of all actuators in model SystemFault failure of all actuators in model Input(?i0)Ofc1actm0(ecu0)Fault Top-level event: unrecoverable system failure Logic gates: define Boolean relationships amongst input and output events Basic events: initiating events Transfer gate: graphical placeholder for sub trees Sample fault generated by fault tree synthesis given in graphical format.