A Requirements Pattern-Driven Approach to Modeling and Analyzing Embedded Systems

1
A Requirements Pattern-Driven Approach to
Modeling and Analyzing Embedded Systems

• Betty H.C. Cheng
• Software Engineering and Network Systems Lab
• Michigan State University

This work is supported in part by Grants from
NSF EIA-0000433, EIA-0130724, CDA-9700732,
CCR-9901017, Department of the Navy, Office of
Naval Research under Grant No. N00014-01-1-0744,
and DARPA grant No. F30602-96-1-0298, managed by
Air Forces Rome Laboratories, Siemens Corporate
Research, Eaton Corporation, Motorola, and in
cooperation with Siemens Automotive and Detroit
Diesel Corporation.
2
Software Engineering and Network Systems
Laboratory
Research sponsored by NSF, ONR, DARPA, DOE, NASA,
EPA, and several industrial partners
3
MSU SENS Laboratory

• The Software Engineering and Network Systems
  Laboratory supports research in
• software engineering
• distributed computing
• network protocols and real-time systems
• fault tolerance and security
• formal methods, code generation
• compilation/analysis of concurrent systems
• Research sponsored by NSF, ONR, DARPA, DOE, NASA,
  EPA, and several industrial partners

4
SENS Personnel

• Betty H.C. Cheng software engineering,
  patterns, OO, formal methods, embedded systems.

• Laura K. Dillon specification and validation
  of concurrent systems

• Sandeep Kulkarni fault tolerance in
  
• distributed systems

• Philip McKinley distributed computing,
• networking, OS, adaptive middleware

• 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

5

• Benefits
• Automated Analysis
• Consistency, completeness
• Rapid Prototyping
• Behavior Simulation
• Design Transformations
• Test Case generation

• Informal specifications,
• graphical models,
• easy for humans to
• formulate,
• may be inconsistent and
• incomplete.

6
Outline
Introduction
UML Formalization
Requirements Patterns
Modeling and Analysis Process
Conclusions
Future Work
7
Introduction
Overview

• 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 systems 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

Introduction
UML Formalization
Req. Patterns
Process
Conclusions
Future Work
8
Problem Statement
Overview

• Desirable properties of requirements analysis
  documents
• Easy to interpret
• Structural description of system
• Behavioral description of system
• Descriptions should be concise and correct
• Requirements analyzable for critical properties

Introduction
UML Formalization
Req. Patterns
Process
Conclusions
Future Work
9
General Approach
Overview

• 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
• Project Collaborators
• Dr. Kurt Stirewalt
• Dr. L. Campbell, Dr. W. McUmber, Dr. E. Wang
• R. Bourdeau, G. Coombs, M. Deng, H. Goldsby, S.
  Konrad

Introduction
UML Formalization
Req. Patterns
Process
Conclusions
Future Work
10
Outline
Overview
Introduction
Introduction
UML Formalization
Req. Patterns
UML Formalization
Process
Conclusions
Future Work
Requirements Patterns
Modeling and Analysis Process
Conclusions
Future Work
11
UML Formalization
Overview

• Automate translation of diagrams into a formal
  language
• OMT Formalization
• TSE95, ICSE97, J. SEKE00, TSE02, IWSSD00, DSN00
• UML Formalization HASE99, ICSE01
• 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

Introduction
UML Formalization
Req. Patterns
Process
Conclusions
Future Work
12
UML Metamodel
Overview

• 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

Introduction
UML Formalization
Req. Patterns
Process
Conclusions
Future Work
13
Unified Class/Dynamic Metamodel
Overview
Introduction
UML Formalization
Req. Patterns
Process
Conclusions
Future Work
14
Example Metamodel Mapping
Overview
Introduction
UML Formalization
Req. Patterns
Process
Conclusions
Future Work
15
Metamodel mapping
Overview
Introduction
UML Formalization
Req. Patterns
Process
Conclusions
Future Work
16
Introduction to Mapping Rules

• 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

17
Summary of Mappings
18
Tool Support
Analysis results
UML
HIL
Spec
Analysis Tool
MINERVA
Hydra
Diagram reports
Analysis reports
19
Architecture of Minerva
20
MINERVA

• MINERVA
• Based on Honeywells DoME (Domain Modeling
  Environment)
• Graphical construction of syntactically correct
  UML diagrams adhering to a defined metamodel
• RE-01
• Visualization of consistency-checking results,
  simulation traces, and paths of execution
• Enables roundtrip engineering of UML diagrams
• REJ-02, RHAS-02, Spin-03

21
Hydra Translation Tool
Modular per formal language
Uses library and parser to implement rules
Language Specific Class Library
Minerva
Hydra parser
HIL
Formal Specifications
Implements mapping rules for specific language
22
Outline
23
Patterns

• Patterns Overview
• Analysis Patterns Recurring reusable analysis
  models Fowler
• Design Patterns Solution skeletons for (OO)
  software design Gamma et al
• Organizational Patterns Structure of
  organizations/ projects
• Process Patterns Software process design
• Security Patterns Skeletons to provide system
  security Fernandez, Yoder, RHAS03
