4.2.3 Program Finite State Ma hine The states, tran ition , cau es an ef fects that comp se the Pro ram F init e St at e Mac ine are lsted in Ta le 1 an i u trated in Fig re 3.. Table 3
Terms and definitions
For the purposes of this document, the terms and definitions given in IEC TR 62541 -1 , IEC 62541 -3, as well as the following apply
3.1 1 function programmatic task performed by a server or device, usually accomplished by computer code execution
A Finite State Machine (FSM) is a computational model that represents a sequence of states and the valid transitions between them It outlines the causes and effects of these transitions, effectively defining a program's actions through discrete stages.
ProgramType type definition of a Program and is a subtype of the FiniteStateMachineType
Method having specific semantics designed for the control of a Program by causing a state transition
Program Invocation unique Object instance of a Program existing on a Server
Note 1 to entry: A Program Invocation is distinguished from other Object instances of the same ProgramType by the object node’s unique browse path.
Abbreviations
General
Integrated automation facilities operate by exchanging data and coordinating system functions, as shown in Figure 1 To facilitate these operations, services are essential for data exchange and function invocation, which can be executed through Human Machine Interfaces, cell controllers, or supervisory control and data acquisition systems OPC UA introduces Methods and Programs as interoperable means to advertise, discover, and request these functions, providing a standardized approach for semantic description, invocation, and result reporting Together, Methods and Programs enhance other OPC UA Services and ObjectTypes, supporting the effective operation of an automation environment within a client-server framework.
Methods and programs in OPC Servers exhibit varying scopes, behaviors, lifetimes, and complexities These functions are generally not defined by data reading or writing, which is primarily handled by the OPC protocol.
Methods are fundamental functions in a Server that can be called by a Client, while Programs represent more complex and stateful system functionalities For instance, a method call can execute calculations or reset counters, whereas a Program is utilized to manage batch processes, execute machine tool part programs, or handle domain downloads The invocation mechanism for Methods is detailed in IEC 62541-3 and IEC 62541-4.
This standard describes the extensions to, or specific use of, the core capabilities defined in IEC 62541 -5 as required for Programs.
Programs
Overview
Programs are intricate functions within a server or underlying system that clients can invoke and manage They can embody various levels of functionality where client control or intervention is necessary, along with the need for progress monitoring This concept is visually represented in Figure 2.
Programs operate in a stateful manner, progressing through a defined sequence of states during execution Their behavior is governed by a Program Finite State Machine (PFSM), which outlines the phases of execution through valid state transitions, the stimuli that trigger these transitions, and the resulting effects.
Security considerations
To ensure the effective use of advanced control algorithms, access to programs should be limited to authorized personnel only It is advisable to generate AuditUpdateMethodEvents to monitor both the number of active programs and their execution frequency.
Program Finite State Machine
The states, transitions, causes and effects that compose the Program Finite State Machine are listed in Table 1 and illustrated in Figure 3
Table 1 – Program Finite State Machine
No Transition name Cause From state To state Effect
1 HaltedToReady Reset Method Halted Ready Report Transition 1
2 ReadyToRunning Start Method Ready Running Report Transition 2
Internal (Error) Running Halted Report Transition 3
4 RunningToReady Internal Running Ready Report Transition 4
No Transition name Cause From state To state Effect
6 SuspendedToRunning Resume Method Suspended Running Report Transition 6
7 SuspendedToHalted Halt Method Suspended Halted Report Transition 7
8 SuspendedToReady Internal Suspended Ready Report Transition 8
9 ReadyToHalted Halt Method Ready Halted Report Transition 9
Figure 3 – Program states and transitions
Program states 1 0
A standard set of base states is established for Programs within the Program Finite State Machine, representing the various stages a Program can occupy at any given moment from the Client's perspective This current state is essential, and all Programs must adhere to this base set Additionally, a Program may require a Client action to trigger a state change, as detailed in Table 2.
Ready The Program is properly initialized and may be started
Running The Program is executing making progress towards completion
Suspended The Program has been stopped prior to reaching a terminal state but may be resumed
Halted The Program is in a terminal or failed state, and it cannot be started or resumed without being reset
The set of states used to describe a Program can be expanded by defining sub states for the base states, allowing for greater detail in the process and a clearer understanding of the causes and effects of additional stimuli and transitions Industry groups and standards bodies may enhance the base Program Finite State Model to align with specific industry models For instance, the Halted state can be subdivided into "Aborted" and "Completed" to specify the outcome of the process.
9 the function achieved a successful conclusion prior to the transition to Halted Transitional states such as “Starting” or “Suspending” might also be extensions of the Running state, for example.
State transitions 1 1
The Program Finite State Machine is governed by a standard set of state transitions that outline the permissible changes between the initial and resultant states of the Program These transitions are formally detailed in Table 3.
Transition no Transition name Initial state Resultant state
Program state transition stimuli 1 1
A Program's state transitions can be triggered by both internal and external stimuli Internal stimuli include the completion of machining steps, detection of alarm conditions, and the transmission of data packets In contrast, external stimuli are represented by methods, specifically Standard Methods, which serve as control stimuli for the Program.
Program Control Methods 1 1
Clients control a Program through the invocation of Methods, which influence the Program's behavior by triggering specific state transitions These transitions determine the actions executed by the Program This standard outlines a comprehensive set of Program Control Methods, equipping clients with the necessary tools to effectively operate a Program.
Table 4 lists the set of defined Program Control Methods Each Method causes transitions from specified states and shall be called when the Program is in one of those states
Individual Programs have the flexibility to support specific Program Control Methods For instance, certain Programs may lack the capability to suspend, and therefore, they will not include the Suspend and Resume Methods.
Programs can support additional user defined Methods User defined Methods shall not change the behaviour of the base Program Finite State Machine
Start Causes the Program to transition from the Ready state to the Running state
Suspend Causes the Program to transition from the Running state to the Suspended state
Resume Causes the Program to transition from the Suspended state to the Running state
Halt Causes the Program to transition from the Ready, Running or Suspended state to the
Reset Causes the Program to transition from the Halted state to the Ready state
Program Control Methods utilize arguments that influence program behavior, such as a Start Method that may include an options argument for dynamic settings These arguments can vary across different Program Types According to IEC 62541-4:2015, section 5.11, the Method Call service defines a return status that indicates whether the Program Control Method was successful or provides a reason for its failure.
Program state transition effects 1 2
A program's state transition is driven by a cause and results in an effect, which serves as a byproduct that clients can use to track the program's progress Effects can be categorized as internal or external; for instance, an external effect is the creation of an event notification linked to each unique state transition These events illustrate the program's progression through its defined states, while internal effects may include actions such as data generation.
Program result data 1 2
Result data is generated by a running Program The result data can be intermediate or final Result data may be associated with specific Program state transitions
Intermediate result data is temporary and produced by the Program during non-terminal state transitions The components of these intermediate results are linked to specific state transitions of the Program, with their values being significant solely at the transition level.
Each program state transition can be linked to various result data items, or multiple transitions can share a single result data item An example of intermediate result data is the percentage complete, which is generated during a state transition and made accessible to the client.
Clients can obtain intermediate result data by subscribing to Program state transition Events, which detail the data items associated with each transition When a transition takes place, the generated Event sends the captured result data values to the subscribed Clients However, if no Client is monitoring the Program, the intermediate result data may be discarded.
Terminal result data represents the final output generated by the Program upon its completion, including metrics such as total execution time, number of widgets produced, and any fault conditions encountered This data is communicated to the client through a transition Event when the Program reaches its terminal state Additionally, terminal result data remains accessible within the Program for the Client to review after execution, persisting until the Program Instance is either rerun or deleted.
Clients can track the execution activities of a Program, including management method invocations, result data generation, and state progressions Audit Events document method calls and state transitions, maintaining a record of client interactions and the resulting Program state changes.
Programs can vary in their lifetimes; some remain permanently on a server, while others are created and deleted as needed The process of creation and removal can be managed by a client or may be limited to local methods.
A Program can be created by the Client, allowing it to be added to the Server The Object Create Method specified in IEC 62541-3:2015, section 5.5.4, is utilized for creating the Program instance Initially, the Program can be in either a Halted or Ready state Some Programs may need specific resources to be available after creation and before they can run, leading to an initial Halted state that transitions to Ready once the required resources are provided.
A program can be client removable, allowing the client to delete its instance from the server using the DeleteNodes Service as defined in IEC 62541-4 To be removed, the program must be in a halted state Additionally, a program may be auto removable, meaning it deletes itself automatically once execution has terminated.
Programs can operate as either multiple instances or a single instance, with a Server capable of supporting multiple instances that run in parallel Each Program may include a Start Method that takes an input argument to specify the resource it interacts with, allowing different instances to be initiated with distinct resources Clients can discover all running instances of a Program on a Server, where each instance is uniquely identified and managed independently.
Programs can be executed either once or multiple times A program that runs only once will remain in a Halted state indefinitely after execution Typically, it is advisable to delete the program after reviewing its terminal results.
Recyclable Programs can operate with either a limited or unlimited cycle count and may necessitate a reset step to move from the Halted state to the Ready state This reset process is essential for replenishing resources or reinitializing parameters before the Program restarts The Program Control Method "Reset" initiates this transition, along with any related actions or effects.
General 1 3
The Program model builds upon the FiniteStateMachineType and ObjectType models outlined in IEC 62541-5 Each Program is defined by a Type Definition that is a subtype of the FiniteStateMachineType, which describes the Finite State Machine model applicable to any Program Invocation of that type Additionally, the ProgramType specifies properties that characterize the Program's behavior, including aspects like lifetime and recycling, as well as the result data generated by the Program.
The base ProgramType establishes the standard Finite State Machine for all Programs, encompassing states, transitions, and their causes (Methods) and effects (Events) Subtypes, such as “MyProgramType” shown in Figure 4, can be created to further refine and specify the behavior of individual Programs.
ProgramType 1 4
Overview 1 4
The additional properties and components that compose the ProgramType are listed in Table
5 No ProgramType specific semantics are assigned to the other base ObjectType or FiniteStateMachineType Attributes or Properties
Includes all attributes specified for the FiniteStateMachineType BrowseName ProgramType
HasProperty Variable Creatable Boolean PropertyType
HasProperty Variable Deletabe Boolean PropertyType Mandatory
HasProperty Variable AutoDelete Boolean PropertyType Mandatory
HasProperty Variable RecycleCount Int32 PropertyType Mandatory
HasProperty Variable InstanceCount UInt32 PropertyType
HasProperty Variable MaxInstanceCount UInt32 PropertyType
HasProperty Variable MaxRecycleCount UInt32 PropertyType
HasComponent Variable ProgramDiagnostic ProgramDiagn osticDataType ProgramDiagnosticTy pe Optional
HasComponent Object Halted StateType Mandatory
HasComponent Object Ready StateType Mandatory
HasComponent Object Running StateType Mandatory
HasComponent Object Suspended StateType Mandatory
HasComponent Object HaltedToReady TransitionType Mandatory
HasComponent Object ReadyToRunning TransitionType Mandatory
HasComponent Object RunningToHalted TransitionType Mandatory
HasComponent Object RunningToReady TransitionType Mandatory
HasComponent Object RunningToSuspende d TransitionType Mandatory
HasComponent Object SuspendedToRunnin g TransitionType Mandatory
HasComponent Object SuspendedToHalted TransitionType Mandatory
HasComponent Object SuspendedToReady TransitionType Mandatory
HasComponent Object ReadyToHalted TransitionType Mandatory
HasComponent Object FinalResultData BaseObjectType Optional
ProgramType Properties 1 6
The Creatable Property is a boolean that indicates whether a Client can create Program Invocations of a specific ProgramType If set to False, these Program Invocations become persistent or can only be generated by the Server.
The Deletable Property is a boolean indicating whether a Client can delete a Program Invocation of this ProgramType If set to False, only the Server has the authority to delete these Program Invocations.
The AutoDelete Property is a boolean setting that determines whether Program Invocations of a specific ProgramType are automatically removed by the Server upon execution termination If set to False, these invocations remain on the Server until manually deleted by the Client, along with any associated result data.
The RecycleCount Property is an unsigned integer indicating how many times a Program Invocation has been recycled or restarted from its initial state, rather than resumed It's important to note that the Reset Method may be necessary to prepare a Program for a restart.
The MaxRecycleCount Property is an integer that defines the maximum number of times a Program Invocation can be recycled or restarted from the beginning A value less than 0 indicates no limit on restarts, while a value of zero means the Program cannot be recycled or restarted.
The InstanceCount Property is an unsigned integer that specifies the number of Program Invocations of this type that currently exist
The MaxInstanceCount Property is an integer that defines the maximum number of simultaneous Program Invocations allowed on the Server If the value is less than the specified limit, it restricts the number of concurrent instances.
0, then there is no limit.
ProgramType components 1 6
The ProgramType components consist of a set of References to the Object instances of StateTypes, TransitionTypes, EventTypes and the Methods that collectively define the ProgramFiniteStateMachine
Figure 5 illustrates the component References that define the associations between two of the ProgramType’s states, Ready and Running The complementary ReferenceTypes have been omitted to simplify the illustration
Table 6 outlines the state Objects of the ProgramType, which are instances of the StateType as defined in IEC 62541-5:2015, Annex B Each state is identified by a unique StateNumber Additionally, subtypes of the ProgramType have the capability to reference any state to a subordinate or nested StateMachine Object, thereby enhancing the FiniteStateMachine.
BrowseName References Target BrowseName Value Target
BrowseName References Target BrowseName Value Target
The Halted state is the idle state for a Program It can be an initial state or a terminal state
The Program Invocation cannot start execution due to server conditions, while the Halted state signifies either a failed or completed program To clarify the nature of termination, a subordinate state can be utilized The Halted state is associated with four Transition Objects that define the permissible transitions to the Ready state, as well as from the Ready, Running, and Suspended states.
The Ready state signifies that a program is set to start execution Programs created in a ready state can transition directly to this state This state is associated with four Transition Objects that define the permissible transitions to the Running and Halted states, as well as from the Halted back to the Ready state.
The Running state signifies that the Program is actively executing its functions It involves five Transition Objects that define the permissible state transitions to Halted, Ready, and Suspended states, as well as transitions from the Ready and Suspended states.
The Suspended state signifies that the Program has halted its operations while still being capable of resuming from the exact point it was suspended This state is associated with four Transition Objects that define the permissible transitions to the Ready, Running, and Halted states, as well as from the Ready state.
ProgramType Transitions are defined as instances of the TransitionType in IEC 62541-5:2015, Clause B.4, which outlines the definitions for ToState, FromState, HasCause, and HasEffect Table 7 details the specific transitions for the ProgramType, with each transition assigned a unique TransitionNumber Additionally, the Notes column clarifies when a cause references Methods and indicates the optional nature of effects.
BrowseName References Target BrowseName Value Target
HasEffect ProgramTransitionEventType HasEffect AuditProgramTransitionEventTy pe
HasEffect ProgramTransitionEventType HasEffect AuditProgramTransitionEventTy pe
HasEffect ProgramTransitionEventType HasEffect AuditProgramTransitionEventTy pe
HasEffect ProgramTransitionEventType HasEffect AuditProgramTransitionEventTy pe
RunningToSuspend ed HasProperty TransitionNumber 5 PropertyType
HasEffect ProgramTransitionEventType HasEffect AuditProgramTransitionEventTy pe
SuspendedToRunni ng HasProperty TransitionNumber 6 PropertyType
BrowseName References Target BrowseName Value Target
HasEffect ProgramTransitionEventType HasEffect AuditProgramTransitionEventTy pe
HasEffect ProgramTransitionEventType HasEffect AuditProgramTransitionEventTy pe
HasEffect ProgramTransitionEventType HasEffect AuditProgramTransitionEventTy pe
HasEffect ProgramTransitionEventType HasEffect AuditProgramTransitionEventTy pe
The HaltedToReady transition specifies the transition from the Halted to Ready states It may be caused by the ResetMethod.
The ReadyToRunning transition specifies the transition from the Ready to Running states It is caused by the Start Method
The RunningToHalted transition specifies the transition from the Running to Halted states It is caused by the HaltMethod
The RunningToReady transition refers to the shift from the Running state to the Ready state, while the RunningToSuspended transition indicates the change from Running to Suspended, triggered by the Suspend Method.
The SuspendedToRunning transition specifies the transition from the Suspended to Running states It is caused by the Resume Method
The SuspendedToHalted transition specifies the transition from the Suspended to Halted states It is caused by the HaltMethod
The SuspendedToReady transition specifies the transition from the Suspended to Ready states It is caused internally
The ReadyToHalted transition specifies the transition from the Ready to Halted states It is caused by the HaltMethod
Each Program transition is associated with two HasEffect references: ProgramTransitionEventType and AuditProgramTransitionEventType, as outlined in section 5.2.5 The ProgramTransitionEventType informs Clients about the transition and provides result data, while the AuditProgramTransitionEventType is utilized for auditing transitions initiated by Program Control Methods Additionally, the "Audit Server Facet" Profile specified in IEC 62541-7 mandates the support of the AuditProgramTransitionEventType.
Figure 6 – ProgramType causes and effects
ProgramType causes (Methods)
The ProgramType outlines the Causes behind specific state transitions, which are linked to Method instances If a Program does not support a particular Program Control Method, the corresponding Causes reference will be excluded from the ProgramType Consequently, if a Method's Causes reference is missing, a Client will be unable to trigger the related state transition The Method instances included in the ProgramType detail the necessary InputArguments and OutputArguments for invoking Methods associated with that ProgramType Table 8 lists the Methods designated as Causes for ProgramTypes, while Figure 6 visually represents the connections between the components and Properties of Methods and Events related to Program transitions.
BrowseName References Target BrowseName Value Target
Start HasProperty InputArguments PropertyType Optional
Suspend HasProperty InputArguments PropertyType Optional
Resume HasProperty InputArguments PropertyType Optional
Halt HasProperty InputArguments PropertyType Optional
Reset HasProperty InputArguments PropertyType Optional
The StartMethod causes the ReadyToRunningProgram transition
The SuspendMethod causes the RunningToSuspended Program transition
The Resume Method causes the SuspendedToRunning Program transition
The Halt Method causes the RunningToHalted, SuspendedToHalted, or ReadyToHalted Program transition depending on the current state of the Program
The ResetMethod causes the HaltedToReady Program transition
The Executable Method attribute determines whether a method is currently executable For Program Control Methods, this indicates that the owning Program's current state allows for the transition initiated by the Method.
Methods can reference a specific set of InputArguments, which may be defined for each ProgramType to support the corresponding Program Control Methods These arguments provide essential data that the Program needs to execute its functions effectively It is mandatory for all calls to a Program Control Method during each Program Invocation of that ProgramType to include the specified arguments.
Methods can refer to a specific set of OutputArguments, which are defined for each ProgramType in relation to the supported Program Control Methods It is essential that all calls to a Program Control Method during each Program Invocation of that ProgramType include the specified arguments.
ProgramType effects (Events)
The ProgramType encompasses component references to the Effects associated with each state transition of the Program, which are classified as Events Each Transition includes a HasEffect Reference to a ProgramTransitionEventType and may also feature an AuditProgramTransitionEventType Upon the occurrence of a transition, Event notifications of the specified type are generated for subscribed Clients The Program Invocation can act as the EventNotifier for these Events, or notifications may be provided by an owning Object or the Server Object.
ProgramTransitionEventTypes facilitate the delivery of result data and the confirmation of state transitions for subscribed Clients during each defined Program State Transition Additionally, the AuditProgramTransitionEventType enables the auditing of changes to the Program's state in conjunction with ClientMethodCalls.
The ProgramTransitionEventType, a subtype of TransitionEventType, is utilized with Programs to obtain intermediate or final results related to state transitions Each Program can define a unique ProgramTransitionEventType for its transitions, specifying the IntermediateResult data pertinent to the designated state transition for that ProgramType Different transitions may produce varying intermediate result data, as detailed in Table 9.
Table 1 0 identifies the ProgramTransitionEventTypes that are specified for ProgramTypes
References NodeClass BrowseName DataType TypeDefinition ModellingRule Subtype of the base TransitionEventType defined in IEC 62541 -5: 201 5, B.4.1 6
HasComponent Object IntermediateResult BaseObjectType Optional
TransitionNumber identifies the Program transition that triggered the Event
FromStateNumber identifies the state before the Program transition
ToStateNumber identifies the state after the Program transition
The IntermediateResult is an object that consolidates a collection of variables essential for the program during a specific transition Its ObjectType defines the group of variables through a series of HasComponent references.
BrowseName References Target BrowseName Value Target
BrowseName References Target BrowseName Value Target
AuditProgramTransitionEventType
The AuditProgramTransitionEventType, a subtype of AuditUpdateStateEventType, is utilized with Programs to audit the state transitions of Programs triggered by Client-invoked Program Control Methods Servers are required to generate AuditProgramTransitionEvents if they comply with the Audit Server Facet Profile outlined in IEC 62541-7.
Table 1 1 specifies the definition of the AuditProgramTransitionEventType.
References NodeClass BrowseName DataType TypeDefinition ModellingRule
Subtype of the AuditUpdateStateEventType defined in IEC 62541 -5:–, B.4 1 7
HasProperty Variable TransitionNumber UInt32 PropertyType Mandatory
This EventType inherits all Properties of the AuditUpdateStateEventType defined in IEC 62541 -5:201 5, B.4.1 7, except as noted below
The Status Property, specified in IEC 62541 -5:201 5, 6.4.3,, identifies whether the state transition resulted from a Program Control Method call (set Status to TRUE) or not (set Status to FALSE)
According to IEC 62541-5:2015, section 6.4.2, the SourceName identifies the Method responsible for a Program transition initiated by a Client invoked ProgramControlMethod This SourceName is formatted with the prefix "Method/" followed by the name of the ProgramControlMethod.
The ClientUserId Property, specified in IEC 62541 -5:201 5, 6.4.3, identifies the user of the Client that issued the Program Control Method if it is associated with this Program state transition
The ActionTimeStamp Property, specified in IEC 62541 -5:201 5, 6.4.3 “AuditEventType”, identifies when the time the Program state transition that resulted in the Event being generated occurred
The TransitionNumber Property is a Variable that identifies the transition that triggered the Event.
FinalResultData
The FinalResultData ObjectType defines the VariableTypes retained upon the completion of the Program's function, incorporating a HasComponent for each VariableType that makes up the final result data.
ProgramDiagnostic DataType
This structure contains elements that chronicle the Program Invocation’s activity and can be used to aid in the diagnosis of Program problems Its composition is defined in Table 1 2
The `ProgramDiagnosticDataType` structure includes the `createSessionId`, which represents the SessionId associated with the session that initiated the Create Method for the Program Invocation Additionally, it features `createClientName`, a string that denotes the name of the client involved in the process.
Sessionthat created the Program Invocation invocationCreationTime UTCTime The InvocationCreationTime identifies the time the Program
The Invocation was created, marking the last transition time in UTC, which indicates when the most recent program state change occurred Additionally, the LastMethodCall identifies the last method invoked on the program, while the LastMethodSessionId contains the SessionId associated with that invocation.
The last method call to the Program Invocation is tracked by the LastMethodInputArguments, which retains the input values from that call Similarly, the LastMethodOutputArguments stores the output values generated by the last method execution The LastMethodCallTime records the exact time when this method was invoked, while the LastMethodReturnStatus captures the return status of the last requested Program Control Method for the Program Invocation.
Its representation in the AddressSpace is defined in Table 1 3
ProgramDiagnosticType VariableType
The VariableType consolidates basic Variables through simple DataTypes that correspond to the elements of the ProgramDiagnosticDataType structure Its DataVariables maintain the same semantics as outlined in section 5.2.8 The formal definition of the VariableType can be found in Table 14.
References NodeClass BrowseName DataType / TypeDefinition Modelling
Rule Subtype of the BaseDataVariableType defined in IEC 62541 -5
HasComponent Variable CreateSessionId NodeId Mandatory
HasComponent Variable CreateClientName String Mandatory
HasComponent Variable InvocationCreationTime UTCTime Mandatory
HasComponent Variable LastTransitionTime UTCTime Mandatory
HasComponent Variable LastMethodCall String Mandatory
HasComponent Variable LastMethodSessionI d NodeId Mandatory
HasComponent Variable LastMethodInputArguments Argument Mandatory
HasComponent Variable LastMethodOutputArguments Argument Mandatory
HasComponent Variable LastMethodCallTime UTCTime Mandatory
HasComponent Variable LastMethodReturnStatus StatusResult Mandatory
Overview
This example demonstrates how a program facilitates the management of domain downloads into a control system, as shown in Figure A.1 The process involves the segmented transfer of control operation data from a secondary storage device to the local memory of the control system.
When a domain download begins, it identifies both the source and target locations The client receives notifications each time a segment of data is successfully transferred, along with updates on the total amount downloaded Periodic reports indicate the percentage of data received during the download process In the event of a failure, the cause is communicated to the client Upon completion, performance information is stored on the server.
DomainDownload Program
General
The Client uses the “DomainDownload” Program to manage and monitor the download of a domain at the Server
Create: Create the program to perform the download
Start: Initiate the download activity
Pause: Suspend the download temporarily
Halt: Terminate the download prior to completion
DomainDownload states
The DomainDownload Program's basic state model, illustrated in Figure A.2, consists of three main states: Ready, Running, and Halted, which correspond to the standard states of a ProgramType Furthermore, the DomainDownloadType enhances the ProgramType by introducing subordinate state machines for the Running and Halted states, providing a more detailed description of the download operations and enabling the Client to monitor download activities with greater precision.
Each time a download is initiated, the Client creates an instance of the DomainDownload Program, which remains active until the Client decides to remove it The program starts in a Ready state and transitions to a Halted state upon completion It can be temporarily suspended, resumed, or aborted, but once halted, it cannot be restarted.
The sequence of state transitions in the download process is depicted in Figure A.2 Initially, the Program enters the Opening state when the download begins Following this, data is transferred in the Sending state Upon completion of the transfer, the Program moves to the Closing state to finalize the process If the transfer is interrupted or an error occurs, the Program transitions to the Aborted state; otherwise, it concludes in the Completed state A detailed overview of the states and their transitions is provided in Table A.1.
DomainDownload transitions
The DomainDownload Program features specific valid state transitions outlined in Table A.1, each defined by a unique identifier that marks the start and end states Five transitions originate from the base ProgramType, maintaining their original transition identifiers, while additional transitions connect the base Program states to the subordinate states of the DomainDownload These subordinate states are assigned distinct transition identifiers to differentiate them from the base Program transitions In instances where transitions occur between substates and the base states, two transitions are defined: one for the base state change and another for the sub-state change, such as the simultaneous transition from Ready to Running and Opening.
The table outlines the defined states, the causes for transitions, and the effects of each transition The Client utilizes ProgramControl Methods to execute the DomainDownload, which trigger the specified transitions The effects of these transitions are represented by EventTypes that inform the Client about Program activity.
No Transition name Cause From State To State Effect
2 ReadyToRunning Start Method Ready Running Report Transition 2 Event/Result
Running Halted Report Transition 3 Event/Result
5 RunningToSuspended Suspend Method Running Suspended Report Transition 5 Event/Result
6 SuspendedToRunning Resume Method Suspended Running Report Transition 6 Event/Result
7 SuspendedToHalted Halt Method Suspended Halted Report Transition 7 Event/Result
1 0 OpeningToSending Internal Opening Sending Report Transition 1 0 Event/Result
1 1 SendingToSending Internal Sending Sending Report Transition 1 1 Event/Result
1 2 SendingToClosing Internal Sending Closing Report Transition 1 2 Event/Result
Method/Error Opening Aborted Report Transition 1 3 Event/Result
1 4 ClosingToCompleted Internal Closing Completed Report Transition 1 4 Event/Result
1 5 SendingToSuspended Suspend Method Sending Suspended Report Transition 1 6 Event/Result
1 6 SuspendedToSending Resume Method Suspended Sending Report Transition 1 7 Event/Result
1 8 SuspendedToAborted Halt Method Suspended Aborted Report Transition 1 8 Event/Result
1 7 ToOpening Internal Ready Opening Report Transition 1 9 Event/Result
DomainDownload Methods
The DomainDownload Program operates using four standard methods: Start, Suspend, Resume, and Halt, with no additional methods defined The ProgramType outlines the base behaviors of these methods The Start method initiates the download by specifying the source and destination locations, while the Suspend method temporarily pauses the activity The Resume method allows the download to continue from the paused state, and the Halt method aborts the download entirely Each method triggers a transition in the program's state and sub-state, which varies based on the current state at the time of the method call If a method is invoked when the DomainDownload is in a state without a corresponding transition, it returns an error status indicating an invalid state for that method.
The Start Method requires three input arguments: Domain Name, DomainSource, and DomainDestination, while other Methods do not need any input arguments Additionally, the DomainDownload Methods do not specify any output arguments, and the error status for the Program is included in the Call Service.
DomainDownload Events
Each DomainDownload Program transition is associated with a specific ProgramTransitionEventType, which triggers an Event notification to the Client upon the occurrence of a state transition in the running Program Instance This notification clearly identifies the transition, and the SendingToSending state transition additionally includes intermediate result data.
The SendingToSending Program transition Event communicates intermediate result data to the Client, including notifications With each transition, it transmits data items that detail both the amount and percentage of data transferred to the Client.
The DomainDownload Program keeps a record of final result data after a download is completed or aborted, including the total transaction time and domain size Additionally, if a download is aborted, the reason for the termination is also documented.
DomainDownload model
The OPC UA model for the DomainDownload Program is detailed through various tables and figures, which collectively outline the program's components The figures illustrate a progression of the model's sections, enhancing the understanding of the tables and showcasing the overall structure of the program.
The DomainDownload Program's type definition accurately reflects its behavior through OPC UA components, which can be explored by a Client to understand or verify the Program's actions.
The DomainDownloadType, a subtype of ProgramType, defines the utilization of optional components, valid extensions like subordinate state machines, and the constrained attribute values for DomainDownload Programs.
Table A.2 outlines the optional and extended components of the DomainDownload Type, highlighting the inclusion of two sub State Machine Types: TransferStateMachine and FinishStateMachine It is important to note that the DomainDownloadType does not include references to the Reset Program Control Method or its related state transition, HaltedToReady, indicating that this functionality is not supported.
Includes all non-optional attributes specified for the ProgramType
HasComponent Object TransferStateMachine StateMachineType Mandatory
HasComponent Object FinishStateMachine StateMachineType Mandatory
HasComponent Variable ProgramDiagnostic ProgramDiagnosticType Mandatory
HasComponent Object ReadyToRunning TransitionType Mandatory
HasComponent Object RunningToHalted TransitionType Mandatory
HasComponent Object RunningToSuspended TransitionType Mandatory
HasComponent Object SuspendedToRunning TransitionType Mandatory
HasComponent Object SuspendedToHalted TransitionType Mandatory
HasComponent Object FinalResultData BaseObjectType Mandatory
Table A.3 outlines the Transfer State Machine type, which serves as a sub state machine within the DomainDownload Program Type This definition clarifies the StateTypes that make up the sub states associated with the Program’s Running StateType.
Table A.3 – Transfer State Machine Type
Includes all attributes specified for the FiniteStateMachineType BrowseName TransferStateMachineType
HasComponent Object Opening StateType Mandatory
HasComponent Object Sending StateType Mandatory
HasComponent Object Closing StateType Mandatory
HasComponent Object ReadyToOpening TransitionType Mandatory
HasComponent Object OpeningToSending TransitionType Mandatory
HasComponent Object SendingToClosing TransitionType Mandatory
HasComponent Object SendingToAborted TransitionType Mandatory
HasComponent Object SendingToSuspended TransitionType Mandatory
HasComponent Object SuspendedToSending TransitionType Mandatory
Table A.3 specifies the StateTypes associated with the Transfer State Machine Type All of these states are sub states of the Running state of the base ProgramType
The Opening state is the preparation state for the domain download
The Sending state is the activity state for the transfer in which the data is moved from the source to destination
The Closing state is the cleanup phase of the download
Table A.4 defines the states of the TransferStateMachineType
Table A.4 – Transfer State Machine – states
BrowseName References Target BrowseName Value Target
Table A.5 outlines the Finish State Machine Type, which serves as a sub state machine within the DomainDownload ProgramType This definition clarifies the StateTypes that make up the sub states associated with the Program’s Halted StateType.
Table A.5 – Finish State Machine Type
Includes all attributes specified for the FiniteStateMachineType BrowseName TransferStateMachineType
HasComponent Object Completed StateType Mandatory
HasComponent Object Aborted StateType Mandatory
Table A.6 specifies the StateTypes associated with the Finish State Machine Type Note these are final states and that they have no associated transitions between them
Table A.6 – Finish State Machine – states
BrowseName References Target BrowseName Value Target
The Aborted state is the terminal state that indicates an incomplete or failed domain download operation
The Completed state is the terminal state that indicates a successful domain download
Table A.7 specifies the constraining behaviour of a DomainDownload
Table A.7 – DomainDownload Type Property Attributes variable values
Variable Deletable Boolean True Mandatory
Variable AutoDelete Boolean False Mandatory
A Client can create and destroy a DomainDownload Program Invocation, which remains active until explicitly removed, even after being halted It is important to note that a DomainDownload Program Invocation cannot be reset for a restart Additionally, the Server is capable of supporting up to 500 concurrent DomainDownload Program Invocations.
Figure A.3 showcases a partial DomainDownloadType model, highlighting the relationship between the states and the DomainDownload, Transfer, and Finish State Machines It is important to note that the current state number for the sub state machines is applicable only when the active base state of DomainDownload references the sub state machine, specifically Running for the Transfer current state and Halted for the Finish current state.
Figure A.3 – DomainDownloadType partial state model
Table A.8 outlines additional ProgramTransitionTypes that complement those listed for Programs in Table 7, linking the Transfer and Finish sub-state machine states to the base Program's states.
Contains the current state of the DownloadDomain Program State Machine (SM)
Contains the current state of Transfer SM if Download- Domain is in the Running State otherwise invalid.
Contains the current state of Finish SM if Download- Domain is in the Halted State otherwise invalid
Program Control Methods and State Transitions are omitted for clarity.
Table A.8 – Additional DomainDownload transition types
BrowseName References Target BrowseName Value Target
SendingToSuspend ed HasProperty TransitionNumber 1 5 PropertyType
SuspendedToSendi ng HasProperty TransitionNumber 1 6 PropertyType
BrowseName References Target BrowseName Value Target
HasEffect ProgramTransitionEventType HasEffect AuditProgramTransitionEventTy pe
HasEffect ProgramTransitionEventType HasEffect AuditProgramTransitionEventTy pe
Figure A.4 through Figure A.1 0 illustrate portions of the DomainDownloadType model In each figure, the referenced tates, Methods, transitions, and EventTypes are identified for one or two state transitions
Figure A.4 – Ready To Running model
The ReadyToRunning Program transition, depicted in Figure A.4, is initiated by the Start Method, which requires three input arguments The Client utilizes the Method Call service to invoke the Start Method and provide these arguments Upon successful execution, the Program Invocation transitions into the Running state and the subordinate Transfer Opening state, while the Server generates two Event notifications: ReadyToRunning (2) and ToOpening (1 9).
BrowseName Start IsAbstract False References NodeClass BrowseName DataType TypeDefinition ModellingRule HasProperty Variable InputArgument Argument[] PropertyType –
Table A.9 specifies that the Start Method for the DomainDownloadType requires input arguments Table A.1 0 identifies the StartArguments required
HasEffect Partial DomainDownloadType Model Part 1
Argument 1 structure name String SourcePath dataType NodeId StringNodeId valueRank Int32 -1 (-1 = scalar) arrayDimensions UInt32[] null description LocalizedText The source specifier for the domain
Name String DesinationPath dataType NodeId StringNodeId valueRank Int32 -1 (-1 = scalar) arrayDimensions UInt32[] null description LocalizedText The destination specifier for the domain
Argument 3 structure name String DomainName dataType NodeId StringNodeId arrayDimensions UInt32[] null valueRank Int32 -1 (-1 = scalar) description LocalizedText The name of the domain
Figure A.5 depicts the model for the transitions from Opening to Sending and from Sending to Closing According to the transition table, these state transitions do not necessitate any methods; instead, they are propelled by the internal actions of the Server Events are generated for each state transition, specifically from state 1 0 to state 1 2, at the time they occur.
Figure A.5 – Opening To Sending To Closing model
A state transition can both initiate and terminate at the same state, known as Sending, which serves a specific purpose The ProgramTransitionEventType effect associated with the SendingToSending state transition includes an IntermediateResultData Object Reference This IntermediateResultData Object identifies two Variables, whose values are retrieved each time the state transition occurs and sent to the Client with the Event notification The definitions of the IntermediateResults ObjectType and its Variables are provided in Table A.1 1 and Table A.1 2, respectively.
Includes all attributes specified for the ObjectType BrowseName IntermediateResults
HasComponent Variable AmountTransferred Long VariableType Mandatory
HasComponent Variable PercentageTransferred Long VariableType Mandatory
Table A.1 2 – Intermediate result data Variables
Name String AmountTransferred dataType NodeId StringNodeId description LocalizedText Bytes of domain data transferred
Name String PercentageTransferred dataType NodeId StringNodeId description LocalizedText Percentage of domain data transferred
The transition from the Running to Suspended state, as depicted in Figure A.6, is triggered by the Suspend Method, allowing the Client to pause the download of domain data This transition generates events for TransitionEventTypes 5 and 16, resulting in the absence of a valid current state for the Transfer State Machine.
Figure A.6 – Running To Suspended model
The transition from Suspended to Running, as shown in Figure A.7, is triggered by the Resume Method, allowing the Client to resume downloading domain data to the control This transition generates events for TransitionEventTypes 6 and 7, and once in the Running state, the Sending state of the Transfer State Machine is designated as the CurrentStateNumber.
FromStatePartial DomainDownloadType Model Part 3
Figure A.7 – Suspended To Running model
The transition model from Running to Halted state during an abnormal termination of domain download is depicted in Figure A.8, triggered by the Halt Method The Client has the ability to terminate the download of domain data to the control, leading to the generation of TransitionEventTypes 3 and 15 TransitionEventType 15 signifies the shift from the Sending state as the Running State concludes, subsequently moving to the Aborted state upon entering the Halted state.
ToStatePartial DomainDownloadType Model Part 4
Figure A.8 – Running To Halted – Aborted model