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