designing a finite state machine simulator to detect …

1

DESIGNING A FINITE STATE MACHINE SIMULATOR TO

DETECT LOOPS FOR ALICE DETECTOR CONTROL

SYSTEM

Bobbi Winema Yogatama Summer Student

EP-UAI (ALICE COLLABORATION)

CERN Summer Student Programme 2017

Supervisor: Dr. Ombretta Pinazza

Abstract

This paper present the design and implementation of a Finite State Machine simulator to

provoke loops in ALICE Detector Control System (DCS). Loops in a Finite State Machine can be very harmful for the control system and need to be prevented. One way to prevent loops is to simulate the

designed Finite State Machine using a simulator that can detect all of the possible conditions that can

provoke loops. Further correction can then be made after the loops are detected in the control system. The proposed simulator is able to get the structure of any unknown FSM, get every datapoint elements

that are associated with the FSM, and find every possible datapoint combinations that can provoke

loops in the FSM. At the end of the project, we tested the simulator on a sample FSM with loops and a

real FSM that belongs to the ALICE PHOton Spectrometer (PHOS). The testing results indicate that the simulator is able to detect every possible condition that can cause loops in the FSM.

1. Introduction

The control system of ALICE Detector [1] created by ALICE DCS Group [2] is designed in a

hierarchical configuration using the concept of “Finite State Machine” [4]. A Finite State Machine (FSM) [4] is a mathematical model of computation that assigns an object to some states and allows that object

to move between states by carrying out commands that can change the parameters of the object. In the hierarchical configuration of a control system, the states of a children nodes (the nodes that are connected below) can affect the states of the parent (the node that is connected above) and the changes will propagate to the top node. From the top node, the command can also propagate from the parent to the children allowing the top node to control all of the devices and channels in the control system.

This mathematical model of computation is implemented by using the JCOP Framework [6] in a WinCC

platform [3] so that every ALICE detector has its own FSM integrated in a single tree and a central

operator able to carry out its task effectively. In a complex FSM with hundreds of nodes and thousands of states, the designer can sometimes

make mistakes and create an FSM that has a “Loop”. A loop is a condition where the states of one or more nodes keep getting back to the same states over and over again for an indefinite amount of time. This loop can be very dangerous for the Control System especially when the control system has been implemented for the real detector. An infinite loop can bring the system down and crash the whole control system. To prevent this from happening, it is important for a designer to be able to simulate the FSM that he or she designed before implementing it to a bigger system. The simulation can then determine if there are loops in the FSM and show every parameter value provoking the loops. By performing this test, the user can fix all of the loop possibilities and implement the FSM to the system without any risk of endangering the system.

The main goal of this project is to design a simulator that can simulate any unknown FSM and help designers to create a clean and safe FSM. The other goal of this project is to test the FSM of the ALICE Detector Control System and find all of the possible conditions that can provoke loops. If there is a loop, the DCS team can fix the condition so that the risk can be eliminated.

2

2. Finite State Machine

A Finite State Machine (FSM) is a mathematical model of computation of an abstract machine that can be in exactly one of a finite number of states at any given time. The FSM can change from one state to another in response to some external commands, the change from one state to another

is called a transition. An FSM is defined by a list of its states and the conditions for each transition [8]. FSM behavior can be observed in many devices in modern society, for example vending machines, elevators, traffic lights, and combination locks. All of these devices have a sequence of actions and states

that can determine the output and the behavior of the device [8]. The concept of FSM is also used for the control system of the detector at CERN. The controller

usually does not know about the hardware behind the control system [5], it controls the detector by

looking at the topology similar to the figure below:

Figure 1. Detector Topology [5]

Each node in the tree has its own state at a given time. The state of each node depends on the state of its children, so the state will propagate up from the devices (the most bottom nodes) to their

parent and arrive at the top node [5]. The parent can also trigger a sequence of commands that will

propagate down and will affect the states of its children [5]. An illustration of a state and command

