Solution for Weighting Scale (Black Box level)

It’s time to put down your pens!

We hope this exercise has allowed you to expand on the use of our toolchain in a simple system.

Below you will find our solution (here is the link to our model).

Do not hesitate to compare the Sequences, look at the body of the activities, play our scenarios, read the comments below, in order to fully appropriate this exercise.

We emphasize that there is no one solution.

EXPECTED FUNCTIONING

Initially, the scale is active (state available), then the state varies according to the conditions and the inputs of the customer.

An Inactive state is mandatory to have a degraded operation: no weighting is possible inside this state.

The expected functioning is summarized in the below diagram:

IMPLEMENTATION

Since the Weighting Scale is not perfect, it needs a period of stability before taking into consideration the weight inserted, two implementations are suggested to correctly model the system:

1. On the one hand, it is possible to create a state called "stabilization" during which the timer is incremented until it reaches the maximum delay then the system goes to the next step.

2. On the other hand, it is also possible to create a variable of type enumeration that contains two enumerations literals (stable and unstable). The newly created variable will be used then in the guard condition to verify the Weighting Scale stability, in parallel with the timer incrementation.

SOLUTION HINTS

As a reminder:

• Don’t forget to add feedback flows to the costumer, to display the messages of weighting progress and the Weighting Scale state (active /inactive) on Virtual Bench.
• The customer can modify/remove the weight from the scale at any time whatever the level of progress in the weighing operation (in active state).
• The weight flow comes from the Environment because it’s the scale sensor that detects the weight, not the user that enters it.
• At initialization, in order to ensure the proper functioning of the system, the scale must be loaded with tickets, otherwise it remains blocked in the inactive state.
• Keep in mind that the scale requires a constant delay to stabilize.
• We used a "when" flow that will be sent from the environment to the service every 40 ms to:
  • check the stability of the Weighting Scale,
  • increment the timer, check the number of tickets and the status of the Weighting Scale.
• The number of tickets to add must be greater than 0. Otherwise, the Weighting Scale does not take it into consideration. This number must be updated after:
  • each printing operation (the ticket number decreases by 1).
  • each recharge made by the technician (the ticket number increases by the number reloaded)

CSV IMPORT

1. It is necessary to create two data types:

• The first type contains the variables that will store the values from the list (it is also necessary to initialize the type of each variable according to the value found in the file).
• The second type contains the whole list. In order to ensure a good initialization of the price list, it is necessary to initialize the multiplicity of the variable created as "Many".

2. Use the script “Edit > Complete Activity > Load CSV” to fill automatically the following:

• Browse the entire list correctly.
• Fixate on the chosen product.
• Store the price per kilogram in the appropriate variable.

SCENARIO ON VB

You can find bellow the graphic representation we used for our scenarios:

• A slider to indicate the weight

• Buttons to select the type of product and confirm/decline the printing of a ticket

Expected scenarios behavior to check

Nominal Case:

1. The technician imports a price list,
   See scale state changes to Available.

2. The customer put products on the scale,
   See scale state changes to Stabilization & weight value changes too.

3. Once the scale is stabilized, the customer selects a type of product,
   See scale state changes to Busy, then Print & see Product name, Price per kilo and Price to pay changes too.

4. After checking the kind of product and final price, the customer confirms to print a ticket.
   See scale state changes to Available & see Number of tickets decreases.

Degraded Cases:

1. The customer changes the weight at any operation of the process (during stabilization, after or before selecting a kind of product),
   See scale state changes to Stabilization OR Available (if weight is null).

2. The customer cancels the ticket printing,
   See scale state changes to Busy.

3. The Weighting Scale prints the last ticket.
   See scale state changes to Inactive.

4. The technician reloads tickets
   See scale state changes to Available & see Number of tickets increases by the number entered.