CROSS-REFERENCE TO RLEATED APPLICATIONS [0001] This application claims the benefit of United States Provisional Patent Application Serial No. 62/924,617, entitled “OPTICAL FIBER CONTINUITY tester” filed on October 22, 2019, which is incorporated herein by reference in its entirety.

BACKGROUND

[0002] Many applications use optical fibers for the transmission of broad bandwidth digital and analog signals. Many networks incorporate optical fibers, such as networks that provide connectivity to the Internet, wide area networks, local area networks, cable, communications, telecommunication systems, among others. When applications have multiple optical fibers, the multiple optical fibers may be arranged in multi-fiber cables.

[0003] Frequently, multi-fiber cables, or other optical fibers, may be tested for optical fiber continuity after assembly to ensure that the multi-fiber cables can act as a light transmission medium. In some implementations, optical fiber continuity testing may be similar to electrical continuity testing. For example, a visible laser may illuminate each fiber at one end of the multi-fiber cable, and each fiber may be checked for light using a camera at the other end of the multi-fiber cable.

[0004] Frequently, optical fibers have polished end faces. Optical testing may be performed without physically contacting the polished end faces to protect the integrity of the end faces. Physical contact with the end faces is avoided by emitting light from the fiber ends, across a gap, towards a detecting camera. The emitted light, from the fiber under test, may disperse as the light traverses the gap. The dispersion may cause the emitted light to affect close neighboring fibers of the multi-fiber cable under test. Also, test accuracy may depend on a camera receiving light emitted from the correct fiber. The ability of the camera to receive the desired light may depend on the alignment of the end face with the camera. Moving optical cables under test, the camera, and other devices that align the camera with the end faces of the optical cables may negatively affect the alignment of the optical devices and the results of the subsequent optical tests.

SUMMARY [0005] Systems and methods for an optical fiber continuity tester are described herein. In certain embodiments, a system includes a host computer that executes an application program interface. The system further includes an optical fiber continuity tester coupled to the host computer, wherein the application program interface facilitates communications between the host computer and the optical fiber continuity tester. The optical fiber continuity tester includes a tester computer that communicates with the host computer, wherein the tester computer receives control messages from the host computer. Additionally, the optical fiber continuity tester includes a plurality of laser modules comprising a plurality of laser ports, wherein the tester computer controls individual power levels of the lasers emitted from the plurality of laser ports based on the received control messages.

DRAWINGS

[0006] Drawings accompany this description and depict only some embodiments associated with the scope of the appended claims. Thus, the described and depicted embodiments should not be considered limiting in scope. The accompanying drawings and specification describe the exemplary embodiments, and features thereof, with additional specificity and detail, in which:

[0007] FIG. l is a block diagram illustrating a system for testing optical fiber continuity according to an aspect of the present disclosure;

[0008] FIG. 2 is a block diagram illustrating a system for testing optical fiber continuity according to a further aspect of the present disclosure;

[0009] FIG. 3 is a block diagram illustrating an optical fiber continuity tester according to a further aspect of the present disclosure;

[0010] FIG. 4 is an isometric diagram of a laser module for use in an optical fiber continuity tester chassis according to a further aspect of the present disclosure;

[0011] FIG. 5 is an isometric diagram of an optical fiber continuity tester according to a further aspect of the present disclosure;

[0012] FIG. 6 is a block diagram illustrating multiple classes implemented as part of an API for controlling an optical fiber continuity tester according to a further aspect of the present disclosure;

[0013] FIG. 7 is a sequence diagram illustrating communications between a host computer and an optical fiber continuity tester according to a further aspect of the present disclosure; [0014] FIG. 8 is a diagram illustrating a data structure for tracking requests and responses in a system for optical fiber continuity testing according to a further aspect of the present disclosure;

[0015] FIG. 9 is a block diagram illustrating different message formats for messages transmitted within a system for performing optical fiber continuity testing according to a further aspect of the present disclosure;

[0016] FIG. 10 is a block diagram of the software architecture for controlling the operation of an optical fiber continuity tester according to a further aspect of the present disclosure;

[0017] FIG. 11 is a diagram illustrating the execution of methods and handling of messages for particular instances of objects within an optical fiber continuity tester according to a further aspect of the present disclosure; and

[0018] FIG. 12 is a flowchart diagram illustrating the transmission of messages within a system for performing optical fiber continuity testing according to a further aspect of the present disclosure.

[0019] Under common practice, the various described features are not drawn to scale but are drawn to emphasize specific features relevant to the example embodiments.

DETAILED DESCRIPTION

[0020] In the following detailed description, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration specific illustrative embodiments. However, it is to be understood that other embodiments may be utilized and that logical, mechanical, and electrical changes may be made.

[0021] Methods and systems described in the present disclosure provide for an optical fiber continuity tester. In certain embodiments, the optical fiber continuity tester may be a standalone system that tests fiber optic cables and assemblies. Further, an application program interface (API) may reside on a host computer, where the API provides functionality that allows the host computer to control the operation of the optical fiber continuity tester. A user may control the optical fiber continuity tester through the host computer. Moreover, the host computer, through the API, may control multiple laser modules in the optical fiber continuity tester. [0022] In some embodiments, a user may individually control the lasers on the different laser modules within an optical fiber continuity tester from a connected host computer. For example, a user can turn the lasers on/off and control the power level/intensity of the lasers on the different laser modules. Using laser modules also allows for the pluggable insertion and removal of the different laser modules without replacing the entire optical fiber continuity tester or a laser control board within the optical fiber continuity tester. Further, each module and component may asynchronously report fault and error conditions to a connected system. When a fault occurs, a laser module may be removed and replaced.

[0023] FIG. 1 is a block diagram illustrating a system 100 for testing optical fiber continuity. As illustrated, the system 100 may include a host computer 101 and an optical fiber continuity tester 105. In some embodiments, the host computer 101 and the optical fiber continuity tester 105 may each have USB ports. A connection 107 may couple the USB ports to one another such that the host computer 101 communicates with the optical fiber continuity tester 105 through the connection 107. In some implementations, the connection 107 may include converters that facilitate the communication between the host computer 101 and the optical fiber continuity tester 105 using a USB communication standard. For example, the host computer 101 may include a USB port that functions as a USB host and the optical fiber continuity tester 105 may include a universal asynchronous receiver/transmitter (UART) port that uses a converter to communicate with the host computer 101 using the USB communication standard. Alternatively, the connection 107 may connect the host computer 101 to the optical fiber continuity tester 105 using communication media other than USB cables. Further, the connection 107 may wirelessly connect the host computer 101 to the optical fiber continuity tester 105.

[0024] In certain embodiments, the host computer 101 may include a processor and a memory unit, where the memory unit stores instructions that direct the processor to provide control of the optical fiber continuity tester 105 to a user. Also, the instructions may cause the processor to direct the general operation of the optical fiber continuity tester 105. Further, the optical fiber continuity tester 105 may include a processor that executes instructions for receiving control commands from the host computer 101 and directly controlling the operation of the optical fiber continuity tester 105.

[0025] The processor on the host computer 101 and the processor on the optical fiber continuity tester 105 may be implemented using software, firmware, hardware, or other appropriate combinations thereof. The processor and/or other computational devices may be supplemented by, or incorporated in, specially designed application-specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). The processor may be a general or special purpose computer or processor, or other programmable logic devices. The processor and other competition devices may also include or function with software programs, firmware, or other computer-readable instructions for carrying out various process tasks, calculations, and control functions used in the present methods and systems.

[0026] Further, computer-executable instructions (such as program modules or components) may implement the methods described in this description. At least one processor, such as the processor on the host computer 101 or the processor on the optical fiber continuity tester 105, may execute the computer-executable instructions. Software, firmware, or other execution- capable devices may execute the computer-readable instructions for carrying out various process tasks, calculations, and generation of data used in the operations of the described methods. The computer-readable instructions may be stored as part of one or more appropriate computer-program products, where a computer-program product may be a set of computer-readable instructions or data structures stored on a computer-readable medium. The computer-readable medium may be a media that stores data that can be accessed by the processor or other computing device. In certain implementations, the computer-readable medium may form part of a memory unit within the host computer 101 or a memory unit within the optical fiber continuity tester 105.

