html5-img
1 / 1

Department of Computer Science & Engineering College of Engineering

Timing Extensions: DRE applications frequently involve timing constraints, but formal semantics for UML diagrams have not been defined

elyse
Download Presentation

Department of Computer Science & Engineering College of Engineering

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. 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 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 • 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. • 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 • 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. • 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 Template: • Four essential elements of a pattern: • 1. Pattern Name • 2. Problem • 3. Solution • 4. Consequences • Those elements can be found • again in our template. • (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 Assurance Patterns for Distributed Real-time Embedded Systems Department of Computer Science & EngineeringCollege 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-0000433, CDA-9700732, CC-9901017, Department of the Navy, and Office of Naval Research under Grant No. N00014-01-1-0744, and in cooperation with Siemens Automotive and Detroit Diesel Corporation. ASSURED 4-17-04

More Related