Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Process Deviation Analyzer Prototype and Approach
Similar a Process Deviation Analyzer Prototype and Approach (20)
Más de Fahad Golra
Más de Fahad Golra (18)
Último
Último (20)
Process Deviation Analyzer Prototype and Approach
- 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 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)
- 15. Reference:MERgE/WP3/22-05-14/initials ITEA2 project #11011, 2012-201515 Tool demonstration
- 16. 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
- 17. 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
- 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 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
- 21. Reference:MERgE/WP3/22-05-14/initials ITEA2 project #11011, 2012-201521 THANK YOU
Notas del editor
- I am going to present the advancements on the tasks concerning UPMC on behalf of my team at LIP6
- 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.
- 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.
- 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.
- 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.
- 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.