businessprocesssimulation / bpsim Goto Github PK

Ability to initialise the model with Tokens pre-loaded into queues at activities

Extra results are useful at a Process level

Simulation results are often required time dependent, for example number of jobs completed per hour.
A possible extension of V1 would be to allow a calendar to be attached to a result request, with an additional control parameter defining if the statistic should be reset.

For example an hourly recording of output could be either for each hour or cumulative by hour.

A warm up period is considered important in most simulation software products. This allows the model to be run from empty for a period, results collection reset, then run on. This provides results based on periods when the system is 'primed', as is normal in industrial or business processes.

This would be a scenario parameter very similar to Duration.

Geoff and Jeremy have reviewed the implementer's guide models and updated them with new BPSim 2.0 functionality. The work carried out was only done to the BPMN version of these models. These need to be saved as xpdl and vdx versions.

See comments in the BPSim v2.0.docx

Section 8.4, see comment relating to this issue

We have needed this functionality in a customer project.
Objective: set a number of arrivals to occur in a given time period. The current Trigger Count and Inter trigger time do not do this.
Solution: a new parameter that specifies the number of tokens to arrive over the duration of a calendar.

We added a vendor extension to achieve this which spreads the quantity of tokens randomly over the calendar duration

Our suggested implementation for BPSim is:

Currently there is no way to specify the type of Property (int, double, string etc.) used during property value assignment.

The Car Repair Process example that is part of the Implementers Guide, uses the following to assign a value to the "noOfIssues" property. The "noOfIssues" property is intended to be an integer count value. However the TruncatedNormalDistribution will return a double precision value between 1 and 1000, for example: 3.565534.

<bpsim:PropertyParameters>
  <bpsim:Property name="noOfIssues">
      <bpsim:TruncatedNormalDistribution max="1000" mean="2" min="1" standardDeviation="1"/>
   </bpsim:Property>
</bpsim:PropertyParameters>

The logic in the model decrements the "noOfIssues" each time an issue is repaired. Having fixed an issue, the number of issues now remaining is now 2.565534 (3.565534 - 1)

The gateway which decides if there are more issue to be fixed uses the logic getProperty('noOfIssues') = 0.

Clearly, unless we are very luck we will never reach exactly zero.

Here are some possible solutions:

• Give a hint during property assignment as to what the expected expression type is e.g.

<bpsim:PropertyParameters>
  <bpsim:Property name="noOfIssues" **type="int"**>
      <bpsim:TruncatedNormalDistribution max="1000" mean="2" min="1" standardDeviation="1"/>
   </bpsim:Property>
</bpsim:PropertyParameters>

Possibly make this an optional attribute?

• Declare somewhere in the <ScenarioParameters> or at the <ElementParameters> what the type of each property is.

Attached is a version of the BPSim 2.0 specification, with minor markups following the face-to-face meeting in July 2016. This need to be integrated to the master document.

BPSim v2.0-1.docx

Doing a lot of work in bending BPMN to do case mgmt, and would like to explore how BPSim could help in simulating the desired operational behaviors. I realize that this is somewhat vague, but I also need help in trying to describe it. I have developed approached to modeling that could start the conversation.

1. Solution is spelled as Sollution (2 l's). This is done three times
2. 2nd level support is spelled as 2 nd level support (extra space)
3. Add a screen shot of the corrected diagram to implementer's guide
4. Re-save in xpdl and vdx formats too.

In many business processes the particular resource instance that is selected for a task must stay with that piece of work (token) through later steps. This named resourced could be stored as an attribute of the token and referred to in a subsequent resource selection expression.

This implementation could also be used to stop a particular resource being used at a later step to work on a token. This functionality is sometimes required to make sure a quality check is performed by a different resource instance to the one that did the work, even though they maybe both doing the same role.

We have found it useful to output a token trace from the simulation. This is useful for validation and deeper analysis. Due to the fact that this can slow down simulation execution and potentially create a very large output file this has been implemented selectively in a vendor extension at Task level

.

Turns out this was missing, leaving it to be set by the tool vendor. It is suggested that it should be in USD.

V1 doesn't support sufficient parameters for holding results for a Task, e.g. both number started and number completed

Section 7.4, see comment relating to this issue

Consider using DMN Decision modelling notation

• to create token attributes

Those parameters are not used by the vendors or users.

Currently the bpsim schema uses http://www.bpsim.org/schemas/1.0 namespace.

Assume this needs to move to xmlns:bpsim="http://www.bpsim.org/schemas/2.0"?

This is required for the Car Repair Process, Loan Process and the Technical Support Process.

This also needs to be added to the Implementer's Guide document as it contains references to 1.0.

The car repair process does not contain valid xml

<bpsim:ElementParameters elementRef="_4799D2B0-A204-4A08-94ED-796C25D9AE57">
    <bpsim:ControlParameters>
        <bpsim:Condition>
            <bpsim:ExpressionParameter value="getProperty('noOfIssues') <= 0"/>
        </bpsim:Condition>
    </bpsim:ControlParameters>
</bpsim:ElementParameters>

Needs to be changed to

<bpsim:ElementParameters elementRef="_4799D2B0-A204-4A08-94ED-796C25D9AE57">
    <bpsim:ControlParameters>
        <bpsim:Condition>
            <bpsim:ExpressionParameter value="getProperty('noOfIssues') &lt;= 0"/>
        </bpsim:Condition>
    </bpsim:ControlParameters>
</bpsim:ElementParameters>

Some sim/mod vendors with their own sim language show queue sizes as a proxy indicator for backlog. BPSim, to my knowledge, does not have this covered. When pressed with the need to report it for a client, Lanner & Trisotech gave me the vendor extension below to use, which was very helpful. I would like BPSim to address this need ASAP. The results set returned by this is the max, min, and mean of queue size as understood as # of tokens waiting for a resource.

                     <VendorExtension name="l-sim-task-results-v1">
                        ...
                        <lsim:MaximumNumberOfTokensWaitingForResource>
                            <ResultRequest>max</ResultRequest>
                        </lsim:MaximumNumberOfTokensWaitingForResource>
                        <lsim:MinimumNumberOfTokensWaitingForResource>
                            <ResultRequest>min</ResultRequest>
                        </lsim:MinimumNumberOfTokensWaitingForResource>
                        <lsim:AverageNumberOfTokensWaitingForResource>
                            <ResultRequest>mean</ResultRequest>
                        </lsim:AverageNumberOfTokensWaitingForResource>
                        <lsim:MaximumNumberOfResourcesUsed>
                            <ResultRequest>max</ResultRequest>
                        ...
                    </VendorExtension>

Turns out this was missing, leaving it to be set by the tool vendor. It is suggested that it should be in Minutes.

I want to be able to set up trigger parameters (inter-trigger and counts) to occur within some kind of collective constraint that holds to a distributed occurrence pattern across the multiple events. At the moment, I as the modeler must hand-jam this and hope for the best.

For example:

<bpsim:Property name="noOfIssues" type="int"> <bpsim:TruncatedNormalDistribution max="1000" mean="2" min="1" standardDeviation="1"/> </bpsim:Property>

The current schema (BPSim 2.0) does not have a definition for the allowed values of the type attribute.

Attached is an updated Implementer's Guide document and the corresponding models with results for validation/checking (consistency).

Implementers Guide Models 2.0.0.zip
BPSim Implementer's Guide v2.0.0.docx