[0027] Computer-readable mediums may include non-volatile memory devices. Non-volatile memory devices may include semiconductor memory devices such as random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), or flash memory devices. The non-volatile memory devices may also include magnetic disks (such as internal hard disks or removable disks), optical storage devices (such as compact discs (CDs), digital versatile discs (DVDs), Blu-ray discs), or other media that can store computer-executable instructions or data structures.

[0028] In certain embodiments, the memory unit on the host computer 101 may store instructions that define an application program interface (API) 103. The API 103 may refer to a set of methods and functions that provide control of the optical fiber continuity tester 105 to the host computer 101 and a user on the host computer 101. The API 103 allows a user on the host computer 101 to send and receive messages to the optical fiber continuity tester 105 without having to know the details of the implemented methods and functions. This description describes examples of methods and functions provided by the API 103 in greater detail below.

[0029] FIG. 2 is a block diagram illustrating a system 200 for testing optical fiber continuity of optical fibers. The system 200 may include a host computer 201, where the host computer 201 is similar to the host computer 101 described above in FIG. 1. For example, the host computer 201 may also include a memory unit and one or more processors that implement an API 203 that is similar to the API 103 described above in FIG. 1. The host computer 201 may communicate with an optical fiber continuity tester 205 through a connection 207 that is similar to the connection 107 described above.

[0030] In certain embodiments, the optical fiber continuity tester 205 may include a tester computer 209. The tester computer 209 may include one or more processors that process computer-readable instructions stored on a memory unit. In some embodiments, the tester computer 209 may also transmit and receive messages through the connection 207. Further, the tester computer 209 may include an interface for communicating with several other devices within the optical fiber continuity tester 205. For instance, the tester computer 209 may communicate with multiple devices through a serial peripheral interface (SPI), an inter- integrated circuit (I2C) bus, or other interface types. Further, the tester computer 209 may be a Raspberry PI computer or other computational devices that provide the desired functionality.

[0031] In certain embodiments, the optical fiber continuity tester 205 may include multiple laser modules 211-1-211-N connected to the tester computer 209. The multiple laser modules 211-1-211-N may be referred to generally and non-specifically as laser modules 211 and individually as laser module 211-X). A laser module 211 may be an electrical component that directly controls the transmission of one or more laser beams from laser ports 219 mounted on the laser module 211. The optical fiber continuity tester 205 may introduce the transmitted laser beams from the laser ports 219 into optical fibers during optical fiber continuity testing. The laser modules 211 may communicate with the tester computer 209 to facilitate the sending of control and configuration messages from the tester computer 209 to the laser modules 211. The laser modules 211 may include logic that controls the laser ports 219 based on control and configuration messages received from the tester computer 209. [0032] In some embodiments, the tester computer 209 may monitor the laser modules 211 for faults by communicating with an NCHK fault monitor 213. In particular, the NCHK fault monitor 213 may monitor the different laser modules 211 for faults that could arise during the operation of the laser modules 211. When the NCHK fault monitor 213 identifies a fault, the NCHK fault monitor 213 may indicate that a fault has arisen to the tester computer 209. The NCHK fault monitor 213 may provide information describing the fault, such as an identifier for the laser module 211 associated with fault and an indicator that describes the fault that occurred. When the tester computer 209 receives fault information from the NCHK fault monitor 213, the tester computer 209 may provide the received fault information to the host computer 201. The host computer 201 may provide the fault information to a user.

[0033] In certain embodiments, when monitoring faults, each laser module 211 may have a fault line connected to the NCHK fault monitor 213 as an input line. Each fault line may be assigned a unique bit position in the NCHK fault monitor 213. When a fault occurs on a laser module 211, the associated NCHK fault line may experience a change of state visible to the NCHK fault monitor 213. An interrupt line may connect the NCHK fault monitor 213 to the tester computer 209. The NCHK fault monitor 213 may raise an interrupt, causing the tester computer 209 to get the status of the fault lines from the NCHK fault monitor to determine which laser module(s) 211 are raising fault(s). More than one laser module 211 may experience a fault, and each laser module 211 may experience one or more faults. When the NCHK fault monitor 213 raises an interrupt, the tester computer 209 may get the status of the fault lines from the NCHK fault monitor 213 using messaging through the interface. The tester computer 209 may identify which laser modules 211 are experiencing faults from the information received from the NCHK fault monitor 213. The tester computer 209 may then acquire specific information about fault conditions by communicating with the laser modules 211 that are currently experiencing faults.

[0034] In additional embodiments, the optical fiber continuity tester 205 may include a module present detector 215. The module present detector 215 may detect whether a specific laser module 211 is currently installed within the optical fiber continuity tester 205. If the module present detector 215 determines that a specific laser module 211 is not presently installed, the module present detector 215 may communicate information identifying the missing laser module 211 to the tester computer 209. The tester computer 209 may also provide the information regarding the missing laser module 211 to the host computer 201. [0035] In some embodiments, the tester computer 209 acquires information about the currently present modules from the module present detector 215 similarly to the identification of laser modules 211 experiencing fault conditions. For example, input lines, one for each laser module 211, connect to the module present detector 215. The tester computer 209 may retrieve the module present information using messaging through the interface with the module present detector 215. Also, the tester computer 209 may retrieve the information in response to a received interrupt.

[0036] In certain embodiments, the optical fiber continuity tester 205 may include one or more light-emitting diodes (LEDs) on an external surface or inside of the optical fiber continuity tester 205. The optical fiber continuity tester 205 may include an LED driver 217 in communication with the tester computer 209. The tester computer 209 may communicate with the LED driver 217 to control the LEDs on the external surface of the optical fiber continuity tester 205. In particular, the tester computer 209 may send control messages to the LED driver 217 to configure the LEDs to communicate information to a user of the optical fiber continuity tester 205. Thus, the tester computer 209 may communicate with various components within the optical fiber continuity tester 205 to control the operation of the optical fiber continuity tester 205.

[0037] FIG. 3 is a block diagram illustrating various electrical components found within an exemplary optical fiber continuity tester 305. The optical fiber continuity tester 305 may function similarly to the optical fiber continuity tester 205 described above in FIG. 2. To provide the functionality of the optical fiber continuity tester 205 described in FIG. 2, the optical fiber continuity tester 305 may include a laser control board 330 mounted within a chassis 320. As described, the laser control board 330 may be one or more electrical components capable of connecting to and providing control of multiple laser modules 311, where the laser modules 311 function similarly to the laser modules 211 described above in FIG. 2. Further, the chassis 320 may be a frame that contains the laser control board 330 along with other components to support optical fiber continuity testing. The chassis 320 may provide connections between the laser control board 330 and systems and devices outside the chassis 320.

[0038] In certain embodiments, the laser control board 330 may include a power converter 323. As described, the power converter 323 may operate as known to those with skill in the art. In particular, the power converter 323 may receive power having a particular voltage and current and convert the received power to one or more other voltages and currents for consumption by the various components on the laser control board 330. In some embodiments, the power converter may receive power from a power source 321 that connects through the chassis 320 to the power converter 323. The power source 321 may be a wall adapter, a wall outlet, a battery, or other power source device known to one having skill in the art.

[0039] In additional embodiments, the laser control board 330 may include a tester computer 309. The tester computer 309 may function similarly to the tester computer 209 described above relative to FIG. 2. As illustrated, an interface may connect the tester computer 309 to various components on the laser control board 330. For example, the tester computer 309 may connect to a serial peripheral interface (SPI) or other connection type known to one having skill in the art, where the tester computer 309 communicates through the interface with multiple components within the laser control board 330. Also, the tester computer 309 may connect to a communication port 337. The communication port 337 may allow the tester computer 309 to transmit and receive messages with a device outside the optical fiber continuity tester 305. For example, the communication port 337 may be a USB port or other type of communication port.