• Requirements Patterns conceptual model, system
  constraints RE02,RHAS02,SPIN03

24
Pattern Essentials

• A pattern has 4 essential elements
• Pattern name
• Problem
• Solution
• Consequences

25
Logical Architecture of Embedded Systems Broy

• Modeled as part of the requirements engineering
  process
• An embedded system typically consists of
• Capture behavior of components and their
  interaction
• Collectively they provide requirements of system

26
Requirements Patterns Template
Design Pattern Template

• Pattern Name and Classification
• Intent
• Also Known As
• Motivation
• Applicability
• Structure
• Participants
• Collaborations
• Consequences
• Implementation
• Sample Code
• Known Uses
• Related Patterns

27
Behavioral Patterns
Communication Link 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.
Computing Component specifies various operational modes of an embedded system, such as fail-safe modes that a system enters in response to occurring faults.
Detector-Corrector detectors offer fault detection capabilities, correctors offer fault correction capabilities, and the interaction between both types of components is controlled by a local fault handler.
Fault Handler A global fault handler collects fault messages from the local fault handlers and Acts as a central coordinator for system recovery and safety.
28
Structural Patterns
Actuator-Sensor 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.
Controller Decompose describes how to decompose an embedded system into different components according to their responsibilities.
User Interface describes how to specify an object model for a user interface that is extensible and reusable.
29
Patterns Overview
30
Actuator-Sensor Pattern

• 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)

31
Actuator-Sensor Pattern Structure
Actuator
PassiveSensor
ComputingComponent

• ActiveSensor

32
Actuator-Sensor Pattern Behavior (sequence
diagram)
33
Actuator-Sensor Pattern

• Consequences
• Common Interface
• Class attributes are accessed through messages
• Pattern describes when to use active and passive
  sensors

34
Actuator-Sensor Pattern

• 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 -gt
• ltgt(Send updated value to Computing
  Component))
• Response pattern
• When an active sensor times out, a fault message
  should be sent to the fault handler.
• (ActiveSensor.Timeout-gt
• ltgt(Report timeout to fault
  handler))

35
Outline
Overview
Introduction
Introduction
UML Formalization
Req. Patterns
UML Formalization
Process
Conclusions
Future Work
Requirements Patterns
Modeling and Analysis Process
Conclusions
Future Work
36
Modeling and Analysis Approach
2
1
3
4
6
1
7
5
6
7
7
37
Diesel Filter System

• 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

38
Modeling Approach

• 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

39
Analysis-Enabled Diesel Filter System
controls
1
_SYSTEM
Fault
Environment
CLASS_
Handler
1
1
1
reports
1
1
controls
controls
controls
1
1
1
1
Heater
1
controls
1
Computing
UserInterface
Regulator1
Pressure Detector
Component
affects
1
1
1
1
monitors
1
affects
1
1
Heater
1
reads
Regulator2
1
Pressure
Driver
Sensor
Display
1
1
Current
Current
EngineControl
Mirror1
Mirror2
Unit
1
40
Environmental Parameters
Equivalence classes derived from the requirements
determine the modes in which the system operates
41
Environmental Parameters
Additional equivalent classes are needed to model
different interactions with the physical
environment
42
Requirement 1

• Detector-Corrector Pattern
• General Claim
• If there is a violation, then start recovery
  action.
• (Violation -gt ltgt Start recovery
  action)
• Instantiated Claim
• If the pressure detector detects a violation,
  then the system should turn off
• ((PressureDetector.Violation 1)
  
• -gt ltgt (ComputingComponent.PowerStatus 0))
• Analysis Results
• A violation was detected using model checking
• State diagram animation revealed a missing
  transition as the cause

43
Diesel Filter System
44
Requirement 1 (2)
Visualization of analysis results
ShutdownES/
45
Requirement 2 (1)

• Detector-Corrector Pattern
• General Claim
• If there is a violation, activate indicator.
• (Violation -gt ltgt Indicator activated)
• Instantiated Claim
• If the watchdog detects a violation, then the
  driver display should be activated
• ((PressureDetector.Violation 1)
• -gt ltgt (DriverDisplay.DriverDisplayValue
  1))
• Analysis Results
• A violation was detected by the model checker

46
Requirement 2 (2)

