Errata exists for this version of the document.

Integrated automation facilities manage their operations through the exchange of data and the coordinated invocation of system Functions as illustrated in Figure 1. Services are required to perform the data exchanges and to invoke the Functions that constitute system operation. These Functions may be invoked through Human Machine Interfaces, cell controllers, or other supervisory control and data acquisition type systems. UA defines Methods and Programs as an interoperable way to advertise, discover, and request these Functions. They provide a normalizing mechanism for the semantic description, invocation, and result reporting of these Functions. Together Methods and Programs complement the other UA Services and ObjectTypes to facilitate the operation of an automation environment using a client-server hierarchy.

Figure 1 – Automation facility control

Methods and Programs model Functions typically have different scopes, behaviours, lifetimes, and complexities in Servers and the underlying systems. These Functions are not normally characterized by the reading or writing of data which is accomplished with the UA Attribute service set.

Methods represent basic Functions in the Server that can be invoked by a Client. Programs, by contrast, model more complex and stateful functionality in the system. For example, a method call may be used to perform a calculation or reset a counter. A Program is used to run and control a batch process, execute a machine tool part program, or manage a domain download. Methods and their invocation mechanism are described in OPC 10000-3 and OPC 10000-4.

This standard describes the extensions to, or specific use of, the core capabilities defined in OPC 10000-5 as required for Programs.

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.

Figure 2 – Program illustration

Programs are stateful and transition through a prescribed sequence of states as they execute. Their behaviour is defined by a Program Finite State Machine (PFSM). The elements of the PFSM describe the phases of a Program’s execution in terms of valid transitions between a set of states, the stimuli or causes of those transitions, and the resultant effects of the transitions.

Since Programs can be used to perform advanced control algorithms or other actions, their use should be restricted to personnel with appropriate access rights. It is recommended that AuditUpdateMethodEvents are generated to allow monitoring the number of running Programs in addition to their execution frequency.

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 Machine

No.	Transition name	Cause	From state	To state	Effect
1	HaltedToReady	Reset Method	Halted	Ready	Report Transition 1 Event/Result
2	ReadyToRunning	Start Method	Ready	Running	Report Transition 2 Event/Result
3	RunningToHalted	Halt Method or Internal (Error)	Running	Halted	Report Transition 3 Event/Result
4	RunningToReady	Internal	Running	Ready	Report Transition 4 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
8	SuspendedToReady	Internal	Suspended	Ready	Report Transition 8 Event/Result
9	ReadyToHalted	Halt Method	Ready	Halted	Report Transition 9 Event/Result

Figure 3 – Program states and transitions

A standard set of base states is defined for Programs as part of the Program Finite State Machine. These states represent the stages in which a Program can exist at an instance in time as viewed by a Client. This state is the Program’s current state. All Programs shall support this base set. A Program may or may not require a Client action to cause the state to change. The states are formally defined in Table 2.

Table 2 – Program states

State	Description
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 defined to describe a Program can be expanded. Program sub states can be defined for the base states to provide more resolution of a process and to describe the cause and effect(s) of additional stimuli and transitions. Standards bodies and industry groups may extend the base Program Finite State Model to conform to various industry models. For example, the Halted state can include the sub states “Aborted” and “Completed” to indicate if 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.

A standard set of state transitions is defined for the Machine. These transitions define the valid changes to the Program’s current state in terms of an initial state and a resultant state. The transitions are formally defined in Table 3.

Table 3 – Program state transitions

Transition no.	Transition name	Initial state	Resultant state
1	HaltedToReady	Halted	Ready
2	ReadyToRunning	Ready	Running
3	RunningToHalted	Running	Halted
4	RunningToReady	Running	Ready
5	RunningToSuspended	Running	Suspended
6	SuspendedToRunning	Suspended	Running
7	SuspendedToHalted	Suspended	Halted
8	SuspendedToReady	Suspended	Ready
9	ReadyToHalted	Ready	Halted

The stimuli or causes for a Program’s state transitions can be internal to the Server or external. The completion of machining steps, the detection of an alarm condition, or the transmission of a data packet are examples of internal stimuli. Methods are an example of external stimuli. Standard Methods are defined which act as stimuli for the control of a Program.