[0040] Further, the laser control board 330 may include an expander module 327. The expander module 327, may communicate with the tester computer 309 through the interface and provide additional communication lines to acquire additional information from other devices. For example, the tester computer 309 may connect to each laser module 311 through the interface. However, the interface may only provide two communication lines to each laser module 311. For example, the tester computer 309 may connect to each laser module 311 through a data bus and a chip-select line. To acquire additional information, the interface may also connect to the expander module 327, which also connects to the laser modules 311 but provides additional connections for the acquisition of additional information. For example, the expander module may provide a connection for acquiring NCHK fault information from the laser modules 311. The expander module 327 may also provide a connection to the laser modules 311 for determining whether a particular laser module 311 presently connects to the laser control board 330.

[0041] In certain embodiments, the laser control board 330 may include mounting locations for multiple laser modules 311. The laser modules 311 may be substantially similar to the laser modules 211 described above. In particular, the laser modules 211 may provide for an electrical connection to the tester computer 309 through the connecting interface and also may provide connections to multiple laser ports 319. Each laser module 311 may removably connect to the laser control board 330, i.e., each laser module 311 may be inserted into and removed from a mounting slot in the laser control board 330. Also, the laser module 311 may provide for the mounting of multiple laser ports 319 onto the laser module 311. As illustrated, two laser ports 319 connected to the laser module 311. While FIG. 3 shows the laser ports 319 as connected to the respective laser module 311; the lasers may directly mount to a respective laser module 311, as discussed below.

[0042] In some embodiments, the laser control board 330 may also include multiple communication ports 339, 343, 345, and 347 for communicating with other devices in the chassis 320. In some implementations, the communication ports 339, 343, 345, and 347 may be USB ports or other types of communication ports that may include both wireless and/or wired communication ports. To control the operation of the various communication ports 339, 343, 345, and 347, the laser control board 330 may include a communication port controller 341. The communication port controller 341 may connect to the tester computer 309 through the communication port 337, where the tester computer 309 provides communications to the various devices connected through the communication ports 339, 343, 345, and 347. Alternatively, the communication port controller 341 may receive control and commands through any of the communication ports 339, 343, 345, and 347 for controlling the other connected communication ports. In one example of a device connected through a communication port, the optical fiber continuity tester 305 may include a bar code reader port 351 connected to the communication port 343. The bar code reader connected to the bar code reader port 351 may acquire identification information for a device under test 333. The bar code reader may communicate the acquired identification information (through the bar code reader port 351) to one or both of the tester computer 309 or a connected host computer 301 through the communication port 343.

[0043] In certain embodiments, the laser control board 330 may connect to other electronic devices within the chassis 320 to facilitate the performance of optical fiber continuity testing. In some implementations, the chassis may include a laser adapter 329. As used herein, the laser adapter 329 may provide an optical connection from the laser ports 319 to the various optical fibers under test that connect to the chassis. For example, the laser adapter 329 may connect through multiple optical fibers to the laser ports 319 associated with multiple laser modules 311. The laser adapter 329 may receive the laser light from the multiple optical fibers and provide them to a device under test transmit port 331, where the laser adapter 329 connects to the device under test transmit port 331 through additional optical fibers. The laser adapter 329 may connect to various optical fibers using LC adapters or other connectors suitable for optical transmissions. In alternative embodiments, the laser beams (provided by the laser ports 319) directly provide to the device under test transmit port 331 without an interceding laser adapter 329.

[0044] In further embodiments, the device under test transmit port 331 may introduce received laser light from the laser ports 319 into one or more ends of optical fibers in a device under test 333. For example, the device under test transmit port 331 may include an MPO connector for testing continuity of optical fibers within a multi-fiber cable. The device under test transmit port 331 may receive the laser light and align the laser light with the desired optical fibers in the device under test 333. The alignment of the laser light with the desired optical fibers facilitates accurate continuity testing of the optical fibers in the device under test 333. The device under test 333 may connect to the optical fiber continuity tester 305 without using shims or other alignment devices. The optical fiber continuity tester 305 may be ruggedized to allow movement of the optical fiber continuity tester 305 during testing without affecting the alignment of the device under test relative to the optical fiber continuity tester 305.

[0045] In additional embodiments, the device under test 333 may connect to a device under test reception port 335. The device under test reception port 335 may receive light from one or more ends of optical fibers in the device under test 333 and provide the light to a camera 353 or other optical detection devices. In some embodiments, the device under test reception port 335 may connect to the device under test 333 through an MPO connector or other optical fiber connector. When the camera 353 receives lights through the device under test reception port 335, the camera 353 may provide electrical signals to one of the communication ports on the laser control board 330. For example, the camera 353 may connect to the communication port 347. The communication port 347 may provide received signals to the tester computer 309 or another computer connected to the optical fiber continuity tester 305.

[0046] In some embodiments, the optical fiber continuity tester 305 may connect to a host computer 301, where the host computer 301 functions substantially similar to the host computers 101 and 201 described in FIGs. 1 and 2. For example, the chassis 320 may include an upstream port 349 for connecting to the host computer 301. The upstream port 349 may connect to the communication port 339 for the transmission of messages between the tester computer 309 and the host computer 301.

[0047] In additional embodiments, the optical fiber continuity tester 305 may include an LED control module 325. The LED control module 325 may include an LED expander 317. The LED expander 317 may couple to the interface such that the tester computer 309 may control the operation of LEDs in the LED control module 325. In some embodiments, the optical fiber continuity tester 305 may control LEDs to communicate the status of optical fiber continuity testing performed by the optical fiber continuity tester 305. For example, the optical fiber continuity tester 305 may turn on LEDs to show that the optical fiber continuity tester 305 has power or can perform a continuity test. The LEDs may also show whether a laser is on, if an error has occurred, or if a laser module 311 is mounted within the optical fiber continuity tester 305.

[0048] FIG. 4 is an isometric diagram of a removably mountable laser module 411 for use within an optical fiber continuity tester. In certain embodiments, the laser module 411 may function substantially as described relative to the laser modules 211 and 311 in FIGs. 2 and 3. The laser module 411 may include a communicative connector 459 that connects to a port on a laser control board. The laser module 411 may receive control commands through the connector 459. Further, the connector 459 may communicatively connect to a laser control circuit 461. The laser control circuit 461 may be an integrated circuit mounted on the laser module 411. The laser control circuit 461 may receive commands and control messages from the tester computer and control the operation of the laser ports 419 in response to the received commands.

[0049] Also, the laser module 411 may include a laser mounting bracket 463, where the laser mounting bracket 463 may secure the laser ports 419 to the laser module 411. Also, the laser ports 419 may couple to a circuit board within the laser module 411. The laser control circuit 461 may control the operation of the laser ports 419.

[0050] FIG. 5 is an isometric diagram of an optical fiber continuity tester 505. The optical fiber continuity tester 505 illustrates an exemplary configuration of the parts described in FIG. 3. For example, the optical fiber continuity tester 505 may include a chassis 520 structured to hold the various components of the optical fiber continuity tester 505 within such that a user merely connects various components to the optical fiber continuity tester 505 and devices for testing.

[0051] In certain embodiments, the chassis 520 may include a front panel 555 and a rear panel 557. The front panel 555 and the rear panel 557 may have various connectors/ports mounted to the panel to facilitate the operation and control of the optical fiber continuity tester 505. For example, the front panel 555 may have two fiber optic connectors: a device under test transmit port 531 and a device under test receive port 535. The device under test transmit port 531 and the device under test receive port 535 may function substantially as described above concerning the device under test transmit port 331 and the device under test reception port 335. In particular, a device under test may connect to the device under test transmit port 531 and the device under test receive port 535. The device under test may receive light produced by one or more of the laser modules 511, where the laser modules 511 function substantially as described above in FIGs. 1-4. To provide the light and to detect the light for the device under test connected to the chassis 520, the chassis 520 may enclose a laser adapter 529 and a camera 553. Both the laser adapter 529 and the camera 553 function substantially similar to the laser adapter 329 and the camera 353 in FIG. 3. The optical fiber continuity tester 505 may provide a single movable box that facilitates the testing of optical fiber continuity without having to align the various testing components.

