The Software Engineering and Network Systems Laboratory supports research in: Laura K. Dillon: specification and validation of concurrent systems

Transcription

1 S ystems L a b Software Engineering and Network Systems Laboratory A Requirements PatternPattern-Driven Approach to Modeling and Analyzing Embedded Systems S ystems L a b Betty H.C. Cheng Software Engineering and Network Systems Lab Michigan State University This work is supported in part by: Grants from NSF EIA , EIA , CDA ,CCR , Department of the Navy, Office of Naval Research under Grant No. N , and DARPA grant No. F , managed by Air Force s Rome Laboratories, SiemensCorporate Research, Eaton Corporation, Motorola, and in cooperation with Siemens Automotive and Detroit Diesel Corporation. Research sponsored by NSF, ONR, DARPA, DOE, NASA, EPA, and several industrial partners MSU SENS Laboratory SENS Personnel Betty H.C. Cheng : software engineering, patterns, OO, formal methods, embedded systems. The Software Engineering and Network Systems Laboratory supports research in: Laura K. Dillon: specification and validation of concurrent systems software engineering distributed computing network protocols and real-time systems fault tolerance and security formal methods, code generation compilation/analysis of concurrent systems Sandeep Kulkarni : fault tolerance in distributed systems Philip McKinley: distributed computing, networking, OS, adaptive middleware Research sponsored by NSF, ONR, DARPA, DOE, NASA, EPA, and several industrial partners S ystems L a b S ystems L a b 3 Jonathan Shapiro: Network protocols, security, peer-to-peer systems Kurt Stirewalt : interactive systems, program reasoning, SE. Approximately 30 grad research assistants Occasional visiting scholars and postdocs Outline Bridge the Gap Between Informal and Formal Methods Informal specifications, graphical models, easy for humans to formulate, may be inconsistent and incomplete. Formalization Techniques and Patterns Object-Oriented Blueprints Formal Representations Objective: formal specifications executable code that can be verified for correctness and completeness Benefits: Automated Analysis Consistency, completeness Rapid Prototyping Behavior Simulation Design Transformations Test Case generation Modeling and Analysis S ystems L a b 6

2 Problem Statement Many embedded systems require high assurance (e.g. automotive, medical) Requirements modeling and analysis One of the most difficult tasks in software development Focus on behavioral specification of system activities Describes a system s modes of operation and events that cause mode changes Challenges for embedded system development: Software does not execute in isolation: Environment (including User) Hardware Current technology involves ad hoc techniques from natural language specifications to code ES community interested in using OO and UML Desirable properties of requirements analysis documents: Easy to interpret Structural description of system Behavioral description of system s should be concise and correct Requirements analyzable for critical properties 7 8 General Approach Outline Objective: Easy to use notation and technique for capturing requirements Notation must be amenable to rigorous analysis Proposed Solution: Provide process and requirements patterns for constructing UML diagrams Formalizing UML enables automated analysis of UML diagrams Visualize analysis errors in terms of original UML diagrams Modeling and Analysis Project Collaborators: Dr. Kurt Stirewalt Dr. L. Campbell, Dr. W. McUmber, Dr. E. Wang R. Bourdeau, G. Coombs, M. Deng, H. Goldsby, S. Konrad 9 0 UML Metamodel Automate translation of diagrams into a formal language OMT Formalization [TSE95, ICSE97, J. SEKE00, TSE02, IWSSD00, DSN00] [HASE99, ICSE0] General framework for mapping diagrams to multiple formal languages Embedded systems domain Currently targets Promela Hydra Mapping from UML to the target language (such as Promela, VHDL) Enables execution through simulation and analysis through model checking Metamodel defines UML syntax using class diagram notation. Semantics not defined by metamodel Note: Any language or diagram syntax can be defined with a metamodel 0..* Compound Statement Program Block Simple Statement 2 2

