Reference:MERgE/WP3/22-05-14/initials
ITEA2 project #11011
2012 – 2015
D3.3.1 & D3.3.2 - Traced process enactment
prototype
Fahad R. Golra, Yoann Laurent on behalf of the team
LIP6 – UPMC, Paris, FRANCE
22/05/2014
Reference:MERgE/WP3/22-05-14/initials
Status: In correction
Submitted : 15/04/2014
Re-submission after the
corrections: 09/05/2014
ITEA2 project #11011, 2012-20152
Deliverable Status D3.3.1 & D3.3.2
Status: Under-development
Submission: 4th Quarter 2014
Traced process
enactments prototype
Version 1
D3.3.1
PRODAN
Traced process
enactments prototype
Version 2
D3.3.2
PRODAN
Process Deviation Analyzer
Reference:MERgE/WP3/22-05-14/initials
ITEA2 project #11011, 2012-20153
Synergies
PRODANIntegration
Sirius, UML Designer
Case studies
Reference:MERgE/WP3/22-05-14/initials
ITEA2 project #11011, 2012-20154
What is a deviation?
 Process specification
 Normal execution trace
 Execution trace (deviation)
Design Code Source Code
Design Model Source Code
Design Code
Design Code Source CodeDesign Model
Reference:MERgE/WP3/22-05-14/initials
ITEA2 project #11011, 2012-20155
Handling deviations
Deviations exist
in process
enactment
Manage
deviations
Ignore
deviations
Restrict
deviations
Consider
deviations
Automatic
deviation
detection
Recovery
guidelines
generation
Reference:MERgE/WP3/22-05-14/initials
ITEA2 project #11011, 2012-20156
PRODAN approach
Develop / take
process model
Generate
Alloy Rule-set
Detect
Deviations
Suggest
Execution
Process
Recovery
Reference:MERgE/WP3/22-05-14/initials
ITEA2 project #11011, 2012-20157
PRODAN approach
Develop / take
process model
Generate
Alloy Rule-set
Detect
Deviations
Suggest
Execution
Process
Recovery
Design Model Source Code
Design Code
Design Code
// If design is executed, code must be executed afterward
G(design -> X code)
Response[a,b:Activity] {
// (alloy code equivalent to LTL)
}
Response[design, code]
Alloy predicate rules
LTL formulas
Rule types:
• Initial[a:Activity]
• Response[a,b:Activity]
• Precedence[a,b:Activity]
• Existence[a:Activity]
• Final[a:Activity]
Reference:MERgE/WP3/22-05-14/initials
ITEA2 project #11011, 2012-20158
PRODAN approach
Develop / take
process model
Generate
Alloy Rule-set
Detect
Deviations
Suggest
Execution
Process
Recovery
 Rules are continually evaluated during the process enactment
• Satisfied: there is no deviation impacting the rule
• Violated: a deviation occurred that made the rule false
Satisfiable: may still be satisfied in the future
Design Code Code
Existence[Desgin]
Reponse[Desgin, Code]
Existence[Code]
…..
Design Model Source Code
Design Code
Execution
Reference:MERgE/WP3/22-05-14/initials
ITEA2 project #11011, 2012-20159
PRODAN approach
Develop / take
process model
Generate
Alloy Rule-set
Detect
Deviations
Suggest
Execution
Process
Recovery
All activities that do will not violate any rule are suggested for
execution at a given time.
Reference:MERgE/WP3/22-05-14/initials
ITEA2 project #11011, 2012-201510
PRODAN approach
Develop / take
process model
Generate
Alloy Rule-set
Detect
Deviations
Suggest
Execution
Process
Recovery
 Suggesting an execution sequence that will propose a solution to
come back to the specified process, in the following priority:
 No more deviations should be encountered
 Minimal deviations should be encountered, if a solution is not available
Reference:MERgE/WP3/22-05-14/initials
ITEA2 project #11011, 2012-201511
PRODAN Architecture
Alloy Analyzer
Process Engine
//execution trace
start(design)
start(code)
finish(code)
Constraint Satisfaction
Problem
Logical Framework
Rules
Trace
Deviation
Alerts
Execution
Suggestions
Alloy
Activity
Start/Finish
Enactment Interface
Process Recovery
Version 2
Reference:MERgE/WP3/22-05-14/initials
ITEA2 project #11011, 2012-201512
Innovation at UPMC
 Automatic deviation detection mechanisms
 On the fly process recovery
 Process deviation patterns
Reference:MERgE/WP3/22-05-14/initials
ITEA2 project #11011, 2012-201513
Project progress
D 3.3.1 D 3.3.2
Q1
Q4
Reference:MERgE/WP3/22-05-14/initials
 Coverage of Process Concepts
• Dataflow, input pins, output pins, flow final node
 Deviation Patterns
• 25 patterns identified
• Currently, only 18 can be completely supported
 Scalability