[0052] FIG. 6 is a block diagram illustrating the various classes and subclasses implemented within an API (such as APIs 103 and 203 described above, referred to hereafter as API 203) executed by a host computer (such as the host computers 101 and 201 described above, referred to hereafter as host computer 201). As stated above, the API 203 allows a user to use a host computer 201 to control an optical fiber continuity tester (such as optical fiber continuity testers 105 and 205, referred to hereafter as optical fiber continuity tester 205) connected to the host computer 201 via a connection 207 that may be physical (i.e. USB) or wireless.

In certain embodiments, the API 203 may define a laser driver class 620. The laser driver class 620 may define the methods that can execute on a host computer 201 to communicate with and control the operation of the optical fiber continuity tester 205. For example, the host computer 201 communicates with a tester computer 209, which communicates with the separate laser modules 211 within the optical fiber continuity tester 205. The host computer 201 may execute methods within the laser driver class 620. The executed methods may cause the host computer 201 to send messages to the tester computer 209 on the optical fiber continuity tester 205. The messages may control the operation of the tester computer 209 and direct the tester computer 209 how to control the separate laser modules 211 and other devices within the optical fiber continuity tester 205. Examples of different methods within the laser driver class may include, but are not limited to, a turn on method 621, a turn selected ports on method 623, a turn off method 625, a turn selected ports off method 627, a system restart method 629, an initialize module method 631, a get all fault conditions method 633, a get module present status method 635, a get serial number method 637, a get module hardware revision method 639, a get temperature method 641, and other methods through which a user can control the tester computer through the host computer.

[0053] In certain embodiments, the laser driver class 620 may identify laser modules 211 and laser ports 219 within the optical fiber continuity tester 205 when sending control messages and status requests to the optical fiber continuity tester 205. For example, the optical fiber continuity tester 205 may have N laser modules 211 and 2*N laser ports 219. To identify the different laser modules 211 and laser ports 219, the API may provide for an enumerated list of identifiers. The laser modules 211 may be numbered from 1-N, and the laser ports 219 may be numbered from 1-2*N. For example, where an optical fiber continuity tester 205 includes twelve laser modules 211, the laser driver class 620 may identify the modules 211 using numbers 1-12 and ports 219 using numbers 1-24.

[0054] Using the identifiers for the laser ports 219 and laser modules 211, the laser driver class 620 may provide a turn on method 621. As used, the turn on method 621 may be a method for turning on a specified laser port 219 at a specified power level. For example, the turn on method 621 may have two parameters: a port number identifier and a power level identifier specifying a desired power level. The port number identifier may be associated with the enumerated list of identifiers described above. The power level identifier may provide a numeric value that identifies a desired power level for a laser port. For example, the API 203 may provide for an enumerated list of power level identifiers (i.e., where 1 is associated with a lowest power level that can be included in a message and a higher number, such as 7, that is associated with a largest power level that can be included in a message sent from the host computer 201 to the optical fiber continuity tester 205). Alternatively, the power level may be specified as an explicit value such as a float indicating the value of the output power for the indicated laser port 219. [0055] Upon receiving the specified values through the turn on method 621, the host computer 201 may send a message to the optical fiber continuity tester 205 directing the tester computer 209 in the optical fiber continuity tester 205 to set the specified laser port 219 to the specified power level. In certain embodiments, the setting of the power level for a specified laser port 219 is best effort. The laser module 211, receiving the command, may not indicate to the tester computer 209 that the laser port 219 was successfully turned on as directed. When a laser module 211 receives a command to turn on a laser port 219 at a particular power level and the laser port 219 is already turned on to the specified level, the laser module 211 may ignore the command. Upon receiving a command to turn on a laser port 219 that is currently on at a different power level, the laser module 211 associated with the specified laser port 219 may adjust the power level of the specified laser port 219. When all the laser ports 219 are turned off and the tester computer 209 receives a turn on command, the tester computer 209 may also turn on an activity LED on the chassis of the optical fiber continuity tester 205.

[0056] Further, the laser driver class 620 may provide a turn selected ports on method 623. The turn selected ports on method 623 is similar to the turn on method 621. However, the turn selected ports on method 623 allows for the turning on of multiple laser ports 219 at respectively specified power levels for the identified laser ports 219. The turn selected ports on method 623 may be associated with a parameter that is a list of 2-tuples where each 2- tuple includes a port number identifier associated with a different power level identifier.

Upon receiving the multiple port number identifiers and associated power level identifiers, the host computer 201 may send a message to the optical fiber continuity tester 205 to turn on the identified laser ports 219 at the specified power levels. The identified laser ports may or may not be contiguously located within the optical fiber continuity tester 205. Also, if no laser ports 219 are currently on, the turn selected ports on message will cause the activity LED to turn on when a first laser port 219 of the ports identified in the message is turned on.

[0057] The laser driver class 620 may provide a turn off method 625. As used, the turn off method 625 may be a method for turning off a specified laser port 219. The turn off method 625 may be associated with one parameter: a port number identifier. Like the turn on method 621, the port number identifier may be associated with the enumerated list of identifiers described above. Upon receiving a port number identifier through the turn on method 621, the host computer 201 may send a message to the optical fiber continuity tester 205 directing the tester computer 209 in the optical fiber continuity tester 205 to turn off the specified laser port 219. Like the turn on method 621, the turning off of a specified laser port 219 is best effort, that is, the laser module 211, receiving the command, may not indicate to the tester computer 209 that the laser port 219 was successfully turned off as directed. Also, when the identified laser port 219 in the turn off method 625 is the only laser port 219 currently on, the turn off method may cause the activity LED to be turned off when the identified laser port 219 is turned off.

[0058] Also, the laser driver class 620 may provide a turn selected ports off method 627. The turn selected ports off method 627 is similar to the turn off method 625, but the turn selected ports off method 627 also allows for the turning off of multiple laser ports 219. The turn selected ports off method 627 may receive parameters that include an array of port number identifiers, where each port number identifier identifies a different laser port 219 to be turned off by the optical fiber continuity tester 205. Upon receiving the multiple port number identifiers, the host computer 201 may send a message to the optical fiber continuity tester 205 to turn off the identified laser ports 219. The identified laser ports may or may not be located at contiguous positions within the optical fiber continuity tester 205. When the identified laser ports 219 in the turn selected ports off method 627 are the only laser ports 219 on, the turn selected port off method 627 may cause the optical fiber continuity tester 205 to turn off the activity LED in addition to turning off the identified laser ports 219.

[0059] The laser driver class 620 may further provide a system restart method 629. The system restart method 629 may be a method that, when executed, directs the tester computer 209 to either turn off or restart. The system restart method 629 may receive a parameter that includes a restart instruction value, such as an enumeration, that dictates to the tester computer 209 to turn off or restart. Upon receiving the restart instruction value through the system restart method 629, the host computer 201 may send a message to the tester computer 209 on the optical fiber continuity tester 205. The tester computer 209 may shut down or restart based on the restart instruction value.

[0060] The laser driver class 620 may also provide an initialize module method 631. The initialize module method 631 may be a method for initializing a specified laser module 211 in the optical fiber continuity tester 205. As part of the initialize module method 631, the host computer 201 may specify a module identifier. Upon receiving the module identifier through the initialize module method 631, the host computer 201 may send a message to the tester computer 209 on the optical fiber continuity tester 205 that directs the tester computer 209 to initialize the specified laser module 211.

[0061] In addition to sending commands, the laser driver class 620 may also define methods that allow the host computer 201 to transmit status requests to the tester computer 209 on the optical fiber continuity tester 205. For example, the laser driver class 620 may provide a get all fault conditions method 633. The get all fault conditions method 633 is a method through which the host computer 201 may request a list of active fault conditions on the optical fiber continuity tester 205. In response to receiving a message produced by the get all fault conditions method 633 from the host computer 201, the tester computer 209 may provide a list of active faults. If there are no active faults, the tester computer 209 may provide a list of zero length to indicate that there are no faults. The get all fault conditions method 633 may provide an explicit way to confirm that the optical fiber continuity tester 205 is free from errors.