Clients manage a Program by calling Methods. The Methods impact a Program’s behaviour by causing specified state transitions. The state transitions dictate the actions performed by the Program. This standard defines a set of standard Program Control Methods. These Methods provide sufficient means for a Client to run 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 can optionally support any subset of the Program Control Methods. For example, some Programs may not be permitted to suspend and so would not provide 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.

Table 4 – Program Control Methods

Method Name	Description
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 Halted state.
Reset	Causes the Program to transition from the Halted state to the Ready state.

All Program Control Methods are defined with their BrowseName on the ProgramStateMachineType with the OptionalPlaceholder ModellingRule. As defined in OPC 10000-3, this rule allows the inclusion of Arguments to these Methods on sub-types or on instances. For example, a Start Method may include an options argument that specifies dynamic options used to determine some program behaviour. The Method Call service specified in OPC 10000-4 defines a return status. This return status indicates the success of the Program Control Method or a reason for its failure.

A Program’s state transition generally has a cause and also yields an effect. The effect is a by product of a Program state transition that can be used by a Client to monitor the progress of the Program. Effects can be internal or external. An external effect of a state transition is the generation of an Event notification. Each Program state transition is associated with a unique Event. These Events reflect the progression and trajectory of the Program through its set of defined states. The internal effects of a state transition can be the performance of some programmatic action such as the generation of data.

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 transient and is generated by the Program in conjunction with non- terminal state transitions. The data items that compose the intermediate results are defined in association with specific Program state transitions. Their values are relevant only at the transition level.

Each Program state transition can be associated with different result data items. Alternately, a set of transitions can share a result data item. Percentage complete is an example of intermediate result data. The value of percentage complete is produced when the state transition occurs and is available to the Client.

Clients acquire intermediate result data by subscribing to Program state transition Events. The Events specify the data items for each transition. When the transition occurs, the generated Event conveys the result data values captured to the subscribed Clients. If no Client is monitoring the Program, intermediate result data may be discarded.

Terminal result data is the final data generated by the Program as it ceases execution. Total execution time, number of widgets produced, and fault condition encountered are examples of terminal result data. When the Program enters the terminal state, this result data can be conveyed to the Client by the transition Event. Terminal result data is also available within the Program to be read by a Client after the program stops. This data persists until the Program Instance is rerun or deleted.

Clients can monitor the activities associated with a Program’s execution. These activities include the invocation of the management Methods, the generation of result data, and the progression of the Program through its states. Audit Events are provided for Method Calls and state transitions. These Events allow a record to be maintained of the Clients that interacted with any Program and the Program state transitions that resulted from that interaction.

Programs can have different lifetimes. Some Programs may always be present on a Server while others are created and removed. Creation and removal can be controlled by a Client or may be restricted to local means.

A Program can be Client creatable. If a Program is Client creatable, then the Client can add the Program to the Server. The Object Create Method defined in OPC 10000-3, is used to create the Program instance. The initial state of the Program can be Halted or Ready. Some Programs, for example, may require that a resource becomes available after its creation and before it is ready to run. In this case, it would be initialized in the Halted state and transition to Ready when the resource is delivered.

A Program can be Client removable. If the Program is Client removable, then the Client can delete the Program instance from the Server. The DeleteNodes Service defined in OPC 10000-4 is used to remove the Program Instance. The Program shall be in a Halted state to be removed. A Program may also be auto removable. An auto removable Program deletes itself when execution has terminated.

Programs can be multiple instanced or single instanced. A Server can support multiple instances of a Program if these Program Instances can be run in parallel. For example, the Program may define a Start Method that has an input argument to specify which resource is acted upon by its Functions. Each instance of the Program is then started designating use of different resources. The Client can discover all instances of a Program that are running on a Server. Each instance of a Program is uniquely identified on the Server and is managed independently by the Client.

Programs can be run once or run multiple times (recycled). A Program that is run once will remain in the Halted state indefinitely once it has run. The normal course of action would be to delete it following the inspection of its terminal results.

Recyclable Programs may have a limited or unlimited cycle count. These Programs may require a reset step to transition from the Halted state to the Ready state. This allows for replenishing resources or reinitializing parameters prior to restarting the Program. The Program Control Method “Reset” triggers this state transition and any associated actions or effects.