Problem solving in control of discrete-event systems Lenko Grigorov and Karen Rudie Queen’s University Kingston, Canada.

Slides:



Advertisements
Similar presentations
Supervisory Control of Hybrid Systems Written by X. D. Koutsoukos et al. Presented by Wu, Jian 04/16/2002.
Advertisements

Conceptual Graph Analysis Chapter 20 Lori Nuth | EDIT 730 | Fall 2005.
ECE 720T5 Fall 2012 Cyber-Physical Systems Rodolfo Pellizzoni.
Patch to the Future: Unsupervised Visual Prediction
Requirements Engineering n Elicit requirements from customer  Information and control needs, product function and behavior, overall product performance,
SSP Re-hosting System Development: CLBM Overview and Module Recognition SSP Team Department of ECE Stevens Institute of Technology Presented by Hongbing.
Software Testing and Quality Assurance
Software Testing and Quality Assurance
Detailed Design Kenneth M. Anderson Lecture 21
Algorithms and Problem Solving-1 Algorithms and Problem Solving.
Knowledge Acquisitioning. Definition The transfer and transformation of potential problem solving expertise from some knowledge source to a program.
Algorithms and Problem Solving. Learn about problem solving skills Explore the algorithmic approach for problem solving Learn about algorithm development.
Design The goal is to design a modular solution, using the techniques of: Decomposition Abstraction Encapsulation In Object Oriented Programming this is.
1 A Framework for Measurement Valérie Paulus, Miguel Lopez, Gregory Seront, Simon Alexandre.
Lecture 13 Revision IMS Systems Analysis and Design.
Lecture 7 Model Development and Model Verification.
CS350/550 Software Engineering Lecture 1. Class Work The main part of the class is a practical software engineering project, in teams of 3-5 people There.
SE 555 – Software Requirements & Specifications Introduction
Session 7 Page 11 ECE361 Engineering Practice Brainstorming, Trades, Evaluation, and Conceptual Capture.
Session 6 Page 11 ECE361 Engineering Practice Brainstorming, Trades and the Design Process.
Requirements Gathering : Determining the scope of the system 1. Elicitiation – fact finding 2. Specification 3. Validation.
[ §4 : 1 ] 4. Requirements Processes II Overview 4.1Fundamentals 4.2Elicitation 4.3Specification 4.4Verification 4.5Validation Software Requirements Specification.
Introduction to Computer Technology
Chapter 7 Requirement Modeling : Flow, Behaviour, Patterns And WebApps.
Software Engineering 2003 Jyrki Nummenmaa 1 REQUIREMENT SPECIFICATION Today: Requirements Specification Requirements tell us what the system should.
Requirements Analysis
ECE 720T5 Winter 2014 Cyber-Physical Systems Rodolfo Pellizzoni.
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
Advanced Instructional Design Dr. Karen Rasmussen EDG 6335.
Design Science Method By Temtim Assefa.
Planning and Writing Your Documents Chapter 6. Start of the Project Start the project by knowing the software you will write about, but you should try.
Models of Computation: FSM Model Reading: L. Lavagno, A.S. Vincentelli and E. Sentovich, “Models of computation for Embedded System Design”
Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa REQUIREMENT SPECIFICATION Today: Requirements Specification.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 4, Requirements Elicitation.
1 Sobah Abbas Petersen Adjunct Associate Professor TDT4252 Modelling of Information Systems Advanced Course Lecture 6: Process Modelling.
Lecture Topics covered CMMI- - Continuous model -Staged model PROCESS PATTERNS- -Generic Process pattern elements.
CHAPTER ONE Problem Solving and the Object- Oriented Paradigm.
1 Introduction to Software Engineering Lecture 1.
Enterprise Systems Architectures EGN 5621 Enterprise Systems Collaboration (Professional MSEM) Fall, 2012.
OHTO -01 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it.
Design of Discrete-Event Systems Using Templates Lenko Grigorov 1, José Eduardo Ribeiro Cury 2 and Karen Rudie 1 1 Queen’s University, Kingston, Canada.
12 Chapter 12: Advanced Topics in Object-Oriented Design Systems Analysis and Design in a Changing World, 3 rd Edition.
Software Engineering1  Verification: The software should conform to its specification  Validation: The software should do what the user really requires.
1 Introduction to Design. 2 Outline Basics of design Design approaches.
The Software Development Life Cycle: An Overview
Issues in Optimal Control of Dynamic DESs Lenko Grigorov and Karen Rudie Queen’s University Kingston, Canada.
Requirement Analysis SOFTWARE ENGINEERING. What are Requirements? Expression of desired behavior Deals with objects or entities, the states they can be.
1 CEN 4020 Software Engineering PPT4: Requirement analysis.
Victorian Curriculum F–10 Online professional learning session Unpacking Digital Technologies Paula Christophersen Digital Technologies, Curriculum Manager.
Design Evaluation Overview Introduction Model for Interface Design Evaluation Types of Evaluation –Conceptual Design –Usability –Learning Outcome.
Advanced Higher Computing Science The Project. Introduction Worth 60% of the total marks for the course Must include: An appropriate interface using input.
Control of Dynamic Discrete-Event Systems Lenko Grigorov Master’s Thesis, QU supervisor: Dr. Karen Rudie.
Software Testing.
INSTRUCTIONAL DESIGN Many definitions exist for instructional design 1. Instructional Design as a Process: 2. Instructional Design as a Discipline: 3.
Project planning The systems life cycle.
Algorithms and Problem Solving
Profiling based unstructured process logs
Software Design Principles
Validating Reconfigurations of Reo Circuits
POAD Book: Chapter 8 POAD: Analysis Phase
Manufacturing system design (MSD)
Introduction to Pattern Oriented Analysis and Design (POAD)
Algorithms and Problem Solving
Programming Fundamentals (750113) Ch1. Problem Solving
Programming Fundamentals (750113) Ch1. Problem Solving
Software Modelling and Design
System architecture, Def.
From Use Cases to Implementation
Unit IV – Chapter 2 V-Test Model.
Presentation transcript:

Problem solving in control of discrete-event systems Lenko Grigorov and Karen Rudie Queen’s University Kingston, Canada

July, 2007Grigorov & Rudie, Queen's Univ.2 Content Motivation Observational study Data analysis methodology Results and discussion Future directions

July, 2007Grigorov & Rudie, Queen's Univ.3 The look of DES software

July, 2007Grigorov & Rudie, Queen's Univ.4 Problems with DES software No facilities to represent huge models meaningfully ( states) Does not support much besides performing DES algorithms Formalizing an informal model Verifying the output of algorithms Implementing supervisors

July, 2007Grigorov & Rudie, Queen's Univ.5 How to address the problems? The problems with DES software are complex No straight-forward solution Study done by Rogers et al. on diagnosis from X-rays Understand cognitive processes Use information to design software interface

July, 2007Grigorov & Rudie, Queen's Univ.6 Goal Understand human problem-solving strategy in control of DES Create a model of the cognitive process Use the model to guide the development of DES software Test the new software to validate improvements

July, 2007Grigorov & Rudie, Queen's Univ.7 Observational study 5 experts asked to solve DES problems Definition of problem: informal description Expected solution: formal model and DES supervisor(s) Use pen and paper and/or software Switch as many times as desired Verbalize thinking Performance recorded with video camera

July, 2007Grigorov & Rudie, Queen's Univ.8 Analysis approach 1.Use prior experience to create taxonomy of DES problem solving 2.Refine taxonomy from observed data 3.Encode data according to taxonomy 4.Analyse encoded form to find patterns [as per Rogers et. al.]

July, 2007Grigorov & Rudie, Queen's Univ.9 Data encoding Encoding activities along 4 main axes Type of activity Perform with pen and paper, perform with computer, verbalize... DES entity referred to Module, event, state... Stage Inspection, verification... Action Create, modify appearance, count...

July, 2007Grigorov & Rudie, Queen's Univ.10 Data analysis – application One video session encoded and analysed Two periods Pen and paper Computer Duration of activities N-gram analysis and clustering

July, 2007Grigorov & Rudie, Queen's Univ.11 Data analysis – n-grams N-gram analysis: the ratio of occurrence of a specific sub-sequence of n items in a larger sequence Sequence 'abcdbbc', 2-gram 'bc' Absolute ratio is 2/6 Relative ratio is 2/3 Relative to all n-grams which start with the same (n-1) symbols

July, 2007Grigorov & Rudie, Queen's Univ.12 Data analysis – clustering Unsupervised clustering: assign data items to separate classes No prior idea of How many classes What the criterion of distinction is Distance between items is bigger if Type of item is different Time between items is larger

July, 2007Grigorov & Rudie, Queen's Univ.13 Analysis of references Reference to entities DES modules FSA elements: states, transitions, events Computational algorithms Reference to DES modules Machines 1 and 2 Buffers 1 and 2 Testing unit

July, 2007Grigorov & Rudie, Queen's Univ.14 Output of N-gram analysis

July, 2007Grigorov & Rudie, Queen's Univ.15 Output of clustering

July, 2007Grigorov & Rudie, Queen's Univ.16 Preliminary results (1) 12 min pen and paper 7 min reading and understanding problem Rest for modeling 34 min computer 8 min (23%) improving layout of graphs Rest for input of models, DES algorithms, verification and remodeling

July, 2007Grigorov & Rudie, Queen's Univ.17 Preliminary results (2) Subject works with “chunks” of related activities Type of entity: if working on states, not likely to interrupt with work on events Module: if working on machine1, not likely to interrupt with work on machine2

July, 2007Grigorov & Rudie, Queen's Univ.18 Preliminary results (3) Subject does not consider DES algorithms if thinking at the low level of states, transitions, etc. Only when thinking at the level of modules Software seems to shape workflow Pen and paper: no predominant pattern Computer: modeling in the sequence “module, events, states, transitions” This is the sequence supported by the software

July, 2007Grigorov & Rudie, Queen's Univ.19 Discussion Discrepancies between the two periods Different stages of problem solving Software imposes constraints Graphical representation of model is very important Software not suitable for conceptual modeling Subject chose pen & paper in the beginning

July, 2007Grigorov & Rudie, Queen's Univ.20 Current research - conceptual modeling In the initial stages of design, subjects Consider participants/ sub-systems and Interactions between them

July, 2007Grigorov & Rudie, Queen's Univ.21 Current research - framework for conceptual modeling Template design of DESs Inspired by observations Library with templates of common behaviors Instantiate templates Link them No need to consider low- level details

July, 2007Grigorov & Rudie, Queen's Univ.22 Future work Analyse all video sessions Improve encoding scheme Use other analysis techniques Build model of problem-solving strategy What steps are taken What information is needed and when Use model to improve DES software

July, 2007Grigorov & Rudie, Queen's Univ.23 Queen’s University