3 Unified Class/Dynamic Metamodel Example Metamodel Mapping Class related Dynamic related Behavior Class Model Relationships Source A R B h: h: h: Target State Vertex Transition Rest of dynamic model Instance Variables Aggregation Generalization Association hascomp(a,c) C h: h: R B A haspart(a,c ) C D 3 4 Metamodel mapping to Mapping Rules Describes instance UML metamodel UML diagram Produces mapping Homomorphism Mapping Rules Formal language metamodel Describes instance Formal description of system VHDL used for embedded systems VHDL contains time notations Many commercial tools available Comprehensive simulation capability SPIN used in industry Spin provides model simulation and checking Concurrency is a feature of both 5 6 Summary of Mappings Tool Support VHDL Ent/Arch Structure Class Promela proctype Analysis results Port signature procedure Ent/Arch Relationship State Composite State channels Labeled block of statements proctype UML Diagram reports MINERVA Analysis reports HIL Hydra Spec* Analysis Tool* Write to signal Event Channel assignment 7 8 3

4 Architecture of Minerva MINERVA UML UML diagram editors Diagram in DoME format Visualization commands Plug-ins Text processing scripts Diagram reports HIL Analysis results (processed) Analysis reports Analysis results (raw) 9 MINERVA Based on Honeywell s DoME (Domain Modeling Environment) Graphical construction of syntactically correct UML diagrams adhering to a defined metamodel [RE-0] Visualization of consistency-checking results, simulation traces, and paths of execution Enables roundtrip engineering of UML diagrams [REJ-02, RHAS-02, Spin-03] 20 Hydra Translation Tool Outline Uses library and parser to implement rules Modular per formal language Minerva HIL Hydra parser Language Specific Class Library Modeling and Analysis Formal Specifications Implements mapping rules for specific language 2 22 Patterns Patterns Analysis Patterns: Recurring & reusable analysis models [Fowler] Design Patterns: Solution skeletons for (OO) software design [Gamma et al] Organizational Patterns: Structure of organizations/ projects Patterns: Software process design Security Patterns: Skeletons to provide system security [Fernandez, Yoder, RHAS03] : conceptual model, system constraints [RE02,RHAS02,SPIN03] Pattern Essentials A pattern has 4 essential elements: Pattern name Problem Solution Consequences NAME SOLUTION PROBLEM CONSE- QUENCES

5 Logical Architecture of Embedded Systems [Broy] Template Modeled as part of the requirements engineering process An embedded system typically consists of: User UI CD Environment A PD Capture behavior of components and their interaction Collectively they provide requirements of system S 25 Design Pattern Template Pattern Name and Classification Intent Also Known As Motivation Applicability Structure Participants Collaborations Consequences Implementation Sample Code Known Uses Related Patterns Requirements Pattern Template Pattern Name and Classification Intent Motivation (incl. use cases) Constraints Applicability Structure (class diagram) Behavior (sequence, state) Participants Collaborations Consequences Design Patterns Also Known As Related Patterns 26 Behavioral Patterns Structural Patterns Communication Link: Computing Component: Detector- Corrector: Fault Handler : describes how to capture high-level information about communication capabilities offered by an embedded system, such as sending periodic heart beat messages to other systems. specifies various operational modes of an embedded system, such as fail-safe modes that a system enters in response to occurring faults. detectors offer fault detection capabilities, correctors offer fault correction capabilities, and the interaction between both types of components A global fault is handler controlled collects by fault a local messages fault from handler. the local fault handlers and Acts as a central coordinator for system recovery and safety. 27 Actuator- Sensor: Controller Decompose: User Interface: specifies basic types of sensors and actuators in an embedded system and describes how relationships between these actuators and sensors and other components in the system can be captured. describes how to decompose an embedded system into different components according to their responsibilities. describes how to specify an object model for a user interface that is extensible and reusable. 28 Patterns Overview Actuator-Sensor Pattern Identification Abstraction Relations btw Pattern Class Structural Behavioral Actuator-Sensor Str X X Communication Link Beh X X Computing Component Beh X X Controller Decompose Str X X Detector- Corrector Beh X X X Fault Handler Beh X X User Interface Str X X X objects Essential behavior Object Correlation Motivation: ES have various kinds of sensors/actuators Can distinguish two main categories of sensors: PassiveSensors (pull: controller requests information) ActiveSensors (push: sends information to controller)

