Patent Description:
According to a first aspect, there is provided a test instrument, comprising: an electrical interface to couple the test instrument to an optical transponder; a memory to store a script, the script encoding a test of the optical transponder, the test comprising a plurality of interactions with the optical transponder to be traced and analyzed; and a controller to: interpret the script to identify a control for the optical transponder based on a statement included in the script; cause, via the electrical interface, an interaction with the optical transponder to occur based on the control; generate a first timestamped log entry to indicate a timing of the control; detect a data path event associated with the optical transponder; generate a second timestamped log entry to indicate a timing of the data path event; determine that the data path event was caused by the control based on the first timestamped log entry and the second timestamped log entry; and assess operation of the optical transponder based on the determination that the data path event was caused by the control.

To interpret the script, the controller may be further to: identify a script type for the script, wherein a plurality of language features for a script interpreter that interprets the script may be based on the script type, wherein each of the plurality of language features may dictate a characteristic related to the optical transponder.

The characteristic may comprise at least one of: a format of register references, a set of pins that are permitted to be manipulated, a host interface lane range, and traced transaction data.

To identify the script type, the controller may be further to: access an input that specifies the script type.

To identify the script type, the controller may be further to: automatically identify the script type based on the optical transponder.

To identify the script type, the controller may be further to: automatically identify the script type based on a type of port used for coupling to the optical transponder.

The statement may encode a control of a transponder management interface operation of the optical transponder.

The transponder management interface operation may comprise a read or write of a register of the optical transponder.

The statement may encode a manipulation of a host interface signal of the optical transponder.

The manipulation of the host interface signal may comprise muting or unmuting of the host interface.

The statement may encode a manipulation of a power supply of the optical transponder.

The statement may encode a manipulation of a hardware pin of the optical transponder.

The manipulation may comprise a get or set function of the hardware pin.

According to a second aspect, there is provided, an optical network tester (ONT) device, comprising: a memory to store a script interpreter and a script; an electrical interface to couple the ONT device to an optical transponder; and a controller coupled to the electrical interface, the controller to execute the script interpreter to: access the script from the memory; interpret the script with the script interpreter; identify a control for interacting with the optical transponder based on the interpreted script; and cause an interaction with the optical transponder based on the control.

The script interpreter may be further to identify a script type for the script, and may constrain one or more controls of the optical transponder based on the script type.

The controller may be further to: detect a data path event associated with the optical transponder; and determine that the data path event was caused by the control.

To detect the data path event, the controller may be further to use a native data path tracer to trace data path events associated with the optical transponder.

To detect the data path event, the controller may be further to use the script interpreter to trace data path events associated with the optical transponder.

According to a third aspect, there is provided a method comprising: executing, by an apparatus, a script based on an embedded script interpreter of the apparatus; and causing, by the apparatus, an optical transponder coupled to the apparatus to be controlled based on the script; receiving, by the apparatus, an indication that a reset of the optical transponder has been initiated; and causing, by the apparatus, execution of the script to be stopped based on the indication that the optical transponder is being reset.

Causing the execution of the script to be stopped may comprises suspending or aborting the script, the method may further comprise: receiving an indication that the reset is complete; and resuming or restarting the script in response to the indication that the reset is complete.

Features of the present disclosure may be illustrated by way of example and not limited in the following figure(s), in which like numerals indicate like elements, in which:.

For simplicity and illustrative purposes, the present disclosure may be described by referring mainly to examples.

Throughout the present disclosure, the terms "a" and "an" may be intended to denote at least one of a particular element.

Optical transponders, such as those for <NUM> Gigabit per second (Gbit/s) transmission rates and above, have a complex built-in management functionality. This complexity is primarily caused by functionality like breakout with multiple independent data paths, Optical Transport Network (OTN) and Ethernet multi-client mapping and multiplexing as well as coherent optics for medium and long reach. Furthermore, these optical transponders (also referred to herein throughout as "transponders" for convenience) may include complex Digital Signal Processing (DSP) chips that may be controlled and managed by the transponder firmware.