• Subsequent Analysis
• Detector-Corrector Pattern
• (PressureDetector.Violation 1 -gt
• ltgt send(LocalFaultHandler.ReportLocalFault(200)))
• FaultHandler Pattern
• (send(GlobalFaultHandler.ReportGlobalFault(200))
  
• -gt ltgt (send(UserInterface.
  ActivateWarningLevel(1)))
• User Interface Pattern
• (send(UserInterface.
• ActivateWarningLevel(1))
• -gt ltgt (DriverDisplay.
• DriverDisplayValue 1))
• Claim 3 uncovered the reason for the violation.

47
Requirement 2 (3)
MINERVA generated sequence diagram of the
violation.
Pressure Detector
ComputingComponent
FaultHandler
PressureSensor
UserInterface
DriverDisplay
()
GetPressureOperationState()
()
CCOK
()
GetPressureValue()
()
SetWDPressureValue(11,000)
()
ShutdownES()
()
StoreError(200)
()
ActivateWarningLevel(1)
()
SetDriverDisplayValue(0)
48
Requirement 2 (4)
Visualization of analysis results

• Transition Trace
• Object UserInterface transitions from state
  Initial" to state Idle" on event modelstart
• Object UserInterface transitions from state
  Idle to state Check on event
  ActivateWarningLevel (WarningLevel)
• Object UserInterface transitions from state
  Check to state Idle on condition
  WarningLevel1

/ _SYSTEMCLASS_.ready
ActivateWarningLevel
Idle
Check
(WarningLevel)/
WarningLevel1
/
DriverDisplay.SetDriverDis
playValue(0)
WarningLevel1/
DriverDisplay.SetDriverDisplayValue(1)
49
Outline
Overview
Introduction
Introduction
UML Formalization
Req. Patterns
UML Formalization
Process
Conclusions
Future Work
Requirements Patterns
Modeling and Analysis Process
Conclusions
Future Work
50
Conclusions
Overview

• Requirements patterns
• Give guidance for developing UML diagrams
• 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
• Facilitate model refinement

Introduction
Background
Process
Conclusions
Future Work
51
Outline
Overview
Introduction
Introduction
UML Formalization
Req. Patterns
UML Formalization
Process
Conclusions
Future Work
Requirements Patterns
Modeling and Analysis Process
Conclusions
Future Work
52
Future Work
Overview

• 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
• Other projects
• RAPIDware (ONR adaptive middleware project)
• Safeness and Correctness of adaptations
• Feature Interactions
• Use AOP to weave adaptability
• Code generation for adaptations.

Introduction
Background
Process
Conclusions
Future Work
53
Acknowledgements
Overview

• Software Engineering and Networking Systems
  Faculty/Students
• This work has been supported in part by
• NSF grants EIA-0000433, EIA-0130724, CDA-9700732,
  CCR-9901017, Department of the Navy, Office of
  Naval Research under Grant No. N00014-01-1-0744,
  and DARPA grant No. F30602-96-1-0298, managed by
  Air Forces Rome Laboratories
• Eaton Corporation, Siemens Corporate Research, a
  Motorola doctoral fellowship, and in cooperation
  with Siemens Automotive and Detroit Diesel
  Corporation

Introduction
Background
Process
Conclusions
Future Work
54
References
Gebhard Broy Glinz Dwyer Gamma 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, 1997 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, 11-22, 2000 M. B. Dwyer, G. S. Avrunin, J. C. Corbett, Patterns in Property Specifications for Finite-State Verification. UM-CS-1998-035, 1998 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. 406 431, 1993

55
Relevant Publications
TSE95 IWSSD-10 DSN00 IJSEKE00 ICSE01 RE01 A Formal Semantics of Object Models'' R.H. Bourdeau and B. Cheng, IEEE Trans. on Software Engineering, Vol. 21, No. 10, pp. 799--821, October 1995. Object-Oriented Modeling and Automated Analysis of a Telemedicine Application, L Campbell and B. Cheng, IEEE International Workshop on Software Specification and Design, November 2000. Enabling Automated Analysis through the Formalization of Object-Oriented Modeling Diagrams, L. Campbell, B. Cheng, and E. Wang, IEEE Dependable Systems and Networks, June 2000. Formalizing the Functional Model within Object-oriented Design, E. Wang and B. Cheng, International Journal on Software Engineering and Knowledge Engineering, Vol 10, No. 1, February 2000. 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, 2001 Integrating Informal and Formal Approaches to Requirements Modeling and Analysis, L. Campbell and B. Cheng, IEEE Requirements Engineering, Poster Workshop, August 2001.

56
Relevant Publications

• Adding Formal Specifications to Requirements
  Patterns, Betty H.C. Cheng, Laura A. Campbell,
  and Sascha Konrad, International Workshop on
  Requirements for High Assurance Systems, Essen,
  September 2002
• Requirements Patterns for Embedded Systems,
  Sascha Konrad and Betty H.C. Cheng, Proc. Of
  IEEE 10th 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)264-287, 2002.
• 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, 2002.
• A Requirements Pattern-Driven Approach to
  Specify Systems and Check Properties S. Konrad,
  L. Campbell, B. Cheng, M. Deng, SPIN 2003, May
  2003. (Co-located with ICSE03.)
• 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 2002. (Co-located with RE02.)

RHAS02 RE02 REJ02 TSE02 SPIN03
RHAS03
57
Relevant Publications

• 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 UML Formalizations,'' M. Deng, R.E.K.
  Stirewalt, and B. Cheng submitted to
  International Journal on Software Engineering and
  Knowledge Engineering, Special issue on
  Traceability, June 2004.
• Object Analysis Patterns for Embedded
  Systems,'' S. Konrad, L. Campbell, and B. Cheng,
  revision under review for IEEE Transactions on
  Software Engineering, August 2004.

ASE04 Trace Patterns
58
Questions/Discussion
Overview
Introduction
Background
Process
Conclusions
Future Work