6 PassiveSensor Actuator-Sensor Pattern: Structure ComputingComponent Actuator Actuator-Sensor Pattern: Behavior (sequence diagram) PassiveIntegerSensor FaultHandler Temperature Sensor Computing Component Radiator Valve Sensor Input Device Temperature Sensor ActuatorOutput Device Temperature Sensor PassiveRealSensor PassiveBooleanSensor PassiveComplexSensor ActiveSensor Actuator-Sensor Pattern Actuator-Sensor Pattern Consequences: Common Interface Class attributes are accessed through messages Pattern describes when to use active and passive sensors Constraints: Specification patterns [Dwyer98] for properties of interest. Response pattern: When the value of an active sensor changes, the computing component should receive the updated value. [](ActiveSensor.``Value change -> <>(``Send updated value to Computing Component )) 33 Response pattern: When an active sensor times out, a fault message should be sent to the fault handler. [](ActiveSensor.``Timeout -> <>(``Report timeout to fault handler )) 34 Outline Modeling and Analysis Approach Modeling and Analysis Requirement Requirements Patterns Prose Requirements User commands 2 UML Minerva 3 HIL 4 Hydra 5 Promela LTL Properties 6 Simulation SPIN 7 Model Checking 36 6

7 Diesel Filter System Modeling Approach Requirement Self cleaning particulate filter in diesel trucks Goal: Reduce amount of particulate combustion aerosols (soot) emitted by diesel engines System consists of several filter tubes that filter particulates Trapped particulates build up, letting the pressure in the filter canister rise Filters can be heated up by applying an electric current to wires embedded in the grid, burning off trapped particulates exhaust + soot filter exhaust pipe exhaust - soot 37 Requirement In order to enable model checking of a system the following elements are modeled: Environment class Contains system and environment condition values chosen from equivalence classes derived from the requirements _SYSTEMCLASS_ class Instantiates classes Non-deterministically picks system and environment conditions Initiates system execution Remaining classes Contain the components of the system 38 Analysis-Enabled Diesel Filter System Environmental Parameters Environment: controls _SYSTEM CLASS_: Fault Handler: Equivalence classes derived from the requirements determine the modes in which the system operates: Requirement reports controls controls Computing Pressure Detector: Component: monitors reads Pressure Sensor: EngineControl Current Unit: Mirror: controls controls Heater Regulator: UserInterface : affects affects Heater Regulator2: Driver Display: Current Mirror2: 39 Requirement 0, Component not working? Component? OperationStatus???, Component working?[0;8,000], No cleaning needed CurrentSystemPressure???? (8,000;0,000], Cleaning needed?(0,000;? ), System shutdown? [ 0;0,000), Cleaning disabled TotalRPMValue???[0,000;? ), Cleaning enabled [0;700), Cleaning disabled CurrentRPMValue???[700,? ), Cleaning enabled 40 Environmental Parameters Requirement Requirement Additional equivalent classes are needed to model different interactions with the physical environment? 250 PressureSensorCleanupValue?? 300?? 3,000? 2 HeaterCurrentConversionRatio?? 3?? 4 4 Requirement Detector-Corrector Pattern: General Claim: If there is a violation, then start recovery action. []( Violation -> <> Start recovery action ) Instantiated Claim: If the pressure detector detects a violation, then the system should turn off []((PressureDetector.Violation == ) -> <> (ComputingComponent.PowerStatus == 0)) Analysis Results: A violation was detected using model checking State diagram animation revealed a missing transition as the cause 42 7