This functional complexity has forced the industry to develop new management standards such as Common Management Interface Standard (CMIS), coherent CMIS (C-CMIS) as well as to extend existing standards like the C form-factor pluggable (CFP) Multi-Source Agreement (MSA) standard. These new management standards may, in turn, use complex data models and define the transponder functional behavior in terms of complex state machines. In some cases, the behavioral definition encompasses multiple interacting state machines. The rules governing these interactions are comprehensive and often difficult to understand. In addition to the logical behavior, timing may play an important role. As a result of these and other issues, the industry has run into problems implementing these management standards. Incomplete and flawed standards, difficulties in standards interpretation, implementation bugs and subtle timing difficulties have caused interoperability and stability issues. Comprehensive test and verification are challenging because test instruments do not offer the required functionality. In addition to functional testing, there may be a need for management stress testing since CPUs embedded in the transponders may be overwhelmed by the various tasks which need to be executed in time and sometimes in parallel.

The issues are likely to worsen as transponder complexity rises. This will lead to even more complex management functionality and a possible move from the current register-based management interface model to a message-based interface model. Thus, what may be needed is an improved apparatus such as a test instrument with the capability to perform comprehensive, repeatable and detailed functional and stress tests of transponder management functionality.

The disclosure relates to an improved apparatus and methods that may embed a script interpreter to interpret and run scripts that may control underlying optical transponder functionality through direct transponder hardware and transponder pin accesses in a way that abstracts the complexities of transponder management through a scripting language. The script interpreter and the scripting language may facilitate detecting run time errors when executing transponder hardware accesses, control the transponder via the management interface, control the transponder hardware pins, control the transponder environment, manipulate transponder host interface signals, and manipulate the transponder power supply. The transponder environment may also encompass the media interface signals.

The apparatus may further monitor and trace interactions between the apparatus and the transponder. Such interactions may take place via the management interface, the host interface, the transponder hardware pins, and/or the transponder power supply (such as when a transponder power-on cycle is tested by a script). The apparatus may further monitor and trace the transponder data path to assess the impact of transponder control by the script on the data path.

The foregoing may be implemented in a test instrument such as an Optical Network Tester (ONT) device through a script interpreter embedded in the instrument. The interpreter may have access to functional blocks embedded in the test instrument, such as a transponder management interface, a host interface, a transponder power supply control, an interface to control transponder hardware pins, an interface to obtain the status of transponder hardware pins, and/or other functions.

In an example operation, a user may define tests by writing suitable scripts in a script (or scripting) language. The script language may be a standard language with extensions (such as the Tcl programming language) or a custom language.

The behavior of the transponder may be tested by running test scripts and by analyzing the resulting traced data. This mechanism can be used for functional testing as well as for stress testing. The foregoing may facilitate precise timing of the controls and precision time correlation of control events with data path events.

<FIG> shows a block diagram of an example system <NUM> for transponder management testing and interaction tracking. System <NUM> may include an apparatus <NUM>, which may be coupled to an optical transponder <NUM> via an electrical interface <NUM>. In some examples, the apparatus <NUM> may interact with the optical transponder <NUM> through controls. For example, the apparatus <NUM> may generate and transmit one or more controls to exert operation over the transponder controls and/or the transponder environment. Various types (form factors) of optical transponders <NUM> may be used. For example, the types of optical transponders <NUM> may include, Quad Small Form-factor Pluggable (QSFP), QSFP+, QSFP28, QSFP double density (QSFP-DD), QSFP56, QSFP-DD. ZR, C form-factor pluggable <NUM> (CFP2), CFP2-DCO, small form-factor pluggable (SFP), SFP+, SFP28, SFP56, and/or others.

Different types of optical transponders may implement different transponder controls and transponder environments. As such, operational control over the optical transponder <NUM> may depend on the type of the optical transponder <NUM>. The transponder controls may include the management interface <NUM> and hardware pins <NUM> of the optical transponder <NUM>. The management interface <NUM> may implement various management standards such as, for example, SFF-<NUM>, CMIS, C-CMIS, CFP MSA, SFF-<NUM>, and/or others. The transponder environment may include the host interface <NUM> and power module <NUM> of the optical transponder <NUM>.

To facilitate the foregoing, the apparatus <NUM> may include a controller <NUM>, a memory <NUM>, and an electrical interface <NUM>. As shown in <FIG>, the apparatus <NUM> may include a controller <NUM> that may control the apparatus <NUM>. The controller <NUM> may be a semiconductor-based microprocessor, a central processing unit (CPU), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and/or other suitable hardware device. Although the apparatus <NUM> has been depicted as including a single controller <NUM>, it should be understood that the apparatus <NUM> may include multiple controllers, multiple cores, or the like, without departing from the scopes of the apparatus <NUM> disclosed herein.

