Test measurement system and task processing method

Abstract

To synchronize a plurality of tasks in a test measurement system.SOLUTION: A test measurement system 10 consisting of devices 12 to 18 includes at least one test measurement device and a device controller, the device controller has at least one user interface 28, a device controller processor 20 is configured to execute instructions, at least one memory 22 stores data and stores instructions in the form of executable code, the code causes the device controller processor 20 to receive an input identifying a task from a client, create a job associated with the task, return to the client an action containing at least one job code block associated with the task, receive a call for the action, determine that the job has completed, and notify the client that the job has completed.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The disclosed technology relates to test and measurement systems comprised of multiple instruments, such as multiple oscilloscopes, and more particularly to a system and method for synchronizing the operation of multiple instruments. [Background technology]

[0002] The Standard Commands for Programmable Instruments (SCPI, often pronounced "skip-pi") protocol defines a standard for the syntax and commands used to control programmable test and measurement equipment. The two standard SCPI commands implemented in all devices that support SCPI are *OPC? (operation complete query) and *WAI (wait-to-continue command). These two standard commands, along with the *OPC command, are intended to be used by an equipment controller (such as a computer-controlled automatic test system) to synchronize the execution of its program with the actual operation of the device under test (DUT). This can be found in section 4.1.3.1 of the SCPI-99 specification. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2018-157375 A Summary of the Invention [Problem to be solved by the invention]

[0004] However, it is well known in the test and measurement industry that due to differences and inconsistencies in the implementation of SCPI among various test and measurement equipment, equipment responses to the *OPC, *WAI, and *OPC? commands do not behave predictably and reliably. For example, some equipment will respond to an operation complete query indicating that the equipment has completed the operation when in fact the operation has not been completed. Other equipment will not respond to an operation complete query in a timely manner when in fact the equipment has completed the operation. This inconsistent behavior requires many test engineers and other equipment controller program writers to insert various waits, delays, sleeps, and time outs into their test programs to compensate for the differences in equipment responses. While these delays and time outs may be necessary for a test program to control some equipment, in other cases these delays and time outs can be a major problem in manufacturing plants because they are irrelevant, inefficient, and unnecessarily slow the throughput of automated test systems.

[0005] SUMMARY OF THE DISCLOSED EMBODIMENTS OF THE DISCLOSURE Embodiments of the disclosed apparatus and methods address shortcomings in the prior art. [Means for solving the problem]

[0006] Broadly speaking, embodiments of the disclosed technology provide synchronization of settings and data within a device, between multiple devices, and between a device controller client program and one or more devices. Embodiments provide better completion notification via device programmatic interface (PI) commands, eliminating the need for delays, timeouts, or sleeps in automation code. This allows users to perform more stable and significantly faster tests. [Brief description of the drawings]

[0007] [Figure 1] FIG. 1 shows an embodiment of a system having a device controller for synchronization. [Diagram 2] FIG. 2 illustrates an embodiment of an operating environment. [Diagram 3] FIG. 3 illustrates a flow chart of an embodiment of a method for managing jobs in an operating environment. [Figure 4] FIG. 4 illustrates a flow chart of an embodiment of a method for managing job completion using milestones. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] FIG. 1 illustrates an embodiment of a system having a device controller that provides synchronization. Although the embodiment of FIG. 1 illustrates multiple devices, the embodiment may be implemented in a single device, where the single device may have one or more processors. The embodiment may be implemented in multiple devices, where each of the devices may have one or more processors. The embodiments described herein are not intended to be limiting to that implementation in any way, and no limitation should be implied. in There is none.

[0009] 1 includes multiple devices 12, 14, 16, and 18, and many more devices are possible. Each of these devices may be test equipment, such as an oscilloscope, and one of the oscilloscopes may be designated as an equipment controller. Alternatively, within the scope of the claims, one device may be a dedicated equipment controller that is not test equipment, such as a general-purpose computing device, to which other devices may connect, possibly via a network.

[0010] For purposes of illustration, one of the devices 12 is a test device that also functions as the device controller. The device 12 may have at least one processor 20 and a memory 22 that stores both code executed by the one or more processors and any data received by the device. The device 12 has one or more ports (such as 24) that form channels for receiving data from, for example, test probes, signal generators, etc. The device 12 may also have a network interface 26 that allows the device to connect to a network. The other devices 14, 16, 18 may be connected to the device controller 12, either directly, by wired connection, or wirelessly. The device 12 will typically have a user interface 28.

