Modelbased approaches for the design of safety critical interactive systems

1
Model-based approaches for the design of safety
critical interactive systems

• Philippe Palanque
• LIIHS-IRIT
• University Paul Sabatier
• Toulouse France
• http//liihs.irit.fr/palanque
• palanque_at_irit.fr

Rio de Janeiro 18-19 september 2007
2
Overview of the lectures

• Overview of LIIHS Research Group
• State of the art in MBA for HCI
• System modeling
• Task modeling
• Design rationale
• Research Themes and Productions
• A Roadmap on FM HCI

3
A bit of History about LIIHS
1 - Overview of LIIHS

• Started in 1988 at University Toulouse 1 (law and
  economics) gathering all the computer scientists
  at UT1
• In 1993 main research theme is HCI and name
  changed to LIHS (group size about 15 people)
• From research on software engineering
  methodologies
• From research on notations for modeling
  activities
• 20 PhDs

4
Research at LIIHS
1 - Overview of LIIHS

• Mono-disciplinary research Human Computer
  Interaction
• Computer Scientists,
• Human Factors, Ergonomics,
• HCI specialists
• Special point of view Software Engineering for
  Human-Computer Interaction
• Usability (methods for design and evaluation of
  computer systems)
• Reliability (formal specification, human error
  assessment, )
• Traceability (Design rationale)
• Special application domain (safety) critical
  interactive systems cost of development much
  lower than the cost of a failure

5
Safety Critical Interactive Systems
1 - Overview of LIIHS

• Safety Critical Systems
• Software Engineers
• System centered
• Reliability
• Safety requirements (certification)
• Formal specification
• Verification / Proof
• Waterfall model / structured
• Archaic interaction techniques

• Interactive Systems
• Usability experts
• User centered
• Usability
• Human factors
• Task analysis modeling
• Evaluation
• Iterative process / Prototyping
• Novel Interaction techniques

6
Modeling

• Tasks models
• Abstract description of users' planned activities
  (goal)
• Scenarios
• Concrete description of users' planned activities
• Temporal organization of actions (and related
  information)
• System models
• Both structure (object oriented approach) and
  behavioral description
• How user's actions change system state
• How system state (rendering)
• Reduces authorized user's actions
• Is presented to the user
• Designing options rationally

7
Research Projects
1 - Overview of LIIHS

• Current projects
• ReSIST EU Network of Excellence Project
  (Resilience for Information Society)
  (01-2006/12-2008)
• COST NSF EU action MAUSE (Maturing Usability)
  (01-2005/12-2008)
• Recently completed
• INTUITION Project (Multimodal Interfaces military
  aircrafts) (02-2003/02-2006)
• MISC Project (Multimodal Interfaces for
  Safety-critical Command and Control)
  (01-2003/01-2007)
• Research Training Network EU ADVISES (11-2002/
  12-2006)
• Capes/ Cofecub SPIDER WEB (07-2002/07-2005)
• Previous relevant projects
• DoD Drones Project (Unmanned Aerial Vehicles)
  (03-2001/09-2002)
• EUD-Net EU Network of Excellence
  (07-2002/07-2002)
• EVALWEB Project Building ergonomic web sites by
  design (1999-2002)
• Project CNET SERPICO Specifications for CORBA
  Components Engineering (1998-2001)
• Esprit Project LTR MEFISTO n24963 Modeling
  Evaluation and Formalizing Interactive Systems
  using Tasks and Objects (1997-2001)
• ERGOVAL (1995)

8
EvalWeb
1 - Overview of LIIHS

• 1998-2002
• Ergonomic application web by design
• Partners Univ. Louvain la neuve (J.
  Vanderdonckt) INRIA (D. Scapin)
• Funding CNRS GIS Cogniscience (1999)

9
MEFISTO (overview)

• Modeling, Evaluating and Formalizing Interactive
  Systems using Tasks and interaction Objects
•  ESPRIT Reactive LTR 24963 Project (EC)
• Air Traffic Control domain
• Multi disciplinary team
• Computer Scientists (F. Paterno CNUCE, LIIHS)
• Psychologists (P. Wright Univ. York, P. Marti
  Univ. Sienna)
