Patent Description:
This disclosure is generally directed to industrial process control and automation systems. More specifically, this disclosure is directed to a system and method for automated checking of <NUM>/<NUM> loops.

Loop checking is the process of validating and verifying the accuracy of cables that are laid from control panels to field instruments, which ensures that the right transmitter is connect to the correct Input/Output (<NUM>/<NUM>) port of a controller. Loop checking is an important activity in a plant during installation, commissioning and maintenance phases. In many plants, loop checking is a mandatory activity that cannot be eliminated and consumes large amounts of time, cost and manpower. Loop checking requires multiple people working together to ensure that the loop is properly connected to <NUM>/<NUM> ports and a marshalling cabinet. Loop checking needs to be completed before powering up of a field instrument or marshalling cabinet. <CIT> relates to industrial process control and automation systems and is directed to an automated loop check for smart junction boxes. <CIT> relates to electronic testing, and more particularly to in-circuit, at-speed testing of electronic systems that use ASICs (Application Specific Integrated Circuits).

Another example of a currently used system can be found in <CIT>, which discloses an I/O-abstracted configuration for a field device that has not yet been assigned or allocated to communicate via a particular I/O device or I/O network within a plant, and this configuration is stored in a device placeholder object in a back-end environment of the plant. Thereafter other objects, modules, applications, user interfaces, etc., that are to execute in the back-end environment of the plant to communicate with the field device during on-line operation of the plant may be designed, built, configured, and tested using the device placeholder object without any actual communications with the field device and without assigning the device placeholder object to a particular I/O channel or I/O network. A commissioning system which may create and store one or more device placeholder objects in a database within the back-end environment of the plant includes an execution engine that executes one or more other back-end environment objects to be commissioned and tested, and a communication interface that determines, from the device placeholder object if a field device is in an I/O-unallocated device state. If so, the communication interface uses the configuration data stored in the device placeholder object to verify that the form, format, and configuration of the object being tested is correct to properly communicate with the field device.

Process Industries like oil & gas, petrochemicals, refineries etc. involves multiple stages of validation and verification in the project lifecycle. Validation and verification of input/output (I/<NUM>) loop checks need to be completed before starting the commissioning and startup of the plant. During a projects lifecycle, the validation of <NUM>/<NUM> loop check activities occur at PRE-FAT (pre-factory acceptance testing), FAT (factory acceptance test) and SAT ( site acceptance test) and validate the hardwired <NUM>/<NUM> loop from the junction boxes, field termination assemblies and marshalling cabinets to field instruments. This is manually intensive, repetitive & time-consuming activity is required to demonstrate that the correct wiring and configuration has been made for each <NUM>/<NUM> channel.

When the cables are checked for failures, the cables between junction boxes, field termination assemblies are tested by detecting a signal transmitted from a control panel to specific field devices. Currently, each cable is manually tested by a group of people from a cable source (such as a marshalling cabinet) to a destination (such as a field transmitter), which is time consuming.

The present disclosure is directed to a system comprising a field terminal block, a dongle configured to be installed on the field terminal block and configured to make an electrical connection with an input/output and a method comprising installing a dongle on a field terminal block to make an electrical connection-with an input/output (I/O) loop according to the appended claims. This disclosure provides a system and method for the automated checking of I/O loops of an industrial process control and automation system.

In a first embodiment a system according to claim <NUM> is provided.

In a second embodiment a method according to claim <NUM> is provided.

The figures, discussed below, and the various embodiments used to describe the principles of the present invention in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the invention. Those skilled in the art will understand that the principles of the invention may be implemented in any type of suitably arranged device or system.

<FIG> illustrates an example industrial process control and automation system <NUM> according to this disclosure. As shown in <FIG>, the system <NUM> includes various components that facilitate production or processing of at least one product or other material. For instance, the system <NUM> is used here to facilitate control over components in one or multiple plants 101a-101n. Each plant 101a-101n represents one or more processing facilities (or one or more portions thereof), such as one or more manufacturing facilities for producing at least one product or other material. In general, each plant 101a-101n may implement one or more processes and can individually or collectively be referred to as a process system. A process system generally represents any system or portion thereof configured to process one or more products or other materials in some manner.