[0011] Many instrument systems use multiple threads to perform multiple tasks at once. The term "task" as used here means a work item that needs to be completed. A task might involve the system adding a new measurement, displaying a waveform, and responding to mouse input all at the same time. Although these are tasks that may occur simultaneously, each of the threads that process these tasks must all cooperate.

[0012] For example, when a user does a factory reset, the thread that sends the settings to the hardware wants to send the new settings as one block. To do this, the thread needs to be notified when many new settings are about to be calculated, and then it needs to be informed when the new settings are ready to be sent.

[0013] As used herein, the term "thread" means the smallest sequence of programmed instructions that can be managed independently by a scheduler. A thread is a component of a process. Multiple threads can exist within a processor. For purposes of this description, each processor executes multiple threads, and multiple threads may migrate between multiple processors within a single device, or even between multiple processors residing in two different devices. Embodiments of the present application improve the operation of a computing device, whether it is a test and measurement device or a general-purpose computing device.

[0014] Figure 2 provides an overview of the environment in which the embodiment operates. Broadly speaking, the initial starting point of the improved operation begins with a client 30, which has one or more threads 36 that generate calls to create jobs that accomplish tasks using the system. As will be explained in more detail below, a client is associated with a sponsor 32 (parameter) that identifies the client. This may consist of a globally unique identifier (GUID) or a universally unique identifier (UUID). In the following description, a GUID 34 is used.

[0015] The client thread may use completion points (such as 58), described in more detail below, to wait for the job to complete. The thread 36 makes a call, which creates a job in the job manager 38. The job manager receives status requests from clients and tracks clients using the GUID.

[0016] The Job Manager helps with coordination by keeping jobs that threads can wait on. A job is for a particular task, such as calculating new settings needed to reset to factory defaults. While a job is in progress, many different threads may be working on it. Other threads may wait for this job to complete. For example, a thread that sends settings to hardware may wait for the new settings to be calculated first.

[0017] The Programmatic Interface has the concept of Operation Complete, which is also dependent on waiting jobs. For example, a user of the Programmatic Interface may add a new measurement, wait for the operation to complete, and then query the measurement. Such a user would like to be sure that the new measurement was actually calculated with valid data. This feature of Operation Complete saves the user time and money where they would otherwise have to delay their PI test program.

[0018] A job 40 is an object associated with a task to be completed as described above. A client creates a new job by calling the job manager. The client can then use the job object and share it with other parts of the system. A job has several associated job code blocks 42, as described further below. If all of these associated blocks have not finished executing, the job is considered to be busy, as indicated by the busy property 44. A job is always busy when it is first created, and then becomes unbusy once all associated job code blocks have executed and finished. Once a job becomes unbusy, there is no way for it to become busy again.

[0019] A job may or may not be completed, as indicated by its completion characteristic 46. To be in a completed state, a job must not be in a busy state. However, there are some additional requirements, as explained further below. Once a job is in a completed state, it cannot leave the completed state. It is intended that all jobs eventually reach a completed state. The completed state may be defined by a completed state policy 48, which may have one or more milestones 50.

[0020] A job completes either successfully 54 or unsuccessfully 56. The choice depends on how the entry points associated with a particular job are called. A failure may have failure data associated with it, but a success is simply a fact with no associated data. This may relate to completion points 58, as explained below.

[0021] Using the job object, clients can determine whether a job is busy, completed, successful, or failed. Clients can also adjust the definition of a job's completion state, as described further below. Clients can register to be notified when a job completes, or they can wait until a job completes.

[0022] The job code block may be a .NET System.Action in an exemplary embodiment. In other words, the job code block must be a C# delegate that has no parameters and returns void. In conjunction with the environment of Figure 1, Figure 3 shows a flow chart of the overall process of an embodiment.

[0023] A client receives input for a task at 60. The client calls the job manager to create a job at 62, and the client specifies a job code block for the job. The resulting job starts at exactly that one job code block in the set (group) of job code blocks.

[0024] During the execution of a job code block, a client may call the job manager to create another job code block. In that case, the new job code block is added to the job to which the currently executing job code block belongs. Thus, the call has the effect of extending the job to include the additional job code block. These are the only ways to create a job code block. In particular, a client cannot add a job code block to a job from the outside.

[0025] When a client calls the Job Manager to create a job, the Job Manager also returns an action at 64. An example of this action might consist of a wrapped action, such as a .NET System.Action object that has a job code block inside it. The Job Manager does not automatically call a job code block on its own. Instead, something, such as a client or another thread, must call this action at 66, which will call the internal job code block.