propagation can be found in the figure below:

Figure 2. State Propagation [5]

Figure 3. Command Propagation [5]

https://en.wikipedia.org/wiki/Model_of_computation

https://en.wikipedia.org/wiki/Abstract_machine

https://en.wikipedia.org/wiki/Abstract_machine

https://en.wikipedia.org/wiki/State_(computer_science)

3

Each node in the tree can act as a control unit or a device unit [5]. The device unit is usually

connected to the hardware and models the behavior of that particular hardware while control unit usually models an abstract object that has states and a sequence of commands to control the device unit [5].

3. Loop

A loop is a condition where one or more nodes in an FSM keep going back to the same state over and over again for an indefinite period of time. A loop can be very harmful for the control system and for the real device itself. One example of a “simple” loop is presented below:

Figure 4. Example of A Loop (1)

For example, there is a Device with two Channels with a ‘when list’ condition of the device stating that:

If All Children in State ‘ON’ do “SWITCH OFF”

If All Children in State ‘OFF’ do “SWITCH ON”

So whenever both channels are in state ‘ON’, the DEVICE will do the “SWITCH OFF” command to switch off all channels (see Figure 5). And right after the channels reach state ‘OFF’, the DEVICE will do the “SWITCH ON” command to switch on all channels (see Figure 6).

Figure 5. Example of a Loop (OFF State) (left); Figure 6. Example of a Loop (ON State) (right).

When the channels reach state ‘ON’, the DEVICE will then do the SWITCH OFF command again and this cycle will keep going through for an indefinite amount of time (see Figure 7). In a more complex FSM, the loop can also happen between more than 2 states. For example, if there is a transition state between ‘ON’ and ‘OFF’, then the loop will cycle through 4 states instead of 2 states (see Figure 8).

4

Figure 7. Example of A Loop with Only 2 States (left); Figure 8. Example of A Loop with More Than 2 States (right).

4. Designing The Simulator

To create a simulator for an FSM, we need to read the structure of the unknown FSM. For this purpose, the function “getstructure” is created to save the structure of the unknown FSM. The structure will then be saved in a dynamic string matrix similar to the matrix that is presented in the example below: Table 1. Dynamic String Matrix of Function “getstructure”

DETECTOR

SIDE A SIDE C

DEVICE 1 DEVICE 2 COOLING

CHANNEL

DEVICE 3 DEVICE 4 SECURITY

ALARM

DEV1_CH1 DEV1_CH2 DEV2_CH1 DEV2_CH2 DEV3_CH1 DEV4_CH1 DEV4_CH2

In this format, the stage and position of each node can be obtained, but the “parent-children” relationship of each node is still unknown. The function “changestructure” is provided to change the

structure of the unknown FSM and save it in a dynamic string matrix as shown in the example below: Table 2. Dynamic String Matrix of Function “changestructure”

DETECTOR SIDE A DEVICE 1 DEV1_CH1




DETECTOR SIDE A COOLING

CHANNEL

DETECTOR SIDE C DEVICE 3 DEV3_CH1

DETECTOR SIDE C SECURITY ALARM



Getting the structure of the FSM is not enough to perform the simulation. The datapoint structure, datapoint elements, and the datapoint elements type of each device are also needed for the simulation. To obtain these parameters, we can use the function “extractstructure” to extract the

datapoint structure and save it in a dynamic string matrix shown in the example below: Table 3. Dynamic String Matrix of Function “extractstructure”

CHANNEL STATUS ONOFF

CHANNEL PARAMETER VOLTAGE

CHANNEL PARAMETER CURRENT

CHANNEL ERRORCODE

This function uses the WinCC function “dpTypeGet()” [7] which returns the datapoint elements

and the datapoint elements type for a given datapoint type. It is also important to note that for a complex datapoint type, there is a possibility of a subtype in a datapoint. The subtype in the datapoint can be detected by setting the value to ‘TRUE’ for the “IncludeSubType” parameter of the function