[0062] Further, the laser driver class 620 may provide a get module status method 635. The get module status method 635 is a method through which the host computer 201 may request the present or missing status of the different laser modules 211 within the optical fiber continuity tester 205. In response to receiving a request produced by the get module status method 635 from the host computer 201, the tester computer 209 may respond with information identifying which laser modules 211 are present within the optical fiber continuity tester 205. Before the tester computer 209 receives the message requesting module status, if all the laser modules 211 are present and the current status indicates that one or more laser modules 211 are missing, the tester computer 209 may turn on an associated module present LED on the chassis of the optical fiber continuity tester 205. Conversely, if one or more laser modules 211 were missing and the current status indicates that all the laser modules 211 are now present, the tester computer 209 may turn off the associated module present LED.

[0063] Also, the laser driver class 620 may provide a get serial number method 637. In some embodiments, the device used for the tester computer 209 may have a unique serial number. For example, when the tester computer 209 is a Raspberry Pi computer, the tester computer 209 may have a unique eight-byte serial number. The host computer 201 may use the get serial number method 637 to acquire the serial number from the tester computer 209 for uniquely identifying a specific tester computer 209 with tests and test results performed using the specific tester computer 209.

[0064] The laser driver class 620 may further provide a get module hardware revision method 639. In certain embodiments, the different laser modules 211 may have different hardware revision numbers. The host computer 201 may use the get module hardware revision method 639 to request the hardware revision numbers from a tester computer 209 for a particular laser module 211 identified in a parameter of the get module hardware revision method 639. The laser driver class 620 may also provide a get temperature method 641. The get temperature method 641 is a method through which the host computer 201 may request the CPU temperature of the tester computer 209. Thus, using the methods described above, the laser driver class 620 may provide control of the optical fiber continuity tester 205 to a user through the host computer 201.

[0065] The API 203 may define additional classes besides the laser driver class 620. For example, the API 203 may define a fault condition class 605. The fault condition class 605 may define fault conditions. The fault condition class 605 may provide a framework through which the tester computer 209 may transmit a message to the host computer 201 such that the host computer 201 may recognize the module or component type that generated a particular fault, the instance of the module, and the fault that was asserted or cleared. In certain embodiments, to aid in reporting the faults, the API 203 may also include a fault condition args class 603. The fault condition args class 603 may contain additional data that specifies the fault condition. The additional data may facilitate the reporting of fault condition events. Examples of reportable faults may include errors related to RAM on a laser module 211, power events, RAM changes, over-temperature events for a laser module 211, over-current events for a laser port 219, various timeout events, undefined error types, among other potential error sources. In some embodiments, faults are associated with individual laser modules 211 or laser ports 219. For faults that occur on specific laser ports 219, the faults may be identified relative to the associated laser module 211. Laser port faults are identified relative to associated laser modules 211 because the laser module may be the part to be replaced or repaired.

[0066] In additional embodiments, the API 203 may define several classes for handling responses from the tester computer 209. For example, the API 203 may include a response message class 607. The response message class 607 may include various subclasses for handling messages received from the tester computer 209 in response to status requests from the host computer 201, where the laser driver class 620 defines the status requests. The response message class 607 may identify a module number associated with a response from the tester computer 209 and response status information indicating the success or failure of a request from the host computer 201. Additional classes defined as part of the response message class 607 may include a get all fault conditions response class 609, a hardware version response class 611, a module status response class 613, a serial number class 615, and a temperature response class 617, among other classes through which the tester computer 209 may respond to various requests for information.

[0067] In certain embodiments, the get all fault conditions response class 609 may handle responses from the tester computer 209 that are received in response to requests produced by the get all fault conditions method 633 in the laser driver class 620. When the response status information associated with the response indicates that the tester computer 209 successfully responded to the requested information, the get all fault conditions response class 609 may identify a list of system fault conditions or determine that the system is not indicating faults. However, when the response status information associated with the response indicates that the requested information was not successfully responded to by the tester computer 209, the get all fault conditions response class 609 may determine that the fault status is unknown for the system. The tester computer 209 may also asynchronously send notifications of fault conditions to the host computer 201. For example, the tester computer 209 may detect NCHK faults on the laser modules 211. When the tester computer 209 detects the first NCHK fault, the tester computer 209 may turn on the NCHK LED for the optical fiber continuity tester 205. Similarly, when a last NCHK fault is cleared, the tester computer 209 may turn off the NCHK LED.

[0068] In additional embodiments, the hardware version response class 611 may handle responses from the tester computer 209 sent in response to requests produced by the get module hardware revision method 639 in the laser driver class 620. When the response status information associated with the response indicates that the tester computer 209 successfully provided the requested information, the hardware version response class 611 may identify the hardware revision for a particular laser module 211.

[0069] In further embodiments, the module status response class 613 may handle responses from the tester computer 209 sent in response to requests produced by the get module status method 635 in the laser driver class 620. The module status response class 613 may indicate the presence or absence of particular laser modules 211. For example, a response may include a 16-bit value, where each bit represents the presence or absence of a particular laser module 211

[0070] In some embodiments, the serial number class 615 may handle responses from the tester computer 209 sent in response to requests produced by the get serial number method 637 in the laser driver class 620. When the response status information associated with the response indicates that the tester computer 209 successfully provided the requested information, the serial number class 615 may identify a serial number for the tester computer 209 in the received response.

[0071] In additional embodiments, the temperature response class 617 may handle responses from the tester computer 209 sent in response to requests produced by the get temperature method 641 in the laser driver class 620. When the response status information associated with the response indicates that the tester computer 209 successfully provided the requested information, the temperature response class 617 may identify the temperature of the tester computer 209 in the received response.

[0072] FIG. 7 is a sequence diagram illustrating different message flows between a host computer 201 and a tester computer 209 in an optical fiber continuity tester 205. As illustrated, the message flows include a command message flow 701, a request/response message flow 703, and a notification message flow 705. The optical fiber continuity tester 205 may use the messages transmitted within the message flows to execute units of work because a message implicitly defines a unit of work to perform and which software block should perform the work. While FIG. 7 illustrates the message flows as applied within the environment of an optical fiber continuity tester 205, the concepts presented with relation to the message flows are abstract and other systems in communication with the host computer 201 may use similar message flows. In particular, systems that use multiple objects, object instances, and methods to implement system functionality, where the message set reflects system functionality, may use similar message flows.

[0073] In additional embodiments, the messages may originate at the host computer 201 and sent across a connection 207 to an optical fiber continuity tester 205 or other systems communicatively connected to the host computer 201. Also, various objects within the optical fiber continuity tester 205 may internally generate messages. The optical fiber continuity tester 205 may send the generated messages to the host computer 201 through the connection 207 or other connections. However, the content and structure of the message encoding may be independent of the transmission medium.