[0026] The client may choose to invoke the action directly. In some embodiments, another option is to pass the wrapped action to a .NET System.Threading.Tasks.Task that invokes the action. In either case, the job remains busy at least until the action is invoked and then the job code block is executed at 68 and returns.

[0027] If you extend a job with a job code block by calling the job manager and adding another job code block, the situation is similar: the job manager returns an action, and the caller is responsible for arranging for that action to be called in some way.

[0028] This process now has some guidelines that allow for improvements in getting the job done - for example, an action must be called exactly once - calling an action twice will result in an error.

[0029] A job starts out busy and eventually becomes not busy and never has the chance to become busy again.

[0030] Client code controls when and how job code blocks are created, and can choose how job code blocks are assigned to threads of execution.

[0031] The Job Manager takes into account that threads may have jobs associated with them. The Job Manager provides an entry point that returns the job associated with the calling thread, or null if there is no associated job. If a thread is executing a job code block for a job, that job becomes the job associated with the thread at that time. If the same thread later executes a job code block for another job, the job associated with the thread changes to the second job. Thus, at different times, threads may have different jobs or no jobs at all.

[0032] At 70, the completion state of the job is determined, which can lead to different paths that can be taken towards the completion state of the task. Referring again to Figure 2, jobs may contain milestones. "Milestones" are provided by the job manager. Milestones represent the results of a job that result from collaboration with another activity outside the job. For example, in a job that adds a new measurement, the user may want the completion state to mean that a new measurement has been calculated. In this example, the job needs to collaborate with a subsystem that calculates the measurement. To divide the work between the job and the subsystem, it would seem reasonable for the job to send milestones that the subsystem can use to indicate when a new measurement has been calculated.

[0033] A milestone is always strictly part of one job. In one embodiment, milestones may be categorized as either configuration milestones or data milestones. Other types of milestones may exist in the system and new types may be created. Milestones start as incomplete milestones and complete either by success or failure.

[0034] The Job Manager provides an entry point for creating milestones. Milestones are always for the job associated with the invoking thread. That is, milestones are created for a job when a job code block is executing. In this document, this behavior is described as a job issuing a milestone. In one example, a job may not have an associated job with the invoking thread. In this case, the Job Manager creates a dummy milestone that does nothing. This arrangement is so that code does not have to test whether it is executing from a job code block.

[0035] A job can only emit milestones from within its job code block, so only busy jobs can emit milestones. Once the job is no longer busy, the set of multiple milestones cannot be changed. This property makes it easier to reason about the completion state of a job.

[0036] On the other hand, any code can mark a milestone complete by either succeeding or failing it. Once completed, a milestone ignores further attempts to mark it complete and cannot be marked incomplete again.

[0037] A job failure occurs in one of two ways. First, a client calls a job manager entry point to declare that the job associated with the calling thread has failed. Such a client can optionally send failure state data associated with the failure. This can happen if there is no job associated with the calling thread. In this case, the call is a no-op. This arrangement is made so that code does not have to test if it is running from a job code block. Second, a client calls a milestone method to declare that the milestone has failed, which causes the associated job to fail.

[0038] As mentioned above, a job may have a completion state policy, which is the rule the job uses to determine when it is complete. This policy is a property of the job. Different jobs can have different policies. A client must specify the completion state policy when calling the job manager to create a job. Once a job is created, any client with access to the job object can change the job's completion state policy.

[0039] All completion state policies share the following rules: First, a job that fails immediately goes to the completion state, regardless of whether the job is busy or not busy. Second, a job can only succeed once it is no longer busy.

[0040] In one embodiment, a client can specify one of three completion state policies. First, the Settings policy means that the job succeeds when the job is no longer busy and all of its settings milestones have succeeded. Second, the DataIfRunningAndSettings policy means that the job succeeds when the job is no longer busy and all of its settings milestones have succeeded, and either no data acquisitions are running or all data milestones have succeeded. Third, DataAndSettings means that the job succeeds when the job is no longer busy and all of its settings and data milestones have succeeded. These are merely examples of completion state policies and are not intended to limit or suggest any particular completion state policy.

[0041] A client can change the completion state policy of a job, so that the job may enter a completed state even if other conditions have not changed. For example, in the measurement addition described above, the job adding the measurement may select the DataIfRunningAndSettings policy. However, if it finds that the code only pertains to reference waveforms, it may decide to change the policy to DataAndSettings in order to request measurement results even when no data acquisition is running. Figure 4 shows a flow chart of an embodiment of a process for managing the completion state of a job using milestones.