“dpTypeGet” [7].

From the table above, the data point name of each device can be obtained by using the function “saveDP” where we can get the format of the datapoint as shown in the table below:

Table 4. Dynamic String Matrix of Datapoint Elements in DEV1_CH1

DEV1_CH1.STATUS.ONOFF

DEV1_CH1.PARAMETER.VOLTAGE

5

DEV1_CH1.PARAMETER.CURRENT

DEV1_CH1.ERRORCODE

For some devices, the names of the nodes are different from the names of the datapoints (the

designer sometimes uses Alias instead of the datapoint name). In this case, the alias of the datapoint

needs to be obtained first by using the WinCC function “getAliasToName()” [7 ].

By saving the datapoint name for each device (the last node of the FSM), the full array of datapoint elements in an FSM can be produced. This array is the most important element for the simulation process as it contains every datapoint name in the simulated FSM. After obtaining the FSM structure and the datapoint structure, the whole structure is displayed in a big panel with the function “printstructure”. The panel is displayed in the following format:

Figure 9. The Output of Function “printstructure”.

The simulation can be performed by setting the values or range of values of the datapoints and

setting the datapoints to every possible combination to see if there is a “Loop” in the combination. The user first needs to enter values or the range of values for the datapoints, and for this purpose 2 panels representing 2 modes of the simulation are presented.

MODE 1

In this mode, the values of the datapoints for each datapoint type can be assigned by typing it in the textbox using comma (“,”) as shown in the example below:

Figure 10. Simulation Panel for MODE 1.

6

The drawback of this mode is that if we want to set a large range of values for integer or float (e.g. -100,-99,-98 ... 98,99,100), we need to type the values one by one which is time consuming and quite ineffective. For that reason, the second mode called “MODE 2” is provided.

MODE 2

In this mode, the values of the datapoints for boolean and string type can be assigned by typing the value in the textbox using comma (“,”) as the separator. However, the datapoint values for the float and integer is assigned differently. They are assigned by typing the bottom limit, upper limit, and increment in the three textboxes shown below:

Figure 11. Panel Display for Integer and Float in MODE 2.

For example, if we type -100 as the bottom limit, 100 as the upper limit, and 1 as the increment.

The panel will automatically generate the values ranging from -100 to 100 with the increment of 1 for that particular datapoint element (-100,-99,-98, .... ,0, .... ,98,99,100). This mode is more effective for FSM with an unknown state transition condition as we can just provide a large range of values and the simulator will run on its own.

For a big FSM with complex a datapoint structure, there can be hundreds of datapoint elements, but usually not all of them are used. In fact, the state of the device only depends on a small number of the datapoint elements. To save time and energy, in this simulator the user only needs to input the value of the “critical” datapoint elements whose value can affect the state of the device. This feature is added to make the simulator more user friendly, as the user may input only the datapoint elements that he or she considered as “critical”, and leave others behind. Of course, to prevent the simulator from simulating unnecessary combinations, this simulator is designed so that it will only save datapoints whose values are inputted by the user. As for the datapoints whose values are not inputted, the datapoint values will not be set in the simulation.

To perform a simulation that is able detect loops, all the possible combinations of the device states need to be covered. To cover all of the possible states, the easiest way is to cover all of the possible combinations of the device datapoints that will affect the state changes. The simulation can then be performed by using the function “simulate”. In this function, the “recursive logic” is implemented to be

able to reach every possible combination. Usually, the main logic to reach every possible combination is by using a nested for-loop. For example, if we want to simulate all combinations of 3 datapoints with the following range of values:

The first datapoint : -1,0,1

The second datapoint: 0,1

The third datapoint: READY,RUN,STOP

Then we will need a nested for-loop with the following structure: Simulate (list of parameter){

For (-1 to 1){ //first datapoint

For (0 to 1){ //second datapoint

For (READY to STOP){ //third datapoint

//Set the values

//Do the simulation

}

}

}

}

7

