Log In
Home
04/22/2021
Offline
Hi,
Programs allow having PFSM which enables a program to handle a state machine and then the OPC UA 1.05 introduced State Machines independently which allows building a state machine and each state is capable of running certain algorithms implemented as methods. Now my question is when to use Programs and when to use State Machines? Why was necessary to have a state machine as an independent chapter in OPC UA.
05/30/2017
Offline
The StateMachines are not new.
They used to be in an Appendix in Part 5 (https://reference.opcfoundatio…..Part5/B.1/)
StateMachines are a generic construct that can be be used in many contexts. For example, Alarms use StateMachine Objects (https://reference.opcfoundatio…..rt9/5.8.2/) or MachineVision (https://reference.opcfoundatio…..ocs/8.2.2/)
Programs are built with StateMachine and represent a long running task.
You would only use Programs to when it fits with your use case:
https://reference.opcfoundatio…..t10/4.2.1/
Programs are complex Functions in a Server or underlying system that can be invoked and managed by a Client. Programs can represent any level of functionality within a system or process in which Client control or intervention is required and progress monitoring is desired. Figure 2 illustrates the model.
07/15/2021
Offline
what do long-running tasks mean? and How should these long-running tasks be implemented inside the Programs? For example, if I have a timer in my state machine that is monitoring the value of an OPC UA variable and triggers a transition based on that, would this be considered a long-running task? (should I call it a program?)
05/30/2017
Offline
A long running task is something that takes a long time to complete and it does not make sense for a client to block waiting for it to finish. An example is the start up sequence for a boiler in a coal generation plant which takes several hours.
04/22/2021
Offline
@Randy: So here long means several hours right? So if a task takes a shorter time like 10 min this can be implemented inside state machines and no need for PFSM. Is this what you are saying?
05/30/2017
Offline
The definition of “long running” depends on the application and should be based on understanding of the process being modelled. There is no standard rule. Some applications could decide that 5mins counts as “long running”.
04/22/2021
Offline
So according to your replies:
- The definition of “long” depends on the application, in some applications this could be 1ms or 1s or 1h or several hours.
- We use PFSM whenever we have a long-running task and we do not need to wait for it.
From the above facts, I can conclude that we are using PFSM when we have a task (a method in the program) that could be invoked/executed asynchronously so we do not need to wait for the completion of this task. But the point is that what prevents us from not being able to have a long-running task in FSM? Only an agreement in specification level?
Some more backgrounds:
What we are more interested to know is to learn how this differentiation between PFSM and FSM has been considered in the OPC UA stacks. From our experiments on different OPC UA stacks, we have noticed that similar to PFSM we can also have a method that is running asynchronously in OPC UA FSM so when we look at the difference between FSM and PFSM at the implementation level we see that in both options we could have defined long-running tasks.
05/30/2017
Offline
A Program is an object that can be used to model long running tasks supported by the Server.
A StateMachine is simply a state machine that has no implied application specific semantics. StateMachines get their semantics when they are added to Objects such as a Program.
While a StateMachine can use used for long running tasks you server will have to supply all the semantics needed to tell the client that this particular StateMachine is intended to represent a long running task. OTOH, if you used a Program the client would immediately know that it represents a long running task because that is what Programs represent.
1 Guest(s)
Usage Policy