In <FIG>, the system <NUM> is implemented using the Purdue model of process control. In the Purdue model, "Level <NUM>" may include one or more sensors 102a and one or more actuators 102b. The sensors 102a and actuators 102b represent components in a process system that may perform any of a wide variety of functions. For example, the sensors 102a could measure a wide variety of characteristics in the process system, such as temperature, pressure, flow rate, or a voltage transmitted through a cable. Also, the actuators 102b could alter a wide variety of characteristics in the process system. The sensors 102a and actuators 102b could represent any other or additional components in any suitable process system. Each of the sensors 102a includes any suitable structure for measuring one or more characteristics in a process system. Each of the actuators 102b includes any suitable structure for operating on or affecting one or more conditions in a process system.

At least one network <NUM> is coupled to the sensors 102a and actuators 102b. The network <NUM> facilitates interaction with the sensors 102a and actuators 102b. For example, the network <NUM> could transport measurement data from the sensors 102a and provide control signals to the actuators 102b. The network <NUM> could represent any suitable network or combination of networks. As particular examples, the network <NUM> could represent an Ethernet network, an electrical signal network (such as a HART or FOUNDATION FIELDBUS (FF) network), a pneumatic control signal network, or any other or additional type(s) of network(s).

In the Purdue model, "Level <NUM>" may include one or more controllers <NUM>, which are coupled to the network <NUM>. Among other things, each controller <NUM> may use the measurements from one or more sensors 102a to control the operation of one or more actuators 102b. For example, a controller <NUM> could receive measurement data from one or more sensors 102a and use the measurement data to generate control signals for one or more actuators 102b. Multiple controllers <NUM> could also operate in redundant configurations, such as when one controller <NUM> operates as a primary controller while another controller <NUM> operates as a backup controller (which synchronizes with the primary controller and can take over for the primary controller in the event of a fault with the primary controller). Each controller <NUM> includes any suitable structure for interacting with one or more sensors 102a and controlling one or more actuators 102b. Each controller <NUM> could, for example, represent a multi variable controller, such as a Robust Multivariable Predictive Control Technology (RMPCT) controller or other type of controller implementing model predictive control (MPC) or other advanced predictive control (APC). As a particular example, each controller <NUM> could represent a computing device running a real-time operating system.

Two networks <NUM> are coupled to the controllers <NUM>. The networks <NUM> facilitate interaction with the controllers <NUM>, such as by transporting data to and from the controllers <NUM>. The networks <NUM> could represent any suitable networks or combination of networks. As particular examples, the networks <NUM> could represent a pair of Ethernet networks or a redundant pair of Ethernet networks, such as a FAULT TOLERANT ETHERNET (FTE) network from HONEYWELL INTERNATIONAL INC.

At least one switch/firewall <NUM> couples the networks <NUM> to two networks <NUM>. The switch/firewall <NUM> may transport traffic from one network to another. The switch/firewall <NUM> may also block traffic on one network from reaching another network. The switch/firewall <NUM> includes any suitable structure for providing communication between networks, such as a HONEYWELL CONTROL FIREWALL (CF9) device. The networks <NUM> could represent any suitable networks, such as a pair of Ethernet networks or an FTE network.

In the Purdue model, "Level <NUM>" may include one or more machine-level controllers <NUM> coupled to the networks <NUM>. The machine-level controllers <NUM> perform various functions to support the operation and control of the controllers <NUM>, sensors 102a, and actuators 102b, which could be associated with a particular piece of industrial equipment (such as a boiler or other machine). For example, the machine-level controllers <NUM> could log information collected or generated by the controllers <NUM>, such as measurement data from the sensors 102a or control signals for the actuators 102b. The machine-level controllers <NUM> could also execute applications that control the operation of the controllers <NUM>, thereby controlling the operation of the actuators 102b. In addition, the machine-level controllers <NUM> could provide secure access to the controllers <NUM>. Each of the machine-level controllers <NUM> includes any suitable structure for providing access to, control of, or operations related to a machine or other individual piece of equipment. Each of the machine-level controllers <NUM> could, for example, represent a server computing device running a MICROSOFT WINDOWS operating system. Although not shown, different machine-level controllers <NUM> could be used to control different pieces of equipment in a process system (where each piece of equipment is associated with one or more controllers <NUM>, sensors 102a, and actuators 102b).