But the problem is that the depth of the for-loop (number of “for-loop”) will depend on the number of datapoints that are going to be simulated, and the more datapoint elements we have, the deeper the for-loop will be. The solution to this problem is to use the “Recursive Logic”. The “Recursive Logic” is a logic where one function keeps calling itself until the stopping condition is reached. The recursive logic has 2 parts, the base case and the recursive rule. The base case is the stopping condition of the recursive logic and the recursive rule is the condition where the function needs to call itself. For our case, the stopping condition is when the number of the “for-loop” is equal to the number of datapoint elements. With this concept, the recursive function can then be constructed in the following structure: Simulate (list of parameter){

//Base Case

If (n==dynlen(dplist))

//dplist is the number of all datapoint elements in the FSM structure

//n is the number representing how deep we are in the loop

{

//set the values

//set the delay

//do the simulation

//set n to the new value (the depth of the next loop)

}

//Recursive Rule

else {

n++;

for (1 to N (number of values))

//save the value

Simulate(list of parameter);

}

This function will automatically generate the “for-loop” until the number of the “for-loop” is

equal to the number of the datapoint elements, and after the stopping condition is met, the function will stop generating the “for-loop” and start the simulation which will automatically cover all of the possible combinations.

Remember that the purpose of performing this simulation is to provoke and find combinations that can cause loops in an FSM. As mentioned in Section 2, a loop is described as a condition where one or more nodes keep getting back to the same state for an infinite amount of time. Therefore, we can determine if a node is in a loop or not by counting how many times that node goes back to the same state.

To count how many times one node goes back to the same state, the function

“fwCU_ConnectState” [9] from the JCOP Framework is used. This function can connect the state behavior

of a node with a CallBack function, and execute the CallBack function every time there are state changes in that node. VerifyLoopCB (string node, string state){

Counterloop=0;

// count how many times the state has been reached before

// save the counter in a variable counterloop

If (counterloop > constant_limit)

{

IsLoop=TRUE;

}

}

To count how many times the state has been reached, for each combination the states are

saved in a dynamic string matrix format shown in the table below:

8

Table 5. Dynamic String Matrix for Counting the Loop

DEVICE NAME

SEQUENCE OF STATES FROM TIME TO TIME

1 DEV1_CH1 RAMPING DOWN

OFF


OFF


OFF RAMPING DOWN

OFF

4 COOLING_CH RAMPING DOWN

OFF RAMPING UP

ON RAMPING DOWN

OFF RAMPING UP

ON

5 DEV3_CH1 OFF RAMPING UP

OFF

Each time there are state changes, a new cell containing the new state will be added and the

counter will increase if the same state can be found in the array. In the table above, number (1) and (2) are normal transitions while number (4) is an example of a loop where a new state will keep being appended endlessly (the counter loop will keep increasing). On the other hand, number (3) and (5) are examples of a glitch (with the counter of 2). A glitch is a condition when a node goes back to the same state before going to another state, this could happen because we set the value in a sequential order, not at the same time. A glitch is different from a loop as it will stop after a short time.

In this simulator, a loop is suspected if there is one node that goes back to the same state once. We can then say that if the counter shows a number more than 0 in some period of time then it can be considered a “suspicious loop”. It is a “suspicious loop” because it cannot be guaranteed as a loop just yet (it can also be a glitch) and will need to be examined further. To distinguish between loops and glitches, a second simulation needs to be performed. This second simulation is called the verification simulation. This second simulation will examine only the combinations that we previously considered as “suspicious loops” for a longer period of time (5x-10x the previous period) and once again count how many times a node goes back to the same state. In other words, the verification simulation will see the behavior of a node in a longer time frame, and check if the state transition will stop or not. If it stops, then it is only a glitch, but if it does not stop, it can be considered as a loop. In this simulator we set a limit for the counter, so if there is a node that goes back to the same state more than 10 times, then it is considered no longer as a glitch, but as a loop. The diagram explaining the basic simulation and the verification simulation is presented in the figure below:

Figure 12. The Simulation Diagram

In the “simulate” pseudocode, there is a delay parameter in the simulation. The delay parameter in the simulate function is simply the time range that is provided for the counter to count how many times a node goes back to the same state. That is why this delay is one of the most important elements

9

in the simulation as it will also determine the success rate of the simulation. If the delay is large, we have a greater chance of success, however it will take a longer time to simulate. And if the delay is small, we have a smaller chance of success but a shorter simulation time. The delay for the basic simulation and the verification simulation can be set with the delay textfield at the “MODE1” and “MODE2” user interface panel.

The other reason for using this two-stages simulation is to shorten the simulation time. We can also perform a one stage simulation with longer delay and bigger counter limit, but for a large FSM with a lot of devices and datapoints, there will be millions of possible combinations and it will require a very long simulation time. To prevent this from happening, the two-stages simulation is implemented: the first stage filters the combination to only the “suspicious combinations” that can cause loops, and the second stage distinguishes between loops and glitches and determine every combination that causes the loops. Because the first stage simulation has a much shorter delay than the second, this approach will be less time consuming. For further modification, a three or four stage simulation can also be implemented to increase the effectiveness and the accuracy of the simulator.

5. Testing Result First, the simulator is tested on an FSM with “loops” that is not a real detector. The topology of this FSM is presented in the figure below:

Figure 15. The Topology of SIDE_LOOP.

The loops are added in this system by injecting codes in the ‘state when list’ of the system. The ‘state

when list’ is the code that is executed when an object reaches a particular state [7]. By injecting the code:

WHEN LIST for ‘OK’:

when ($ALL$DEV in_state STANDBY) and ($ALL$COOLING_PLANT in_state STOP) do START

WHEN LIST for ‘NOT_OK’:

when ($ALL$DEV in_state ON) and ($ALL$COOLING_PLANT in_state RUNNING) do STOP

We can generate loops whenever all devices and cooling plants are ‘ON’ or all devices and

cooling plants are ‘OFF’. The system will then be simulated using the simulator to test whether the simulator can detect all of the possible loops or not. For this testing, there are only 576 combinations in total, so we can set a slightly longer delay, 150 ms for basic simulation and 400 ms for verification simulation. The result of this simulation is then presented below: WCCOAui1:["The order of the datapoints: "]

WCCOAui1:["CHANNEL1.OnOff, CHANNEL1.ErrorCode, CHANNEL2.OnOff, CHANNEL2.ErrorCode,

CHANNEL3.OnOff, CHANNEL3.ErrorCode, COOLCHANNEL1.CoolingState, COOLCHANNEL2.CoolingState"]

WCCOAui1:["The combinations of datapoints that can trigger loops:"]

WCCOAui1:[dyn_dyn_string 10 items

WCCOAui1: 1: dyn_string 1 items

WCCOAui1: 1: "0 | 0 | 0 | 0 | 0 | 0 | 0 | 0"


WCCOAui1: 1: "0 | 0 | 0 | 0 | 0 | 0 | 0 | 1"


WCCOAui1: 1: "0 | 0 | 0 | 0 | 0 | 0 | 1 | 0"


WCCOAui1: 1: "0 | 0 | 0 | 0 | 1 | 0 | 0 | 0"

10


WCCOAui1: 1: "0 | 0 | 0 | 0 | 1 | 0 | 0 | 1"


WCCOAui1: 1: "0 | 0 | 0 | 0 | 1 | 0 | 1 | 0"


WCCOAui1: 1: "0 | 0 | 1 | 0 | 0 | 0 | 0 | 0"


WCCOAui1: 1: "0 | 0 | 1 | 0 | 0 | 0 | 0 | 1"


WCCOAui1: 1: "0 | 0 | 1 | 0 | 0 | 0 | 1 | 0"


WCCOAui1: 1: "1 | 0 | 1 | 0 | 1 | 0 | 1 | 1"

WCCOAui1:]

From the testing result, it can be seen that there are 10 loops detected in this FSM. When we

perform further manual examinations, we found that all of the combinations above are the combinations that set both devices and cooling plant to ‘ON’ or set both devices and cooling plant to ‘OFF’. Therefore, it can be concluded that this simulator is able to detect all of the possible loops accurately. Some of the console displays during the simulation is presented below: Table 6. Console Display during the Simulation

Basic Simulation

Basic Simulation Display When The Combination is Not Suspected As A Loop

Basic Simulation Display When The Combination is Suspected As A Loop

WCCOAui1:["Count Combinations : 30"]

WCCOAui1:["Set Values: 0, 0, 0, 0, 1, 1, -1,

1"]

WCCOAui1:["Current States: "]



WCCOAui1: 1: "ERROR"


WCCOAui1: 1: "STANDBY"




WCCOAui1: 1: "OFF"

WCCOAui1: 2: "OFF"



WCCOAui1: 5: "ON"

WCCOAui1:]

WCCOAui1:["Loop Possibility: No"]

WCCOAui1:["Count Combinations : 9"]

WCCOAui1:["Set Values: 0, 0, 0, 0, 0, 0, 1,

1"]

WCCOAui1:["Current States: "]



WCCOAui1: 1: "OK"


WCCOAui1: 1: "ON"

WCCOAui1: 2: "ON"

WCCOAui1: 3: "RUNNING"


WCCOAui1: 1: "OFF"

WCCOAui1: 2: "OFF"

WCCOAui1: 3: "ON"

WCCOAui1: 4: "ON"

WCCOAui1: 5: "ON"

WCCOAui1:]

WCCOAui1:["Loop Possibility: Yes"]

Verification Simulation

Verification Simulation Display When the Combination is Not Determined as a Loop

Verification Simulation Display When the Combination is Determined as a Loop

WCCOAui1:["Total suspicious loops: 18"]

WCCOAui1:["Count suspicious loops: 3"]

WCCOAui1:["Set Values: 0, 0, 0, 0, 0, 0, 1, -

1"]

WCCOAui1:["Current States : "]









WCCOAui1: 1: "OFF"

WCCOAui1: 2: "OFF"

WCCOAui1: 3: "OFF"

WCCOAui1: 4: "ON"


WCCOAui1:]

WCCOAui1:["THIS ONE IS NOT A LOOP"]

WCCOAui1:["Loops Detected so Far: 2"]

WCCOAui1:["Total suspicious loops: 18"]

WCCOAui1:["Count suspicious loops: 4"]

WCCOAui1:["Set Values: 0, 0, 0, 0, 0, 0, 1,

0"]

WCCOAui1:["Current States : "]



WCCOAui1: 1: "OK"


WCCOAui1: 1: "ON"

WCCOAui1: 2: "ON"

WCCOAui1: 3: "RUNNING"


WCCOAui1: 1: "OFF"

WCCOAui1: 2: "OFF"

WCCOAui1: 3: "OFF"

WCCOAui1: 4: "OFF"

WCCOAui1: 5: "OFF"

WCCOAui1:]

WCCOAui1:["IT'S A LOOOOOP!!!"]


11

Next, we test the simulator on a real branch of ALICE Detector. A branch of PHOS detector

(Photon Spectrometer) [10] called “phos mod 1” is chosen for the simulation. To shorten the simulation

time, we can simplify this detector by removing some channels which have the same type. But it is also important to remember that this action can only be performed if the presence of the device/channel is guaranteed to be unnecessary and will not affect the simulation’s result. The FSM of this detector can be seen in a figure below:

Figure 13. The Topology of phos_mod1.

The structure of this detector is then extracted and printed below:

Figure 14. The Printed Structure of phos_mod1.

We use MODE1 simulation. To shorten the simulation time, we select the minimum number of

combinations that still cover all possible states. This simulation test uses 10 ms delay for the basic simulation and 100 ms delay for the verification simulation. The testing result of this simulation is presented below: WCCOAui1:["Total suspicious loop: 118363"]

WCCOAui1:["Count suspicious loop: 118363"]

WCCOAui1:["Set Value: 1, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, 0, 0, 0, 0, 0,

0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 300, 0, 0, 0, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0, 1,

0, 1, 0, 1"]

WCCOAui1:["Current State : "]







WCCOAui1: 3: "UPLOADED"




12






WCCOAui1: 8: "UPLOADED"

WCCOAui1:]

WCCOAui1:["THIS ONE IS NOT A LOOP"]


WCCOAui1:["The order of the datapoints: "]

WCCOAui1:["Wiener/alidcswie196.Status.On, Wiener/alidcswie196.Status.InputFailure,

Wiener/alidcswie196.Status.SystemFailure, Wiener/alidcswie196.Status.FanTrayFailure,

Wiener/alidcswie196.Status.SensorFailure, Wiener/alidcswie196.Status.SignalFailure,

Wiener/alidcswie196/Channel0.Status.On,

Wiener/alidcswie196/Channel0.Status.FailureMaxTemperature,

Wiener/alidcswie196/Channel0.Status.FailureMaxCurrent,

Wiener/alidcswie196/Channel0.Status.FailureMaxSenseVoltage,

Wiener/alidcswie196/Channel0.Status.FailureMaxTerminalVoltage,

Wiener/alidcswie196/Channel0.Status.FailureMinSenseVoltage,

Wiener/alidcswie196/Channel0.Status.FailureMaxPower,

Wiener/alidcswie196/Channel0.Status.FailureTimeout,

Wiener/alidcswie196/Channel0.Status.RampUp, Wiener/alidcswie196/Channel0.Status.RampDown,





Wiener/alidcswie196/Channel4.Statu

WCCOAui1:s.FailureMaxTerminalVoltage,









Wiener/alidcswie195/Channel6.Status.FailureMaxTerminalVoltage,





dist_1:Iseg/can0/crate00.Actual.On, dist_1:Iseg/can0/crate00.Actual.AlarmFlag,

Iseg/can0/crate00/ma01.Actual.On,

Iseg/can0/crate00/ma01.ReadBackSettings.StatHardwareVLimit,

Iseg/can0/crate00/ma01.ReadBackSettings.StatHardwareILimit,

Iseg/can0/crate00/ma01.ReadBackSettings.StatITrip, Iseg/can0/crate00/ma01/ch00.Actual.On,

Iseg/can0/crate00/ma01/ch00.Actual.ITripStat,

Iseg/can0/crate00/ma01/ch00.Actual.RampingStat,

Iseg/can0/crate00/ma01/ch00.Actual.ILimitError, sru01.control.command.firmware,

sru01.control.command.fee_cfg, sru01.control.command.fee_mask, sru01.control.command.altro,

sru01.control.command.pedestal, sru01.control.command.hv, sru01.control.status.firmware,

sru01.control.status.fee_cfg, sru01.control.status.fee_mask, sru01.control.status.hv,

sru01.control.status.count"]

WCCOAui1:["The combinations of datapoints that can trigger loops:"]


WCCOAui1:]

The testing result showed that there is no loop in the “phos mod 1” FSM. The basic simulation

caught a lot of glitches (around 118363), but the verification simulation did not catch any loop. However, this testing result cannot be trusted 100% because there is a possibility that the time to perform one single loop is more than 10 ms. If that is the case, then the loop will not be suspected as a loop during the basic simulation and the simulation result will be incorrect. To obtain a more trustworthy result, the simulation needs to be performed once again with a longer delay for the basic simulation and the verification simulation, but in return it will also consume a much longer simulation time (about 200-300 hours). The longer simulation will be performed later, so the result will not be presented in this paper.

13

6. Future Improvements for the Simulator

There is a number of improvements that can be made on the simulator. The simulation time is now the biggest limitation, since the time needed to simulate a big FSM can take weeks or even months. One of the improvements that can shorten the simulation time is by simulating not the combination of the datapoint elements, but the combination of the states in each device. This approach will be able to minimize the number of combinations to a minimum limit.

7. Conclusion

We present a simulator that can get the structure of any unknown FSM and all of the datapoint elements that are included in the FSM. All of the possible combinations of the datapoint elements is reached by using a recursive function with the base case “when the number of the for-loops is equal to the number of the datapoint elements”. We proposed to divide the simulation into two parts, the basic simulation which filters all of the possible combinations to only glitches and loops and the verification simulation which separates between glitches from loops. Our experiment on “Phos Mod 1” showed that there is no loop in the FSM. This simulation result can still be incorrect if the time needed to perform 1 loop is bigger than 10 ms (the delay parameter of the basic simulation). The simulation result for the “Sample Detector” SIDE LOOP showed that the simulator can detect all of the combinations that provoke loops accurately. In future work, this simulator can still be upgraded by shortening the simulation time and minimizing the combinations to increase its efficiency.

8. References

1. The ALICE Collaboration et al., “The ALICE experiment at the CERN LHC”, JINST 3, S08002, 2008.

2. The ALICE Collaboration, “Technical Design Report of the Trigger, Data Acquisition, High-Level Trigger and Control System,” CERN/LHCC/2003-062.

3. Simatic WinCC Open Architecture, developed by ETM GmbH, http://www.etm.at/index_e.asp?id=2.

4. Gaspar, Clara, ”The Finite State Machine Toolkit of The JCOP Framework,”

http://indico.cern.ch/getFile.py/access?contribId=s1t4&resId=0&materialId=0&confId=a041114, 2004

5. Boccioli, Marco, “Short Introduction to JCOP Hierarchical Control (FSM),” http://indico.cern.ch/event/140703/contribution/1/attachments/123813/175820/FSM_overview.pptx, 2011.

6. Gonzalez Berges, Manuel, “The JCOP Framework,”

http://indico.cern.ch/event/420901/contributions/1884529/attachments/881072/1237355/06_0900.ppt, 2005.

7. Siemens Automation, “WinCC OA 3.15 Documentation English”. 8. Wikipedia, “Finite-state Machine”, https://en.wikipedia.org/wiki/Finite-state_machine. 9. The LHCb Collaboration et al., “Installing and Using the PVSS/FSM tools

on Linux or Windows”, https://lhcb-online.web.cern.ch/lhcb-online/ecs/fw/FW_FSM_WCCOA_SP1.HTML.

10. The ALICE Collaboration, “The ALICE Photon Spectrometer (PHOS),”

http://aliceinfo.cern.ch/Public/en/Chapter2/Chap2_phos.html. 2008.

http://www.etm.at/index_e.asp?id=2

http://indico.cern.ch/getFile.py/access?contribId=s1t4&resId=0&materialId=0&confId=a041114

http://indico.cern.ch/getFile.py/access?contribId=s1t4&resId=0&materialId=0&confId=a041114

http://indico.cern.ch/event/140703/contribution/1/attachments/123813/175820/FSM_overview.pptx

http://indico.cern.ch/event/140703/contribution/1/attachments/123813/175820/FSM_overview.pptx

http://indico.cern.ch/event/420901/contributions/1884529/attachments/881072/1237355/06_0900.ppt

http://indico.cern.ch/event/420901/contributions/1884529/attachments/881072/1237355/06_0900.ppt

https://en.wikipedia.org/wiki/Finite-state_machine

https://lhcb-online.web.cern.ch/lhcb-online/ecs/fw/FW_FSM_WCCOA_SP1.HTML

https://lhcb-online.web.cern.ch/lhcb-online/ecs/fw/FW_FSM_WCCOA_SP1.HTML

http://aliceinfo.cern.ch/Public/en/Chapter2/Chap2_phos.html

designing a finite state machine simulator to detect …

Documents