1 / 13

Specification and Verification of Trustworthy Component-Based Real-Time Reactive Systems

This paper introduces a formal methodology for developing Trustworthy Real-Time Reactive Systems (RTRS) by generating component behavior automatically. It emphasizes the importance of trustworthiness in non-terminating systems.

angelafay
Download Presentation

Specification and Verification of Trustworthy Component-Based Real-Time Reactive Systems

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. Specification and Verification of Trustworthy Component-Based Real-Time Reactive Systems Authors: Vasu Alagar and Mubarak Mohammad Concordia University Montréal, Canada Presented by: Mubarak Mohammad

  2. Agenda • Context • Motivation • Contributions: • A formal methodology for developing trustworthy RTRS • Automatic generation of component behavior • Modeling Checking • Example • Conclusion SAVCBS @ Dubrovnik, Croatia, 2007

  3. stimulus Environment RS response Real-Time Reactive Systems (RTRS) SAVCBS @ Dubrovnik, Croatia, 2007

  4. Trustworthiness • A trustworthy system is a system that can be depended upon for quality of service. • RTRS are required to be trustworthy due to: • Their non-terminating behavior • The critical contexts it operate in • In order to trust, the credentials of trust should be defined and examined: • Safety • Security SAVCBS @ Dubrovnik, Croatia, 2007

  5. Component-Based Development (CBD) • Advantages [1]: • Reusability • Managing design complexity • Reducing time and effort • Increasing productivity • Trustworthy component: a component that guarantees safe and secure interactions. [1] Ivica Crnkovic and Magnus Larsson, editors. building reliable component-based Software Systems. Artech House Publishers, 2002. SAVCBS @ Dubrovnik, Croatia, 2007

  6. Motivation • The design of RTRS should rely on rigorous formal model to be formally verifiable. • Provide a formal approach for the development of trustworthy component-based RTRS. SAVCBS @ Dubrovnik, Croatia, 2007

  7. Formal Methodology • Verification-oriented design methodology that involves: • Formal specification of component structure and functional/nonfunctional (trustworthiness) properties ; • Automatic generation of component behavior; and • Verification of functional/nonfunctional component behavior using model checking. [2] [2] Vasu Alagar and Mubarak Mohammad. A component model for Trustworthy Real-Time Reactive Systems Development. In Proceedings of Formal Aspects of Component Systems, Sophia-Antipolis, France, Sept 2007. SAVCBS @ Dubrovnik, Croatia, 2007

  8. SAVCBS @ Dubrovnik, Croatia, 2007

  9. Lis a set of locations denoting states; l0is the initial location; Kis a set of clocks; Ais a set of actions, events causing transitions; Eis a set of edges, transition specifications; and Iis a function assigning clock constraints to locations as invariants. [3] UPPAAL Modeling Language • Time Automata (L,l0,K,A,E,I) [3] Gerd Behrmann, Alexandre David, and Kim G Larsen. A tutorial on UPPAAL. In Proceedings of SFM-RT’04, 2004. SAVCBS @ Dubrovnik, Croatia, 2007

  10. Component Template Transformation Rules UPPAAL Template Structure Create a location for every request for service Locations (L) Services Create an action for every request for service or request from service Actions (A) Create an edge for every request for service or request from service Edges (E) Expressions: 1-Select 2-Guard 3- Sync 4- Update Data Parameters Set values of parameters in the Update expression Interface Types, Frame, Architecture Types, and Connector Types Used in Guard conditions, preconditions Contract Used to constrain Updates to data parameters Data Constraints Used in Guard conditions, preconditions Data Security Create an edge for every response from the service Service Security Reactivity Create an invariant for every time constraint Invariants (I) Time Constraints Create a clock for every time constraint Clocks (K) SAVCBS @ Dubrovnik, Croatia, 2007

  11. Model Checking SAVCBS @ Dubrovnik, Croatia, 2007

  12. Example Events = {e1:Stimulus, e2:Response, e3:Request}, Data Parameters(e1)={d:Int}, Reactivity(e1)={e2,e3}, Data Constraint(e1,e2): d>10, Data Constraint(e1,e3): d<=10, Time Constraint(e1,e2)=[0,5], Time Constraint(e1,e3)=[0,5] SAVCBS @ Dubrovnik, Croatia, 2007

  13. Conclusion • We plan to evaluate our method on problems from different domains where safety and security are critical. • We are investigating the requirements of a trustworthy ADL. • We are building a visual interface tool for designing trustworthy RTRS. SAVCBS @ Dubrovnik, Croatia, 2007

More Related