• Process model size
• Process loading time
• Activity execution time
• Reduction of memory consumption
ITEA2 project #11011, 2012-201514
KPIs (rather goals)
Reference:MERgE/WP3/22-05-14/initials
ITEA2 project #11011, 2012-201515
Tool demonstration
Reference:MERgE/WP3/22-05-14/initials
 Process Case study
• Process formalization
• Process verification & validation
• Deviation Analysis
• Process Recovery
ITEA2 project #11011, 2012-201516
Current synergies
Reference:MERgE/WP3/22-05-14/initials
 Process Case study
• Process deviation risk analysis
• Declarative process modeling
 Traceability tool development
• Traceability tool architecture
• Implementation of the prototype
• Integration to SASNV demonstrator
ITEA2 project #11011, 2012-201517
Current synergies
Reference:MERgE/WP3/22-05-14/initials
ITEA2 project #11011, 2012-201518
Possible synergies
Initialization
Normal mode
PTC-mode
Fail-Safe model
Prepare
configuration
Mode navigation
Self-check /
diagnostic
Initialize internal
registers …
EEPROM initial
test
EEPROM caching Run signal processing… … …
The Triaxis software architecture - Source: Deliverable D1.1.2a
Reference:MERgE/WP3/22-05-14/initials
ITEA2 project #11011, 2012-201519
Possible synergies
 World Class Manufacturing WCM
• TPM, TQM, Six Sigma, JIT & Lean
Manufacturing
 Standardized tasks and processes
 Relentless reflection (hansei)
 Continuous improvement (kaizen)
 Automation with a human touch (Jidoka)
Thales Research
& Technology
Thales Global
Services
(source: The Toyota Way, 2006)
Reference:MERgE/WP3/22-05-14/initials
 Manual Activities in safety and security concerns?
 Implementation of individual activities. How to place these
activities in a process that is safe and secure?
ITEA2 project #11011, 2012-201520
Open questions
Reference:MERgE/WP3/22-05-14/initials
ITEA2 project #11011, 2012-201521
THANK YOU