One or more operator stations <NUM> are coupled to the networks <NUM>. The operator stations <NUM> represent computing or communication devices providing user access to the machine-level controllers <NUM>, which could then provide user access to the controllers <NUM> (and possibly the sensors 102a and actuators 102b). As particular examples, the operator stations <NUM> could allow users to review the operational history of the sensors 102a and actuators 102b using information collected by the controllers <NUM> and/or the machine-level controllers <NUM>. The operator stations <NUM> could also allow the users to adjust the operation of the sensors 102a, actuators 102b, controllers <NUM>, or machine-level controllers <NUM>. In addition, the operator stations <NUM> could receive and display warnings, alerts, or other messages or displays generated by the controllers <NUM> or the machine-level controllers <NUM>. Each of the operator stations <NUM> includes any suitable structure for supporting user access and control of one or more components in the system <NUM>. Each of the operator stations <NUM> could, for example, represent a computing device running a MICROSOFT WINDOWS operating system.

At least one router/firewall <NUM> couples the networks <NUM> to two networks <NUM>. The router/firewall <NUM> includes any suitable structure for providing communication between networks, such as a secure router or combination router/firewall. The networks <NUM> could represent any suitable networks, such as a pair of Ethernet networks or an FTE network.

In the Purdue model, "Level <NUM>" may include one or more unit-level controllers <NUM> coupled to the networks <NUM>. Each unit-level controller <NUM> is typically associated with a unit in a process system, which represents a collection of different machines operating together to implement at least part of a process. The unit-level controllers <NUM> perform various functions to support the operation and control of components in the lower levels. For example, the unit-level controllers <NUM> could log information collected or generated by the components in the lower levels, execute applications that control the components in the lower levels, and provide secure access to the components in the lower levels. Each of the unit-level controllers <NUM> includes any suitable structure for providing access to, control of, or operations related to one or more machines or other pieces of equipment in a process unit. Each of the unit-level controllers <NUM> could, for example, represent a server computing device running a MICROSOFT WINDOWS operating system. Although not shown, different unit-level controllers <NUM> could be used to control different units in a process system (where each unit is associated with one or more machine-level controllers <NUM>, controllers <NUM>, sensors 102a, and actuators 102b).

Access to the unit-level controllers <NUM> may be provided by one or more operator stations <NUM>. Each of the operator stations <NUM> includes any suitable structure for supporting user access and control of one or more components in the system <NUM>. Each of the operator stations <NUM> could, for example, represent a computing device running a MICROSOFT WINDOWS operating system.

In the Purdue model, "Level <NUM>" may include one or more plant-level controllers <NUM> coupled to the networks <NUM>. Each plant-level controller <NUM> is typically associated with one of the plants 101a-101n, which may include one or more process units that implement the same, similar, or different processes. The plant-level controllers <NUM> perform various functions to support the operation and control of components in the lower levels. As particular examples, the plant-level controller <NUM> could execute one or more manufacturing execution system (MES) applications, scheduling applications, or other or additional plant or process control applications. Each of the plant-level controllers <NUM> includes any suitable structure for providing access to, control of, or operations related to one or more process units in a process plant. Each of the plant-level controllers <NUM> could, for example, represent a server computing device running a MICROSOFT WINDOWS operating system.

Access to the plant-level controllers <NUM> may be provided by one or more operator stations <NUM>. Each of the operator stations <NUM> includes any suitable structure for supporting user access and control of one or more components in the system <NUM>. Each of the operator stations <NUM> could, for example, represent a computing device running a MICROSOFT WINDOWS operating system.

At least one router/firewall <NUM> couples the networks <NUM> to one or more networks <NUM>. The router/firewall <NUM> includes any suitable structure for providing communication between networks, such as a secure router or combination router/firewall. The network <NUM> could represent any suitable network, such as an enterprise-wide Ethernet or other network or all or a portion of a larger network (such as the Internet).