The apparatus <NUM> may include a memory <NUM> that may have stored thereon machine-readable instructions (which may also be termed computer readable instructions) that the controller <NUM> may execute. The memory <NUM> may be an electronic, magnetic, optical, or other physical storage device that includes or stores executable instructions. The memory <NUM> may be, for example, Random Access memory (RAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage device, an optical disc, and the like. The memory <NUM> may be a non-transitory machine-readable storage medium, where the term "non-transitory" does not encompass transitory propagating signals.

In some examples, the memory <NUM> may store a plurality of scripts <NUM> (illustrated in <FIG> as scripts 111A-N). In some examples, some or all of the scripts <NUM> may be interpreted by a script interpreter <NUM> into machine instructions that are executable by the controller <NUM> at runtime. In other examples, some or all of the scripts <NUM> may be compiled into binary or machine code (such as prior to runtime) that is executable by the controller <NUM>. In some examples, the script interpreter <NUM> may itself include instructions stored at the memory <NUM> and executed by the controller <NUM>. In other examples, the script interpreter <NUM> may include a hardware processor (separate from the controller <NUM>) that interprets the scripts <NUM>.

In some examples, the script interpreter <NUM> may generate, based on the interpreted scripts <NUM>, controls to cause interactions with the optical transponder <NUM>. Such controls may be stored as first timestamped log entries in the control events <NUM> datastore. In some examples, the script interpreter <NUM> and/or a native application <NUM> on the apparatus <NUM> may monitor data path events and generate second timestamped log entries for the data path events. The native application <NUM> may include instructions that program the controller <NUM> to perform apparatus-specific operations. For example, for implementations in which the apparatus <NUM> is an Optical Network Tester (ONT) device, the native application <NUM> may provide ONT-specific functions.

The second timestamped log entries may be stored in the trace events <NUM> datastore. In this manner, controls initiated based on scripts <NUM> may be timestamped and correlated with timestamped data path events to determine whether or not the controls caused the data path events. Thus, in these examples, the scripts <NUM> may encode testing operations for testing the optical transponder and assess results of the testing through generation of controls that cause interactions with the optical transponder <NUM> and monitored data path events that may result from the controls.

Examples of operations and traceability of the operations supported by a script language for a script <NUM> is described in Table <NUM>. Other numbers and types of operations may be used in the script language as well. As such, Table <NUM> is provided for illustrative, and not necessarily limiting, purposes.

<FIG> shows an example data flow diagram <NUM> of a script interpreter <NUM> that interprets statements 202A-N of a script <NUM> and generates controls <NUM>, <NUM>, <NUM>, <NUM>, and/or <NUM> for transponder management testing and interaction tracking. In some examples, each statement <NUM> may encode an operation (such as an operation listed in Table <NUM> and/or other operation) to be performed with respect to the optical transponder <NUM>. Examples of statements are listed in Table <NUM>. Other numbers and types of operations and statements may be used in the script <NUM>. As such, Table <NUM> is provided for illustrative, and not necessarily limiting, purposes.

Regardless of the particular statements <NUM> and operations encoded by the statements <NUM>, each script <NUM> may be structured in a uniform way to facilitate compliance by script developers. In an example script structure, a single statement <NUM> per line may be permitted, and each statement <NUM> may be numbered according to a corresponding line number. Thus, in this example, an end of line may terminate a statement <NUM>. In some examples, the maximum size of register references may be <NUM> bits and the internal data format may be a <NUM>-bit signed integer (<NUM>-bit unsigned bits for C-CMIS management interfaces). In some examples, data read from/written to bitfields may be converted to/from the internal data format. Signed bitfields may be assumed to be in two's complement format. It should be noted that other script structures may be used as well. Thus, the foregoing example structure is provided for illustration and not necessarily for limitation.

Regardless of the particular script structure, a control portion <NUM> of the script interpreter <NUM> may interpret the script <NUM>, and generate a control <NUM>, <NUM>, <NUM>, <NUM>, and/or <NUM> that corresponds to the operation encoded by a statement <NUM> in the script <NUM>. For example, the control portion <NUM> may interface with the optical transponder <NUM> via transponder management interface <NUM>, host interface <NUM>, transponder power supply control <NUM>, transponder hardware pin control <NUM>, transponder pin interface <NUM>, and/or other control portions to generate the control <NUM>, <NUM>, <NUM>, <NUM>, and/or <NUM>. A control may be an electronically communicated instruction to perform an operation. In an example, the operation may be an operation in an optical transponder such as operations listed in Table <NUM>.

In some examples, the transponder management interface <NUM> may generate management controls (such as control <NUM>) to the optical transponder <NUM>. The control <NUM> may control registers of the optical transponder <NUM> to control management operations. In some examples, the transponder management interface <NUM> of the script interpreter <NUM> may switch to a message-based control of the optical transponder <NUM> from a register-based control as appropriate and without having to change current scripts <NUM>. In other words, a shift from register-based control to message-based control may be supported through the transponder management interface <NUM> without having to change scripts <NUM> to accommodate the shift.

In some examples, the transponder management interface <NUM> may be encoded with register references that may be specific to optical transponders and types of modes or standards employed by the optical transponders. In some examples, a maximum data size of register references is <NUM> bits. As will be described further with respect to <FIG>, there may be various types of scripts (or "script types") depending on the type of optical transponder or standards employed by the optical transponder. The script interpreter <NUM> (and in particular the transponder management interface <NUM> of the script interpreter <NUM>) may use various register references based on the script type.

For example, I2C script types may be employed for I2C modes used in QSFPxx types of transponders. With these transponders, registers may be organized in a bank-page-byte structure. Registers may be <NUM> bits wide. For examples in which register references involve multiple registers, particular access sequences may be used to guarantee data consistency. An example syntax is provided for illustration:.

Management Data Input/Output (MDIO) CFPx script types may be employed for MDIO modes used in CFPx type of transponders. With these transponders, registers may be organized in a linear fashion. Registers may be <NUM> bits wide. For examples in which register references involve multiple registers, particular access sequences may be used to guarantee data consistency. An example syntax is provided for illustration:.

In some examples, access to registers in the B000h page may require write flow control. Write flow control may be provided by checking the status of a particular bit (the ready bit). In these examples, the script interpreter <NUM> may handle write flow control so that the script <NUM> need not include flow control related statements.

In some examples, bitfield reference write accesses may be executed as read-modify-write sequences. In contrast, byte (I2C) or word (MSA) write access may not be executed as read-modify-write sequences, but rather as simple writes.

In some examples, the host interface <NUM> may generate host interface controls (such as control <NUM>) to the optical transponder <NUM>. To do so, the script interpreter <NUM> (and in particular the host interface <NUM>) may be embedded with host interface lane references. For example, host interface lanes may be referenced by physical lane number. An example syntax is provided below:.

In some examples, the transponder power supply control <NUM> may generate power supply manipulation controls (such as control <NUM>) to the optical transponder <NUM>. Such controls may include power on and off controls for the power supply of the optical transponder <NUM>.

In some examples, the transponder hardware pin control <NUM> may generate pin manipulation controls (such as control <NUM> to set pin configurations) to the optical transponder <NUM>. In some examples, the transponder pin interface <NUM> may generate pin interface controls (such as control <NUM> to get pin status information) to the optical transponder <NUM>.

The controller <NUM> and/or the script interpreter <NUM> may provide the control <NUM>, <NUM>, <NUM>, <NUM>, and/or <NUM> to the optical transponder (such as the optical transponder <NUM> illustrated in <FIG>) such as via the electrical interface <NUM> (illustrated in <FIG>). In some examples, script triggered interactions with the optical transponder <NUM> may be traceable.

For example, a trace switch <NUM> may be implemented as a software-based or an electrical switch that may turn on or off interaction tracing of control events. A control event may include a transmission of control <NUM>, <NUM>, <NUM>, <NUM>, and/or <NUM> to the optical transponder <NUM>. Control events may also be referred to as transponder interactions since they cause interactions with the optical transponder.

The trace switch <NUM> may be enabled or disabled from the script <NUM>, from the native application <NUM>, based on user input (such as via UI <NUM>), and/or other source. Interaction tracing is enabled/disabled from script. With interaction tracing enabled, transponder interactions may be timestamped and logged by the interaction tracer <NUM> in the control events <NUM> datastore, which may include a list of transponder interactions. For example, the interaction tracer <NUM> may obtain an indication of a control event from the control portion <NUM>, a timestamp from the clock source <NUM>, and generate a timestamped log entry that identifies the control event and the time that such control event occurred.

In some examples, only interactions triggered by control events determined from the script <NUM> may be logged. In these examples, ONT background interactions may not be logged. Interaction tracing by the interaction tracer <NUM> may provide a timestamped log of transponder interactions, which may facilitate correlation of control events with data path events (e.g. errors and alarms), and aid in debugging scripts <NUM>. In some examples, the resolution of timestamps from the clock source <NUM> may be <NUM> milliseconds (ms), although other resolutions may be used as well. Various types of control events may be traced, such as register accesses, pin accesses, host interface settings or other manipulations; power events (such as transponder resets), and/or other types of control events described herein.

In some examples, physical transactions may be traced and logged. In these examples, register read/writes may be bytes (for I2C modes) or words (for MDIO modes). In some examples, bitfield notation may not be used in the control events <NUM> datastore logs.

In some examples, bitfield write statements may be executed as read-modify-write sequences. Therefore, they may generate two entries in the control events <NUM> datastore logs. A first entry may be made for the read access and a second entry may be made for the subsequent write access. In some examples, host interface controls may be logged with a lane bitmask value. The bitmask may indicate whether the operation is applicable (bit set to <NUM>) to a certain lane or not (bit set to zero).

In some examples, the data path signal event tracer <NUM> may monitor data path events, and generate timestamped entries that indicate the data path event <NUM> and a time at which the data path event occurred. The timestamped entries may be stored in trace events <NUM> data store. It should be noted that the data path signal event tracer <NUM> may be part of the script interpreter <NUM>, the native application <NUM> (illustrated in <FIG>) and therefore may be a "native data path tracer", and/or the controller <NUM>.

In some examples, the error detector <NUM> may correlate the timestamped entries in the control events <NUM> datastore and the trace events <NUM> datastore to determine whether a given control caused a given data path event. Such determination may be based on correlating a time of the given data path event occurring within a maximum time after the given control.

<FIG> shows an example data flow diagram <NUM> of generating different controls from a statement based on a script type. The script type may determine script language features such as a format of register references, permitted pins in set/get pin operations, host interface lane range, which transaction data (control events) may be traced, and/or other features. In some examples, the script type may be determined based on various modes of operation, such as "Manual," "Semi-Manual," "Automatic," and "Unmanaged. " In Manual mode, the script type detector <NUM> may detect the script type based on input from the user such as input via UI <NUM> illustrated in <FIG>. In "Semi-Manual", the script type detector <NUM> may infer the script type based on information from the user such as input via UI <NUM>. In "Auto" mode, the script type detector <NUM> may detect the script type based on information from the optical transponder <NUM>. In "Unmanaged" mode, the script type detector <NUM> may infer the script type from the port type used to connect to the optical transponder <NUM>. Various transponder types (illustrated as Types A-N in <FIG>) may be supported.

In examples, the script interpreter <NUM> may interpret the script <NUM> based on the script type. The script interpreter <NUM>, subject to the script type, may generate a control <NUM> (illustrated as one of controls 252A-N) based on a statement 202A and the script type. In some examples, the control <NUM> may be constrained by various script language features that are based on the script type. Thus, statements <NUM> may be interpreted in accordance with and constrained by the script type.

<FIG> shows an example data flow diagram <NUM> of parallel script execution in a multiport environment. In some examples, scripts <NUM> may be executed (interpreted by the script interpreter <NUM> and then executed at the apparatus <NUM>). For examples, as illustrated, multiple scripts 111A-N may be executed in parallel on multiport 402A-N modules. In some examples (not illustrated) a single script <NUM> may be forked to run in parallel on multiple ports 402A-N. In this manner, a given script <NUM> may include multiple statements that each are intended to run in parallel in the multiport environment.

Various manners in which the apparatus <NUM> may operate to control the optical transponder <NUM> are discussed in greater detail with respect to the method <NUM> depicted in <FIG>. It should be understood that the method <NUM> may include additional operations and that some of the operations described therein may be removed and/or modified without departing from the scopes of the method <NUM>. The description of the method <NUM> may be made with reference to the features depicted in <FIG> for purposes of illustration.

<FIG> depicts an example method <NUM> of transponder management testing and interaction tracking. The method <NUM> may be implemented by the controller <NUM> of the apparatus <NUM>, which may include an electrical interface (such as electrical interface <NUM>) to couple the apparatus <NUM> to an optical transponder (the optical transponder <NUM>) and a memory (such as the memory <NUM>) to store a script (such as script <NUM>) written in a scripting language. The script may encode a test of the optical transponder. The test may include a plurality of interactions with the optical transponder to be traced and analyzed.

As shown in <FIG>, for example, at block <NUM>, the method <NUM> may include interpreting the script to identify a control for the optical transponder based on a statement included in the script. In some examples, to interpret the script, the method <NUM> may include identifying a script type for the script. Identifying the script type may be performed in various ways. For example, to identify the script type, the method <NUM> may include accessing an input (e.g., an input from a user and/or an indication in the script that specifies the script type) that specifies the script type, automatically identifying the script type based on the optical transponder (such as based on a type of optical transponder), and/or inferring the script type based on a type of port (port type) used for coupling to the optical transponder (which may indicate a type of optical transponder and/or management interface used by the optical transponder). A type of port may include the form factors used to connect the optical transponder to the apparatus, such as the ONT device. Examples of form factors are illustrated in Table <NUM> under "Transponder Type.

The script type may dictate a plurality of language features for the script interpreter such that each language feature of the plurality of language features dictates a characteristic related to the optical transponder. Examples of characteristic include, without limitation, a format of register references, allowed pins in set or get pin operations, host interface lane range, traced transactions data (types of data path events that may be traced), and/or other characteristic.

In some examples, the statement may encode a control of the optical transponder. At block <NUM>, the method <NUM> may include causing, via the electrical interface, an interaction with the optical transponder to occur based on the control. For example, the method <NUM> may generate a control (such as a control <NUM>, <NUM>, <NUM>, <NUM>, and/or <NUM>) and transmit the control to the optical transponder, which may act based on or otherwise execute the control.

The interaction may include, for example, a management interface operation (caused by a control from the transponder management interface <NUM>) that reads from or writes to a register of the optical transponder. In another example, the interaction may include a transponder hardware pin control (caused by a control from the transponder hardware pin control <NUM>) that sets or gets a value of a hardware pin (such as a value of "high" or "low"). In yet another example, the interaction may include a host interface operation (caused by a control from the host interface <NUM>) that manipulates a host interface signal of the optical transponder (such as muting or unmuting the host interface). In still another example, the interaction may include a transponder power supply control (caused by a control from the transponder power supply control <NUM>) that manipulates a power supply of the optical transponder (such as turning on or off).

Regardless of the identified control, at block <NUM>, the method <NUM> may include generating a first timestamped log entry to indicate a timing of the control. For example, the method <NUM> may include obtaining a first timestamp from a clock source <NUM> and generating the first timestamped log entry with the first timestamp and information indicating the identified control.

At block <NUM>, the method <NUM> may include detecting a data path event (such as a data path event <NUM>) associated with the optical transponder. The data path event <NUM> may include, for example, loss of lock, Forward Error Correction (FEC) error, loss of frame/packet, bit error, block error, and/or other events indicating an error associated with the optical transponder.

At block <NUM>, the method <NUM> may include generating a second timestamped log entry to indicate a timing of the data path event. For example, the method <NUM> may include obtaining a second timestamp from a clock source (such as the clock source <NUM> in examples that use a single clock source for both the first and second timestamps) and generating the second timestamped log entry with the second timestamp and information indicating the data path event.

At block <NUM>, the method <NUM> may include determining that the data path event was caused by the control based on the first timestamped log entry and the second timestamped log entry. For example, the method <NUM> may include correlated timestamped log entries in the control events <NUM> (which may store the first timestamped log entry) and trace events <NUM> (which may store the second timestamped log entry) datastores. Generally speaking, the method <NUM> may include determining that a control in the control events <NUM> caused a data path event in the trace events <NUM> based on timestamps in their respective timestamped log entries. In particular, the method <NUM> may include determining that the control logged in the first timestamped log entry caused the data path event logged in the second timestamped log entry based on a time delta that indicates a difference in time between the first timestamp and the second timestamp. In some examples, if the time delta is within a predefined amount of time (and the second timestamp indicates a time after the first timestamp), the method <NUM> may determine that the control (having the first timestamp) caused the data path event (having the second timestamp).

At block <NUM>, the method <NUM> may include assessing operation of the optical transponder based on the determination that the data path event was caused by the control. In some examples, assessing operation of the optical transponder may include generating one or more results of the testing to be displayed via a user interface, such as III <NUM>. Such results may include the data path event and correlated control that caused the data path event.

<FIG> depicts an example method <NUM> of generating controls for an optical transponder <NUM> based on interpreted scripts <NUM>. At block <NUM>, the method <NUM> may include accessing a script from a memory. At block <NUM>, the method <NUM> may include interpreting the script with an embedded script interpreter. For example, the script interpreter may be embedded (stored) at an onboard memory of the apparatus. At block <NUM>, the method <NUM> may include identifying a control for interacting with an optical transponder based on the interpreted script. At block <NUM>, the method <NUM> may include causing an interaction with the optical transponder based on the control. For example, the method <NUM> may include transmitting the control to the optical transponder.

<FIG> depicts an example method <NUM> of automatically restarting scripts executing at the apparatus <NUM>. At block <NUM>, the method <NUM> may include executing a script (such as script <NUM>) based on an embedded script interpreter (such as script interpreter <NUM>) of the apparatus. At block <NUM>, the method <NUM> may include causing an optical transponder coupled to the apparatus to be controlled based on the script. At block <NUM>, the method <NUM> may include receiving an indication that a reset of the optical transponder has been initiated.

At block <NUM>, the method <NUM> may include causing execution of the script to be stopped based on the indication that the optical transponder is being reset. For example, the script <NUM> may be suspended, as will be described further with respect to <FIG>, or aborted, as will be described further with respect to <FIG>. In some examples, the method <NUM> may include receiving an indication that the reset is complete; and resuming (as in <FIG>) or restarting (as in <FIG>) the script <NUM> in response to the indication that the reset is complete.

Some or all of the operations set forth in the methods <NUM>-<NUM> may be included as utilities, programs, or subprograms, in any desired computer accessible medium. In addition, the methods <NUM>-<NUM> may each be embodied by computer programs, which may exist in a variety of forms. For example, some operations of the methods <NUM>-<NUM> may exist as machine-readable instructions, including source code, object code, executable code or other formats. Any of the above may be embodied on a non-transitory computer readable storage medium. Examples of non-transitory computer readable storage media include computer system RAM, ROM, EPROM, EEPROM, and magnetic or optical disks or tapes. It is therefore to be understood that any electronic device capable of executing the above-described functions may perform those functions enumerated above.

Attention will now turn to operational starting, suspension, or restarting of a script <NUM> with reference to <FIG> may refer to the features of <FIG>. <FIG> shows a block diagram 800A of an example of execution of a script <NUM> that is started in response to a transponder reset. A transponder reset and initialization may be triggered by a user (user-initiated), detection of optical transponder <NUM> being coupled (e.g., plugged in) to the apparatus <NUM>, a native application <NUM> (such as an ONT application) being loaded, the script <NUM> being initiated manually by a user or otherwise, and/or other triggers. The script <NUM> in examples illustrated in <FIG> may be referred to as "auto-start scripts" since they start running, or are otherwise initiated to execute, in response to a transponder reset and initialization (at Time reference <NUM>). Auto-start scripts may be used for automatic transponder configuration. In these instances, auto-start scripts are automatically started every time transponder reset and initialization has been performed. Auto-start scripts may be started after transponder reset and initialization is complete. The amount of optical transponder initialization/configuration by the apparatus <NUM> (such as an ONT device) may be based on the transponder type and/or the active transponder management mode (such as whether "Manual", "Semi-manual", "Auto," etc.).

<FIG> shows a block diagram 800B of an example of execution of a script <NUM> that is aborted and then restarted in response to a transponder reset. The transponder reset may be triggered based on a user-initiated reset (such as a user pressing a reset button on III <NUM>), application loaded, a detection of an optical transponder being coupled to (plugged in) the apparatus <NUM>, initiation by script <NUM>, and/or other triggers. Script <NUM> may be executing at time references X-<NUM>, X-<NUM>, and X. Upon transponder reset, execution of script <NUM> may be aborted after time reference X. When the transponder reset is finished (optical transponder <NUM> has been restarted), then the script <NUM> may also be restarted at time reference <NUM>. In this example, the script <NUM> does not resume operation, but rather is restarted.

<FIG> shows a block diagram 800C of an example of execution of a script <NUM> that is suspended by a transponder reset. The transponder reset in the example illustrated in <FIG> is similar to the transponder reset illustrated in <FIG> except that the transponder reset in <FIG> may result in suspension of the script <NUM> rather than an abort and then restart. Script <NUM> may be executing at time references X-<NUM>, X-<NUM>, and X. Upon transponder reset, execution of script <NUM> may be suspended after time reference X. When the transponder reset is finished (optical transponder <NUM> has been restarted), then the script <NUM> may resume operation from the time that the suspension started.

Referring to <FIG>, script <NUM>-initiated transponder resets may be intercepted by the native application <NUM> (such as ONT software). For example, when a script <NUM> performs an operation leading to a transponder reset, the operation may be intercepted by the native application. To do so, the native application <NUM> may monitor transponder reset pin accesses and/or monitoring register write accesses. After interception, the native application <NUM> may initiate the reset and initialization sequence.

<FIG> respectively each depicts an example of a screenshot 900A-F of a user interface (such as UI <NUM>) for transponder management testing and interaction tracking. <FIG> depicts an example of a screenshot 900A of a UI <NUM> for viewing, loading, and editing scripts <NUM> for storage and/or execution at the apparatus <NUM>.

<FIG> depicts an example of a screenshot 900B of a UI <NUM> for displaying script <NUM>-generated messages. <FIG> depicts an example of a screenshot 900C of a UI <NUM> for displaying I2C interaction traces (such as from the control events <NUM> and/or the trace events <NUM>). <FIG> depicts an example of a screenshot 900D of a UI <NUM> for displaying MDIO interaction traces (such as from the control events <NUM> and/or the trace events <NUM>). <FIG> depicts an example of a screenshot 900E of a UI <NUM> for an alternative way of displaying I2C interaction traces (such as from the control events <NUM> and/or the trace events <NUM>). <FIG> depicts an example of a screenshot 900F of a UI <NUM> for an alternative way of displaying MDIO interaction traces (such as from the control events <NUM> and/or the trace events <NUM>).

In some examples, the apparatus <NUM> shown in <FIG> may perform transponder management testing. As such, the apparatus <NUM> may be referred herein throughout as a "testing instrument," "testing device," or the like. In some examples, the apparatus <NUM> may be a component such as an optical network terminal ("ONT") in an optical network, a computing device such as a laptop device, or the like.

For instance, although examples of a script described herein throughout refer to an interpreted script, the script may be a compiled script. In this example, the script interpreter may be a script compiler that compiles the source of the script into a binary, or machine-language, executable program.

Claim 1:
A test instrument (<NUM>), comprising:
an electrical interface (<NUM>) to couple the test instrument (<NUM>) to an optical transponder (<NUM>);
a memory (<NUM>) to store a script (<NUM>), the script (<NUM>) encoding a test of the optical transponder (<NUM>), the test comprising a plurality of interactions with the optical transponder (<NUM>) to be traced and analyzed; and
a controller (<NUM>) to:
identify a script type for the script (<NUM>), wherein a plurality of language features for a script interpreter (<NUM>) that interprets the script (<NUM>) is based on the script type, wherein each of the plurality of language features dictates a characteristic related to the optical transponder (<NUM>);
interpret the script(<NUM>) to identify a control (<NUM>) for the optical transponder (<NUM>) based on a statement (<NUM>) included in the script (<NUM>);
cause, via the electrical interface (<NUM>), an interaction with the optical transponder (<NUM>) to occur based on the control (<NUM>);
generate a first timestamped log entry to indicate a timing of the control (<NUM>);
detect a data path event associated with the optical transponder (<NUM>);
generate a second timestamped log entry to indicate a timing of the data path event;
determine that the data path event was caused by the control (<NUM>) based on the first timestamped log entry and the second timestamped log entry; and
assess operation of the optical transponder (<NUM>) based on the determination that the data path event was caused by the control (<NUM>).