8 Diesel Filter System Requirement (2) Visualization of analysis results Requirement Watchdog PassiveSensor PassiveInteger Sensor controls Computing Component 8 reads monitors DieselFilterSystem reports controls Current Mirror Pressure Sensor UserInterface affects 0..* FaultHandler controls collaborate affects Boolean Indicator Driver Display Actuator Boolean Actuator EngineControl 8 Heater Regulator Unit Integer Actuator 43 Requirement []/ ^_SYSTEMCLASS_.ready PowerOff entry/ PowerStatus:=0 ShutdownES[]/ ShutdownES[]/ ShutdownES[]/ (Initialization) GetPressure []/^PressureSensor. GetCurrentPressureValue ShutdownES[]/ GetPressure 2 SetCurrentPressureVal (CurrentPressureVal) []/ Idle [Current PressureVal >8000]/ Normal Behavior (elided) [CurrentPressureVal<=8000]/ ^PressureSensor.GetCurrent PressureValue CCOK[]/ CCFail[]/ (2) Requirement Detector-Corrector Pattern: General Claim: If there is a violation, activate indicator. []( Violation -> <> Indicator activated ) Instantiated Claim: If the watchdog detects a violation, then the driver display should be activated []((PressureDetector.Violation == ) -> <> (DriverDisplay.DriverDisplayValue == )) Analysis Results: A violation was detected by the model checker 45 Requirement Subsequent Analysis:. Detector-Corrector Pattern: [] (PressureDetector.Violation == -> <> send(localfaulthandler.reportlocalfault(200))) 2. FaultHandler Pattern: [](send(globalfaulthandler.reportglobalfault(200)) -> <> (send(userinterface. ActivateWarningLevel)) 3. User Interface Pattern: [](send(userinterface. ActivateWarningLevel) -> <> (DriverDisplay. DriverDisplayValue == )) Claim 3 uncovered the reason for the violation. 46 (3) (4) MINERVA generated sequence diagram of the violation. Visualization of analysis results Requirement Pressure Detector: ComputingComponent: FaultHandler: UserInterface: PressureSensor: ShutdownES StoreError(200) GetPressureOperationState CCOK GetPressureValue SetWDPressureValue(,000) ActivateWarningLevel SetDriverDisplayValue(0) DriverDisplay: Requirement [] / ^_SYSTEMCLASS_.ready Idle ActivateWarningLevel (WarningLevel)[]/ [WarningLevel=]/ ^DriverDisplay.SetDriverDis playvalue(0) Check [WarningLevel=]/ ^DriverDisplay.SetDriverDisplayValue Transition Trace:. Object UserInterface transitions from state Initial" to state Idle" on event modelstart 2. Object UserInterface transitions from state Idle to state Check on event ActivateWarningLevel (WarningLevel) 3. Object UserInterface transitions from state Check to state Idle on condition WarningLevel=

9 Outline Background Requirements patterns: Give guidance for developing UML diagrams Modeling and Analysis Constraints section in patterns: Give guidance for properties to check Formalization work and tool suite: Enable rigorous checking of requirements using simulation and model checking techniques Visualization tools: Help locate errors in original diagrams 49 Facilitate model refinement 50 Outline Background Current and future work: Extend our tools and patterns to support discrete timing aspects [ASE-04] Real-time specification patterns [RT-patterns04] Extend our pattern repository to address security [RHAS03] Examine how to abstract model specifications Modeling and Analysis 5 Other projects: RAPIDware (ONR adaptive middleware project) Safeness and Correctness of adaptations Feature Interactions Use AOP to weave adaptability Code generation for adaptations. 52 Acknowledgements References Background Software Engineering and Networking Systems Faculty/Students [Gebhard] [Broy] Bernd Geghard, Martin Rappl, Requirements Management for Automotive Systems Development. SAE World Congress, 2000 Manfred Broy, Requirements Engineering for Embedded Systems. Workshop on Formal Design of Safety Critical Embedded Systems, 997 This work has been supported in part by NSF grants EIA , EIA , CDA , CCR-99007, Department of the Navy, Office of Naval Research under Grant No. N , and DARPA grant No. F , managed by Air Force s Rome Laboratories Eaton Corporation, Siemens Corporate Research, a Motorola doctoral fellowship, and in cooperation with Siemens Automotive and Detroit Diesel Corporation 53 [Glinz] [Dwyer] [Gamma] Martin Glinz, Problems and Deficiencies of UML as a Requirements Specification Language. Proceedings of the Tenth International Workshop on Software Specification and Design, San Diego, -22, 2000 M. B. Dwyer, G. S. Avrunin, J. C. Corbett, Patterns in Property Specifications for Finite-State Verification. UM-CS , 998 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns: Abstraction and Reuse of Object-Oriented Design. Lecture Notes in Computer Science, vol. 707, p ,

10 Relevant Publications Relevant Publications [TSE95] [IWSSD-0] [DSN00] [IJSEKE00] [ICSE0] ``A Formal Semantics of Object Models'' R.H. Bourdeau and B. Cheng, IEEE Trans. on Software Engineering, Vol. 2, No. 0, pp , October 995. Object-Oriented Modeling and Automated Analysis of a Telemedicine Application, L Campbell and B. Cheng, IEEE International Workshop on Software Specification and Design, November Enabling Automated Analysis through the Formalization of Object-Oriented Modeling Diagrams, L. Campbell, B. Cheng, and E. Wang, IEEE Dependable Systems and Networks, June Formalizing the Functional Model within Object- oriented Design, E. Wang and B. Cheng, International Journal on Software Engineering and Knowledge Engineering, Vol 0, No., February A General Framework for Formalizing UML with Formal Language,. William E. McUmber, Betty H.C. Cheng, Proceedings of IEEE International Conference on Software Engineering, Toronto, 200 [RHAS02] [RE02] [REJ02] [TSE02] [SPIN03] Adding Formal Specifications to, Betty H.C. Cheng, Laura A. Campbell, and Sascha Konrad, International Workshop on Requirements for High Assurance Systems, Essen, September 2002 for Embedded Systems, Sascha Konrad and Betty H.C. Cheng, Proc. Of IEEE 0 th International Requirements Engineering Conference Essen, September 2002 ``Automatically detecting and visualizing errors in UML diagrams, Laura A. Campbell, Betty H. C. Cheng, William E. McUmber, and R. E. K. Stirewalt, Requirements Engineering Journal, 7(4): , Formalizing and Integrating the Dynamic Model for Object-Oriented Modeling, B. Cheng and E. Wang, IEEE Transactions on Software Engineering, Vol 28, No. 8, August, A Requirements Pattern- Driven Approach to Specify Systems and Check Properties S. Konrad, L. Campbell, B. Cheng, M. Deng, SPIN 2003, May (Co-located with ICSE03.) [RE0] Integrating Informal and Formal Approaches to Requirements Modeling and Analysis, L. Campbell and B. Cheng, IEEE Requirements Engineering, Poster Workshop, August [RHAS03] Using Security Patterns to Model and Analyze Security Properties, S. Konrad, B. Cheng, L. Campbell, R. Wassermann, IEEE Workshop on Requirements for High Assurance Systems, September (Co- located with RE02.) 56 Relevant Publications Questions/Discussion [ASE04] [Trace] ``Automated Analysis of Timing Information in UML Diagrams,'' Sascha Konrad, Laura Campbell, and Betty H.C. Cheng), Proc. of IEEE International Conference on Automated Software Engineering (to appear), September 2004, Linz Austria. ``Retrieval-By-Construction: A Traceability Technique to Support Verification and Validation of s,'' M. Deng, R.E.K. Stirewalt, and B. Cheng submitted to International Journal on Software Engineering and Knowledge Engineering, Special issue on Traceability, June Background [Patterns] ``Object Analysis Patterns for Embedded Systems,'' S. Konrad, L. Campbell, and B. Cheng, revision under review for IEEE Transactions on Software Engineering, August