[0042] The job manager receives a call from a client at 80 specifying a completion state policy and providing a GUID as part of the sponsor parameters. As described above, the job manager provides an entry point for the milestone at 82. The job manager then monitors the milestone at 84. The job manager is notified that the milestone has been completed. As described above, the client can change the completion state policy at 86 so that the job manager tracks the milestones to ensure that both data milestones and configuration milestones are completed. If the client changes the completion state policy at 86 and, for example, the configuration milestone is completed, the job manager marks the job as successful at 88 and then completes at 90. The job is marked as completed even if it fails.

[0043] If the client does not change the completion state policy and all milestones are completed, the job manager still determines success at 86 and completes the job at 88.

[0044] Once a job has completed for any reason, it cannot become incomplete again. Also, a failed job cannot succeed later, and a successful job cannot fail later. Jobs can also be partially completed. For example, say a job emits both configuration milestones and data milestones. In some cases, you only want to wait for the configuration milestones, but also have a final completion state that means both types of milestones have completed. Partial completion handles the first case, where you only want to wait for the configuration milestones.

[0045] With partial completion, the client specifies which types of milestones to include. A job is considered partially complete when it is no longer busy and all milestones of a specified type have been completed. Failed jobs are also considered partially complete.

[0046] Another way to manage completion states is through the use of "completion points", an abstract data type provided by the Job Manager. A completion point represents the ability to wait for a job (or, sometimes, several jobs) to complete or be partially completed. Completion points also allow testing the completion state without waiting.

[0047] Completion points can be job or client specific. For example, a client can get a completion point from a job object. In that case, the completion point waits for only this one job. In another embodiment, a client can request a completion point from the job manager, and the completion point waits for all jobs created by the client up to the moment of the request. In that case, the completion point waits for the completion or partial completion of all of the client's jobs together using only one action.

[0048] Because the completion point may depend on the client, the Job Manager needs to keep track of that client. To do so, when the client creates a job, the client must identify itself using the sponsor parameter described above. This sponsor parameter in these embodiments consists of a globally unique identifier (GUID) selected by the client. When the client subsequently calls the Job Manager to get the completion points of all jobs so far, the client identifies itself again, passing the sponsor parameter. The Job Manager keeps track of the sponsor of each job so that it can service client requests.

[0049] If a client waits for all previous jobs to be completed, then the notion of completion for each job depends on the completion state policy for that particular job. Thus, in this case, completion state may mean different things for each job in a set (group). On the other hand, if a client waits for partial completion of all previous jobs, then partial completion means the same thing for each job in a set.

[0050] Thus, the performance of the system can be improved by adding a job manager that manages client requests and coordinates the actions within the system, eliminating or reducing the need to build in delays and pauses in processing, as well as the associated guesswork. In the above example where a user wants to add a new measurement, instead of the user building in a delay for that new measurement, the user will not actually know if the measurement is indeed completed. In the present system, the job manager will complete the job for the new measurement and then notify the system that the job is complete, ensuring that the measurement was calculated on valid data.

[0051] An embodiment of the disclosed technology can operate on a specially created hardware, firmware, digital signal processor, or specially programmed general-purpose computer including a processor that operates according to programmed instructions. The term "controller" or "processor" in this application contemplates microprocessors, microcomputers, ASICs, special purpose hardware controllers, and the like. Aspects of the disclosed technology can be implemented in computer-available data and computer-executable instructions, such as one or more program modules, executed by one or more computers (including a monitoring module) or other devices. Generally, program modules include routines, programs, objects, components, data structures, and the like, which, when executed by a processor in a computer or other device, perform particular tasks or implement particular abstract data formats. The computer-executable instructions may be stored in a computer-readable storage medium, such as a hard disk, optical disk, removable storage medium, solid-state memory, RAM, and the like. As will be appreciated by those skilled in the art, the functionality of the program modules may be combined or distributed as desired in various embodiments. Furthermore, such functionality may be embodied in whole or in part in firmware or hardware equivalents, such as integrated circuits, field programmable gate arrays (FPGAs), etc. Certain data structures may be used to more effectively implement one or more aspects of the disclosed techniques, and such data structures are considered to be within the scope of the computer-executable instructions and computer-usable data described herein.