• Industrial partners (DERA UK, CENA F, Alenia I)
• Users (ENAV I ATC association)

10
UAV Project (1/2)
1 - Overview of LIIHS
11
UAV Project (2/2)
1 - Overview of LIIHS

• Design, implementation and evaluation of user
  interfaces for drones command and control
• Performance and user capabilities
• Authority sharing
• From several controllers per drone to one
  controller for several drones

12
MISC Project
1 - Overview of LIIHS

• Multimodal Interaction for Command and Control of
  Safety critical Systems
• Starting beginning 01/2003
• Finances DGA (French Department of Defense ,
  CNES (National center for spatial studies), and
  LIIHS

13
Project SPIDER WEB
1 - Overview of LIIHS

• Specification and Prototyping for user Interface
  Design, Engineering and Re-engineering for the
  Web
• France- Brazil cooperation
• Partners LIIHS and Instituto de Informatica
  (Porto Alegre)
• Beginning Feb. 2002
• In conjunction with a CNPq funding of Marco
  Winckler PhD about "model-based approaches for
  wed application evaluation"

14
ADVISES Analysis Design and Validation of
Interactive Safety-critical and Error-tolerant
Systems

• Type de projet Research Training Network
• Sponsors EU (Fifth Framework Improving Human
  Potential Programme)
• 8 sites Delft University of Technology (NL),
  ISTI-CNR(I), Risø National Laboratory (DK),
  Université de Liège (B), Université Paul Sabatier
  Toulouse (F), University of Glasgow (UK),
  University of York (UK), Universität Paderborn
  (D)
• Objectifs
• Étudier et développer des méthodes outils et
  techniques pour l'analyse, la conception et la
  validation de systèmes interactifs fiables et
  tolérants aux erreurs humaines
• Principes
• Approche pluridisciplinaire intégrant des
  spécialistes facteurs humains (ergonomie
  cognitive, psychologie du travail) des
  spécialistes informatiques (génie logiciel,
  méthodes formelles, approches à objets et
  distribuées) des spécialistes en interaction
  homme-machine (méthodes de conception centrée
  utilisateur) et des spécialistes en systèmes
  critiques (analyse d'incidents/accidents,
  systèmes embarqués civil et militaires,
  nucléaire)
• Formation à la recherche et par la recherche
• Formation des jeunes chercheurs dans ces domaine
  par la mobilité au sein du réseau

Durée (4 ans) Oct. 02 ? Oct. 06
Budget LIIHS 160 K HT
15
EUD-Net
1 - Overview of LIIHS

• The EUD-NET Network of Excellence is financed by
  European Community and started in July, 1st 2002.
  
• Goal help the European Commission to prepare a
  research agenda in the end-user development field
• Related to previous work on notations and tools
  for visual programming

16
Project INTUITION

• Financed by DoD. THALES avionic in charge. LIIHS
  team 240K HT.
• Start January 2003. 3 years
• Definition and construction of a platform for the
  design, specification and development of
  multimodal interactive systems
• Application domains
• Rafale Cockpit
• Air Traffic Control multimodal Interfaces

17
Cockpit Rafale
Visu tête haute
Ecran tactile
Joystick
18
MAUSE Towards the MAturation of Information
Technology USability Evaluation

• Type de projet action COST
• Sponsors ESF (European Science Foundation) et
  COST (European Cooperation in the field of
  Scientific and Technical research)
• 19 pays UE (AT, BE, CY, CZ, DK, FI, FR, DE, GR,
  IS, NL, NO, PL, RO, SI, ES, SE, CH and UK)
• Objectifs
• Étudier, développer, évaluer et comparer les
  Méthodes dEvaluation de lUtilisabilité (MEU)s
• Activités
• WG 1 Révision et Analyse de (MEU)s
• WG 2 Comparaison de (MEU)s Stratégies et
  Implémentation
• WG 3 Validation de Schèmes de Classification de
  Problèmes dutilisabilité
• WG 4 Révision des approches assistées par
  lordinateurs pour lévaluation de
  lutilisabilité
• (SIG) E-Learning
• Dissémination de résultats (Coordination)
  LIIHS-IRIT, P. Palanque, M. Winckler

Durée (4 ans) Déc. 04 ? Nov. 08
Budget Défini en fonctions des missions et des
activités des participants
19
ReSIST
1 - Overview of LIIHS

• http//www.resist-noe.eu/
• Resilience
• Diversity
• Usability
• Evolvability
• Assessability
• DependabilitySafetySecurityUsability
• Duration 3 years

20
Members of LIIHS working in that field
1 - Overview of LIIHS
Regina BERNHAUPT Visiting Professor
Joseph Xiong PhD Student 4th year
Jean-François LADRY PhD Student 1st year
Eric BARBONI Post Doc
Florence Pontico PhD Student 4th year
Sandra BASNYAT Post Doc
21
Outline of the presentation

• Overview of LIIHS Research Group
• State of the art in MBA for HCI
• Specificities of Interactive System
• What is modeling?
• What kind of modelling in HCI?
• What has still to be done?
• System modelling
• Task modelling
• Design rationale
• Research Themes and Productions
• A Roadmap on FM HCI

22
Interactive Systems
2 State of the art
23
"Classical" Design Process SS
2 State of the art
Informal requirements
Manual
Spec 1
...
Specification
Spec n
Design 1
Design
...
Design n
User testing
Prog. 1
Coding
...
Prog. n
24
What is a "Model" ?
2 State of the art

• Concepts relationships between concepts
• Example Entity Relationship Model
• Concepts Entity types, Relationship Types,
  Attributes, Domain of Values, Identifiers, ...
• Relationships between concepts "A Relationship
  type is a sub set of the Cartesian product of two
  Entity Type"
• An entity e1 cannot have more than one
  relationship with another entity e2 through the
  same relationship type

25
What can we Expect from a Model ?
2 State of the art

• Completeness (we can express all the information
  we need to)
• Consistency (Contradictory elements cannot be
  expressed)
• Generality (Independent from a given application
  domain always ?)

26
What is a "formalism" ?
2 State of the art

• A set of conventions for representing the
  concepts of a Model
• Lexical elements (graphical or textual)
• Concrete Syntax (separators, terminators, ...)
• A formal definition of these conventions
  (otherwise just a notation)

Person
Flat
0,n
1,1
Owns
27
What can we expect from a "formalism" ?
2 State of the art

• Expressiveness
• Conciseness
• Closeness of the representation to the
  application domain
• Completeness wrt the Model (counter example
  Graphical formalism of the Entity Relationship
  Model)
• L. Lamport "the only difficult problem the author
  solved was understanding his own notation"
• L. Lamport "Automaton is a formal description
  technique dedicated to the specification of
  stacks"

28
Bug With a "Formalism" we build "models"
Modelling
2 State of the art

• model ideal representation of a given situation
  form the real world restrained to the concepts
  covered by the Model
• Goal analyze the model to draw conclusions about
  the actual state of the real world
• Meta-model model representing the concepts of
  the Model using the formalism (done for E/R and
  UML using class diagrams)

29
What and why modeling systems?
2 State of the art

• An abstract description of the system
• independent from the implementation
• that do not deal too early with details
• Describe what are the outputs of the system
  according to the inputs
• To allow discussions between the various actors
  (at a time, along the design process)
• to store results of discussions

30
What is a system model for Interactive Systems ?
2 State of the art

• Represents the system data and actions
• Represents behaviour of the system
• what actions are offered by the system
• when an action is available (according to the
  state of the system)
• what is the effect of an action on the state of
  the system
• Represents both how the system is presented to
  the user and how the user interacts with it

31
Design process for IS ?
2 State of the art
Informal requirements
Manual
Spec 1
Goal 1
User requirements
...
Specification
...
Spec n
Goal n
Design 1
Task 1
Task Analysis
Design
...
...
Design n
Task n
User testing
Prog. 1
Coding
...
Prog. n
32
Why Modelling Interactive Systems Formally ?
2 State of the art

• To cope with the complexity
• To avoid a human observer (checking models)
• To avoid a human translator (writing code)
• To reason (verification, validation)
• To meet three basic requirements
• Reliability generic and specific properties
• Efficiency performance of the system, the user
  (workload, ) and the couple (user, system) tasks
• Usability

33
Design process using FM
2 State of the art
Automatic
Informal requirements
Manual
Spec 1
Verification
...
Specification
Spec n
Validation
Design 1
Design
...
Generic properties
Verification
Design n
Informal validation
Coding
Prog. 1
...
Progr.
Gener.
Prog. n
34
The design process of models
2 State of the art
35
Examples of models (requirements)
2 State of the art

• A need for a declarative formalismRequirements
• Every clearance sent by a controler to a plane p
  is received by this plane
• " p Planes, " req DLRequest,
• AGsend(req,p)AFltreceive(req,p)gttrue
• A data-link clearance sent by a controler to a
  plane p will only be received by that plane
• " p,p' Planes, " req DLRequest,
• AGsend(req,p)AGnot(receive(req,p')true

36
Temporal Logic CTL (Computational Tree Logic
Star)
2 State of the art

• A state has one or mode successors
• The set of possible states is infinite
• Operators
• A (all the possible future) E (one possible
  future) F eventually, G always, X next, U
  until
• Logical connectors
• ? (and) ? (or) ? (not) ? (implies)

37
Temporal Logic CTL
2 State of the art
si
si AGp
si AFp
si
si EGp
si EFp
p formula is true if the system is in red state
false otherwise
38
Temporal Logic CTL
2 State of the art
si
si
si AXp
si EXp
si
si
si E(p U q)
si A(p U q)
39
Relating tasks and system
2 State of the art
Maintain task and system
models consistency
Formal task modelling
Formal system modelling
Preliminary
Preliminary
th
th
system model
i
iteration
i
iteration
task model
Quantitative
analysis
Ok
Towards
Not Ok
Proposals for
Check
Usability
improving the
Objectives
Testing
system model
40
Proving compatibility of models
2 State of the art

• All the objects in the tasks model are part of
  the data model of the system model
• All the actions in the tasks model are offered by
  the system model
• All the actions in the system model exist in the
  tasks models
• All the sequences of actions in the tasks model
  are "legal" in the system model

41
Fundamental elements for formal methods for IS
2 State of the art

• Describe both state and events
• Describe both data structure and control
  structure
• Provide structuring mechanisms (80 of the code
  is dedicated to UI Myers 90)
• Take into account concurrency (multimodal
  systems)
• Deals with temporal aspects (temporal windows)
• Do it formally (it is easier to prove than to
  test)

42
State versus Events (Dix 91)
2 State of the art

• Reactive systems
• Event driven
• Slicing of code into event handlers require
  explicit state representations
• Approaches
• Approaches coming from Reactive Systems
• Reactive or synchronous languages (esterel,
  Lotos)
• Methodological use of Petri nets

43
Data Structure / Control Structure
2 State of the art

• Software crisis has shown limitations of
  separation (maintainability, modifiability,
  reusability, ...)
• Approaches
• Mix two dedicated approaches (CSP-Z, Object-Z, )
  
• Integrate two approaches (Full LOTOS, Petri nets
  with objects)

44
Structuring Mechanisms
2 State of the art

• Handling of complex components
• Understandability of models
• Reusability
• Modifiability
• Approaches
• composition (aggregation, association, )
• communication (client-server, actors)
• macros and plugs

45
Concurrence
2 State of the art

• Concurrency between input and output devices (
  multimodality)
• Groupware
• Multi threaded dialogues
• Approaches
• Textual formalisms (CSP, CCS, LOTOS, Temporal
  Logic)
• Graphical formalisms (Petri nets, Statecharts)
• Only Petri nets feature full concurrency semantics

46
Temporal Aspects
2 State of the art

• Multimodal systems
• Animation (time based evolution)
• Alarms
• Calendar events
• Approaches
• Procedural (Petri nets, Lotos, ... )
• Declarative (Temporal Logics, ...)

47
Formal Aspects
2 State of the art

• Easier to prove than to test
• Critical Systems
• Completeness, concision et non-ambiguity
• Executability
• Approaches
• Mathematical validation
• Test case generation
• Automatic code generation

48
A Small Example/Exercise

• Model of a Mouse behaviour (one button, no wheel)
• Model of the interaction technique
• Click
• Double click
• Extensions
• Several buttons
• Behaviour of the wheel
• Several mice

49
A Small Example
2 State of the art

• Requirement
• Whatever state the system is in, Move is always
  available

50
A Small Example
2 State of the art
51
A Small Example
2 State of the art
Adding Time
52
A Small Example
2 State of the art
Taking Movements into account
53
State of the Art in FM for HCI
2 State of the art

• Understanding interactive systems
• What is an IS ?
• What are the generic properties of IS ?
• Specific properties of IS ?
• Engineering interactive systems
• What are the components of IS ?
• How to model components and their relationships ?
• Relationships with design process ?

54
Understanding IS
2 State of the art

• Generic architectures for IS
• PIE and red-PIE models (Dix 91)
• Seeheim (Green 85) and Arch/Slinky (Bass 92)
• Generic properties for IS
• (Sufrin He 90), (Dix 91)
• External and internal prop. (Gram Cockton 96)
• Between understanding and engineering
• CNUCE interactors (Paternò Faconti 92)
• York interactors (Duke Harrison 93)

55
Engineering IS
2 State of the art

• Dialogue modelling WIMP
• (Bastide Palanque 90)
• (Beck et al. 95)
• Model-Based UIMS (WIMP) (CADUI'96)
• UIDE (Foley et al. 93)
• Tadeus (Elwert Schlungbaum 95)
• PetShop (Bastide Palanque 95)
• TRIDENT (Vanderdonckt 95)
• Design Patterns PAC (Coutaz 87) MVC
• Model-Driven Interactive Systems Engineering
  (Vanderdonckt 2002, Paterno 2004) targeting at
  multiplatform UI (One model many interfaces)
  Paterno 98

56
Generic properties
2 State of the art

• Generic properties for Software Systems
• Liveness
• Safety
• Ability to wear
• Generic properties for Interactive Systems
• Predictability
• Observability
• Reachability
• Insistence
• Honesty,

57
Verification of properties
2 State of the art

• Observability
• the system makes all relevant information
  potentially available to the user
• Insistence
• the dialogue structure ensures that necessary
  information is perceived
• Predictibility
• users can predict future states and system
  response time from current and prior observable
  states

58
References (books)
2 State of the art

• Formal Methods in HCI, Harrison Thimbleby 90,
  Cambridge University Press
• Formal Methods for Interactive Systems, Dix 91,
  Cambridge University Press
• Formal Methods in HCI, Palanque Paterno 97,
  Springer Verlag

59
References (conferences)
2 State of the art

• Eurographics workshops DSV-IS (Design,
  Specification and Verification of Interactive
  Systems) since 94 published by Springer Verlag
  (LNCS)
• CHI 96 workshop on Formal Methods and HCI
• CHI 98 workshop on designing user interfaces for
  safety critical systems
• CHI 05 SIG on Safety Critical Interaction
• CHI 07 SIG Beyond Usability for Safety Critical
  System
• HCI Aero 2000 SUCA (Safety and Usability concerns
  in Aeronautics)
• Mini-track of World Congress on FM 99
• FMIS workshop series (Formal Methods for
  Interactive Systems)
• MDAUI workshop series at MODELS conference
  (formerly UML conference)

60
References (journals)
2 State of the art

• No dedicated journal
• Software engineering journals
• HCI journals
• Some "special issues"
• Interacting with Computers vol 9, n3, 1997
• Journal of Visual Language and Computing (vol 10,
  n3, 1999)
• ACM Transactions on Computer Human Interaction
  (2001)

61
Research Work carried out at LIIHS
62
Outline of the presentation

• Overview of LIIHS Research Group
• State of the art in FM for HCI
• Research Themes and Productions
• Formalisms and tools
• Demos
• A Roadmap on FM HCI

63
Main Results Relevant to FM in HCI
3 Research results

• Vilage (work with S. Chatty at CENA)
• A notation Whizz
• A case tool Whizz'ed
• SpiderWeb (work with Marco Winckler)
• A notation StateWebCharts
• A tool SWC Environment
• PetShop
• A formal notation ICOs
• A case tool PetShop
• User-centered design methods
• Linking tasks, scenarios, system and user models
• Design rationale (lecture on that topic on
  Wednesday morning)

64
VILAGE (1)
3 Research results

• Initially developed for Air Traffic Controllers
• Interactive prototyping of highly interactive
  applications (post-WIMP)
• Build and test prototypes in a modeless way

65
VILAGE (2)
3 Research results

• A data flow model
• A set of basic building bricks
• Strongly typed connection
• Event listeners

POINT
POINT
S
e
g
m
e
n
t
T
e
m
p
o
T
r
a
j
e
c
t
o
ire
66
VILAGE (3)
3 Research results
Tool Palete
Dialogue Zone
Editing Zone
Simulation Zone
67
Overview of the Interactive Cooperative Objects
(1)
3 Research results

• Petri nets with objects
• Petri nets inside objects
• Objects inside Petri nets
• Petri nets for dynamic aspects
• Objects for structuring
• Specific aspects for Interactive Systems
• Activation
• Rendering
• Tool support
• Editing, Execution, Analysis, Prototyping

68
Overview of the Interactive Cooperative Objects
(2)
3 Research results

• Set of cooperating classes
• For each class
• Behaviour (places and transitions) in the Petri
  net
• Software Services (availability)
• States (distribution AND value of tokens)
• Presentation
• Rendering function
• Activation function
• User services

69
Verification
3 Research results

• What ?
• Safety nothing bad will ever happen
• Liveness something good will eventually happen
• "Smooth functioning"
• "good cooperation between Models"
• Efficiency (both local and global)
• How ?
• Based on Petri nets theory (the basic brick of
  our system modelling technique)
• Cross execution of models
• Performance evaluation techniques

70
PetShop Fundamental Principles
3 Research results

• Highly interactive tool support for the ICO
  notation
• Formal methods can be usable (and useful beyond
  n! calculation)
• Shortening the Path from Specification to
  Prototype
• to practically nothing
• Model-Based
• The specification model is embedded and
  interpreted at run-time WYMIWYR (what you model
  is what you run) to reduce gaps in interpretation
  (Norman's model)
• No Modes no automation surprises
• The model is editable and interpretable at any
  time
• Allows for interactive prototyping of new
  interaction scenarios

71
PetShop Architecture
3 Research results
72
(No Transcript)
73
Requirements
3 Research results

• A voice request sent to a plane p is received by
  all the planes in the sector
• " p Planes, " req VRequest,
• send (p, req) " p' Planes, receive (p', req)
• It is not possible to build several orders at a
  time
• " p Planes, " req, req' DLRequest,
• AFstart_send(req,p)ATruenot(start_send(req',p)
  U(end_send(req,p)true

74
A demonstration ?
75
ATM in France
3 Research results

• Systems currently used
• A radar screen
• A board of paper strips
• Limited interaction with the radar screen (zoom)
• Few systems - a lot of prototypes

76
ATM
3 Research results
77
An Air Traffic Management Case Study Current
System
3 Research results

• VHF communication
• all the pilots listen to all the communications
• limited bandwidth
• low quality
• Manual stripping
• the controller has to write down by hand all the
  information given to pilots
• only a note pad and an aide memoire

78
Envisioned ATM System
79
A demonstration !
80
User Centered Design Methods
81
User Centered Design Methods
3 Research results
Mapping
A demonstration ?
Input
82
Routine Scenario
3 Research results

• Several aircrafts in my sector
• I assume two of them
• I have to transfer both of them
• 2 slips then first aircraft transferred
• Second plane directly transferred

83
A small case study a timer controlled light
switch
3 Research results

• The system
• use of a timer controlled switch (30 sec period)
• very simple
• hardware based (but same as screen saver)
• Users goal
• maintain the light on 3 minuts
• dont press the button more than necessary
• Two iterations on the life cycle

84
Task model
3 Research results

• What ?
• both activity and planned tasks
• based on the notion of goal
• several task models for a given goal
• sequence of users actions on the system
• How ?
• temporal relationships in Petri nets
• invocation of actions offered by the system

85
User Model
3 Research results

• Only basic user Models (human processor)
• Possibility to describe user learning
• Cooperation and/or merging with tasks and system
  models
• Currently working on higher level user models
  (ICS)

86
Initial System
3 Research results

• the light bulb
• the timer
• not possible to reach the goal

87
First Improvement
3 Research results

• Add a stop-watch
• Require hand and eyes

WatchOff
Press
Press
WatchOn
CurrentTime
lttgt
88
The Task model
3 Research results
t gt 25
T1
ReadyTo
P1
StopWatch

• Goal reachable
• Really complex for the user

Watch.Press
CountDown
T2
ReadyTo
StartLight
ReadyTo
P2
P3
P4
StartWatch
Watch.Press
lttgt
Light.PressSwitch
T4
T3
Light
Started
Watch
Started
CurrentTime
P6
P7
P5
lttgt
StartCounting
t lt 25
T6
lttgt
T5
lt0gt
lttgt
T7
ReadyTo
lttgt
t
Watch.CurrentTime
ReadTime
P8
89
Second Improvement
3 Research results

• Add a bell
• Remove stop watch

PressSwitch
AutoSwitchOff
5
LightOn,
AutoBeep
Beeping
25
PressSwitch
PressSwitch
90
The Task model
3 Research results

• Less complex
• Less pooling

Start/ Elapsed
CountDown
Light.PressSwitch
Waitting
Hear beep
91
User model
3 Research results

• The perceptual system
• boundary with the environment
• eye between 50 and 200 ms (average 100 ms)
• The motor system
• physical mouvement
• hand between 30 and 100 ms (average 70 ms)
• The cognitive sytem
• interface between motor and perceptual
• brain between 25 and 125 ms (average 70 ms)

92
Performance Evaluation of the first System
3 Research results
(0,n,1,1,0,0,0,0)
T3 / ngt1
T4
nn-1
(0,n,0,1,0,1,0,0)
(0,n,1,0,0,0,1,0)

• based on marking graph of the Petri net
• based on the previous user model
• Initial state n7

T3 / ngt1
T4
nn-1
(0,n,0,0,0,1,1,0)
T6
(0,n,0,0,0,0,0,1)
T5
T7
(0,n,0,0,1,0,0,0)
T1
(1,n,1,0,0,0,0,0)
T3 / ngt1
T2
nn-1
(0,n,1,1,0,0,0,0)
(1,n,0,0,0,1,0,0)
T3 / ngt1
T4
T3 / ngt1
nn-1
T2
nn-1
T4
(0,n,0,1,0,1,0,0)
(0,n,1,0,0,0,1,0)
93
Performance Evaluation of the first System (2)
3 Research results
T1
Cognitive
Comparison of values
T2
Motor
Press button (Stop Watch)
T3
Motor
Press button (Light)
T4
Motor
Press button (Stop Watch)
T5
Cognitive
Comparison of values
T6
-
Nothing
T7
Perceptual
Look at the Stop Watch
94
Performance Evaluation of the second System(1)
3 Research results
T1
Motor
Press button (Stop Watch)
T2
Perceptual
Hear the beep
95
Results
3 Research results

• First upgrade
• Min Time (Goal) 7165 60 1205 ms
• Mean Time(Goal) 7380 140 2800 ms
• Max Time(Goal) 7625 200 4575 ms
• Second upgrade
• Min Time (Goal) (830) (750) 590 ms
• Mean Time(Goal) (870) (7100) 1260 ms
• Max Time(Goal) (8200) (7100) 2300 ms

96
(No Transcript)