Deviation Detection in Process Enactment

  • 1.
    Reference:MERgE/WP3/22-05-14/initials ITEA2 project #11011 2012– 2015 D3.3.1 & D3.3.2 - Traced process enactment prototype Fahad R. Golra, Yoann Laurent on behalf of the team LIP6 – UPMC, Paris, FRANCE 22/05/2014
  • 2.
    Reference:MERgE/WP3/22-05-14/initials Status: In correction Submitted: 15/04/2014 Re-submission after the corrections: 09/05/2014 ITEA2 project #11011, 2012-20152 Deliverable Status D3.3.1 & D3.3.2 Status: Under-development Submission: 4th Quarter 2014 Traced process enactments prototype Version 1 D3.3.1 PRODAN Traced process enactments prototype Version 2 D3.3.2 PRODAN Process Deviation Analyzer
  • 3.
    Reference:MERgE/WP3/22-05-14/initials ITEA2 project #11011,2012-20153 Synergies PRODANIntegration Sirius, UML Designer Case studies
  • 4.
    Reference:MERgE/WP3/22-05-14/initials ITEA2 project #11011,2012-20154 What is a deviation?  Process specification  Normal execution trace  Execution trace (deviation) Design Code Source Code Design Model Source Code Design Code Design Code Source CodeDesign Model
  • 5.
    Reference:MERgE/WP3/22-05-14/initials ITEA2 project #11011,2012-20155 Handling deviations Deviations exist in process enactment Manage deviations Ignore deviations Restrict deviations Consider deviations Automatic deviation detection Recovery guidelines generation
  • 6.
    Reference:MERgE/WP3/22-05-14/initials ITEA2 project #11011,2012-20156 PRODAN approach Develop / take process model Generate Alloy Rule-set Detect Deviations Suggest Execution Process Recovery
  • 7.
    Reference:MERgE/WP3/22-05-14/initials ITEA2 project #11011,2012-20157 PRODAN approach Develop / take process model Generate Alloy Rule-set Detect Deviations Suggest Execution Process Recovery Design Model Source Code Design Code Design Code // If design is executed, code must be executed afterward G(design -> X code) Response[a,b:Activity] { // (alloy code equivalent to LTL) } Response[design, code] Alloy predicate rules LTL formulas Rule types: • Initial[a:Activity] • Response[a,b:Activity] • Precedence[a,b:Activity] • Existence[a:Activity] • Final[a:Activity]
  • 8.
    Reference:MERgE/WP3/22-05-14/initials ITEA2 project #11011,2012-20158 PRODAN approach Develop / take process model Generate Alloy Rule-set Detect Deviations Suggest Execution Process Recovery  Rules are continually evaluated during the process enactment • Satisfied: there is no deviation impacting the rule • Violated: a deviation occurred that made the rule false Satisfiable: may still be satisfied in the future Design Code Code Existence[Desgin] Reponse[Desgin, Code] Existence[Code] ….. Design Model Source Code Design Code Execution
  • 9.
    Reference:MERgE/WP3/22-05-14/initials ITEA2 project #11011,2012-20159 PRODAN approach Develop / take process model Generate Alloy Rule-set Detect Deviations Suggest Execution Process Recovery All activities that do will not violate any rule are suggested for execution at a given time.
  • 10.
    Reference:MERgE/WP3/22-05-14/initials ITEA2 project #11011,2012-201510 PRODAN approach Develop / take process model Generate Alloy Rule-set Detect Deviations Suggest Execution Process Recovery  Suggesting an execution sequence that will propose a solution to come back to the specified process, in the following priority:  No more deviations should be encountered  Minimal deviations should be encountered, if a solution is not available
  • 11.
    Reference:MERgE/WP3/22-05-14/initials ITEA2 project #11011,2012-201511 PRODAN Architecture Alloy Analyzer Process Engine //execution trace start(design) start(code) finish(code) Constraint Satisfaction Problem Logical Framework Rules Trace Deviation Alerts Execution Suggestions Alloy Activity Start/Finish Enactment Interface Process Recovery Version 2
  • 12.
    Reference:MERgE/WP3/22-05-14/initials ITEA2 project #11011,2012-201512 Innovation at UPMC  Automatic deviation detection mechanisms  On the fly process recovery  Process deviation patterns
  • 13.
    Reference:MERgE/WP3/22-05-14/initials ITEA2 project #11011,2012-201513 Project progress D 3.3.1 D 3.3.2 Q1 Q4
  • 14.
    Reference:MERgE/WP3/22-05-14/initials  Coverage ofProcess Concepts • Dataflow, input pins, output pins, flow final node  Deviation Patterns • 25 patterns identified • Currently, only 18 can be completely supported  Scalability • Process model size • Process loading time • Activity execution time • Reduction of memory consumption ITEA2 project #11011, 2012-201514 KPIs (rather goals)
  • 15.
  • 16.
    Reference:MERgE/WP3/22-05-14/initials  Process Casestudy • Process formalization • Process verification & validation • Deviation Analysis • Process Recovery ITEA2 project #11011, 2012-201516 Current synergies
  • 17.
    Reference:MERgE/WP3/22-05-14/initials  Process Casestudy • Process deviation risk analysis • Declarative process modeling  Traceability tool development • Traceability tool architecture • Implementation of the prototype • Integration to SASNV demonstrator ITEA2 project #11011, 2012-201517 Current synergies
  • 18.
    Reference:MERgE/WP3/22-05-14/initials ITEA2 project #11011,2012-201518 Possible synergies Initialization Normal mode PTC-mode Fail-Safe model Prepare configuration Mode navigation Self-check / diagnostic Initialize internal registers … EEPROM initial test EEPROM caching Run signal processing… … … The Triaxis software architecture - Source: Deliverable D1.1.2a
  • 19.
    Reference:MERgE/WP3/22-05-14/initials ITEA2 project #11011,2012-201519 Possible synergies  World Class Manufacturing WCM • TPM, TQM, Six Sigma, JIT & Lean Manufacturing  Standardized tasks and processes  Relentless reflection (hansei)  Continuous improvement (kaizen)  Automation with a human touch (Jidoka) Thales Research & Technology Thales Global Services (source: The Toyota Way, 2006)
  • 20.
    Reference:MERgE/WP3/22-05-14/initials  Manual Activitiesin safety and security concerns?  Implementation of individual activities. How to place these activities in a process that is safe and secure? ITEA2 project #11011, 2012-201520 Open questions
  • 21.

Editor's Notes

  • #2 I am going to present the advancements on the tasks concerning UPMC on behalf of my team at LIP6
  • #3 We at UPMC are responsible for preparing two deliverables in this project. These deliverables concern a prototype for process enactment, which can detect deviations during the process execution. We have named this tool, PRODAN Process deviation Analyzer. The first deliverable was submitted for review around mid-April and it is re-submitted after corrections. The second deliverable is under development and is due by the end of current year.
  • #4 PRODAN can be integrated with the latest version of Merge platform. Our tool uses Sirius and and UML designer from Obeo to model our processes. Currently we are working on two industrial case studies with our tool: one from space application services and the other from nsense.
  • #5 Lets say we have a process model for software development activities. The normal execution should be first activity, its artifacts, second activity and its artifacts. But in case we start second activity before we the first activity produced its artifacts would be considered as a deviation from the standard model.
  • #6 Empirical studies suggest that deviations are very very common in process enactments. What matters is how we respond to it. We have multiple possibilities to handle these deviation. We can ignore them. But then there will be a lot of gap between what we show and what we do. And we loose all the benefits of using the process at the first place. So we can consider deviations during process enactment. In this case we have the possibility to restrict the the user from deviating from the specified process. But this is very constraining and it is hard to deal with unexpected situations. So the final choice is to consider the deviations and allow user to deviate where it is unavoidable. However, we have to develop a mechanism to manage these deviations.
  • #19 With the surface knowledge that we have about this complete process, we can say that it holds some properties that ensure safety and security of the system. By modeling the complete system in our Validation tool, we can guarantee that the model holds certain properties e.g. we can guarantee that it is free from all deadlocks.