[0052] Aspects of the present disclosure work in various modifications and alternative forms. Particular aspects are shown by way of example in the drawings and are described in detail below. However, the embodiments disclosed herein are presented for clarity of explanation and are not intended to limit the scope of the disclosed general concepts to the specific examples described herein, unless expressly so limited. Thus, the present disclosure is intended to cover all modifications, equivalents and alternatives of the described embodiments in light of the accompanying drawings and claims.

[0053] References in the specification to an embodiment, aspect, example, or the like indicate that the described item may include a particular feature, structure, or characteristic. However, each disclosed aspect may or may not include such a particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same aspect, unless specifically stated otherwise. Furthermore, when a particular feature, structure, or characteristic is described in connection with a particular aspect, such feature, structure, or characteristic may also be used in connection with other disclosed aspects, regardless of whether such feature is explicitly described in connection with such other disclosed aspects.

[0054] The disclosed aspects may, in some cases, be implemented in hardware, firmware, software, or any combination thereof. The disclosed aspects may also be implemented as instructions carried by or stored on one or more computer-readable media that may be read and executed by one or more processors. Such instructions may be referred to as computer program products. A computer-readable medium as described herein means any medium that can be accessed by a computing device. By way of example, and not limitation, computer-readable media may include computer storage media and communication media.