In the Purdue model, "Level <NUM>" may include one or more enterprise-level controllers <NUM> coupled to the network <NUM>. Each enterprise-level controller <NUM> is typically able to perform planning operations for multiple plants 101a-101n and to control various aspects of the plants 101a-101n. The enterprise-level controllers <NUM> can also perform various functions to support the operation and control of components in the plants 101a-101n. As particular examples, the enterprise-level controller <NUM> could execute one or more order processing applications, enterprise resource planning (ERP) applications, advanced planning and scheduling (APS) applications, or any other or additional enterprise control applications. Each of the enterprise-level controllers <NUM> includes any suitable structure for providing access to, control of, or operations related to the control of one or more plants. Each of the enterprise-level controllers <NUM> could, for example, represent a server computing device running a MICROSOFT WINDOWS operating system. In this document, the term "enterprise" refers to an organization having one or more plants or other processing facilities to be managed. Note that if a single plant 101a is to be managed, the functionality of the enterprise-level controller <NUM> could be incorporated into the plant-level controller <NUM>.

Access to the enterprise-level controllers <NUM> may be provided by one or more operator stations <NUM>. Each of the operator stations <NUM> includes any suitable structure for supporting user access and control of one or more components in the system <NUM>. Each of the operator stations <NUM> could, for example, represent a computing device running a MICROSOFT WINDOWS operating system.

Various levels of the Purdue model can include other components, such as one or more databases. The database(s) associated with each level could store any suitable information associated with that level or one or more other levels of the system <NUM>. For example, a historian <NUM> can be coupled to the network <NUM>. The historian <NUM> could represent a component that stores various information about the system <NUM>. The historian <NUM> could, for instance, store information used during production scheduling and optimization. The historian <NUM> represents any suitable structure for storing and facilitating retrieval of information. Although shown as a single centralized component coupled to the network <NUM>, the historian <NUM> could be located elsewhere in the system <NUM>, or multiple historians could be distributed in different locations in the system <NUM>.

In particular embodiments, the various controllers and operator stations in <FIG> may represent computing devices. For example, each of the controllers could include one or more processing devices <NUM> and one or more memories <NUM> for storing instructions and data used, generated, or collected by the processing device(s) <NUM>. Each of the controllers could also include at least one network interface <NUM>, such as one or more Ethernet interfaces or wireless transceivers. Also, each of the operator stations could include one or more processing devices <NUM> and one or more memories <NUM> for storing instructions and data used, generated, or collected by the processing device(s) <NUM>. Each of the operator stations could also include at least one network interface <NUM>, such as one or more Ethernet interfaces or wireless transceivers.

In accordance with this disclosure, various components of the system <NUM> support a process for an automated loop check in the system <NUM>. For example, the controllers 104a-104b may represent field device controllers, and the process elements 102a-102b may represent field devices. Additional details regarding this functionality are provided below.

Although <FIG> illustrates one example of an industrial process control and automation system <NUM>, various changes may be made to <FIG>. For example, a control system could include any number of sensors, actuators, controllers, servers, operator stations, and networks. Also, the makeup and arrangement of the system <NUM> in <FIG> is for illustration only. Components could be added, omitted, combined, or placed in any other suitable configuration according to particular needs. Further, particular functions have been described as being performed by particular components of the system <NUM>. This is for illustration only. In general, process control systems are highly configurable and can be configured in any suitable manner according to particular needs.

<FIG> illustrates an example the marshalling cabinet <NUM> according to this disclosure. For ease of explanation, the marshalling cabinet <NUM> is described as being used in the system <NUM> of <FIG>. For example, the marshalling cabinet <NUM> may be located between a system cabinet <NUM> housing controllers <NUM>, and process elements 102a and 102b, and other hardware such as switch/firewall <NUM>, or a combination of the components described in <FIG>. However, the marshalling cabinet <NUM> could also be used in any other suitable system.

The marshalling cabinet <NUM> includes field termination block <NUM> and field termination relay hardware <NUM>. Only one field termination block <NUM> is shown in <FIG> for ease of illustration, however, it is well known to those skilled in this art, that marshalling cabinets may containing a plurality of terminal blocks <NUM> housed in cabinet <NUM>. The field termination block <NUM> connects wire cables between cabinet <NUM> and process elements, such as actuators, sensors and other process instruments installed in the automation system. The system cabinet <NUM> connects to the marshaling cabinet <NUM> via the field termination relay hardware <NUM> and wiring cables 220a and 220b. The marshalling cabinet <NUM>, further connects to a plurality of junction boxes <NUM>, and to a plurality of process instruments 230a - 230d.

