Department of Computer Science & Engineering College of Engineering Dr. Betty H.C. Cheng, Laura A. Campbell, Sascha Konrad The demand for distributed real-time.

Slides:



Advertisements
Similar presentations
1 Verification by Model Checking. 2 Part 1 : Motivation.
Advertisements

Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Chapter 4 Quality Assurance in Context
M INERVA (Metamodel-based Intuitive Editors with Reports and Visualizations of Analysis) Laura A. Campbell Advisor: Dr. Betty H.C. Cheng Software Engineering.
Presented by: Thabet Kacem Spring Outline Contributions Introduction Proposed Approach Related Work Reconception of ADLs XTEAM Tool Chain Discussion.
Software Engineering for Real- Time: A Roadmap H. Kopetz. Technische Universitat Wien, Austria Presented by Wing Kit Hor.
Presentation R. R. Lutz. Analyzing Software Requirements Errors in Safety-Critical Embedded Systems. In Proceedings of the IEEE International Symposium.
UML CASE Tool. ABSTRACT Domain analysis enables identifying families of applications and capturing their terminology in order to assist and guide system.
Software Engineering for Safety : A Roadmap Presentation by: Manu D Vij CS 599 Software Engineering for Embedded Systems.
Smart Cruise, an application of M INERVA and Hydra Dr. William E. McUmber, Laura A. Campbell, and Dr. Betty H.C. Cheng This work is supported in part by.
HAS. Patterns The use of patterns is essentially the reuse of well established good ideas. A pattern is a named well understood good solution to a common.
Metrics-Based Analysis of UML Designs Department of Computer Science & Engineering Ryan Stephenson Advisor: Prof. Betty H.C. Cheng Software Engineering.
End-to-End Design of Embedded Real-Time Systems Kang G. Shin Real-Time Computing Laboratory EECS Department The University of Michigan Ann Arbor, MI
1 FM Overview of Adaptation. 2 FM RAPIDware: Component-Based Design of Adaptive and Dependable Middleware Project Investigators: Philip McKinley, Kurt.
A given modeling and code generation framework Formalization of UML with Traceability Department of Computer Science & Engineering College of Engineering.
Safe Dynamic Adaptation Department of Computer Science & Engineering Ji Zhang and Zhenxiao Yang Advisor: Prof. Betty H.C. Cheng Software Engineering and.
Highlighting the Challenges of Model- Based Engineering for Spaceflight Software Systems Dr. Rob Pettit Flight Software and Embedded Systems Office The.
What Exactly are the Techniques of Software Verification and Validation A Storehouse of Vast Knowledge on Software Testing.
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
02/06/05 “Investigating a Finite–State Machine Notation for Discrete–Event Systems” Nikolay Stoimenov.
Romaric GUILLERM Hamid DEMMOU LAAS-CNRS Nabil SADOU SUPELEC/IETR.
Formal Methods 1. Software Engineering and Formal Methods  Every software engineering methodology is based on a recommended development process  proceeding.
Chapter 10 Architectural Design
Software Engineering Muhammad Fahad Khan
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
© Siemens AG, CT SE 1, Dr. A. Ulrich C O R P O R A T E T E C H N O L O G Y Research at Siemens CT SE Software & Engineering Development Techniques.
Chapter 6 System Engineering - Computer-based system - System engineering process - “Business process” engineering - Product engineering (Source: Pressman,
CPIS 357 Software Quality & Testing I.Rehab Bahaaddin Ashary Faculty of Computing and Information Technology Information Systems Department Fall 2010.
L. Dillon Software Engineering & Network Systems Laboratory Michigan State University 1 Getting Results From Testing Laura K. Dillon Software Engineering.
Computer Science Open Research Questions Adversary models –Define/Formalize adversary models Need to incorporate characteristics of new technologies and.
Assessing the Suitability of UML for Modeling Software Architectures Nenad Medvidovic Computer Science Department University of Southern California Los.
Lecture 9: Chapter 9 Architectural Design
Configuration Management (CM)
Reliable Design of Safety Critical Systems Dr. Abhik Roychoudhury School of Computing
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
Programming in Java Unit 3. Learning outcome:  LO2:Be able to design Java solutions  LO3:Be able to implement Java solutions Assessment criteria: 
Ch.2 Part C: Message Sequence Charts, UML EECE **** Embedded System Design.
Model-Driven Analysis Frameworks for Embedded Systems George Edwards USC Center for Systems and Software Engineering
Chapter 13 Architectural Design
Lecture Topics covered CMMI- - Continuous model -Staged model PROCESS PATTERNS- -Generic Process pattern elements.
© 2012 xtUML.org Bill Chown – Mentor Graphics Model Driven Engineering.
CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Chapter 6 System Engineering Overview of System Engineering.
1 Introduction to Software Engineering Lecture 1.
Correctness of Software Models Mira Balaban, Azzam Maraee Computer Science Department Ben-Gurion University Model correctnessFall
Building Dependable Distributed Systems Chapter 1 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University
Secure Systems Research Group - FAU 1 Active Replication Pattern Ingrid Buckley Dept. of Computer Science and Engineering Florida Atlantic University Boca.
Requirement Handling
A common meta-model for the interoperation of tools with heterogeneous data models ECMFA 2010 Third Workshop on Model-Driven Tool & Process Integration.
Basic Concepts of Component- Based Software Development (CBSD) Model-Based Programming and Verification.
Formal Methods.
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
Software Quality Assurance SOFTWARE DEFECT. Defect Repair Defect Repair is a process of repairing the defective part or replacing it, as needed. For example,
Real-Time Systems, Events, Triggers. Real-Time Systems A system that has operational deadlines from event to system response A system whose correctness.
Formal Specification: a Roadmap Axel van Lamsweerde published on ICSE (International Conference on Software Engineering) Jing Ai 10/28/2003.
International Telecommunication Union © ITU-T Study Group 17 Integrated Application of SDL Amardeo Sarma NEC Europe Ltd.
What’s Ahead for Embedded Software? (Wed) Gilsoo Kim
Formal Methods in Software Engineering1 Today’s Agenda  Mailing list  Syllabus  Introduction.
Engineering the Advanced Power Grid: Research Challenges and Tasks M. L. Crow, F. Liu, B. McMillin, D. Tauritz {crow, fliu, ff, University.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
Design Engineering 1. Analysis  Design 2 Characteristics of good design 3 The design must implement all of the explicit requirements contained in the.
Overview of System Engineering
Model-Driven Analysis Frameworks for Embedded Systems
Introduction Artificial Intelligent.
CS 8532: Advanced Software Engineering
Software Verification and Validation
Chapter 9 Architectural Design.
Software Verification and Validation
Software Engineering for Safety: a Roadmap
Software Verification and Validation
Presentation transcript:

Department of Computer Science & Engineering College of Engineering Dr. Betty H.C. Cheng, Laura A. Campbell, Sascha Konrad The demand for distributed real-time embedded systems (DREs) has increased considerably in recent years and is expected to continue to grow. DREs occur in many application domains, including automotive, aerospace, manufacturing, and telecommunication. The complexity of the DREs has increased in order to add new services and features in an effort to keep these applications competitive in a global market. These embedded devices often operate in environments where a failure could lead to significant losses, such as human life or financial losses. The increase in the number and complexity of DREs strongly motivates the need for more rigorous, repeatable, and cost-effective development techniques. To address this challenge, we propose to develop assurance patterns that focus on late requirements and the early design of DREs, with the intent of preventing and/or detecting errors in the early stages of development prior to coding and fabrication. This work has been supported in part by NSF grants EIA , CDA , CC , Department of the Navy, and Office of Naval Research under Grant No. N , and in cooperation with Siemens Automotive and Detroit Diesel Corporation Claims Patterns: Expansion of the Constraints field the requirements patterns with a claims patterns template that will include structured English specification templates that can be instantiated and translated to formal specifications Each requirements pattern may have several constraint families, each with various claims patterns associated with it. A constraint family refers to a collection of properties that have a common objective. Timing Extensions: DRE applications frequently involve timing constraints, but formal semantics for UML diagrams have not been defined To address these questions, we propose to add timing syntax to UML and timing semantics to our UML-based formalization in order to enable formal analysis of requirements-based properties with timing constraints We propose assurance patterns for modeling and high-level design of DREs, which consists of several components: Requirements patterns with structural and behavioral UML templates that can be instantiated for use with a previously developed formalization framework Fault-tolerance patterns appropriate for introducing fault detection and handling capabilities, including the coordination of decentralized fault handling Claims patterns that link natural language und formal specifications of properties Additionally, the assurance patterns will contain timing information, crucial for embedded systems, that can be analyzed with the extended version of our formalization framework. Several abstraction techniques are used to keep the model checking part of the verification tractable. Requirements Patterns: Idea: Apply approach used for design reuse to requirements engineering Requirements Patterns: –More concrete than Analysis Patterns –More abstract than Design Patterns Use a similar template for patterns –More rigorous description –Make it easier to compare, learn and use (1) Pattern Name and Classification (2) Intent (2) Motivation Constraints Specifications Applicability (3) Structure (3) Behavior (3) Participants (3) Collaborations (4) Consequences Related Design Patterns Also Known As Related Requirements Patterns Four essential elements of a pattern: 1. Pattern Name 2. Problem 3. Solution 4. Consequences Those elements can be found again in our template. Requirements Patterns Template: ASSURED Fault-tolerance Patterns: Fault-tolerance = The ability of a system to continue to execute correctly in the presence of a finite number of hardware and software faults Several of our previously identified requirements patterns address modeling fault-tolerance under different contexts We propose to investigate the addition of fault detectors and correctors to the existing requirements patterns for individual embedded systems We believe the combination of detectors, correctors, and safety constraints will enable developers to instantiate and then analyze fault-tolerance properties from the Constraints field of the requirements patterns. Our premise is that fault-tolerance is in essence a general property and as such is not limited to a specific application domain. Therefore, we expect that many fault detector and corrector patterns will be applicable to fault handling in DREs as well as to other types of systems. Embedded systems frequently control critical devices anti-lock brakes, power-assisted steering, etc. Embedded systems are pervasive cellular telephones, microwave ovens, etc. Failure can have catastrophic consequences loss of life, expense to retrofit already deployed systems Distributed Embedded Systems have to collaborate higher complexity than isolated embedded systems