[0055] Computer storage media means any medium that can be used to store computer-readable information. By way of example and not limitation, computer storage media may include random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital video disc (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, and any other volatile or non-volatile removable or non-removable media implemented in any technology. Computer storage media excludes signals themselves and transitory forms of signal transmission.

[0056] A communication medium refers to any medium capable of communicating computer readable information. By way of example, and not limitation, communication media may include coaxial cables, fiber optic cables, air, or any other medium suitable for communicating electrical, optical, radio frequency (RF), infrared, acoustic, or other types of signals. [Example]

[0057] In the following, examples useful for understanding the technology disclosed in the present application are presented. The embodiment of the technology may include one or more of the examples described below and any combination thereof.

[0058] Example 1 is a method for synchronizing a plurality of tasks in a test and measurement system, the method comprising: receiving a task input at a client in the system; receiving a call from the client to create a job associated with the task in a job manager running on a processor of a first device in the system; returning an action including at least one job code block associated with the job to the client; receiving a call for the action; executing at least one of the job code blocks by at least one processor in the system; determining that the job is complete; and completing the task.

[0059] Example 2 is the method of example 1, wherein the processor of the first device is in a controller device, and at least one of the processors in the system is in a test and measurement device in the system.

[0060] Example 3 is a method of either example 1 or 2, where the call from the client includes a completion state policy, and the process of verifying that the job is complete includes a process of determining whether the completion state policy has been satisfied.

[0061] Example 4 is the method of example 3, wherein the completion state policy is satisfied by either a job failure or a job success.

[0062] Example 5 is the method of example 4, wherein the job success occurs when the job is no longer busy and either: all configuration milestones are successful; either all configuration milestones are successful and no data ingestion has occurred or all data milestones are successful; all configuration milestones and data milestones are successful.

[0063] Example 6 is the method of any of Examples 1 to 4, wherein the process of executing at least one job code block includes a process of creating at least one additional job code block.

[0064] Example 7 is the method of any of Examples 1 to 5, further comprising sending an action from the client to either a different thread in the same processor or a thread in a different processor in the system.

[0065] Example 8 is a method of any of Examples 1 to 6, wherein the process of executing at least one job code block includes a process of issuing a milestone having a unique identifier, the milestone being completed outside of a job associated with the at least one job code block.

[0066] Example 9 is the method of example 8, further comprising receiving a notification that the milestone has been completed.

[0067] Example 10 is the method of example 8, wherein the unique identifier is provided to a job manager, and the job manager tracks the milestones across multiple devices via the unique identifier.

[0068] Example 11 is a system comprising a plurality of devices including at least one test and measurement device and an equipment controller, the equipment controller comprising at least one user input, an equipment controller processor configured to execute instructions, and at least one memory for storing data and instructions in the form of executable code, the code causing the equipment controller processor to receive input from a client identifying a task, create a job associated with the task, return an action to the client including at least one job code block associated with the task, receive a call relating to the action, determine that the job is completed, and notify the client that the job is completed.

[0069] Example 12 is the system of example 11, wherein the device controller processor is comprised of either one or more processors in a device controller separate from the test and measurement device, or one or more processors in the test and measurement device.

[0070] Example 13 is the system of any of examples 11 or 12, further comprising at least one processor within the system other than the device controller processor that executes at least one of the job code blocks.

[0071] Example 14 is the system of example 13, wherein the at least one processor includes a plurality of processors, and the at least one job code block is executed, in part, by two or more of the plurality of processors.

[0072] Example 15 is the system of example 13, wherein either at least one processor accommodates multiple threads or at least one processor includes multiple processors having at least one thread, and at least one processor executing at least one job code block includes multiple threads executing at least one job code block.

[0073] Example 16 is a non-transitory storage medium including a computer program product, the computer program product including instructions that, when executed by at least one processor in a test system, cause the at least one processor to receive a task based on user input from a client, perform one or more operations to convert the task into a job, return an action to the client including at least one job code block associated with the job, receive a call related to the action, execute the at least one job code block by the at least one processor in the test system, determine that the job is complete, and complete the task.

[0074] Example 17 is a storage medium of Example 16, wherein the task has an associated completion state policy, and the process of verifying that the job is completed includes a process of determining whether the completion state policy is satisfied.

[0075] Example 18 is the storage medium of any of Example 17, wherein the completion state policy is satisfied by either a failure of the job or a success of the job.

[0076] Example 19 is a storage medium of Example 18, wherein the job is successful when the busy state is no longer present and any of the following occurs: all setting milestones are successful; either all setting milestones are successful and no data capture has occurred or all data milestones are successful; all setting milestones and data milestones are successful.

[0077] Example 20 is a storage medium of any of Examples 16 to 19, wherein execution of at least one job code block includes issuing a milestone having a unique identifier, and the milestone is completed outside of a job associated with the job code block.

[0078] Although for convenience of illustration, specific embodiments of the invention have been illustrated and described, it will be understood that various modifications can be made without departing from the spirit and scope of the invention. Accordingly, the invention should not be limited, except as by the appended claims. [Explanation of symbols]

[0079] 10. System 12 Equipment 14 Equipment 16 Equipment 18 Equipment 20 processors 22 Memory 24 Ports 26 Network Interface 28 User Interface 30 clients 32 Sponsor 34 Globally Unique Identifier (GUID) 36 client threads 38 Job Manager 40 Jobs 42 Job Code Block 44 Busy Characteristics 46 Completion characteristics 48 Completion Status Policy 50 Milestone 54 success 56 failure 58 Completion Points

Claims

1. 1. A method for processing a task in a test and measurement system, comprising: receiving input of a task at a client in the test and measurement system; receiving a call from the client to create a job associated with the task in a job manager executing on a processor of a first device in the test and measurement system; returning an action to the client, the action including at least one job code block associated with the job; A process for receiving a call for the action; executing at least one of the job code blocks by at least one processor in the test and measurement system; A process to confirm that the job has been completed. The process of completing the above tasks and A task processing method comprising:

2. 2. The task processing method of claim 1, wherein the call from the client includes a completion state policy, and the process of verifying that the job is completed includes a process of determining whether the completion state policy has been satisfied.

3. 3. The method of claim 2, wherein the completion state policy is satisfied by either a failure of the job or a success of the job.

4. The success of the above job is As the above job becomes no longer busy, All configured milestones were successful, Either all configuration milestones have been successful and no data has been captured or all data milestones have been successful; Were all configuration and data milestones successful? 4. The task processing method according to claim 3, wherein said task processing method is any one of the above.

5. 2. The task processing method of claim 1, wherein the process of executing at least one of the job code blocks includes a process of issuing a milestone having a unique identifier, the milestone being completed outside of a job associated with the at least one of the job code blocks.

6. 1. A test and measurement system comprising a plurality of devices including at least one test and measurement device and an device controller, the device controller comprising: At least one user input; a device controller processor configured to execute instructions; at least one memory for storing data and instructions in the form of executable code; Equipped with The code causes the device controller processor to: receiving input from a client identifying a task; Create a job associated with the task, returning to the client an action including at least one job code block associated with the task; Receive a call regarding the above action, Verify that the above job is complete. Notify the client that the job is complete Test and measurement systems.

7. 7. The test and measurement system of claim 6, wherein the instrument controller processor comprises either one or more processors in the instrument controller separate from the test and measurement instrument, or one or more processors in the test and measurement instrument.

8. A computer program comprising instructions which, when executed by at least one of the processors in the test and measurement system, cause the at least one of the processors to perform any of the methods of claims 1 to 5.

Images