The marshalling cabinet <NUM> receives signals transmitted from one of the process instruments 230a-230d through a junction boxes <NUM> and cable bundles <NUM>. Each process instrument 230a-230d is coupled to a respective junction box <NUM> via a cable <NUM>. The cables <NUM> are bundled at the junction boxes <NUM> to form a cable bundle <NUM> upstream of the junction box <NUM>. A junction box <NUM> can also be used to combine multiple cable bundles <NUM> into a single cable bundle <NUM>, as illustrated between the junction box <NUM> and the marshalling cabinet <NUM>.

Although <FIG> illustrates one example of a junction box <NUM>, <NUM>, various changes may be made to <FIG>. For example, the number(s) and type(s) of components shown in <FIG> and the functional divisions of the junction boxes <NUM>, <NUM>, marshaling cabinet <NUM>, system cabinet <NUM> and their included hardware shown in <FIG> are for illustration only. Various components in <FIG> could be omitted, combined, or further subdivided and additional components could be added according to particular needs.

The automated loop check system of the disclosure employs an intelligent dongle <NUM> arranged to connect to the terminal blocks of cabinet <NUM> such as terminal block <NUM> and simulate signals based on input/output information provided to the dongle <NUM> from operating software <NUM> operating in a mobile hand-held device <NUM>. The dongle <NUM> can also be installed to terminal blocks in the junction boxes <NUM> in the same manner as will be explained for the terminal block <NUM> of the marshalling cabinet <NUM>.

Operating software <NUM> is installed on a hand-held mobile device <NUM>, for example, such as a cellular telephone, data pad, tablet, or hand-held computer operating any on an IOS an ANDROID or WINDOWS operating system. The operating software <NUM> controls the sequencing of execution of tests through dongle <NUM> based on personality information of each process instrument connected to the terminal block <NUM>. The operating software <NUM> automatically generates an I/O loop check file using predefined library functions based on project engineering database input. The I/O loop check file is downloaded to dongle <NUM> for execution and testing of the I/O loops connected to the dongle <NUM>.

The hand-held device <NUM> is connected via a wireless WI-FI or BLUETOOTH connection to the dongle <NUM>. Additionally, the hand-held device <NUM> is further connected via a wireless WI-FI connection to an engineering workstation <NUM>, as well as to the cloud <NUM> through WAP <NUM> mounted on L2 switch <NUM> as shown in <FIG>. The cloud connections are through integrity policy enforcement (IPE) security that hosts a smart plant instrumentation (SPI) database that among other functions within an industrial process control and automation system design, defines the overall wiring connections between the sensors, actuators, controllers, servers, operator stations, and networks of the industrial process control and automation system.

Turning know to <FIG>, the dongle <NUM> of the disclosure is illustrated. Dongle <NUM> is comprised of an electronics section <NUM> and a separate terminal section <NUM>. The terminal section <NUM> provides a snap-in arrangement of terminal pins <NUM>. For example, in the terminal section <NUM> shown in <FIG>, an <NUM>-channel snap-in terminal section <NUM> has <NUM> terminal pins <NUM>. Each terminal pin is adapted to engage with and establish an electrical connection to terminal sockets found in the terminal block <NUM>. Various snap-in terminal pins <NUM> (not shown) can be installed in the terminal section <NUM> adapted to plug into specific electrical sockets of the terminal block <NUM>. The terminal section <NUM> also includes an electrical connector (not shown) that engages a similar connector on the electronics section <NUM> that passes electrical signals between the terminal pins <NUM> and the electronic section <NUM> of the dongle <NUM>.