[0074] In some embodiments, messages may be encoded for transmission between different devices. For example, in an object-oriented environment (such as C#, Java, and Python), transmissible messages may be created as objects. Upon message creation, the transmitting device may encode the message for the transmission medium at the transmission time, and the receiving device may decode the message on reception. The transmitting device may encode the message using various formats such as string formats, KLV (key, length, value) sequences, or other types of encoding. For example, when the transmitting device encodes messages in a string format, the message may include multiple parameters, where a delimiter separates the parameters. The delimiter may be a pre-defmed value like a comma, space, hyphen, or other characters.

[0075] In certain embodiments, a message flow may be a command message flow 701. In a command message flow, the host computer 201 may send messages to the tester computer 209 or other devices in communication with the host computer 201. Example of command message flows 701 may include commands to turn laser ports 219 on/off, restart/shutdown the tester computer 209, and initialize laser modules 211, among other commands. In a command message flow 701, the host computer 201 may transmit the command with no expectation of a reply or confirmation. As there is no expectation of a reply or confirmation, command messages may be referred to as “set and forget.”

[0076] In additional embodiments, a message flow may be a request/response message flow 703. In a request/response message flow 703, the host computer 201 may send a request for information to the tester computer 209 or other devices in communication with the host computer 201. In response to the request, the tester computer 209 (or other devices) may respond to the host computer 201 with the requested information. If the host computer 201 fails to receive a response to the request, the host computer 201 may detect the lack of a received response and/or timeout and raise an error. Examples of request/response message flows 703 may include requests sent from the host computer 201 for fault conditions, device status, and identification information, where the tester computer 209 and/or other target devices respond with the requested information. [0077] In further embodiments, a message flow may be a notification message flow 705. In a notification message flow 705, the tester computer 209 or other devices may send an asynchronous notification to the host computer 201 without being prompted by the host computer 201. Examples of notification message flows 705 may include message transmissions from the tester computer 209 to the host computer 201 to apprise the host computer 201 of changes in the status of the tester computer 209 and other devices within the optical fiber continuity tester 205.

[0078] FIG. 8 is a diagram illustrating a data structure 801 stored on the host computer 201 for tracking requests from a host computer 201 and responses from a tester computer 209 on the optical fiber continuity tester 205. In certain embodiments, the host computer 201 may translate requests using the API 203 into message requests. The host computer 201 may send the message requests across the connection 207 to the tester computer 209. Some transmitted requests call for responses, and the requests calling for a response may be tracked within the data structure 801. In certain embodiments, the transmitted requests may have an associated timeout period. If a timeout occurs, the API 203 may not provide a retransmission mechanism. The API 203 may also allow the tracking of multiple outstanding requests within the data structure 801, even if the requests are of the same type.

[0079] In some embodiments, when there is an outstanding request from the host computer 201 waiting for a request from the tester computer 209, the request may be non-blocking. A request is non-blocking when the executing application or the API 203 does not freeze or block as the application waits for the response. When a request message is being prepared for transmission, the host computer 201 may assign a unique message identifier 807. For example, the host computer 201 may assign the request message a sequential message ID, a hash value, or other unique identifiers that facilitate tracking. The host computer 201 may add the message identifier 807 to the message. The optical fiber continuity tester 205 may return the message identifier 807 in a response message to correlate each response message with the associated request message.

[0080] In further embodiments, each message identifier 807 may be added to the data structure 801 as a key value 803. In some embodiments, the data structure 801 may be a thread-safe hash table or other types of data structures capable of storing key values 803. In addition to storing the message identifier 807, the API 203 may also store a response event object 809 that the host computer 201 adds to the table as a value 805 associated with a particular message identifier 807. A response event object may contain a wait handle/semaphore and a blank message. The host computer 201 populates the blank message when the host computer 201 receives a response from the optical fiber continuity tester 205 having the associated message identifier 807. In some implementations, the message identifiers 807 and the response event objects 809 may be added to the data structure 801 on a thread executing separately from the main application thread to keep the main application thread non-blocking.

[0081] In additional embodiments, each entry in the data structure 801 may have a unique thread instance configured to wait on the associated wait handle/semaphore for a timeout period. When the host computer 201 receives a response from the optical fiber continuity tester 205, a receive handler may use the message identifier in the received response to find the correct response event object in the data structure 801. If the receive handler finds an entry in the data structure 801, the receive handler may populate the message field of the response event object 809 with the received message and then signal the wait handle/semaphore to indicate that the host computer 201 received a response.

[0082] In further embodiments, when a thread associated with a message identifier 807 awakes, the thread awakes because the receive handler signaled the wait handle/semaphore to indicate that the host computer 201 received a message, or the thread awakes because of a timeout. When a thread awakes, the thread may remove the key value 803 and value 805 entries in the data structure 801 associated with the message identifier 807 and may provide either a valid response message constructed from the response event object 809, or a timeout response to the application. Multiple awake threads, new requests, and the receive handler may simultaneously access the data structure 801.

[0083] FIG. 9 is a block diagram illustrating different message formats for messages transmitted between a host computer 201 and on optical fiber continuity tester 205. As discussed above, the above-described messages (transmitted between the host computer 201 and the optical fiber continuity tester 205) may have different formats depending on the messages being transmitted. For example, messages may be in a command/request format 910, a response format 920, a notification format 930, or other message formats based on the message being transmitted.

[0084] In certain embodiments, the command/request format 910 may provide a message format that applies to messages transmitted to the optical fiber continuity tester 205 by the host computer 201 when the host computer 201 is sending a command to or requesting information from the optical fiber continuity tester 205. As shown, a message sent in the command/request format 910 may include a header 911 and a message ID 913. Also, the message ID 913 in the command/request format 910 may be optional. For example, “set and forget” commands may not include a message ID 913. Optionally, a message sent in the command/request format 910 may include parameters 915 and a checksum 917. In some embodiments, the messages transmitted between the host computer 201 and the optical fiber continuity tester 205 may have the same format for the header 911. For example, the header 911 may have a field that defines the message type and an instance number for the message. Having the same format for the various messages transmitted between the host computer 201 and the optical fiber continuity tester 205 may provide extensibility and processing advantages. In additional embodiments, the message ID 913 may provide information regarding the unique identification number described above concerning FIG. 8.

[0085] In further embodiments, the command/request format 910 may optionally provide parameters 915 based on the message type defined in the header 911. For example, a “turn on laser port” message may include the parameters field for sending the information describing a particular laser port to turn on and the desired power level of the laser port 219. The command/request format 910 may optionally provide a checksum 917. The optical fiber continuity tester 205 may use the checksum 917 to verify that the data received in a command/request message is the data transmitted by the host computer 201 and that the received message is error free.

[0086] In some embodiments, a message sent in the response format 920 may include a header 921, a message ID 923, and a status 925. Optionally, a message sent in the response format 920 may include parameters 927 and a checksum 929. As described above, the header 921 may be similar to the header 911. Likewise, the message ID 923 may provide information regarding the unique identification number described above regarding FIG. 8. In contrast to the command/request format 910, the response format 920 may include a status 925. The status 925 may indicate whether a received message is OK, has an error, experienced a timeout, or if the optical fiber continuity tester 205 is unreachable by the host computer 201.

[0087] In further embodiments, the response format 920 may optionally provide parameters 927. In contrast to the command/request format 910, the response format 920 provides the parameters 927 based on the status 925. For example, if the status 925 is OK, then the response format 920 may include parameters 927 to respond to a request message. Like the command/request format 910, the response format 920 may optionally provide a checksum 929. The host computer 201 may use the parameters 927 to verify that the data received in a response message is the data transmitted by the optical fiber continuity tester 205.

[0088] In additional embodiments, the notification format 930 may include a header 931, optional parameters 933, and an optional checksum 935, which are respectively similar to the header 921, the optional parameters 927, and the optional checksum 929 described above regarding the response format 920.

[0089] FIG. 10 is a block diagram of the software architecture 1000 for controlling the operation of an optical fiber continuity tester 205. As shown, the software architecture 1000 may describe the various software components for controlling the handling of communications received by a computational device such as the tester computer 209. Also, the software architecture 1000 may describe software components for communicating and controlling various electrical components operating within the optical fiber continuity tester 205.

[0090] In certain embodiments, the software architecture 1000 may include a message processor 1001. The message processor 1001 may control the work, operation, and handling of configuration requests received from the host computer 201. The message processor 1001 may function on the tester computer 209. In certain implementations, the message processor 1001 is thread safe and runs on threads associated with the message originator. Further, the message processor 1001 may process a single message at a time as an atomic operation. When the message processor 1001 is processing a message, other threads associated with other messages that attempt to access the message processor may be blocked. After the message processor 1001 completes processing a particular message, the control of the message processor 1001 may be passed to a next waiting thread that invokes the message processor 1001. Control of the message processor 1001 continues to be passed until there are no blocked threads with messages.

[0091] In some embodiments, by blocking threads from accessing the message processor 1001 when the message processor 1001 is processing a message, the message processor 1001 may control access to shared hardware resources, such as an SPI interface, serial links, laser ports 219, laser modules 211. Accordingly, the message processor 1001 may avoid contention and race conditions. The blocking also has the effect of stopping threads from stealing CPU time when the message processor 1001 is using an interface (such as the SPI interface) or trying to configure a laser module 211 under strict timing constraints.

[0092] In further embodiments, the message processor 1001 may take a single parsed message as a parameter and may return a message response or return a null if the message does not require a response. For string-based messaging, a parsed message may be an array of strings, where each string is a message parameter. For KLV messages, a parsed message is an array of objects, where each object may be a different object type derived from a base type. Additionally, message parameter order is strictly enforced as defined above, creating an easily extensible interface for new messages. The message processor 1001 may be the sole transmitter of message responses to the host computer 201 to avoid resource contention issues. Also, the message processor 1001 is a critical-section code to avoid other contention issues.

[0093] In certain embodiments, the message processor 1001 may communicate through a communication port. For example, the communication port may be a USB serial port 1005 or a UART port. The USB serial port 1005 may receive messages through a receive port 1025 from a host computer 201. The message processor 1001 may communicate with a host computer 201 through a transmit port 1023. Also, the message processor 1001 may include a fault condition monitor 1003 and a module present monitor 1007. The fault condition monitor 1003 may monitor the various components for various faults that may arise as described above. The module present monitor 1007 monitors the various laser modules 211 to determine whether they are present within the optical fiber continuity tester 205.

[0094] In some implementation, the software architecture 1000 may include a fault condition expander object 1009 that monitors fault conditions for the various laser modules 211. For example, each laser module 211 may signal fault conditions via a hardware signal. The various signals may connect to the fault condition expander object 1009, and the signals may occupy bit positions corresponding to the laser module number in a hardware register having a different bit associated with each laser module 211. The hardware register may have an address within the fault condition expander object 1009 accessible by the fault condition expander object 1009 via an interface (such as an SPI interface).

[0095] In certain embodiments, a set bit position in the hardware register may indicate that one or more faults have occurred in a corresponding laser module 211. In some implementations, fault change of states are interrupt driven and may cause the creation of a new message for the message processor 1001. The message processor 1001 may invoke the fault condition expander object 1009 to detect the assertion and clearance of laser module faults and report the new or cleared faults to the host computer 201 through a notification message via a serial link.

[0096] In further embodiments, there may be multiple instances of the laser object 1011, where each instance associates with a different laser port 219. Each laser object 1011 may have an instance number that corresponds with a particular laser port number. As described above, lasers may be turned on at a certain power level/intensity, set to a certain power level/intensity, and turned off.

[0097] In additional embodiments, the software architecture 1000 may provide for multiple instances of the laser module object 1013, where each instance associates with a different laser module 211. Each laser module object 1013 may have an instance number that corresponds with a hardware module number/slot. In some implementations, the laser module object 1013 can initialize laser modules 211, check status and fault registers, read ADC feedback values, set register values, read the module hardware version, and the like.

[0098] In certain embodiments, the software architecture 1000 may provide for a module present object 1015. The module present object 1015 may keep track of whether particular laser modules 211 are present within the optical fiber continuity tester that corresponds to the module number in a hardware register. For example, module 6 occupies bit position 6 when the modules are numbered 1-12. The hardware register may have an address within the expander module hardware that may be accessed by the module present expander object 1015 via an interface. The module present expander object 1015 may read bit positions in the hardware register to detect that a corresponding laser module 211 is missing where the bits are set and cleared in hardware from a signal on a pin in the modules slot that is connected to the expander. Changes of state to a laser module 211 may optionally cause an interrupt. Upon causing an interrupt, the corresponding code may generate a message, and invoke the message processor 1001 to process the state changes. In some embodiments, the message processor 1001 may send a notification message to the host computer 201 describing the state changes. Also, the module present expander object 1015 may set or clear a module present LED on the optical fiber continuity tester 205 based on whether the modules are all present within the optical fiber continuity tester 205. [0099] In additional embodiments, the software architecture 1000 may include an LED expander object 1017. The LED expander object 1017 may keep track of whether particular LEDs on the optical fiber continuity tester 205 are on or off. Also, the LED expander object 1017 may associate the different LEDs with different states of the optical fiber continuity tester 205. For example, LEDs may be on if there are one or more errors, a laser port 219 is turned on, a module is missing, power is provided to the optical fiber continuity tester 205, the optical fiber continuity tester 205 is ready to perform a continuity test, or other states. The LED expander object 1017 may maintain a hardware register of various bits, where each bit is associated with a particular LED, and the bits are set to control which LEDs are on and which LEDs are off.

[0100] In further embodiments, the software architecture 1000 may provide an interface that allows the various software objects to communicate with hardware modules 1021 or laser modules 211. For example, the interface may be an SPI interface, and the various software objects communicate through the interface using an SPI manager object 1019. For example, the hardware modules 1021 may be allocated different module numbers. The different module numbers may be mapped to unique SPI chip selects (CS) for the various hardware modules 1021. The software objects may invoke the SPI manager object 1019, using their object instance (module number) and the data to send, and a buffer for any result/response. The calling software object may send messages in the message format used by the corresponding SPI device, which may vary depending on the SPI device. The software architecture 1000 described above may provide a means for controlling hardware modules 1021 while providing control to a host computer 201 executing an API 203.

[0101] FIG. 11 is a diagram illustrating the managing of message instances by the message processor 1001 of FIG. 10 within an optical fiber continuity tester 205. In certain embodiments, the message processor 1001 may store message instances within an array 1100. For example, the array 1100 may be a two-dimensional jagged array, where a first axis 1101 is associated with a particular message instance, and a second axis 1103 is associated with a particular message type. When code 1117 (associated with a particular method and object) is to be implemented, the code 1117 is added to the array 1100 at a location by message type and by message instance. For example, the message types 1105 and 1111 at rows 0 and 3, each have 24 instances, where each instance for the message type defines a method that is associated with an instance of the object, in this case, an instance of a laser port 219. Each instance of message types 1107 and 1115 at rows 1 and 5 are associated with separate laser modules 211. Further, the message types 1109 and 1113 at rows 2 and 4 may be associated with a single object or include a response or notification message to send to the host computer 201. When a method instance at a particular array entry is invoked, the return value is either null or a message. If the return value is a message, a response has been generated, and the message processor 1001 may transmit the response over the serial link to the host computer 201. The message processor 1001 may operate without knowledge of message types, and which messages generate responses, which information may be known by the object methods.

[0102] In some embodiments, the use of the array 1100 may provide an easily extensible framework for invoking methods on objects having an arbitrary number of objects of different types, and each object type having an arbitrary number of instances from 1 to N, and an arbitrary number of methods. While the application, in this case, is an optical fiber continuity tester 205, the framework can easily be implemented within other applications. To implement in other applications, the appropriate objects may be created and the array implemented.

[0103] To add new objects and methods to an application implementing the array 1100, a new message may be created using the next available message type number. When the message has been created, the appropriate parameters for the message may be defined, and the message may be added as a new row at the bottom of the array 1100. At each row entry, the object method associated with the message may be called and implemented at a particular instance in the implementation of the array 1100. For example, if the new object has a single instance, there may be a single entry for the column, where the entry has an index 0. If there are N instances, there may be N+l, where the column entries, having indexes 1-N, are used for indexing the entries. If an object has, as an example, 3 methods, there may be three row entries. If there are 10 instances of the object, there may be 10 column entries, one for each method instance. In total then, so that all method instances of this object can be uniquely invoked, a total of 30 array elements are occupied.

[0104] FIG. 12 is a flowchart diagram illustrating a method 1200 for transmitting messages within a system for performing optical fiber continuity testing. The method 1200 proceeds at 1201, where a message is generated on a host computer 201. The method 1200 proceeds at 1203, where the message is transmitted. When the host computer 201 transmits the message, the method 1200 proceeds at 1205, where the tester computer 209 determines whether a message is received in error or is error free (i.e., perform a checksum), check length, etc. If a message is received in error by the tester computer 209, the method 1200 proceeds to 1207, where the message is discarded. For example, if the message was a command message and the tester computer 209 does not receive the message, then the tester computer 209 may not respond to the message, and the host computer 201 may not transmit a follow-up message to ensure that the tester computer 209 received the message. Alternatively, if the message was a request message and the tester computer 209 does not receive the message, then the host computer 201 may experience a timeout and stop waiting for a response to the request message.

[0105] In certain embodiments, when the tester computer 209 receives an error free message of any type from the host computer, the method 1200 proceeds at 1209, where the message is parsed into an array of strings. For example, the message may be parsed into an array of strings for decoding. When the message is parsed, the method 1200 proceeds at 1211, where an object method is invoked from the message processor. Additionally, when the object method is invoked, the method 1200 proceeds at 1213, where the object method determines whether to generate a response. As stated above, object methods know what type of message they are processing, and whether the method calls for the generation of a response message. If the method does not call for a response message, the method 1200 proceeds at 1215, where the method completes without generating a response.

[0106] In additional embodiments, when the method generates a response 1213, the method 1200 proceeds at 1217, where a response is transmitted from the tester computer 209 to the host computer 201. When the response is transmitted, the method 1200 proceeds at 1219, where it is determined whether the host received a valid error-free message. For example, as described above in connection to FIG. 8, the host computer 201 may store message IDs in a data structure along with associated wait handles. If the wait handle experiences a timeout, then the host computer 201 may determine that a response was not received. If the host computer 201 does not receive a response, the method 1200 proceeds at 1221, where information related to the request message is discarded.

[0107] In some embodiments, when the host computer 201 receives a response from the tester computer 209, the method 1200 proceeds at 1223, where a response thread is signaled. For example, the host computer 201 may create a wait handle upon sending a request message to the tester computer 209. Upon receiving the response message, the host computer 201 may use information (such as the message ID as discussed above in FIG. 8) in the received response to signal the wait handle. Also, a blank message field associated with the request message may be populated with data from the associated response message. When the response thread is signaled, the method 1200 proceeds at 1225, where a response message is passed to an application. For example, the response message may be passed to the appropriate application for further processing.

EXAMPLE EMBODIMENTS

[0108] Example 1 includes a device comprising: a chassis having a plurality of ports; a plurality of laser modules mounted on a laser control board within the chassis, wherein each laser module in the plurality of laser modules comprises a plurality of laser ports through which laser light is emitted for introduction into a first end of one or more optical fibers; an optical detection device mounted within the chassis for detecting the laser light emitted from a second end of the one or more optical fibers that is connected to the chassis; and a tester computer mounted within the chassis, the tester computer configured to control operation of the plurality of laser modules.

[0109] Example 2 includes the device of Example 1, wherein the tester computer controls the operation of the plurality of laser modules based on commands received from a host computer.

[0110] Example 3 includes the device of any of Examples 1-2, wherein a laser module in the plurality of laser modules is individually removable from and connectable to the laser control board.

[0111] Example 4 includes the device of any of Examples 1-3, wherein controlling the operation of the plurality of laser modules comprises: turning a laser port in the plurality of laser ports on and off; and setting a power level of the laser light to one of a plurality of power levels.

[0112] Example 5 includes the device of any of Examples 1-4, wherein the tester computer communicates with components through a serial peripheral interface.

[0113] Example 6 includes the device of Example 5, further comprising one or more serial peripheral interface expanders that couple the tester computer to multiple instances of a component within the chassis. [0114] Example 7 includes the device of any of Examples 1-6, wherein a laser module in the plurality of laser modules comprises a laser control circuit in communication with the tester computer, wherein the laser control circuit controls the operation of the plurality of laser ports on the laser module in response to commands received from the tester computer and provides status of the laser module to the tester computer.

[0115] Example 8 includes the device of any of Examples 1-7, wherein the tester computer receives signals from components in the chassis that indicate: fault conditions for the components; and whether the components are present in the chassis.

[0116] Example 9 includes the device of Example 8, wherein the tester computer provides messages to a host computer describing the fault conditions and whether the components are present: in response to a request from the host computer; and asynchronously when the signals are received by the tester computer.

[0117] Example 10 includes the device of any of Examples 1-9, wherein the tester computer creates objects for messages and stores instances of the objects in a data structure, wherein each instance of an object is associated with a different component in communication with the tester computer.

[0118] Example 11 includes a system comprising: a host computer that executes an application program interface; and an optical fiber continuity tester coupled to the host computer, wherein the application program interface facilitates communications between the host computer and the optical fiber continuity tester, the optical fiber continuity tester comprising: a tester computer that communicates with the host computer, wherein the tester computer receives control messages from the host computer; and a plurality of laser modules comprising a plurality of laser ports, wherein the tester computer controls individual power levels of lasers emitted from the plurality of laser ports based on the control messages.

[0119] Example 12 includes the system of Example 11, wherein a laser module in the plurality of laser modules is individually removable from and connectable to a laser control board in the optical fiber continuity tester.

[0120] Example 13 includes the system of any of Examples 11-12, wherein the tester computer communicates with components in the optical fiber continuity tester through a serial peripheral interface. [0121] Example 14 includes the system of Example 13, wherein the optical fiber continuity tester further comprises one or more serial peripheral interface expanders that couple the tester computer to multiple instances of a component within the optical fiber continuity tester.

[0122] Example 15 includes the system of any of Examples 11-14, wherein a laser module in the plurality of laser modules comprises a laser control circuit that communicates with the tester computer, wherein the laser control circuit controls operation of the plurality of laser ports on the laser module in response to commands received from the tester computer and provides status of the laser module to the tester computer.

[0123] Example 16 includes the system of any of Examples 11-15, wherein the tester computer receives signals from components in the optical fiber continuity tester that indicate: fault conditions for the components; and whether the components are present in the optical fiber continuity tester.

[0124] Example 17 includes the system of Example 16, wherein the tester computer provides messages to the host computer describing the fault conditions and whether the components are present: in response to a request from the host computer; and asynchronously when the signals are received by the tester computer.

[0125] Example 18 includes the system of any of Examples 11-17, wherein the tester computer creates objects for messages and stores instances of the objects in a data structure, wherein each instance of an object is associated with a different component in communication with the tester computer.

[0126] Example 19 includes the system of any of Examples 11-18, wherein the host computer generates a request message for information from the tester computer and transmits the request message to the tester computer.

[0127] Example 20 includes the system of Example 19, wherein generating the request message comprises: generating a message identifier for the request message; storing the message identifier in a data structure; storing a wait handle in the data structure, the wait handle being associated with the message identifier; and associating a blank message field with the message identifier in the data structure.

[0128] Example 21 includes the system of Example 20, wherein the host computer handles a response message that is received in response to the request message by: identifying a response message identifier in the response message; matching the response message identifier to the message identifier in the data structure; populating the blank message field associated with the message identifier with data from the response message; signaling the wait handle; and passing the data from the response message to an application executing on the host computer.

[0129] Example 22 includes the system of any of Examples 1 l-22wherein the tester computer asynchronously transmits a notification message to the host computer in response to receiving information from components of the optical fiber continuity tester.

[0130] Example 23 includes a method comprising: generating a message on a host computer, wherein the message contains a command associated with a device controlled by a tester computer; transmitting the message to the tester computer; receiving the message at the tester computer; invoking an object method associated with an instance of the device based on the command in the message; and executing the object method.

[0131] Example 24 includes the method of Example 23, further comprising: generating a request message on the host computer; transmitting the request message to the tester computer; determining if a response message is received from the tester computer; and when the response message is received, processing the response message.

[0132] Example 25 includes the method of Example 24, wherein generating the request message on the host computer comprises: generating a message identifier for the request message; storing the message identifier in a data structure; storing a wait handle in the data structure, the wait handle being associated with the message identifier; and associating a message field with the message identifier in the data structure.

[0133] Example 26 includes the method of Example 25, wherein processing the response message comprises: identifying a response message identifier in the response message; matching the response message identifier to the message identifier in the data structure; populating the message field associated with the message identifier with data from the response message; signaling the wait handle; and passing the response message to an application executing on the host computer.

[0134] Example 27 includes the method of any of Examples 25-26, further comprising asynchronously transmitting a notification message to the host computer.

[0135] Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that any arrangement, which is calculated to achieve the same purpose, may be substituted for the specific embodiments shown. Therefore, it is manifestly intended that this invention be limited only by the claims and the equivalents thereof.