Invited presentation given by Niels Lohmann on June 27, 2006 in Turku, Finland as part of the Advanced Tutorial on Petri Net Modelling of Business Processes; satellite event of the PETRI NETS 2006/ACSD 2006 conferences.
service-technology.org — A tool family for correct business processes and ser...Universität Rostock
Tool demonstration given by Niels Lohmann on September 16, 2010 in Hoboken, NJ, USA at the Eighth International Conference on Business Process Management (BPM 2010).
The document discusses applying counterexample guided abstraction refinement (CEGAR) to verifying properties of Petri nets. It summarizes using the Petri net state equation to represent reachable markings as solutions to a system of linear equations. It then describes using CEGAR to iteratively check solutions and refine the abstraction by adding increments when solutions are found to be infeasible. The approach is implemented in a tool called Sara which shows better performance than other tools on verification problems involving large Petri nets and parameterized systems.
Workshop presentation given by Niels Lohmann on August 16, 2007 in Eindhoven, The Netherlands at the Berlin-Eindhoven Service Technology Colloquium 2007 (B.E.S.T. 2007).
This document discusses diagnosing uncontrollability in services. It explains that uncontrollability can have many different reasons and is independent of specification language. It presents patterns that can cause uncontrollability and discusses the relationship between uncontrollability and soundness. The document proposes an algorithm to diagnose uncontrollability by partitioning graphs into "good" and "bad" parts and analyzing how moves occur from good to bad. Blacklists are used in the algorithm to identify issues like deadlocks.
Correctness Ensuring Process Configuration: An Approach Based on Partner Synt...Universität Rostock
This document discusses configurable process models and correctness of process model configurations. It presents an approach to characterize the set of all correct configurations of a configurable process model based on partner synthesis. The document uses examples of blocking and hiding transitions in a process model to illustrate how to determine if a particular configuration is correct and discusses questions around determining the set of all correct configurations and automatically completing a partial configuration.
Where did I go wrong? Explaining errors in process modelsUniversität Rostock
Workshop presentation given by Niels Lohmann on February 20, 2014 in Potsdam, Germany at the Sixth Central-European Workshop on Services and their Composition (ZEUS 2014).
Extending the Compatibility Notion for Abstract WS-BPEL ProcessesUniversität Rostock
Conference presentation given by Niels Lohmann on September 2, 2008 in Milan, Italy at the Sixth International Conference on Business Process Management (BPM 2008).
service-technology.org — A tool family for correct business processes and ser...Universität Rostock
Tool demonstration given by Niels Lohmann on September 16, 2010 in Hoboken, NJ, USA at the Eighth International Conference on Business Process Management (BPM 2010).
The document discusses applying counterexample guided abstraction refinement (CEGAR) to verifying properties of Petri nets. It summarizes using the Petri net state equation to represent reachable markings as solutions to a system of linear equations. It then describes using CEGAR to iteratively check solutions and refine the abstraction by adding increments when solutions are found to be infeasible. The approach is implemented in a tool called Sara which shows better performance than other tools on verification problems involving large Petri nets and parameterized systems.
Workshop presentation given by Niels Lohmann on August 16, 2007 in Eindhoven, The Netherlands at the Berlin-Eindhoven Service Technology Colloquium 2007 (B.E.S.T. 2007).
This document discusses diagnosing uncontrollability in services. It explains that uncontrollability can have many different reasons and is independent of specification language. It presents patterns that can cause uncontrollability and discusses the relationship between uncontrollability and soundness. The document proposes an algorithm to diagnose uncontrollability by partitioning graphs into "good" and "bad" parts and analyzing how moves occur from good to bad. Blacklists are used in the algorithm to identify issues like deadlocks.
Correctness Ensuring Process Configuration: An Approach Based on Partner Synt...Universität Rostock
This document discusses configurable process models and correctness of process model configurations. It presents an approach to characterize the set of all correct configurations of a configurable process model based on partner synthesis. The document uses examples of blocking and hiding transitions in a process model to illustrate how to determine if a particular configuration is correct and discusses questions around determining the set of all correct configurations and automatically completing a partial configuration.
Where did I go wrong? Explaining errors in process modelsUniversität Rostock
Workshop presentation given by Niels Lohmann on February 20, 2014 in Potsdam, Germany at the Sixth Central-European Workshop on Services and their Composition (ZEUS 2014).
Extending the Compatibility Notion for Abstract WS-BPEL ProcessesUniversität Rostock
Conference presentation given by Niels Lohmann on September 2, 2008 in Milan, Italy at the Sixth International Conference on Business Process Management (BPM 2008).
Reactive solutions using java 9 and spring reactorOrenEzer1
This document discusses reactive programming concepts using Java 9 and Spring Reactor. It introduces reactive streams interfaces in Java 9 like Publisher, Subscriber, and Subscription. It then covers Spring Reactor implementations of these interfaces using Mono and Flux. Code examples are provided for creating simple reactive streams and combining them using operators. The threading model and use of schedulers in Spring Reactor is also briefly explained.
The document discusses code optimization techniques in compilers. It covers the following key points:
1. Code optimization aims to improve code performance by replacing high-level constructs with more efficient low-level code while preserving program semantics. It occurs at various compiler phases like source code, intermediate code, and target code.
2. Common optimization techniques include constant folding, propagation, algebraic simplification, strength reduction, copy propagation, and dead code elimination. Control and data flow analysis are required to perform many optimizations.
3. Optimizations can be local within basic blocks, global across blocks, or inter-procedural across procedures. Representations like flow graphs, basic blocks, and DAGs are used to apply optimizations at
openERP- How to connect OpenERP with external Systems, AkretionAkretion base...Odoo
This document discusses how to connect OpenERP with external systems using base external referential modules. It provides examples of connectors that have been developed including MagentoERPConnect, PrestashopERPConnect, and FileExchange. It describes how the base modules support multi-referential connections, flexible mappings, error reporting, and optimization of data synchronization between systems. Roadmaps are given for ongoing connector projects, and how various modules utilize the base referential frameworks.
Nagios Conference 2007 | Enterprise Application Monitoring with Nagios by Jam...NETWAYS
IT infrastructure such as switches and servers is the traditional focus of network monitoring tools. Increasingly organisations are focusing on monitoring business critical applications sitting on top of this infrastructure.
Altinity have deployed their Opsview software in a number enterprise environments to ensure availability of business critical applications and capture data for capacity planning. We will explain how we approach monitoring in these environment and what challenges we encounter. Opsview is an Open Source monitoring solution based on Nagios. Altinity are the commercial organsiation behind Opsview.
Benjy Weinberger, one of the maintainers of the Pants build system, spoke at PyCon Israel 2021 about the monorepo codebase architecture, its advantages for Python repos, and the tooling needed to work effectively in a monorepo.
The document discusses production planning topics and provides an example of a typical production cycle in a process industry. It outlines the key steps in a production cycle as: 1) Creating a process order, 2) Releasing the process order for production, 3) Goods issue from stores, 4) Starting processing, 5) Confirming production output, 6) Goods receipt, 7) Quality approval and release, and 8) Stock appearing in unrestricted use for sale or further processing. The document then provides details on required masters, transactions, and an example scenario to demonstrate setting up and executing a production cycle.
This document provides an overview of the key transactions and processes used in process manufacturing in SAP. It describes the master data needed such as materials, resources, recipes, quality inspection characteristics, and quality plans. It then outlines the basic production cycle including creating a process order, goods issue, confirmation, goods receipt, quality approval, and stock release. Key transactions referenced include COR1, MIGO, CORK, QA32, and more. The production cycle explained focuses on production and quality management for a process manufacturing company.
This document provides an overview of several R&D projects at OpenERP including Apps, release policy, packaging, R&D processes, and the Web Client version 6.1. It discusses the OpenERP Apps platform, release cycles, packaging for different operating systems, bug and project lifecycles, and monitoring tools. It also provides details on the new Web Client 6.1 which features a cleaner architecture, improved performance, modularity, and support for mobile and embeddable apps. Upcoming workshops are announced for discussing ideas on areas like CRM, payroll, and the Web Client.
This document discusses processes and process management in operating systems. It covers key topics such as:
- Process states including new, running, ready, waiting, and terminated.
- Process representation using Process Control Blocks (PCBs) which contain process state and scheduling information.
- Process scheduling with long-term, short-term, and medium-term schedulers that move processes between queues.
- Interprocess communication (IPC) which allows processes to communicate and synchronize, using both direct and indirect communication with mailboxes.
Symfony2 for legacy app rejuvenation: the eZ Publish case studyGaetano Giunta
This document discusses the rejuvenation of the legacy eZPublish content management system through adoption of the Symfony full-stack framework. Key aspects of the migration included maintaining backwards compatibility, integrating the legacy codebase through a dual-core architecture, refactoring the front controller, integrating routing, adopting Symfony caching practices, building a REST API, using the Doctrine database abstraction layer, improving performance through caching, and replacing the legacy templating language with Twig. The migration aimed to balance maintaining the existing system functionality while modernizing the codebase and architecture.
EP_LE_E2611_Debagging Process And Differences for Debagging WHRonen Madar
This document outlines requirements and test scenarios for enabling SABIC to debag materials for customer sales orders from their warehouses. The key requirements are to settle stock differences and financial activities with affiliates, and to debag stock for customer sales while ensuring materials for an order don't come from multiple affiliates. The proposed process involves creating a production order and transfer requirements for debagging, with a user exit to prevent picking from multiple affiliates. It provides test data and outlines 21 steps to test the end-to-end process.
PLC Programming Example - Conveyor Reject (Shift Register)ACC Automation
More information can be obtained at our website.
http://accautomation.ca/plc-programming-example-shift-register-conveyor-reject/
We will apply the five steps to PLC Program development to our next programming example of a shift register - conveyor reject.
1.Define the task
2.Define the inputs and outputs
3.Develop a logical sequence of operation
4.Develop the PLC program
5.Test the program
Another example of programming PLC Shift Registers can be seen at on our product sorting application. This will use 3D factory IO to demonstrate sorting colour tags.
PLC Programming Example – Sorting Station (Shift Register)
http://accautomation.ca/plc-programming-example-sorting-station-shift-register
PLC Programming Example - Sorting Station Testing - Video
https://youtu.be/W0aibYb3DnE
PLC Programming Example - Sorting Station - Video
https://youtu.be/YMl2DPm_yaU
http://www.accautomation.ca
- The goal is to define a data manifest (metadata) that ensures telemetry data can still be interpreted correctly even if the source device is not accessible or has changed.
- The data manifest consists of a platform manifest describing the platform producing the data and a data collection manifest describing how and when the telemetry was collected.
- The data and manifests must be streamed and stored together so the data can be properly analyzed with context even if separated from the source device in the future. Open questions remain around representing virtual devices and handling mis-collections.
The document introduces the Pro-EC44, a new single or dual loop temperature controller. Key features include a graphic display, USB configuration, data logging, Modbus communications, and support for one or two control loops. It can be configured using intuitive front panel controls or software to easily program multiple units for applications requiring plant-wide temperature control and monitoring.
This document describes a student project to implement a software-defined network load balancer using the POX controller. It is divided into two parts: the first part analyzes the POX controller and its OpenFlow module, explaining components like the libopenflow library and discovery module. The second part details the development of a load balancer using a round-robin algorithm to distribute traffic across multiple servers, including modifications made to the POX code and testing in a Mininet environment to analyze performance.
Best Practices and Performance Studies for High-Performance Computing ClustersIntel® Software
The document discusses best practices and a performance study of HPC clusters. It covers system configuration and tuning, building applications, Intel Xeon processors, efficient execution methods, tools for boosting performance, and application performance highlights using HPL and HPCG benchmarks. The document contains agenda items, market share data, typical BIOS settings, compiler flags, MPI usage, and performance results from single node and cluster runs of the benchmarks.
This document introduces serverless computing and the Fn Project open source platform. It defines key serverless concepts like Functions as a Service (FaaS) and discusses benefits like agility, economics, and reliability. It then provides an overview of the Fn Project, including its use of containers, CLI, architecture, and Flow capability for composing functions. The document positions Fn as an ideal open source functions platform that is platform independent, approachable, Docker-based, and scheduler independent.
- Dolibarr v14 includes over 118 new features and fixes 28 issues for developers
- The look and feel was improved with changes like standardized styling for amounts and placeholders
- Security and performance were enhanced through fixes identified in bug bounty campaigns and new admin tools
- New prototype modules were introduced for recruiting, event organization, partnerships, knowledge management, and workstation management, with testers needed
Invited presentation given by Niels Lohmann on December 3, 2013 in Potsdam, Germany as invited lecture at the Business Process Compliance course at the Hasso-Plattner-Institute.
Conference presentation given by Niels Lohmann on December 6, 2011 in Paphos, Cyprus at the Ninth International Conference on Service-Oriented Computing (ICSOC 2011).
Reactive solutions using java 9 and spring reactorOrenEzer1
This document discusses reactive programming concepts using Java 9 and Spring Reactor. It introduces reactive streams interfaces in Java 9 like Publisher, Subscriber, and Subscription. It then covers Spring Reactor implementations of these interfaces using Mono and Flux. Code examples are provided for creating simple reactive streams and combining them using operators. The threading model and use of schedulers in Spring Reactor is also briefly explained.
The document discusses code optimization techniques in compilers. It covers the following key points:
1. Code optimization aims to improve code performance by replacing high-level constructs with more efficient low-level code while preserving program semantics. It occurs at various compiler phases like source code, intermediate code, and target code.
2. Common optimization techniques include constant folding, propagation, algebraic simplification, strength reduction, copy propagation, and dead code elimination. Control and data flow analysis are required to perform many optimizations.
3. Optimizations can be local within basic blocks, global across blocks, or inter-procedural across procedures. Representations like flow graphs, basic blocks, and DAGs are used to apply optimizations at
openERP- How to connect OpenERP with external Systems, AkretionAkretion base...Odoo
This document discusses how to connect OpenERP with external systems using base external referential modules. It provides examples of connectors that have been developed including MagentoERPConnect, PrestashopERPConnect, and FileExchange. It describes how the base modules support multi-referential connections, flexible mappings, error reporting, and optimization of data synchronization between systems. Roadmaps are given for ongoing connector projects, and how various modules utilize the base referential frameworks.
Nagios Conference 2007 | Enterprise Application Monitoring with Nagios by Jam...NETWAYS
IT infrastructure such as switches and servers is the traditional focus of network monitoring tools. Increasingly organisations are focusing on monitoring business critical applications sitting on top of this infrastructure.
Altinity have deployed their Opsview software in a number enterprise environments to ensure availability of business critical applications and capture data for capacity planning. We will explain how we approach monitoring in these environment and what challenges we encounter. Opsview is an Open Source monitoring solution based on Nagios. Altinity are the commercial organsiation behind Opsview.
Benjy Weinberger, one of the maintainers of the Pants build system, spoke at PyCon Israel 2021 about the monorepo codebase architecture, its advantages for Python repos, and the tooling needed to work effectively in a monorepo.
The document discusses production planning topics and provides an example of a typical production cycle in a process industry. It outlines the key steps in a production cycle as: 1) Creating a process order, 2) Releasing the process order for production, 3) Goods issue from stores, 4) Starting processing, 5) Confirming production output, 6) Goods receipt, 7) Quality approval and release, and 8) Stock appearing in unrestricted use for sale or further processing. The document then provides details on required masters, transactions, and an example scenario to demonstrate setting up and executing a production cycle.
This document provides an overview of the key transactions and processes used in process manufacturing in SAP. It describes the master data needed such as materials, resources, recipes, quality inspection characteristics, and quality plans. It then outlines the basic production cycle including creating a process order, goods issue, confirmation, goods receipt, quality approval, and stock release. Key transactions referenced include COR1, MIGO, CORK, QA32, and more. The production cycle explained focuses on production and quality management for a process manufacturing company.
This document provides an overview of several R&D projects at OpenERP including Apps, release policy, packaging, R&D processes, and the Web Client version 6.1. It discusses the OpenERP Apps platform, release cycles, packaging for different operating systems, bug and project lifecycles, and monitoring tools. It also provides details on the new Web Client 6.1 which features a cleaner architecture, improved performance, modularity, and support for mobile and embeddable apps. Upcoming workshops are announced for discussing ideas on areas like CRM, payroll, and the Web Client.
This document discusses processes and process management in operating systems. It covers key topics such as:
- Process states including new, running, ready, waiting, and terminated.
- Process representation using Process Control Blocks (PCBs) which contain process state and scheduling information.
- Process scheduling with long-term, short-term, and medium-term schedulers that move processes between queues.
- Interprocess communication (IPC) which allows processes to communicate and synchronize, using both direct and indirect communication with mailboxes.
Symfony2 for legacy app rejuvenation: the eZ Publish case studyGaetano Giunta
This document discusses the rejuvenation of the legacy eZPublish content management system through adoption of the Symfony full-stack framework. Key aspects of the migration included maintaining backwards compatibility, integrating the legacy codebase through a dual-core architecture, refactoring the front controller, integrating routing, adopting Symfony caching practices, building a REST API, using the Doctrine database abstraction layer, improving performance through caching, and replacing the legacy templating language with Twig. The migration aimed to balance maintaining the existing system functionality while modernizing the codebase and architecture.
EP_LE_E2611_Debagging Process And Differences for Debagging WHRonen Madar
This document outlines requirements and test scenarios for enabling SABIC to debag materials for customer sales orders from their warehouses. The key requirements are to settle stock differences and financial activities with affiliates, and to debag stock for customer sales while ensuring materials for an order don't come from multiple affiliates. The proposed process involves creating a production order and transfer requirements for debagging, with a user exit to prevent picking from multiple affiliates. It provides test data and outlines 21 steps to test the end-to-end process.
PLC Programming Example - Conveyor Reject (Shift Register)ACC Automation
More information can be obtained at our website.
http://accautomation.ca/plc-programming-example-shift-register-conveyor-reject/
We will apply the five steps to PLC Program development to our next programming example of a shift register - conveyor reject.
1.Define the task
2.Define the inputs and outputs
3.Develop a logical sequence of operation
4.Develop the PLC program
5.Test the program
Another example of programming PLC Shift Registers can be seen at on our product sorting application. This will use 3D factory IO to demonstrate sorting colour tags.
PLC Programming Example – Sorting Station (Shift Register)
http://accautomation.ca/plc-programming-example-sorting-station-shift-register
PLC Programming Example - Sorting Station Testing - Video
https://youtu.be/W0aibYb3DnE
PLC Programming Example - Sorting Station - Video
https://youtu.be/YMl2DPm_yaU
http://www.accautomation.ca
- The goal is to define a data manifest (metadata) that ensures telemetry data can still be interpreted correctly even if the source device is not accessible or has changed.
- The data manifest consists of a platform manifest describing the platform producing the data and a data collection manifest describing how and when the telemetry was collected.
- The data and manifests must be streamed and stored together so the data can be properly analyzed with context even if separated from the source device in the future. Open questions remain around representing virtual devices and handling mis-collections.
The document introduces the Pro-EC44, a new single or dual loop temperature controller. Key features include a graphic display, USB configuration, data logging, Modbus communications, and support for one or two control loops. It can be configured using intuitive front panel controls or software to easily program multiple units for applications requiring plant-wide temperature control and monitoring.
This document describes a student project to implement a software-defined network load balancer using the POX controller. It is divided into two parts: the first part analyzes the POX controller and its OpenFlow module, explaining components like the libopenflow library and discovery module. The second part details the development of a load balancer using a round-robin algorithm to distribute traffic across multiple servers, including modifications made to the POX code and testing in a Mininet environment to analyze performance.
Best Practices and Performance Studies for High-Performance Computing ClustersIntel® Software
The document discusses best practices and a performance study of HPC clusters. It covers system configuration and tuning, building applications, Intel Xeon processors, efficient execution methods, tools for boosting performance, and application performance highlights using HPL and HPCG benchmarks. The document contains agenda items, market share data, typical BIOS settings, compiler flags, MPI usage, and performance results from single node and cluster runs of the benchmarks.
This document introduces serverless computing and the Fn Project open source platform. It defines key serverless concepts like Functions as a Service (FaaS) and discusses benefits like agility, economics, and reliability. It then provides an overview of the Fn Project, including its use of containers, CLI, architecture, and Flow capability for composing functions. The document positions Fn as an ideal open source functions platform that is platform independent, approachable, Docker-based, and scheduler independent.
- Dolibarr v14 includes over 118 new features and fixes 28 issues for developers
- The look and feel was improved with changes like standardized styling for amounts and placeholders
- Security and performance were enhanced through fixes identified in bug bounty campaigns and new admin tools
- New prototype modules were introduced for recruiting, event organization, partnerships, knowledge management, and workstation management, with testers needed
Invited presentation given by Niels Lohmann on December 3, 2013 in Potsdam, Germany as invited lecture at the Business Process Compliance course at the Hasso-Plattner-Institute.
Conference presentation given by Niels Lohmann on December 6, 2011 in Paphos, Cyprus at the Ninth International Conference on Service-Oriented Computing (ICSOC 2011).
Workshop presentation given by Niels Lohmann on December 5, 2011 in Paphos, Cyprus at the 6th International Workshop on Engineering Service-Oriented Applications (WESOA'11).
Compliance by Design for Artifact-Centric Business ProcessesUniversität Rostock
This document discusses an approach called "compliance by design" for ensuring that artifact-centric business processes are compliant with regulations. It involves:
1) Specifying a business process model, artifacts, agents, locations and goals
2) Translating legal texts into compliance rules
3) Modeling the compliance rules and integrating them with the business process model
4) Using tools to generate a compliant business process model that satisfies both behavioral and compliance requirements.
This approach aims to avoid subsequent proofs of compliance by building compliance into the design from the start. It also allows flexibility to change compliance rules without needing to regenerate the entire process model.
LoLA is an explicit-state model checker for Petri nets that focuses on standard properties and uses many reduction techniques such as stubborn sets, symmetries, and sweep-line heuristics to efficiently analyze large state spaces. It takes Petri nets as input in the form of place/transition nets or high-level algebraic nets and allows users to specify verification tasks involving properties such as boundedness, reachability, and temporal logics. LoLA is open source and has been used in several case studies to generate experimental results tables exploring the impact of basic design decisions.
The document describes various techniques for implementing a Petri net state space search:
1. It discusses how transitions are fired and states are evaluated by marking changed places and checking enabled transitions.
2. State predicates are stored in negation-free normal form to efficiently check state properties.
3. The state space is managed by representing states as bit vectors and organizing them in a decision tree for fast lookup and insertion.
4. Search organization involves firing transitions, finding/inserting states, and backtracking with a search stack and write-only memory approach.
This document discusses integrating the LoLA model checker as a web service for verifying Petri net properties. It lists soundness checks that LoLA can perform, including classical, weak, and relaxed soundness. It provides URLs for editing Petri nets in Oryx and calling the LoLA web service from the University of Rostock service technology site to verify properties by translating nets from PNML to LoLA format and running LoLA as a system call.
Niels Lohmann explores several case studies applying symbolic systems biology techniques:
1) Analyzing biochemical reaction chains using the tool LoLA for fast reachability queries.
2) Finding hazards in Globally Asynchronous Locally Synchronous (GALS) circuits design using Petri nets and partial order reduction.
3) Verifying service choreographies for deadlocks by translating models to open workflow nets and discovering a design flaw.
LoLA is a tool for verifying properties of Petri nets. This document discusses how to:
1. Choose and manage LoLA configurations to optimally verify properties.
2. Ask the right verification questions in a specific, modular way to efficiently verify properties.
3. Optimize Petri net modeling to take advantage of LoLA's reduction techniques and scale verification.
4. Employ scripts and makefiles to automate calling LoLA and analyzing results.
5. Integrate calling LoLA from other tools using UNIX streams for modular verification.
The document summarizes the stubborn set method for state space reduction in Petri nets. It explains that the method works by defining a stubborn set of transitions in each marking that can fire independently of transitions outside the set. This allows reducing the state space by only exploring firings within each stubborn set, while still preserving properties like deadlocks. The proof for deadlock preservation is also outlined.
LoLA is an open source tool for verifying properties of Petri nets through explicit state space generation. It features many state space reduction techniques and can verify standard properties like boundedness, reachability, and LTL/CTL formulas. LoLA was created to generate experimental results tables and explore basic design decisions like having no GUI and generating a dedicated state space for each property. It has been under development since 1998 and is aimed at helping users verify realistic models efficiently.
The document describes the input language for the LoLA model checker. It allows specifying Petri nets and verification tasks in a high-level algebraic style. Key elements include:
1. Defining sorts, operations, and their interpretations to specify the types and functions used.
2. Declaring high-level places and markings as terms over sorts to represent multiple low-level places and tokens.
3. Specifying high-level transitions as procedures with guards and input/output terms to represent multiple low-level transitions.
4. Providing verification tasks as logical formulas involving state predicates to check properties over the unfolded net.
This document describes a joint research project between the University of Rostock's Computer Science and Electrical Engineering departments. The project aims to develop tools and formal methods for analyzing systems and synthesizing web services for resource-constrained devices. This will be done by applying the Devices Profile for Web Services (DPWS) standard, which allows using web service technology on embedded systems and sensor networks in a way that is compatible with existing enterprise web services. The goal is to enable web service capabilities on more intelligent devices that increasingly communicate with each other.
Workshop presentation given by Niels Lohmann on February 22, 2011 in Karlsruhe, Germany at the Third Central-European Workshop on Services and their Composition (ZEUS 2011).
This document compares Petri nets and state spaces for modeling and verification. It discusses that state spaces allow modeling global state changes over time, while Petri nets consider asynchronous components and causality of events. The document also describes techniques for efficient state space generation from Petri nets, such as checking enabled transitions with constant time, firing transitions with constant effort, backtracking transitions, and storing markings in a set. Reduction techniques like linear algebra, sweep-line methods, symmetries, and stubborn sets are also covered to reduce the state space.
Formale Fundierung und effizientere Implementierung der schrittbasierten TLDA...Universität Rostock
Presentation given by Niels Lohmann on September 23, 2005 in Berlin, Germany; Talk given at the diploma defense ceremony at Humboldt-Universität zu Berlin.
Tool demonstration given by Niels Lohmann on September 1, 2006 in Eindhoven, The Netherlands at the Berlin-Eindhoven Service Technology Colloquium 2006 (B.E.S.T. 2006).
This document discusses key questions around service-oriented architecture (SOA) including how services are discovered and matched, what information about services should be published, and how services bind together. Specifically, it raises questions about how to design a service broker to facilitate finding and publishing services, what criteria determine when one service matches the needs of another service requester, and how services connect and interact with each other.
Strategies for Effective Upskilling is a presentation by Chinwendu Peace in a Your Skill Boost Masterclass organisation by the Excellence Foundation for South Sudan on 08th and 09th June 2024 from 1 PM to 3 PM on each day.
it describes the bony anatomy including the femoral head , acetabulum, labrum . also discusses the capsule , ligaments . muscle that act on the hip joint and the range of motion are outlined. factors affecting hip joint stability and weight transmission through the joint are summarized.
A workshop hosted by the South African Journal of Science aimed at postgraduate students and early career researchers with little or no experience in writing and publishing journal articles.
How to Manage Your Lost Opportunities in Odoo 17 CRMCeline George
Odoo 17 CRM allows us to track why we lose sales opportunities with "Lost Reasons." This helps analyze our sales process and identify areas for improvement. Here's how to configure lost reasons in Odoo 17 CRM
This presentation was provided by Steph Pollock of The American Psychological Association’s Journals Program, and Damita Snow, of The American Society of Civil Engineers (ASCE), for the initial session of NISO's 2024 Training Series "DEIA in the Scholarly Landscape." Session One: 'Setting Expectations: a DEIA Primer,' was held June 6, 2024.
Thinking of getting a dog? Be aware that breeds like Pit Bulls, Rottweilers, and German Shepherds can be loyal and dangerous. Proper training and socialization are crucial to preventing aggressive behaviors. Ensure safety by understanding their needs and always supervising interactions. Stay safe, and enjoy your furry friends!
MATATAG CURRICULUM: ASSESSING THE READINESS OF ELEM. PUBLIC SCHOOL TEACHERS I...NelTorrente
In this research, it concludes that while the readiness of teachers in Caloocan City to implement the MATATAG Curriculum is generally positive, targeted efforts in professional development, resource distribution, support networks, and comprehensive preparation can address the existing gaps and ensure successful curriculum implementation.
A Strategic Approach: GenAI in EducationPeter Windle
Artificial Intelligence (AI) technologies such as Generative AI, Image Generators and Large Language Models have had a dramatic impact on teaching, learning and assessment over the past 18 months. The most immediate threat AI posed was to Academic Integrity with Higher Education Institutes (HEIs) focusing their efforts on combating the use of GenAI in assessment. Guidelines were developed for staff and students, policies put in place too. Innovative educators have forged paths in the use of Generative AI for teaching, learning and assessments leading to pockets of transformation springing up across HEIs, often with little or no top-down guidance, support or direction.
This Gasta posits a strategic approach to integrating AI into HEIs to prepare staff, students and the curriculum for an evolving world and workplace. We will highlight the advantages of working with these technologies beyond the realm of teaching, learning and assessment by considering prompt engineering skills, industry impact, curriculum changes, and the need for staff upskilling. In contrast, not engaging strategically with Generative AI poses risks, including falling behind peers, missed opportunities and failing to ensure our graduates remain employable. The rapid evolution of AI technologies necessitates a proactive and strategic approach if we are to remain relevant.
How to Build a Module in Odoo 17 Using the Scaffold MethodCeline George
Odoo provides an option for creating a module by using a single line command. By using this command the user can make a whole structure of a module. It is very easy for a beginner to make a module. There is no need to make each file manually. This slide will show how to create a module using the scaffold method.
3. The tools
• BPEL2oWFN
translates a BPEL service into an oWFN
• Fiona
analyzes the interaction of an oWFN:
(1) checks controllability and
(2) computes the operating guideline of the net
• Tools4BPEL GUI
graphical user interface for BPEL2oWFN and Fiona
3
5. Requirements
• to run:
– Windows, Linux, UNIX or Macintosh for BPEL2oWFN
and Fiona
– J2SE 5.0 (Java 1.5) for the GUI
• to compile:
– GNU Compiler Collection (gcc)
• to develop:
– GNU Autotools (automake, autoconf, …)
– GNU Compiler Tools (flex, bison, kimwitu++)
5
6. Download
• all tools are free and open source
• download them from the Tools4BPEL website
www.informatik.hu-berlin.de/top/tools4bpel
• the tools are also hosted at SourceForge.net
sourceforge.net/projects/tools4bpel
6
7. Set up BPEL2oWFN
• download the source tarball (“bpel2owfn-1.3.tar.gz”)
• open a shell and enter:
– gunzip bpel2owfn-1.3.tar.gz
– tar xf bpel2owfn-1.3.tar
– cd bpel2owfn-1.3
– ./configure
– make
• an executable file “bpel2owfn” is created in the
directory /bpel2owfn-1.3/src
7
8. Set up Fiona
• download the source tarball (“fiona-1.0.tar.gz”)
• open a shell and enter:
– gunzip fiona-1.0.tar.gz
– tar xf fiona-1.0.tar
– cd fiona-1.0
– ./configure
– make
• an executable file “fiona” is created in the
directory /fiona-1.0/src
8
9. Set up Tools4BPEL GUI
• download the jarfile (“tools4bpelgui-1.0.jar”)
• edit the config-file and point to the executables of
BPEL2oWFN and Fiona
• start the GUI with
java -jar tools4bpelgui-1.0.jar
9
11. Overview
• input:
– BPEL process (compliant to the
BPEL4WS 1.1 specification)
• output:
– oWFN
– Petri net (without interface places)
• additionally:
– control flow analysis
11
12. Translation
Translation can be adjusted to the analysis task:
– feature-complete
all aspects of BPEL are modelled
– abstraction from data
variables are not modelled
net size
– abstraction from fault management
fault and compensation handlers are not modelled
– abstraction from stop and termination management
only the communicational behaviour is modelled
12
13. Translation (cont.)
• Output file formats:
Petri net with
– oWFN in Fiona format interface places
– LoLA place/transition net
– Petri Net Markup Language (PNML) Petri net without
– Abstract Petri Net Notation (APNN) interface places
– Low-level PEP Notation
13
14. Translation (cont.)
• The translation is supported by:
– static analysis
– structural simplification rules
14
15. Control Flow Analysis
• detects design flaws:
– conflicting receive operations
– uninitialized variables
– cyclic links
(not presented here)
• more information on the website:
www.informatik.hu-berlin.de/top/tools4bpel/bpel2owfn
15
18. Parameters
• set communication depth
• adjust maximal event occurrence
• usage of reduction rules for the IG
• more information on the website:
www.informatik.hu-berlin.de/top/tools4bpel/fiona
18
21. Description
When the online shop receives the login information from a
customer, its business strategy distinguishes between already
known customers and new customers. In case of a known
customer the left branch is executed: first the shop expects an
order, and then it sends the invoice to the customer. In case of a
new customer (right branch) the shop initiates two tasks
concurrently: in the first task (Sequence1) the shop first receives
the order and then confirms it. In the second task (Sequence2)
the shop receives the terms of payment before it sends an invoice
to the customer. In either case the shop finally sends the delivery
information to the customer. The customer may send an abort
message at any time. This is modelled by an event handler that
receives the abort message and then terminates the whole
process. 21
22. Analysis tasks
• Does there exist a partner that can use the online
shop “properly”, i.e. login, order and eventually
receive a delivery information?
• If there exists more than one partner of the online
shop, can we characterize all of them?
22
23. Todo
1. Translate the BPEL process to an oWFN
(prerequisite for further analysis)
2. Check for controllability and calculate the IG
(analysis: existence of a partner)
3. Calculate the operating guideline
(analysis: characterize all partners)
23
24. 1. Translation
We use BPEL2oWFN to generate an oWFN:
the modelling of
./bpel2owfn standard faults, data
or variables is not
--input=shop.bpel
necessary for this
--mode=petrinet analysis task
--format=owfn
--parameter=novariables
--parameter=nostandardfaults
--parameter=simplify structurally simplify
--output the resulting net
24
25. 1. Translation (cont.)
• BPEL2oWFN creates a
file “shop.owfn”:
– 70 places (4 input, 3 output)
– 75 transitions
– 233 arcs
• Due the <terminate/>
activity, each BPEL activity
has a stop pattern.
25
26. 2. Controllability
We use Fiona to calculate the interaction graph:
./fiona
--net=shop.owfn
--graphtype=IG
26
27. 2. Controllability (cont.)
• Fiona creates two files:
– “shop.owfn.IG.out”
– “shop.owfn.IG.png”
• The interaction graph has
a blue subgraph:
) The online shop is controllable!
27
28. 2. Controllability (cont.)
The controller found reflects the intended behaviour
of a customer. First he sends a login, followed by an
order. Then he must be able to either receive an
invoice (in case he is known to the shop) or to receive
the confirmation (in case he is a new customer). If he
actually has received the confirmation, he must send a
terms of payment message. After that he will receive
the invoice. In either case he finally receives the
delivery information. At any time he may abort.
28
29. 3. Operating Guideline
We use Fiona to calculate the operating guideline:
./fiona
--net=shop.owfn
--graphtype=OG
29
30. 3. Operating Guideline (cont.)
• Fiona again creates two files:
– “shop.owfn.OG.out”
– “shop.owfn.OG.png”
• The operating guidelines contains
more interleavings of sending or
receiving messages. For instance,
a customer may reverse the order
of sending the login and the
order message.
30
33. Description
The shop now modifies its business strategy: every
known customer that orders something can choose a
gift. The changes only affect the left branch of the
switch. The shop initiates two tasks concurrently now:
in the first task (Sequence1) the shop first receives the
order and then confirms it. In the second task
(Sequence2) the shop receives which gift is chosen
before it sends the invoice to the customer.
33
35. Todo
1. Translate the BPEL process to an oWFN
(prerequisite for further analysis)
2. Check for controllability and calculate the IG
(analysis: existence of a partner)
3. Calculate the operating guideline
(analysis: characterize all partners)
4. Compare it to the operating guideline of the first
online shop 35
36. 1. Translation
• Using the same parameters
as before, BPEL2oWFN
generates an oWFN:
– 83 places (4 input, 3 output)
– 90 transitions
– 279 arcs
36
37. 2. Controllability
• Using the same parameters as
before, Fiona calculates an
interaction graph with a nonempty
blue subgraph:
The new shop is still controllable!
• The controller in the IG represents a
customer who sends an abort
message during the interaction.
37
38. 3. Operating Guidelines
• Using the same parameters as
before, Fiona calculates the
operating guideline of the new
shop.
38
39. 4. Comparison
A closer look at the OG reveals that actually every
customer of the modified shop must eventually send
an abort message. This surely means that the process
is controllable. However, the way this is done is
obviously a not intended one. There is no way that a
customer can get what he has ordered from the
process.
39
40. 4. Comparison (cont.)
We can see that the shop does not communicate its inner
decision about which branch (known customer, new customer) is
chosen. In the original online shop the controller must send an
order, but receives either an invoice or a confirmation w.r.t. which
branch the shop has chosen before. That way the controller knows
what branch the shop is actually in and hence knows how to
continue. In contrast, in the modified shop the controller must
send an order and receives undistinguishable confirmation
messages in either case. The modified shop expects a choice of a
gift in case it decided for the known customer branch. In the other
case it expects the terms of payment. The controller, however,
does not know about the decision of the shop. However, sending
an abort is always correct.
40
43. Description
The coffee vending has a button for coffee and one for
tea, and a money slot. After money is inserted and a
button is pressed, the beverage (coffee or tea) is
returned.
43
44. Analysis Task
• Are these three customers partners of the coffee
vending machine?
customer1.bpel customer2.bpel customer3.bpel
44
45. Todo
1. Translate the vending machine service to an
oWFN.
2. For each customer service:
a) Translate the service to an oWFN.
b) Compose this oWFN with the oWFN of the
service.
c) Test: Is the composed service weak
terminating?
45
46. Translation and Composition
BPEL2oWFN can perform step 1, 2a and 2b:
compose the input
services and create
./bpel2owfn a CTL formula to
-- mode=consistency check
-- input=coffee.bpel
-- input=customer1.bpel
-- format=lola use patterns that
-- parameter=communicationonly only model the
-- parameter=simplify communicational
-- output behaviour
46
47. Translation and Composition (cont.)
• BPEL2oWFN creates two files for the explicit model
checker LoLA:
– coffee_customer1.lola
the composed net in LoLA format
– coffee_customer1.task
a CTL formula stating that it is always possible to
reach the final marking of the composed net
(AG EF finalmarking)
47
48. Test on weak termination
• We use the LoLA to check the CTL formula:
./lola coffee_customer1.lola -a
• LoLA verifies the formula: the final state of the
composed service can be reached from any
reachable marking
48
49. Results
• The composition weakly terminates.
) The first customer is a partner of the coffee
vending machine (and vice versa).
• Using the same parameters, we find that the
second consumer is also a partner of the coffee
vending machine (and vice versa).
49
50. Results (cont.)
• The composition of the coffee vending machine
service and the third consumer does not weakly
terminate:
– LoLA finds a counter example path (the
composition deadlocks after the coffee button is
pressed).
– This path can be used to fix the BPEL process of
this customer (an automatic re-translation is
subject of current work).
50
52. Conclusion
The presented tools can:
• generate a formal model of a BPEL process
(translate a BPEL process to an oWFN or a Petri net
without interface),
• generate a partner of a service, if there is one (check
an oWFN for controllability),
• characterize all partners of a service (calculate the
operating guideline of an oWFN),
• check if two services are partners, i.e. they are
consistent (check if the composition is weakly
terminating).
52
53. References
• These slides together with all examples can be
downloaded at:
www.informatik.hu-berlin.de/top/tools4bpel/tools/tutorial
• For more information on the tool chain, see:
Niels Lohmann, Peter Massuthe, Christian Stahl, and
Daniela Weinberg. Analyzing Interacting BPEL Processes.
BPM 2006, Lecture Notes in Computer Science (to appear),
2006. Springer-Verlag.
53
54. References (cont.)
• For more information on LoLA, see:
Karsten Schmidt. LoLA: A Low Level Analyser. In Mogens
Nielsen and Dan Simpson, editors, ICATPN 2000, volume
1825 of Lecture Notes in Computer Science, pages 465-474,
June 2000. Springer-Verlag.
• LoLA can be downloaded at:
www.informatik.hu-berlin.de/top/lola
54
55. Tools4BPEL Tutorial
Niels Lohmann
Humboldt-Universität zu Berlin
Department of Computer Science
nlohmann@informatik.hu-berlin.de