As can be best seen at <FIG>, the dongle <NUM> also includes a clip/holder mechanism <NUM> that is used to retain the dongle <NUM> securely to the terminal block <NUM>. The clip/holder <NUM> is mounted to the dongle <NUM> in a manner that allows the clip arm <NUM> of holder mechanism <NUM> to be moved latterly away from the terminal block. Applying pressure to arm <NUM> moves members <NUM> and hooks <NUM> laterally away from the terminal block <NUM>. The dongle is installed by inserting pins <NUM> into complementary electrical sockets in terminal block <NUM>. Attaching hooks <NUM>' to engage edge <NUM> of terminal block <NUM>. Releasing the clip arm <NUM> allows hooks <NUM> to grab edge <NUM> of terminal block <NUM> and retain the dongle <NUM> on the terminal block <NUM> as is shown in <FIG>. Lateral movement of the clip/holder can be accomplished, for example, with the use of a spring (not shown) which will allow the lateral movement of the clip arm <NUM> by physical manipulation or by use of a live hinge that is made from a thinner cross-section of the material making-up the housing of the dongle <NUM>.

The electronics section <NUM> of dongle <NUM> is shown schematically at <FIG>. The electronics section <NUM> includes at least one processor <NUM>, at least one storage device <NUM>, at least one communications unit <NUM>, and at least one input/output (I/O) unit <NUM>. Processor <NUM> can execute instructions, such as those that may be loaded into memory <NUM>. Processor <NUM> denotes any suitable processing device, such as one or more microprocessors, microcontrollers, digital signal processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or discrete circuitry.

The memory <NUM> and a persistent storage <NUM> are examples of storage devices, which represent any structure(s) capable of storing and facilitating retrieval of information (such as data, program code, and/or other suitable information on a temporary or permanent basis). The memory <NUM> may represent a RAM or any other suitable volatile or non-volatile storage device(s). The persistent storage <NUM> may contain one or more components or devices supporting longer-term storage of data, such as a ROM, and flash memory, or the like. Memory <NUM> can be used to store for example, the intermediate results of the operation of the processor <NUM> and the test files to be executed by dongle <NUM> as well as the results of the executed loop tests. The persistent storage may be used, for example, for storing the processor operating system, and the software for performing self-testing and calibration of the dongle <NUM>.

The communications unit <NUM> supports communications with other systems or devices. For example, the communications unit <NUM> could include at least one network interface facilitating communications over a wireless communication protocol such as WI-FI or BLUETOOTH.

The I/O unit <NUM> allows for the input and output of data and is electrically connected through a connector (not shown) to the terminal section <NUM> of dongle <NUM>. For example, the I/O unit <NUM> may provide a connection through the terminal section <NUM> for providing simulated I/O commands to a process instrument. The I/O unit <NUM> supports <NUM> channels of any IO Type with functional <NUM>-point analog test support. The I/O unit <NUM> drives signals to the I/O loops under test via the <NUM>-channel terminal section <NUM> through the terminal block <NUM>. The I/O unit <NUM> supports I/O configurations downloaded from the I/O loop operating software <NUM> such as analog input (AI), digital input (DI), digital output (DO), Analog Output (AO), Thermocouple/RTD, Low Level Multiplexing / Low Level analog input End of Line (LLMux/LLAI EOL) monitoring (Short/Open) and burnout detection.

The execution of I/O loop tests by dongle <NUM> is based on the personality information of each I/O loop or I/O loop channel. The personality information is compiled from engineering data from the automation and control system and on inputs received from a smart plant instrumentation database (SPI). As shown on <FIG>, a loop check file <NUM> is created automatically by the operating software <NUM> by importing to the operating software <NUM> wiring diagrams <NUM> of the wiring and cabling path between the marshalling cabinet <NUM>, or junction box <NUM> and the process instruments 230a-230d to be tested. The wiring diagram <NUM> is provided and downloaded to the operating software <NUM> from a master wiring database from the project engineering workstation <NUM> or from an SPI located in the cloud <NUM>. Alarm trip set points <NUM> are also input from the project engineering workstation <NUM> for the process instruments 230a-230d connected to the I/O loop channel under test. Next the type of test to be run is selected from a predefined library <NUM>, for example, an analog input test or a digital input test. The wiring data <NUM> and alarm trip setpoints <NUM> and test types <NUM> build the I/O loop check file <NUM> which is downloaded to the dongle <NUM> via the WI-FI or BLUETOOTH wireless connection. The I/O loop check file <NUM> is the test image for the personality information of a specific I/O loop channel to be tested. The operating software <NUM> executing on the mobile device <NUM> enables and supervises the execution status of the dongles <NUM>.

<FIG> illustrates an example method <NUM> for automatic loop checking according to this disclosure. For ease of understanding, the method <NUM> is described with respect to the marshaling cabinet <NUM> in <FIG>. However, the method <NUM> could be used by any suitable marshaling cabinet, field termination assembly or junction box and in any suitable system.

The method <NUM> includes block <NUM> in which the I/O channel personality image is downloaded to the operating software <NUM> from the engineering database and an I/O loop check file <NUM> is created. In block <NUM>, the operating software <NUM> sends a notification to the display of the mobile device <NUM> instructing the field operator to connect the dongle <NUM> to the terminal block <NUM> of the marshaling panel <NUM>. Once the dongle <NUM> is installed, the dongle <NUM> goes through a series of self-tests and attempts to establish a wireless WI-FI or BLUETOOTH connection with the mobile device <NUM>. As is shown in block <NUM>, if the dongle <NUM> fails to connect, the dongle attempts the connection again and repeats a connection attempt until a connection is established between the dongle <NUM> and the mobile device <NUM>.

In block <NUM>, upon establishing a wireless connection between the dongle <NUM> and the mobile device <NUM>, the I/O loop check file <NUM> is downloaded from the operating software <NUM> to the dongle <NUM> and the dongle instructed to simulate the loop check to be performed. For example, if an analog input loop check is to be performed, the I/O unit <NUM> of the electronics section <NUM> sets up I/O circuitry to perform an analog loop check.

Next in block <NUM>, the I/O loop test is performed for the I/O loop or I/O loop channel under test. In block <NUM>, the dongle <NUM> tracks the test data which is compared to an expected result for the I/O loop test. If the results of the loop test pass, in block <NUM> the dongle sends the test results to the operating software where the results are recorded. The operating software <NUM> then determines, in block <NUM>, if more I/O loops checks are to be performed for the terminal block that the dongle <NUM> is installed on, for example, a second I/O loop or I/O channel. The I/O channel number is incremented in block <NUM> and a second <NUM>/O loop check file <NUM> is downloaded to the dongle <NUM> for execution.

However, if an I/O loop fails its loop test, the dongle <NUM>, in block <NUM> sends the failed results to the operating software <NUM> where the failure is recorded and a determination is made in block <NUM> if more loops checks are to be performed for the terminal block that the dongle is installed on. If one or more I/O loop tests are required to be made, the I/O channel number is incremented in block <NUM> and a second <NUM>/O loop check file is downloaded to the dongle <NUM> for execution.

In block <NUM>, once all I/O loop tests are complete for all I/O loop channels connected to the dongle <NUM> , a notification is displayed on the mobile device <NUM>, for the field operator to install the dongle <NUM> to the next terminal block <NUM> of the marshalling panel <NUM>. The dongle <NUM> in this embodiment is able to connect to eight I/O loops or I/O loop channels and perform eight I/O loop tests before requiring it to be moved to the next set of I/O loops to be tested.

Although <FIG> illustrates one example of a method for automatic loop checking, various changes may be made to <FIG>. For example, while shown as a series of steps, various steps shown in <FIG> could overlap, occur in parallel, or occur multiple times. Moreover, some steps could be combined or removed, and additional steps could be added.

<FIG> shows a display <NUM> presented to the user on mobile device <NUM> by a user interface of operating software <NUM> to the field operator when setting up a dongle <NUM>. The display <NUM> includes information <NUM> identifying the industrial process control and automation system, the name of the marshalling cabinet <NUM> and a pane including thumbnail images <NUM> of the terminal blocks installed in the cabinet. Each terminal block thumbnail <NUM> can have a unique name associated with it, which would be shown as label <NUM> over the specific terminal blocks thumbnail <NUM>. On the left side of the screen a dongle tray is displayed with a series of thumbnail images representing dongles, such as dongle thumbnail <NUM>. Each dongle thumbnail <NUM> would be associated with a particular I/O loop check file <NUM> that has been completed by the operating software <NUM>. Each dongle thumbnail <NUM> therefore would represent a personality image of the I/O loop check file <NUM> built to be executed for a specific terminal block <NUM>. Each dongle is further identified by a specific ID. For example, the ID could be a specific numeral representing the dongle or a unique alphanumeric name.

In order to run an automated I/O loop check the appropriate dongle thumbnail <NUM> from the dongle tray is dragged and dropped on a specific terminal block thumbnail <NUM> to be tested as shown by arrow <NUM>. The dongle thumbnail <NUM> can be dragged and dropped on a selected terminal block using for example, the field operator's finger, a stylus, track pad or by other means for completing the selection such as using modern input/output mechanisms such as drop-down menus and mouse right-clicks. Testing is started when the "begin testing" button <NUM> is pressed. The I/O loop check file <NUM> is then downloaded to the dongle <NUM> associated with the terminal block selected and the I/O loop testing started.

As can be seen in <FIG>, once a dongle thumbnail <NUM> is associated with a terminal thumbnail <NUM> the terminal block changes from a dashed line square to a solid square <NUM> signifying that a dongle and a loop check file has been associated with the terminal block. I/O loop checks completed successfully, are indicated by a solid image color as shown. However, upon a failure of a I/O loop check, the terminal block thumbnail <NUM> indicates a failed state by displaying a failure color and the dongle image ID associated with the loop failure is marked and identified <NUM> for later troubleshooting by the field operator.

<FIG> illustrates a display <NUM> presented to the user on the mobile device <NUM> by the graphic user interface of operating software <NUM> when the dongle <NUM> is physical installed on terminal block <NUM> and executing the I/O loop checks. The dongle ID <NUM> is indicated on the screen display header. As is shown in <FIG>, a pictorial representation of the terminal block <NUM> is displayed showing, in this example, eight I/O loop channels being tested. Each I/O loop channel signifying an I/O loop being tested by an I/O loop check file <NUM>. Overall progress of the tests being run by the dongle <NUM> is shown in the screen header by display <NUM> as well as the elapsed time of the test at <NUM>. The terminal block under test is also identified by a label <NUM> that identifies the terminal block being tested. Each channel includes indication if an I/O loop check has passed the testing <NUM>, is in progress <NUM>, or failed (not shown). The tests can be stopped and or resumed using the function buttons <NUM>, <NUM> respectively on the bottom of the screen.

Reports for each I/O loop test is recorded by the operating software <NUM> and uploaded to the project engineering diabase at an engineering workstation <NUM> or to the cloud <NUM>. The test results are validated automatically and can be retrieved at any time. Once a dongle <NUM> is associated with a terminal block <NUM> and a I/O loop check started, the system performs the I/O loop checks automatically without the need of a test engineer or field operator to watch over the testing. Further, I/O loop checks can be performed overnight and can be perform on multiple systems at the same time.

In some embodiments, various functions described in this patent document are implemented or supported by a computer program that is formed from computer readable program code and that is embodied in a computer readable medium.

The description in this patent document should not be read as implying that any particular element, step, or function is an essential or critical element that must be included in the claim scope. Also, none of the claims is intended to invoke <NUM> U. §<NUM>(f) with respect to any of the appended claims or claim elements unless the exact words "means for" or "step for" are explicitly used in the particular claim, followed by a participle phrase identifying a function. Use of terms such as (but not limited to) "mechanism," "module," "device," "unit," "component," "element," "member," "apparatus," "machine," "system," "processor," "processing device," or "controller" within a claim is understood and intended to refer to structures known to those skilled in the relevant art, as further modified or enhanced by the features of the claims themselves, and is not intended to invoke <NUM> U.

Claim 1:
A system (<NUM>), comprising:
a field terminal block (<NUM>);
a dongle (<NUM>) configured to be installed on the field terminal block (<NUM>) and configured to make an electrical connection with an input/output, I/O, loop (<NUM>);
a mobile hand-held device (<NUM>) including an operating software (<NUM>) for communicating with the dongle (<NUM>) and with a database of I/O loop data and wiring diagrams, wherein:
the operating software is configured to use the database of I/O loop data and wiring diagrams of a wiring and cabling path between a marshalling cabinet, junction box and process instruments to be tested to automatically construct an I/O loop check file (<NUM>), and
the dongle is configured to download the I/O loop check file (<NUM>) to execute the testing of the I/O loop (<NUM>) wherein an I/O loop test for the I/O loop comprises comparing a test data to an expected result for the I/O loop test.