System and method for configuring a test system

Abstract

A method for configuring a test system may include receiving, with a switch, a request including an identification or configuration request of a first test asset of the test system for testing. The method may also include accessing a current configuration and current test asset utilization of the test system, evaluating the current configuration based on the current test asset utilization and the request, determining a test configuration based on the evaluation and an implementation matrix for the test system, and implementing the switch according to the test configuration. Implementing the switch may include the switch connecting the test assets according to the test configuration such that configuration according to the first test or configuration request for the first test asset is performed non-exclusively with respect to capabilities of the test system implemented to test other test assets.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Application No. 63 / 476,582, filed December 21, 2023, which is incorporated herein by reference in its entirety.

[0002] The present disclosure relates to systems, devices, and methods for configuring test systems, and more particularly, to systems, devices, and methods for configuring test systems implemented to test vehicles and vehicle systems, such as test systems used to test aircraft and avionics, flight controls, powertrains, actuators, and cockpit systems, devices, computers, and components for aircraft and aircraft. [Background technology]

[0003] Introduction Test systems, such as system integration labs, are often used to test both the hardware and software incorporated into complex integrated systems for vehicles (e.g., aircraft, unmanned aerial vehicles, automobiles, boats, submarines, etc.), often as part of the development of those vehicles and prior to real-world implementation. Test systems may include complex configurations of workbenches (also known as test benches), and may include as many pieces of hardware for the vehicle's subsystems operable within the lab environment.

[0004] In a workbench, hardware and other types of components (e.g., software packages for hardware components) may define line replaceable units (LRUs). Additionally, a workbench may include LRUs interconnected with LRUs on other workbenches. In the context of an aircraft, this may include, for example, an LRU such as an aircraft management computer (AMC) on an avionics workbench interconnected with an LRU on another workbench, e.g., a flight control system (FCS) on a flight control bench or actuator or actuator system on an actuation bench. Complex configurations of interconnected workbenches may enable test systems to tie together and test groups of systems or strings of interconnected LRUs all at once that may be incorporated into a control system being developed for a vehicle. Summary of the Invention [Problem to be solved by the invention]

[0005] In the context of the test system described herein, a workbench and an LRU may provide or otherwise define the test assets of a test system. However, a test involving one workbench or the LRUs of interconnected workbenches may require the lockdown of all other parts of the test system. Requiring the lockdown of an entire lab to test the functionality of one LRU (one test asset) is inefficient and does not fully utilize the lab's capabilities. In fact, test runs specific to one engineering team may prevent an entire team of engineers from working simultaneously, as they likely require the lockdown of the entire test system. A workaround for this problem may include creating a collision-free schedule that allows only one of multiple engineering teams to use the test system. Alternatively, a standalone workbench may be built to test a single LRU, but this is generally a practically impossible proposition in terms of cost, time, and / or labor required.

[0006] Furthermore, integrating additional individual systems into existing test systems typically requires a redesign of the lab architecture. This may require lab operators (e.g., engineers) to physically disconnect and plug connectors when changing lab components. Physical reconnection can take hours or days to perform and involves a substantial risk of human error. Furthermore, common methods used by engineers in many technology fields to test new installations of new systems, devices, or components may not be available in the context of vehicle-compatible test systems. That is, lab operators cannot use methods that involve first testing the software supporting the new LRU, then testing the LRU in isolation, and then testing the LRU together with other LRUs to verify the integration between them. Instead, after changes are made to the lab, a time-consuming, labor-intensive, and difficult quality assurance process (also known as a "system checkout") is performed to ensure (A) that the change process does not create errors and (B) that tests performed after the change are reliable. Such quality assurance processes involve many manual processes and may take days or weeks to perform.

[0007] The present disclosure is directed to overcoming one or more of the problems set forth above. [Means for solving the problem]

[0008] Examples described herein include devices, systems, and methods for configuring a test system. In one embodiment, the method of configuring a test system may include receiving, using a switch, a request including an identification or configuration request of a first test asset of the test system for testing. The method may also include accessing a current configuration and current test asset utilization of the test system, evaluating the current configuration based on the current test asset utilization and the request, determining a test configuration based on the evaluation and an implementation matrix for the test system, and implementing the switch according to the test configuration. In one embodiment, implementing the switch may include the switch connecting the test assets according to the test configuration such that configuration according to the first test or configuration request for the first test asset is performed non-exclusively with respect to capabilities of the test system implemented to test other test assets.

[0009] Various aspects of exemplary switches and methods of implementing the switches according to the present disclosure include one or more of the following features: an implementation matrix that may specify at least two test assets of the test system that may include a misconfiguration specific to the test system and that may not be operably coupled; an implementation matrix that includes a utilization scheme that specifies at least two test assets that may be operably coupled by two or more operably coupled test assets; a method that includes modifying a test configuration using the switch to include a hardware simulation of at least one test asset in the test configuration based on a current utilization status of the hardware; and a method that includes modifying a test configuration using the switch to include a hardware simulation of at least one test asset in the test configuration based on a current utilization status of the hardware. The method may include implementing a first test on a test asset and implementing a second test on a second test asset simultaneously with the first test using a switch, the first test asset including a system of test assets, the first test asset being a single line replaceable unit within the system of test assets that is integrated into an actuation workbench or a powertrain workbench, the first test including configuring the first test asset to be disconnected from the system of test assets, and testing of the asset including a standalone test of the test asset, wherein the first test includes connecting the first test asset to a second test asset that is not included in the system of assets.

[0010] Various additional aspects of the example methods described herein may include a method comprising: determining that a configuration of a configuration request corresponds to a misconfiguration included in an implementation matrix; issuing a notification that the configuration is invalid; and displaying the notification using a computing device; locking down a second test asset of a test system; implementing a first test of a first test asset; incorporating the first test asset and the second test asset into a first workbench; and implementing a second test of a third test asset incorporated into the first workbench during at least a portion of the implementation of the first test of the first test asset, wherein the test system corresponds to an aircraft, and the test assets of the test system include an avionics workbench, a flight control system workbench, and a powertrain workbench.

[0011] Examples described herein include a test system that may correspond to a vehicle and may include multiple workbenches, each workbench incorporating at least two test assets, and may include a switch operably coupled to the multiple workbenches. In one example, the switch may include multiple ports connected to the multiple workbenches, one or more processors, and computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform operations. In various examples described herein, the operations may include receiving, with the switch, a request including one of an identification of a first test asset of the test system for a test and a configuration request; accessing a current configuration of the test system and current test asset utilization; evaluating the current configuration based on the current test asset utilization and the request; determining a test configuration based on the evaluation and an implementation matrix for the test system; implementing the switch according to the test configuration; and tracking changes to the current configuration of the test.

[0012] Various aspects of the example test system described herein may include operations including accessing a plurality of workbenches; identifying misconfigurations among test assets of the test system; incorporating the misconfigurations into an implementation matrix; identifying usage schemes for connecting test assets across the plurality of workbenches, each of which may specify at least two test assets of the test system that may be operably coupled by two or more consecutively operably coupled test assets; modifying the test configuration using a switch to include a simulation of hardware of at least one test asset within the test configuration based on current utilization of the hardware; and locking down a second test asset of the test system and implementing a first test of the first test asset, wherein the first test asset and the second test asset are incorporated into a first workbench of the plurality of workbenches.

[0013] Examples described herein include an exemplary switch having a plurality of ports, one or more processors, and one or more computer-readable media containing instructions. In various examples of the present disclosure, the instructions, when executed by the one or more processors, cause the one or more processors to perform operations including receiving a request including one of an identification and configuration request of a first test asset of a test system for testing, accessing a current configuration of the test system and a current test asset utilization, evaluating the current configuration based on the current test asset utilization and the request, determining a test configuration based on the evaluation and an implementation matrix for the test system, operating in accordance with the test configuration, and modifying the test configuration to include a hardware simulation of at least one test asset in the test configuration based on the current utilization of the hardware.

[0014] Various aspects of the example switches described herein may include multiple ports for the switch, including two of an Ethernet port, an RS-485 port, a CAN port, and an RS-422 port.

[0015] Additional objects and advantages of the disclosed embodiments will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the disclosed embodiments. The objects and advantages of the disclosed embodiments will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims.

[0016] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosed embodiments as claimed.

[0017] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various exemplary embodiments and, together with the description, serve to explain the principles of the disclosed embodiments. [Brief explanation of the drawings]

[0018] [Figure 1] 1 illustrates an exemplary test system for performing vehicle testing, according to one embodiment. [Figure 2] 1 illustrates a flowchart of an exemplary method for building or generating an implementation matrix, according to one embodiment. [Figure 3] 1 illustrates a flowchart of an exemplary method for determining or generating a test configuration for a test system, according to one embodiment. [Figure 4] 1 illustrates a sequence diagram of an exemplary method for configuring a test system according to a test configuration, according to one embodiment. [Figure 5] 1 illustrates a sequence diagram of an exemplary method for managing test system data including test configuration related information, according to one embodiment. [Figure 6] 1 illustrates a flowchart of an exemplary method for adding test assets to a test system, according to one embodiment. [Figure 7] 1 illustrates exemplary system components of a test system for a vehicle, such as an aircraft, according to one embodiment. [Figure 8] 1 illustrates an exemplary graphical user interface (GUI) for a test system that may be used to perform various methods described herein. [Figure 9A] 1 illustrates an exemplary GUI of a test system that may be used to perform various methods described herein. [Figure 9B] 1 illustrates an exemplary GUI of a test system that may be used to perform various methods described herein. [Figure 9C] 1 illustrates an exemplary GUI of a test system that may be used to perform various methods described herein. [Figure 9D] 1 illustrates an exemplary GUI of a test system that may be used to perform various methods described herein. [Figure 9E] 1 illustrates an exemplary GUI of a test system that may be used to perform various methods described herein. [Figure 9F] 1 illustrates an exemplary GUI of a test system that may be used to perform various methods described herein. [Figure 9G] 1 illustrates an exemplary GUI of a test system that may be used to perform various methods described herein. DETAILED DESCRIPTION OF THE INVENTION

[0019] Both the foregoing general description and the following detailed description are exemplary and explanatory only and are not intended to limit the present disclosure, as defined in the claims. As used herein, the terms "comprise," "comprising," "has," "having," "includes," "including," or other variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus comprising a list of elements does not include only those elements, but may include other elements not expressly listed or inherent in such process, method, article, or apparatus. In this disclosure, unless otherwise stated, relative terms such as "about," "substantially," and "approximately" are used to indicate a possible variation of ±10% in the stated value. In this disclosure, unless otherwise stated, any numerical value may include a possible variation of ±10% in the stated value.

[0020] The terms used below, while being used in conjunction with detailed descriptions of certain specific embodiments of this disclosure, may be interpreted in their broadest reasonable manner. Indeed, even though certain terms may be emphasized below, any terms intended to be interpreted in a limiting manner are expressly and specifically defined as such in this Detailed Description section.

[0021] Various embodiments of the present disclosure generally relate to exemplary switches and methods for implementing those switches to enable a test lab environment to adapt to changing testing needs without physically reconfiguring the lab. All individual systems of a vehicle corresponding to a single lab can be connected to an exemplary switch of the present disclosure. This switch can have physical connections found in real-world versions of a vehicle, including Ethernet, controller area network (CAN), RS-422, RS-485, or any other necessary data bus. The switch can implement one or more services that can configure which workbenches are connected to each other to best suit test objectives and enable maximum utilization of the lab. This can include individual asset testing that traditionally requires standalone test setups and / or purchasing a system of system test.

[0022] FIG. 1 illustrates an exemplary test system 100 for performing vehicle testing, according to one embodiment. In one embodiment, the test system may provide a system integration lab (SIL) for testing components of a vehicle, such as an aircraft. In one example, using avionics, flight control, powertrain, actuation, and flight / cockpit workbenches 120, 130, 150, 160, 170, the test system 100 may include a substantial amount of actual physical hardware from a vehicle that may be provided in a simulated environment. The test system 100 may further include a switch 110 connected to the avionics, flight control, powertrain, actuation, and flight / cockpit workbenches 120, 130, 150, 160, 170. Furthermore, the switch 110 may be connected to a model and simulation system 140.

[0023] In general, avionics workbench 120 includes those related to mission management within the vehicle corresponding to test system 100. In one example, avionics workbench 120 may be responsible for waypoint navigation and receiving and processing sensor data. From a component perspective, first LRU 123 of avionics workbench 120 may include an aircraft management computer (AMC) and one or more of various sensors and navigation equipment installed in the actual aircraft corresponding to test system 100.

[0024] Flight control workbench 130 may include a second LRU 133 that corresponds to a computing device (e.g., a flight control system (FCS)) associated with controlling the aircraft that defines the vehicle corresponding to test system 100. Thus, if a test includes an action corresponding to a pilot pushing the stick left, second LRU 133 of flight control bench 130 corresponds to a component responsible for directing the action by the aircraft necessary for the aircraft to execute a left turn.

[0025] Turning to powertrain workbench 150, third LRU 153 for this workbench may include a dyno, which may be the electrical equivalent of an engine component found on an aircraft or other type of vehicle corresponding to test system 100. In one example, third LRU 153 may correspond to components responsible for moving an aircraft (e.g., driving the aircraft up and forward) defining the vehicle corresponding to test system 100. Additionally, actuators or actuation systems 163 of actuation workbench 160 may encompass flaps found throughout an aircraft defining the vehicle corresponding to test system 100.

[0026] 1 also illustrates connections between switch 110 and possible system expansions 180 of the illustrated test system 100. This may include workbenches that accommodate new components or systems (e.g., auxiliary electric drive systems, additional types of rotors, or landing gear) that may be incorporated into the vehicle that corresponds to test system 100 (or new iterations thereof). As explained below, one advantage of the systems, devices, and methods described herein is that the test system can be easily expanded and potentially tested without having to lock down the rest of the test system.

[0027] 1 may not be limited in type or number to one additional system, component, or workbench. Those skilled in the art will further recognize that system extensions are not limited to known systems, components, or workbenches, but may include systems, components, or workbenches that have not yet been developed for vehicles compatible with test system 100.

[0028] As described herein, each of the first and second LRUs 123, 133, dyno 153, actuator or actuation system 163, or flight / cockpit component 173 may be considered a test asset within test system 100. Additionally, each of the avionics, flight control, powertrain, actuation, and flight / cockpit workbenches 120, 130, 150, 160, 170 may be considered a test asset. Switch 110 provides the flexibility to connect to these different test assets and make different interconnections between them. Furthermore, the switch provides the ability to facilitate simultaneous testing of (1) multiple independent test assets, (2) independent test assets and systems of test assets, and (3) multiple systems of test assets.

[0029] Switch 110 may include multiple ports configured to connect to different types of cables (Ethernet cable, coaxial cable) configured for different communication protocols (e.g., Ethernet, CAN, RS-422, RS-485) as well as configured to receive wireless signals of different communication protocols (WiFi, Bluetooth, NFC, Zigbee, etc.). In one example, switch 110 may include multiple switches (e.g., Ethernet switches) associated with ports to which different cables are connected or ports to which different wireless signals are received. The switch may be configured to recognize one or more types of identifiers (e.g., IP addresses, MAC addresses, or other proprietary LRU identification protocols) for the multiple switches and use the identifiers to route or otherwise connect information between different switches from the multiple switches. In one example, switch 110 may include multiple switches (e.g., Ethernet switches), and a network of multiple switches may be provided within switch 110.

[0030] In one embodiment, the switch 110 may include a test data manager 112, a central automation module 114, a local configuration management (LCM) control 116, and an inter-configuration management (ICM) control 118. In one embodiment, the avionics, flight control, powertrain, actuation, and flight / cockpit workbenches 120, 130, 150, 160, 170 may each include a data server controller as part of their respective bench, powertrain, and actuation controllers 125, 135, 155, 165. The test data manager 112 may be configured to connect to, communicate with, or otherwise receive information from these data server controllers. The test data manager 112 may include a server or servers connected to the switch 110. In another embodiment, the test data manager 112 may be a connection between the switch 110 and a server or servers. The test data manager 112 stores or routes for storage test results from implementations of the test system 100, such as those provided by the data server controllers 125, 135, 155, 165.

[0031] The central automation module may include a computing device integrated within or externally connected to switch 114 and may manage any test automation performed by test system 100. In one example, a test may be initiated by, and in some cases may consist of, direct user interaction with test system 100 and one of the workbenches therein. In other examples, tests implemented by the test system may be managed, initiated, or automated pursuant to other types of instructions communicated by switch 114 to automation controllers in bench, powertrain, and / or actuation controllers 125, 135, 155, 165.

[0032] The LCM control 116 may instruct local configuration management ("LCM") controllers to implement, record, and provide for recording / storage by the LCM control 116, information regarding the configuration of test assets in individual workbenches. Meanwhile, the ICM control 118 may instruct the workbench controllers 125, 1325, 155, 165, 175 to implement, record, and provide for recording by the ICM control 118, information regarding the configuration of test assets connected between workbenches, as well as the connections between target workbenches. Aspects of the LCM and ICM controls, such as those shown in FIG. 1, are provided in more detail with reference to FIG. 4.

[0033] In addition to being physically or otherwise operably coupled to the avionics, flight control, powertrain, actuation, and flight / cockpit workbenches 120, 130, 150, 160, 170, the switch 110 may be connected to a model and simulation system 140. According to the present disclosure, the test system 100, and in particular the switch 110, may enable simultaneous and independent testing of multiple test assets. In situations where multiple test assets being independently tested are connected to another test asset (a common test asset) on the same or different workbenches, the model and simulation system 140 may be utilized by the switch to simulate the common test asset for one of the independent test assets while the other test assets are connected to and tested with the actual common test asset.

[0034] As described above, each of the first and second LRUs 123, 133, dyno 153, actuator or actuation system 163, or flight / cockpit component 173 may be considered a test asset within test system 100. A primary advantage of the systems, devices, and methods described herein is the ability to non-exclusively test these test assets (and test assets yet to be developed) for their respective suitability to correctly or otherwise satisfactorily perform the functional, mechanical, or otherwise operational process that the test asset is intended to perform.

[0035] As used herein with respect to the test systems, switches, and test assets of the present disclosure, "non-exclusively" may correspond to the ability to test a test asset independently of other test assets within a string or system of test assets that includes the test asset. Absent the systems, apparatus, and methods described herein, such a string or system of test assets may typically need to be tested as a whole as a means to test any constituent test assets. Thus, "non-exclusively" may include the testing characteristics of a test asset that does not require testing all other test assets in the respective string or system.

[0036] Separate from or in addition to the functionality immediately described above, "non-exclusively" may correspond to the ability to independently test one test asset without requiring lockdown of the remaining test assets incorporated within a string that includes that test asset, or generally, any other test assets included in a test system. Thus, the systems, devices, and methods described herein enable independent testing of a test asset while (1) other test assets in the test asset's respective system or other systems are independently tested, and / or (2) other systems in the test asset are tested as they would normally be tested as a system, and / or (3) a user-defined system in the test asset is tested.

[0037] FIG. 2 illustrates a flowchart 200 of an exemplary method for building or generating an implementation matrix, according to one embodiment.

[0038] At 210, a switch, such as the example switch 110 shown in Figure 1, can access test assets incorporated into a test system, such as the example test system 100 also shown in Figure 1, and can identify the current configuration of connections between the test assets. In one embodiment, this can include the switch polling an ICM control, such as ICM 118, an LCM control, such as LCM 114, or a CM controller, such as the example CM controller shown in Figure 1, to obtain connection and LRU related information.

[0039] At 220, the switch may evaluate communication protocols for the test assets in the current configuration identified at 210. Specifically, the switch may access LRU-related information, such as corresponding physical component and / or computing device information, from a workbench controller, such as controllers 125, 135, 155, and 165 shown in FIG. 1. A request for information from the switch to the controller may specify the communication protocol as the sought information. The switch may complete this polling of communication protocol information for all test assets in the test system.

[0040] The evaluation of communication protocols may include identifying the communication protocols currently in use between test assets for the current configuration. This may be managed via one or more matrices or databases loaded into the switch as the source of truth. In one example, the evaluation of communication protocols may include identifying the types and requirements for connections to different data buses included in the workbench of the test system.

[0041] At 220, the switch can build a base of information regarding the types of cables connected to various ports of the switch and the type of wireless signal, if any, that any of these ports are receiving. In one embodiment, the switch may determine different types of data buses used by various other components of the test system, such as a workbench. The data bus information can be adapted by the switch to determine the different interfaces (e.g., cable connections) used in the test system and to configure the switch to maintain isolation between these interfaces and drive switching between those interfaces, and more generally, switching between different data buses.

[0042] At 230, the switch may identify misconfigurations based on the communication protocols for the switch and the test assets. In one example, a misconfiguration may include the specification of a connection between two test assets that is incompatible in terms of operation and / or communication protocol. Identification of these misconfigurations may be utilized by the switch to determine and communicate that a requested configuration is invalid and cannot be implemented.

[0043] At 240, the switch may identify a utilization configuration based on the communication protocol. In one example, the utilization configuration may include specifications for alternative connection schemes between two or more test assets currently connected in the current configuration. In another example, at 240, the switch may determine that there are one or more groups of two or more test assets that are connected to or otherwise dependent on a common test asset for testing and operation purposes. The switch may then determine which of the connections between the test assets and the common test asset can be simulated using a model and simulation system, such as model and simulation system 140 shown in FIG. 1 . This information may then be incorporated into the implementation matrix as a utilization scheme at 250.

[0044] At 250, an implementation matrix may be constructed or otherwise created based on the communication protocol information for the test assets, the misconfigurations identified at 230, and the utilization schemes identified at 240. In one embodiment, the implementation matrix may include a type of lookup table that specifies all misconfigurations, standard configurations, and utilization schemes applicable to each test asset in the test system.

[0045] FIG. 3 illustrates a flowchart of an example method 300 for determining or generating a test configuration for a test system.

[0046] At 310, the switch may receive a configuration request specifying the identification of test asset(s) for testing or a configuration of the test system that a user (e.g., a lab operator, an engineer) may desire or that may be required by another switch, workbench, or other type of test asset. In one example, a test asset may be selected and entered at a computing device, for example, by a lab operator. Additionally, the test asset identification received at 310 may specify the type of test to be performed and any hardware, if any, that may be involved. Meanwhile, the configuration request may specify, for example, changing a connection between two test assets, so that one of the tests may be tested in an independent, standalone manner. In another example, the configuration request may specify connecting a test asset that was previously disconnected.

[0047] At 320, the switch may access the current configuration and current asset utilization. Accessing the current configuration may include a similar process as described for the method shown in FIG. 2 at 210. In other embodiments, the switch may utilize a data management service to access current configuration information obtained (1) from an earlier determination of the current configuration or (2) after the last test deployment of the test system including the switch.

[0048] In addition to the current configuration, the current utilization of test assets may be obtained at 320. In one example, this may include identifying all test assets currently being tested and all test assets not being tested, including test assets affected by the test asset specified at 320 or the resulting configuration for the configuration request. As noted above, the systems, devices, and methods described herein enable simultaneous but separate testing of different test assets provided in standalone configurations and / or as strings of subsystems or assets. As described below, the current asset utilization may be used to determine whether the test asset or configuration request specified at 310 can or must complete at the same time as another test or configuration of another test is completed.

[0049] At 330, the switch may evaluate the current configuration based on the current asset utilization and the configuration identified or requested at 310. More specifically, the switch may determine whether changes to the current configuration are necessary to test the identified test asset or the configuration requested at 310.

[0050] At 340, a decision may be made regarding the test configuration based on the evaluation at 330 and the implementation matrix. More specifically, in one example, the evaluation may specify that the current configuration is not usable as a test system to perform tests on the identified test assets or differs from the configuration specified in the configuration request at 310. The implementation matrix may be accessed by the switch in this situation to identify any utilization schemes that may be implemented to satisfy the identification or request received at 310.

[0051] In one example, the test configuration determined at 340 may specify a configuration that may capture improved, near-optimal, or optimal utilization of all test assets of the test system, including not locking down the test system to test one test asset or to implement the configuration of a configuration request.

[0052] At 350, the switch may poll the test assets included in the test configuration determined at 340 to obtain an inventory of which of these test assets include hardware and determine whether that hardware is or will become available to implement the test configuration. Additionally, the switch may perform the same evaluation on test assets that include hardware and are included in potential alternative test configurations using different utilization schemes. In one example, the switch may poll a workbench that includes the hardware incorporating the test assets or access an implementation matrix to look up this information.

[0053] Hardware of a test asset included in the test configuration may be determined to be unavailable at 350, and a switch may be configured to change the test configuration at 355 to utilize simulated hardware for the unavailable hardware.

[0054] For example, referring back to FIG. 1 , a team of powertrain engineers may want to perform one or more standalone tests involving one or more powertrain dynos 153 installed in powertrain workbenches 150. A particular avionics LRU 123 installed in one of avionics workbenches 120 may depend on one or more powertrain dynos 153 and be part of a particular test that the avionics team wants to perform. Alternatively, a particular avionics LRU 123 may be the subject of a standalone test that the avionics team wants to perform on that LRU 123. Similarly, a particular flight control LRU 133 may depend on one or more powertrain dynos 153 and be part of a particular test that the control team wants to perform. Alternatively, a particular flight control LRU 133 may be the subject of a standalone test that the control team wants to perform on those LRUs 133.

[0055] For the example just described, an exemplary switch according to the present disclosure may be implemented according to a test configuration generated in execution of the exemplary method shown in FIG. 3 . Such an implementation may include a switch disconnecting the powertrain workbench 150 from the target avionics and flight control workbenches 120, 130. Additionally, such an implementation may include a switch connecting the avionics and flight control workbenches 120, 130 to a simulation rack containing any simulations necessary to execute or conduct standalone tests involving the avionics or flight control LRUs 123, 133. The ability to simultaneously test the avionics or flight control LRUs 123, 133 may then be maintained without the need for the physical disconnection and reconnection of cables associated with the workbenches and LRUs referenced above for purposes of this example. Thus, as its basic functionality, an exemplary switch according to the present disclosure may complete all network configuration between the workbenches to enable standalone tests for a particular LRU without the need to change the physical connections between the workbenches.

[0056] Once modifications to the test configuration are specified at 355, or once all hardware associated with the original test configuration is determined to be available at 350, a switch may be implemented at 360 according to the test configuration to test the identified test assets or to configure the test system according to the configuration specified in the configuration request at 310.

[0057] FIG. 4 illustrates a sequence diagram of an exemplary method for configuring a test system according to a test configuration, according to one embodiment.

[0058] At 410, the coordination service may receive a request to test a specific test asset within a test system or a request to configure the test system according to a specified configuration. In the case of a request to test a test asset, the test asset in the request may identify one or more individual test assets, one or more workbenches, or a system of test assets being tested. Meanwhile, in the case of a configuration request, the request may specify the configuration of the test asset and / or workbench for implementation. At 412, the coordination service may send the request to a data management service and test data manager of an example switch of the present disclosure.

[0059] In one embodiment, each of the coordination service, data management service, ICM control, and LCM control may be configured by or include an application or agent that executes on the switch or is implemented on the switch, for example, by a processor of the switch. Additionally, each of the coordination and data management services may be part of, or an application or agent configured to be compatible with, a software product that is installed on, or at least partially provided on, the processor of an exemplary switch according to the present disclosure. The software product may provide tools for generating implementation matrices, tools for identifying misconfigurations and utilization schemes, tools for data conversion and formatting, tools for generating components and / or selectable options for a user interface (UI), such as a graphical user interface, tools for supporting selections made via the UI, and any other related features.

[0060] The test data manager may be similar to or a version of the test data manager 112 of the test system 100 shown in FIG. 1. Accordingly, the test data manager shown in FIG. 4 may be configured to connect to, communicate with, or otherwise receive information from a data server controller running within a workbench of the test system. Additionally, the test data manager may include a server or servers connected to a respective switch, or may include a server or servers configured by connections between the switch and the server or servers. The test data manager of FIG. 4 may store or route for storage test results from the test system implementation.

[0061] In one embodiment, the request may be sent to a test data manager at 410 so that the request can be later associated with test results resulting from testing the test assets identified in the request. Similarly, the test request may be sent to a data management service so that it can be later associated with a test configuration to be used in running the test or implementing the configuration specified in the request.

[0062] At 414, the coordination service may access the current configuration and current asset utilization of the test system including the switch that implements the coordination service. As at 320 in the example method shown in FIG. 3, the coordination service may poll the ICM control, LCM control, and / or CM controller to obtain connection- and LRU-related information for the test assets of the test system. In other examples, the coordination service may utilize, request, or instruct the data management service to access current configuration information maintained by the data management service. In one embodiment, the current configuration information sent by the data management service may have been obtained (1) from an earlier determination of the current configuration or (2) since the last test deployment of the test system including the switch.

[0063] At 418, the coordination service may access an implementation matrix for the test system that includes the switch that received the request at 410. In one embodiment, the coordination service may access misconfiguration and utilization scheme information embedded in the implementation matrix to validate the request.

[0064] In one embodiment, the validation at 418 may include determining that the request does not correspond to any misconfiguration represented by information included in the implementation matrix.

[0065] In another embodiment, the validation at 418 may include a coordination service using an implementation matrix to determine that the request corresponds to at least one of a current configuration, a standard configuration that excludes any simulation for the hardware, or a configuration defined by one or more utilization schemes.

[0066] In yet another embodiment, the request is validated at 418 once the coordination service determines that: The request does not correspond to a misconfiguration, but corresponds to a current, standard, or usage scheme configuration; The request corresponds to a misconfiguration, but can be substituted for the purpose of testing or satisfying the configuration request using the configuration of the utilization scheme; - includes hardware that does not address misconfiguration but is currently utilized to perform testing or fulfill another request (meaning that testing of another test asset is currently being performed, but the rest of the test system is not locked down so other testing can be completed), but an equivalent of that hardware can be provided by the model and simulation service; or -A misconfiguration, such as may be the case when a new test asset, system of test assets, or workbench is added to a test system, that does not correspond to the current configuration, the standard configuration, or the configuration defined by the usage scheme, in which case a process such as in the exemplary method shown in Figure 6 and described herein below may be implemented.

[0067] On the other hand, if the request cannot be reconciled with any of the conditions immediately described above, the reconciliation service may generate and communicate to the user device a notification that the request is not valid at 422. The user device may then display or otherwise communicate the notification to a user, such as a lab operator or engineer, another switch, or test asset.

[0068] At 424, the coordination service may determine the test configuration based on the current configuration (accessed at 414), the current test asset utilization, and / or the implementation matrix (accessed at 418), similar to the process of the exemplary method of FIG. 3 at 340. Additionally, the coordination service may determine the test configuration based on the lab schedule. An exemplary switch according to the present disclosure may enable a team of engineers to test and integrate on a system or subsystem of a test system without affecting the work activities of other teams and other teams using the system, the same subsystem, or a different subsystem. This allows engineers to test and integrate the test assets, subsystems, and systems with which their teams typically interact, at the same time as other teams test and test the system / subsystem. Table 1, provided below, illustrates an example of a test system schedule broken down into engineering team schedules with respect to subsystems (e.g., workbenches).

[0069] [Table 1]

[0070] From the information provided in Table 1, one skilled in the art can glean that the systems, devices, and methods of the present disclosure, particularly the exemplary switch described herein, may enable multiple engineering teams to use, test, and modify test assets simultaneously using different configurations of their similar test assets. This contrasts sharply with test systems that do not include a switch according to the present disclosure and therefore lack the level of flexibility that a switch provides. Instead, in a test system lacking a switch, testing a single test asset requires testing, or at least locking down, the entire workbench or suite of test assets that contains the single test asset, as well as locking down all other test assets in the test system (the workbench, suite of test assets, and any other test assets not incorporated into a standalone workbench). As a result, instead of five engineering teams working on the test system at the same time, as in the test system depicted in Table 1 at 9:00 AM, only one team can run tests and work on the test system at the same time. Only one team can run tests and work on a test system that is not equipped with at least any of the exemplary switches of the present disclosure.

[0071] At 428, the coordination service may issue configuration instructions to configure the test system according to the test configuration determined at 422. This may include sending the test configuration and configuration instructions to the data management service, the LCM control, and the ICM control.

[0072] Upon receiving the instructions, the data management service may associate these instructions and test configurations with the test asset(s) being tested, along with test results subsequently generated from implementing the test configurations. Further, the data management service may associate the test configurations, test assets, and test results with test results from any subsequent tests that implement the test configurations with other test assets.

[0073] At 432A, the LCM control may implement the intra-test configuration portion of the configuration instruction issued at 428. Similarly, at 432B, the ICM control may implement the inter-test configuration portion of the instruction issued at 428.

[0074] In one example, implementing the instructions in 432A and 432B may include LCM and ICM controls tracking the implementation of each portion of the test configuration until it is fully implemented. This may include communicating on an iterative basis with the local CM controllers of the workbenches that contain the test assets involved in or affected by the implementation of the test configuration. This may include checking the progress and accuracy of the implemented configuration against the test configuration defined by the coordination service. In another example, implementing the instructions in 432A and 432B may include tracking and recording all aspects of the implementation of each portion of the test configuration.

[0075] In yet another example, implementation of the instructions in 432A and 432B may include the LCM and ICM controls instructing the bench control to connect or disconnect between the test assets and the workbench (in the case of an ICM control) necessary to provide the test configuration.

[0076] Thus, the processes and methods implemented in 432A and 432B may reduce the need for, reduce the amount of labor required for, or completely or partially replace quality assurance testing such as system checkout. Such quality assurance processes may require the physical lockdown of all or part of the test system, and a team of engineers conduct formal testing to ensure that test results are 100% accurate from a hardware and software perspective. This may include engineers reviewing the entire installation documentation and test report line by line to ensure that everything was installed exactly as described in the installation documentation (e.g., all cables are connected exactly as specified). Following a four-month testing campaign, a two- to three-week quality assurance process may occur in which the test system is locked down; if one LRU or other test specification is found to be incorrect, the entire four-month test may be invalidated.

[0077] At 436, the ICM and LCM controls may send notifications to the coordination service that their respective portions of the test configuration have been implemented.

[0078] FIG. 5 illustrates a sequence diagram of an exemplary method for managing test system data including test configuration related information, according to one embodiment.

[0079] At 510, the coordination service can issue a test start command to the automation control, which causes the automation control to begin testing the target asset at stage 514. Tests that can be performed using the test systems and switches of the present disclosure can include testing all test assets together in a mission-like environment. An example of this can include a test involving a test system corresponding to an aircraft and a simulation of the aircraft flying from one location to another. Such a test might involve all test assets operating in conjunction with one another, from takeoff, where the powertrain system boosts the aircraft, to the flight control system rotating all rotors, initiating forward flight, and making all appropriate turns, to the avionics workbench controlling the aircraft to reach different points along the flight path and be at specific altitudes at those points, to final landing, where the entire system of test assets needs to be tested on the entire aircraft. However, prior to the point in the simulation involving landing, an engineer or lab operator may want to test specific in-flight operations that do not involve the entire system. Such a test might involve a flight control system as the aircraft is pointed to go left, up, or right, and a team of engineers may only be interested in seeing if the actuators move in the correct direction when the aircraft is pointed in a particular direction.

[0080] Upon completion or during execution of the test on the target test asset at 518, test results may be sent to the test data manager at 522. The test results may include any, some, or all of: an indication of whether the test was executed or the configuration was implemented; a time value for either the time to complete the test or configuration or any sub-process thereof; and values ​​of any performance metrics associated with the test or configuration, including performance metrics applicable to either the functions or operations performed as part of the test or configuration and the functions or operations performed by any test asset affected by or involved in the test or configuration.

[0081] In one example, the test data manager can request or instruct a data server controller, such as the exemplary data server controller of the test system shown in Figure 1, to transmit the test results when the test results are received. Alternatively, the test data manager can instruct the controller to transmit the test results at the end of any phase of a test being performed or according to a schedule independent of the completion of any test or test phase.

[0082] At 526, the test data manager may send the test results to the data management service and coordination service. Additionally, the test data manager may temporarily store the test results at 526 in a storage device of the switch or via a server. In one example, the test data manager itself may define the storage device. Test results may be stored by the test data manager as a backup provision in case the data management service experiences a problem resulting in data loss. Additionally, the test data manager controls access to these stored test results and can direct their destruction. In another example, the test data manager can destroy test results as directed by the data management service.

[0083] At 528, the coordination service may access the ICM and / or LCM controls to determine whether any configuration transitions were implemented in completing the test or configuration request.

[0084] Configuration transitions may be relevant in situations where multiple teams submit test requests simultaneously, or with little time between them, that include common test assets that may be substituted in the usage scheme of one request but not in the usage scheme of another. This is likely to occur increasingly as engineering teams make greater use of the capabilities provided by the systems, devices, and methods described herein: the ability to simultaneously test different test assets, whether interconnected with different workbenches, provided independently, or incorporated as part of their respective subsystems.

[0085] An example of how a configuration transition may be implemented may include an initial version of a first test configuration that includes a subsystem that is also included in a second test configuration. The first test configuration may be able to implement a utilization scheme that takes into account the unavailability of the subsystem, but such an option is not available in the second test configuration. However, due to the time the respective requests are received at the switch, the initial version of the first test configuration may include the subsystem. The LCM control or ICM control may modify the initial first test configuration to include the utilization scheme so that both test configurations may be implemented simultaneously. Accordingly, information regarding the modification may be accessed or otherwise provided by the ICM control and / or LCM control to the coordination and data management service at 528.

[0086] The coordination service may associate the test results with the test configuration and implementation matrix at 530. In one embodiment, the association may include a comparison of implementation aspects of the test configuration associated with different utilization schemes.

[0087] At 534, the coordination service may send the test or configuration results and any associations determined at 530 to the user device and the data management service. Thus, the user device may display or otherwise communicate the test results and associations at 538.

[0088] At 542, the data management service may process the test results and associations received from the coordination service. The processing at 542 may include organizing, distributing, and / or assigning levels of accessibility to the information received at 542.

[0089] FIG. 6 illustrates a flowchart of an exemplary method for adding test assets to a test system, according to one embodiment.

[0090] At 610, the switch may receive an indication that a new test asset is being added or is being added to a test system including the switch. As described throughout this specification, a test asset may include a single test asset (e.g., an LRU, a powertrain dyno, an actuator, or an actuation system), or a workbench including test assets, or a new string or system operatively connected, or new test assets and existing test assets integrated across multiple workbenches.

[0091] In one example, the instruction received by the switch may be in the form of a new workbench being connected (via a cable) to a port on the switch. In another example, the instruction may come from the switch receiving a request from the test asset, or some form of user interface for sending and / or receiving information from the test asset. In yet another example, the instruction to add a new test asset may be in the form of a communication from an existing workbench to which the new test asset may be connected or embedded.

[0092] At 620, the switch may obtain communication protocol and line replace unit information associated with the new test asset. In one example, the switch performs or has otherwise performed a process similar to the process described as being included in the exemplary method of FIG. 2 at 220.

[0093] At 630, the switch may determine the system configurations of the individual configurations and systems into which the new test assets may be incorporated. In one example, the switch performs or has otherwise performed processes similar to those described as being included in the exemplary method of FIG. 3 at 340 and 355.

[0094] At 640, the switch can determine misconfigurations between the new test asset and individual test assets, workbenches, and switches. In the case of a switch, if the new test asset corresponds to a new workbench or even a new switch, the switch can access all port information of the new component, for example, via a coordination service, and determine whether the ports cannot be connected, either directly or through another asset or bench in the test system.

[0095] Furthermore, regardless of the type of component (eg, individual test assets, workbench, switch, cable), the switch may perform a process similar to that described with respect to the example method of FIG. 2 at 230 .

[0096] At 650, the switches can update their respective implementation matrices to include the new test assets. This may include switches performing some or all of the processes described with respect to the example method of FIG. 2 at 240 and 250. Additionally, the switches may manage the information represented by the implementation matrices, which may be processed and made accessible in a processed format, e.g., as described herein, via a data management service, (A) for later use in the event of complex issues with a test system that includes the switches, or (B) based on needs arising from other activities, such as establishing a new test system, duplicating portions of an existing test system for expansion, etc.

[0097] Those skilled in the art will recognize that an exemplary switch according to the present disclosure, in combination with the exemplary method 600 shown in FIG. 6, can provide a test system with “plug-and-play” functionality for adding or removing various types of test assets from the test system.

[0098] The systems, devices, and methods described herein may provide significant advantages in the context of test systems, particularly in systems-integrated labs for testing vehicles such as aircraft. Using a switch to which essentially all test assets are connected, lab operators / engineering teams may plug and play which test assets and / or which features (hardware or software) of test assets or systems of test assets work together or can be separated. Furthermore, all individual workbenches may be operatively connected to the switch via a coordination service, as described herein. As a result, different test assets, workbenches, or systems of test assets may be added, removed, or isolated from systems of assets included in other test assets, workbenches, or test systems. Thus, the entire system may be tested, or specific test assets may be tested in a standalone manner that does not interfere with the testing of other assets or systems of assets.

[0099] Additionally, individual systems can be easily integrated into a test system, such as test system 100 of FIG. 1, without requiring a redesign of the lab architecture, as described in FIG. 1. Also, switching based on the actions of a coordination service, for example, can eliminate the need for individuals to physically disconnect and connect connectors, reducing the possibility of human error. Furthermore, the systems, devices, and methods described herein may enable improved, near-optimal, or optimal utilization of lab capacity. Individual system testing does not require the lockdown of all other systems in a test system corresponding to a vehicle, such as an aircraft. This potentially allows more engineering teams to work simultaneously.

[0100] 7 illustrates exemplary system components of a test system for a vehicle, such as an aircraft, according to one embodiment. As shown, system components 700 may include a switch 710 and a user device 720, first, second, and third databases 712, 714, 716, and flight control, avionics, powertrain, actuation, and flight / cockpit workbenches 750, 755, 760, 765, 770 (hereinafter referred to as “workbenches 750-770”) connected to or otherwise in communication with switch 710.

[0101] In one example, each of the switch 710, the user device 720, the first, second, and third databases 712, 714, and 716, and the workbenches 750-770 may be, include, or consist of one or more computing devices, each including a processor, memory storage, and a non-transitory computer-readable medium containing instructions executed by the processor. Further, each of the example system components 700 may be configured as a computing device for executing processes according to example embodiments of the present disclosure.

[0102] More specifically, each of the exemplary system components 700 discussed above may be a hardware assembly including, for example, a data communication interface for packet data communication, a central processing unit (CPU) in the form of one or more processors for executing program instructions, an internal communication bus, and a storage unit capable of storing data on a computer-readable medium. Additionally, each of the exemplary system components 700 may receive programming and data via network communication. Furthermore, while any and all of the exemplary system components 700 may have memory (such as RAM) for storing instructions for executing the techniques presented herein, the instructions may also be temporarily or permanently stored in other modules of other system components. Each of the exemplary system components 700 may include input and output ports and / or a display for connecting to input and output devices such as a keyboard, mouse, touchscreen, monitor, display, etc. Various functions may be distributed across many similar combinations of system components to distribute processing loads. Alternatively, a system comprised of the exemplary system components 700 may be implemented by appropriate programming of a single computer hardware platform.

[0103] 8 illustrates an example graphical user interface (GUI) 800 for a test system used to perform various methods described herein. The GUI 800 may display a system identifier 810 above equipment, connection, and port information tables 820, 830, 840. In one example, the system identifier 810 may identify the vehicle that corresponds to the test system represented by the GUI 800.

[0104] As shown, the equipment information table 820 may include a first list 825 of test assets incorporated into the test system of the GUI 800. Note that the first list 825 is a list of workbenches included in the test system of the GUI 800. Note that workbenches include combinations of test assets, systems, or subsystems, but are themselves test assets. In one example, selection of any of the test assets listed in the first list 825 may cause the GUI 800 to display a list of test assets incorporated into the workbenches listed as test assets in the equipment information table 820. In one example, the list of test assets may be displayed within the equipment information table 820. In another example, a second GUI (e.g., a page, a pop-up screen, etc.) may be displayed that includes a list of test assets and specification information for each (e.g., LRU information, connections to other test assets or workbenches).

[0105] 8 , the connection information table 830 may include a second list 835 of items, each item including at least two test assets integrated or otherwise connected within the test system of the GUI 800. In one example, selection of any of the items in the second list 835 may cause the GUI 800 to display additional information about the connection represented by the selected item. In one example, additional information specific to each test asset may be displayed. In another example, information about the connections (e.g., type—cable or signal, communication protocol, status) between the test assets and between the test assets and the switch (port of the switch for or used in the selected connection).

[0106] Port information table 840 may include a third list of test assets 845 and sublists of ports belonging to each test asset 847. Selecting any port in any sublist 847 may trigger information about that port in port information table 840 (e.g., type, other test assets connected to it, status).

[0107] In one example, the information contained in the connection and / or port information tables 830, 840 may be accessed and populated from an implementation matrix maintained by a switch in the test system of the GUI 800.

[0108] 9A-9G illustrate an exemplary GUI of a test system that may be used to perform the various methods described herein.

[0109] 9A shows GUI 900 in a mode that provides for the configuration of test assets for a test system. As shown, the GUI includes lab configuration, lockdown configuration, and print lab configuration options 940, 950, 960 arranged above a message center 970 and below a lab display area 910. Lab display area 910 is arranged below a title bar 912 that may indicate the mode that GUI 900 is currently in. GUI 900 is in the current lab configuration display mode, as indicated by title bar 912 having a current lab configuration mode signal 913.

[0110] 9A shows an exemplary representation of a lab configuration of test assets for an exemplary test system. More specifically, a first test asset grouping 920, a second asset grouping 922A, and a third asset grouping 928 are displayed. Also displayed are a first standalone asset 924 (an operational workbench) and a second standalone asset 926A (a third flight control system workbench or LRU (FSC3)).

[0111] As shown, the first test asset grouping 920 includes a cockpit dome LRU, a second flight control system workbench or LRU (FCS2), and a first avionics workbench or LRU (AV1).

[0112] A second asset grouping 922A includes a first cockpit LRU and a second avionics workbench or LRU (AV2).

[0113] A third grouping 928 includes a first flight control system workbench or LRU (FCS1), a third avionics workbench or LRU (AV3), and a second cockpit LRU.

[0114] According to one aspect of the present disclosure, selecting the lab configuration option 940, as shown in FIG. 9B, causes the GUI 900 to display an authorization entry form 914. According to another aspect of the present disclosure, a user must provide valid credentials to enter the lab configuration mode, as shown in FIG. 9C. Upon entry and validation of user credentials, lab configuration mode is activated, and an example switch according to the present disclosure can record, track, or otherwise document the identity of the user with the changes made to the lab configuration. In one example, this recording of the user can be completed by an example data management service described herein. As a result, the switch can store or access information that a subsequent user or engineering team can use to obtain more information about a particular change to the lab configuration.

[0115] 9C and 9D show GUI 900 in lab configuration mode, which may be presented once the credentials provided in authorization entry form 914 are verified. GUI 900 may display several indicators that configuration mode is active. For example, title bar 912 may include a current lab configuration mode signal 913, and saved versions 945 of lab configuration option 940 may be activated (as indicated by shading and / or text) as shown in FIG. 9C. Additionally, a first message 971 in message center 970 may advise of actions that must be taken regarding the actual physical test system and its test assets.

[0116] The example systems, devices, and methods described herein may provide a platform where a user may submit change requests via a GUI such as GUI 900, and a switch implementing or operatively associated with the GUI may execute the requested configuration changes to an actual test system.

[0117] In one embodiment, a user may drag and drop an element representing a test asset away from a group of elements representing a test asset group, such as the second asset grouping 922A, e.g., separating the selected and moved element from all other elements (test assets) of the original asset grouping. Indeed, such use of GUI 900 may be considered a configuration request, as described with respect to the exemplary methods of FIGS. 3 and 4 at 310 and 410, respectively. Accordingly, once such a change is finalized by selection of save version 945 of lab configuration option 940, an exemplary switch according to the present disclosure that implements or is otherwise operatively associated with GUI 900 may perform various processes of the methods described herein. In particular, the above-described operations using GUI 900 may cause the switch to determine a test configuration and implement the switch according to that test configuration, thereby changing the actual configuration of the test system.

[0118] In addition to the saved version 945 of the lab configuration option 940, Figure 9C also shows a first preliminary configuration change 930 made by a user who selected and moved a second avionics workbench or LRU (AV2) from the second grouping 922A. As shown, the first preliminary configuration change 930 provides third and fourth standalone test assets 922B, 923. This configuration is called preliminary because it is not implemented before, or at least not before, the saved version 945 of the lab configuration option 940 is selected. However, once saved, the first preliminary configuration change 930 may be considered a configuration request, as described with respect to the example methods of Figures 3 and 4 at 310 and 410, respectively.

[0119] Alternatively, or in addition to modifying a previously saved configuration, a user may drag and drop an element of GUI 900 representing a single test asset or a subsystem of test assets to connect it with another element representing a different test asset or subsystem of test assets. For example, FIG. 9D shows a second preliminary configuration change 932 made by a user selecting and moving a first standalone test asset 924 to connect it with a second standalone test asset 926A. As shown, the second preliminary configuration change 932 provides a fourth asset grouping 926B.

[0120] As described above, the save version 945 of the lab configuration option 940 may be selected to save the new configuration defined by the second configuration changes 932 and enable implementation of the new configuration. Selection of the save version 945 of the lab configuration option 940 may be followed by a pop-up indicating the update status. The percentage completed may correspond to the amount of configuration actually implemented within the test system corresponding to the GUI 900. Once the update is complete, a current lab configuration mode signal 913 may be displayed in the title bar 912.

[0121] 9E and 9F show GUI 900 in a lockdown configuration mode that becomes active after selection of lockdown option 950. In one example, lockdown configuration mode may be activated only after a user provides credentials, such as in FIG. 9B. However, in one example, this may be a separate authorization process, independent of any other authorization processes previously implemented. That is, each time configuration lab option 940 or lockdown option 950 is selected, the user must satisfy the authorization process.

[0122] The GUI 900 may display several indicators that lockdown mode is active. For example, the title bar 912 may include a lockdown mode signal 917, and an active version 955 of the lockdown configuration options 955 may be displayed (with shading and / or text) as shown in Figures 9E and 9F. Additionally, a second message 973 in the message center 970 may advise actions that may be taken with respect to the GUI 900.

[0123] In one example, a user may select test assets to lock down, and successful selection of a test asset or group of test assets may be indicated by a change in appearance of the representation of the selected test assets. Figure 9F provides an example. As shown, after the fourth asset grouping 926B has been selected, it is shown in a preliminary lock mode 934 (shaded compared to its appearance in Figure 9E).

[0124] The user can select the active version 955 of the lockdown option 950 after completing the selection of all desired assets, thus verifying that the lockdown action should proceed according to the selections made. Successful registration of the test asset or group of test assets to be locked down may be indicated by another change in the appearance of the representation of the selected test assets. Unlocking a locked-down asset may involve a similar process of asset selection, with the representation of the previously locked test asset returning to its original state, as shown, for example, in FIG. 9A.

[0125] Figure 9G shows the configurations depicted in Figures 9D and 9F, respectively, and the current configuration after completion of the lockdown activities. As shown, the second asset grouping 926B is shown in a locked mode 936 with different shading than the preliminary locked mode 934 shown in Figure 9F.

[0126] In one example, report option 960 may be selected and a report may be generated that includes information about the current lab configuration (test assets, connections, ports, configuration changes). In one example, the system may generate a time-stamped csv file for the report in response to selecting report option 960.

[0127] Program aspects of the technology described herein can be considered a "product" or "article of manufacture," typically in the form of executable code and / or associated data carried on or embodied in some type of machine-readable medium. The "storage" class of media includes tangible memory of a computer, processor, or the like, or any or all of various semiconductor memories, tape drives, disk drives, and other associated modules, which can provide non-transitory storage for software programming at any time. All or portions of the software can be communicated from time to time via the Internet or various other telecommunications networks. Such communication may, for example, enable loading of the software from one computer or processor to another, e.g., from an administrative server or host computer of a mobile communications network to a server computing platform, and / or from a server to a mobile device. Accordingly, other types of media capable of carrying software elements include optical waves, radio waves, and electromagnetic waves, such as those used across physical interfaces between local devices via wired and optical terrestrial communications networks and via various air links. Physical elements carrying such radio waves, e.g., wired or wireless links, optical links, and the like, can also be considered software-bearing media. As used herein, if not limited to non-transitory, tangible "storage" media, terms such as computer or machine "readable medium" refer to any medium that participates in providing instructions to a processor for execution.

[0128] In the foregoing description of exemplary embodiments, it should be understood that various features may be grouped together in a single embodiment, figure, or description thereof for the purpose of simplifying the disclosure and facilitating an understanding of one or more of the various aspects of the disclosure. However, this method of disclosure should not be interpreted as reflecting an intention that the claimed subject matter requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of the disclosure.

[0129] Furthermore, although some embodiments described herein do not include other features included in other embodiments, combinations of features from different embodiments are meant to be within the scope of the present disclosure and form different embodiments, as will be understood by those skilled in the art. For example, in the following claims, any of the claimed embodiments can be used in any combination.

[0130] Thus, while particular embodiments have been described, those skilled in the art will recognize that other and further modifications may be made without departing from the spirit of the invention, and it is intended to claim all such modifications and variations as fall within the scope of this disclosure. For example, functions may be added or deleted from the block diagrams, operations may be interchanged between functional blocks, and steps may be added or deleted to methods described within the scope of this disclosure.

[0131] Other embodiments of the present disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the present disclosure. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.

Claims

1. 1. A method of configuring a test system, comprising: receiving, with a switch, a request including one of an identification of a first test asset of the test system for testing and a configuration request; accessing the current configuration and current test asset utilization of the test system; evaluating the current configuration based on the current test asset utilization and the requirements; determining a test configuration based on the evaluation and an implementation matrix for the test system; and implementing the switch in accordance with the test configuration; The method, wherein implementing the switch includes the switch connecting the test assets according to the test configuration so that a first test on the first test asset or configuration according to the configuration request is performed non-exclusively with respect to the capabilities of the test system implemented to test other test assets.

2. the implementation matrix includes misconfigurations and utilization schemes specific to the test system; The method of claim 1 , wherein the misconfiguration specifies at least two test assets of the test system that cannot be operatively coupled.

3. The method of claim 2 , wherein the utilization scheme specifies at least two test assets that can be operably coupled by two or more consecutively operably coupled test assets.

4. 10. The method of claim 1, further comprising: using the switch to modify the test configuration to include a hardware simulation of at least one test asset in the test configuration based on current utilization of the hardware.

5. implementing the first test on the test asset of the request using the switch; The method of claim 1 , further comprising: using the switch to implement a second test on a second test asset simultaneously with the first test.

6. The method of claim 5 , wherein the first test asset comprises a system of test assets.

7. the first test asset is a single line replaceable unit in a system of test assets that is integrated into an operational workbench or a powertrain workbench; The method of claim 5 , wherein the first test includes configuring the first test asset to be disconnected from the system of test assets.

8. The method of claim 7 , wherein the first test comprises a standalone test of the first test asset.

9. The method of claim 7 , wherein the first test includes connecting the first test asset to a second test asset that is not included in the system of assets.

10. determining that a configuration of the configuration request corresponds to a misconfiguration included in the implementation matrix; issuing a notification that the configuration is invalid; and The method of claim 1 , further comprising: displaying the notification using a computing device.

11. locking down a second test asset of the test system and implementing the first test of the first test asset; The method of claim 1 , wherein the first test asset and the second test asset are incorporated into a first workbench.

12. The method of claim 11 , further comprising implementing a second test of a third test asset embedded in the first workbench during at least a portion of the implementation of the first test.

13. the test system corresponds to an aircraft; The method of claim 1 , wherein the test assets of the test system include an avionics workbench, a flight control system workbench, and a powertrain workbench.

14. 1. A test system for a vehicle, comprising: The test system includes: a plurality of workbenches, each workbench incorporating at least two test assets; the plurality of workbenches; a switch operably coupled to the plurality of workbenches; The switch is a plurality of ports connected to the plurality of workbenches; one or more processors; one or more computer-readable media; the one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform operations; The operation is receiving a request including one of an identification of a first test asset of the test system for testing and a configuration request; accessing the current configuration and current test asset utilization of the test system; evaluating the current configuration based on the current test asset utilization and the requirements; determining a test configuration based on the evaluation and an implementation matrix for the test system; implementing the switch according to the test configuration; tracking changes to the current configuration of the test. Test system.

15. The operation, prior to the receiving, comprises: accessing the plurality of workbenches; identifying misconfigurations among test assets of the test system; The test system of claim 14 , further comprising: incorporating the misconfiguration into the packaging matrix.

16. The operation, prior to the receiving, comprises: further comprising identifying a usage scheme for connecting the test assets across the plurality of workbenches; 16. The test system of claim 15, wherein each of the utilization schemes specifies at least two test assets of the test system that can be operatively coupled by two or more consecutively operatively coupled test assets.

17. The operation is 15. The test system of claim 14, further comprising: using the switch to modify the test configuration to include a hardware simulation of at least one test asset within the test configuration based on current utilization of the hardware.

18. The operation is locking down a second test asset of the test system; and implementing a first test of the first test asset; The test system of claim 14 , wherein the first test asset and the second test asset are installed in a first workbench of the plurality of workbenches.

19. A switch, Multiple ports and one or more processors; one or more computer-readable media; the one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform operations; The operation is receiving a request including one of an identification of a first test asset of the test system for testing and a configuration request; accessing the current configuration and current asset utilization of the test system; evaluating the current configuration based on the current test asset utilization and the requirements; determining a test configuration based on the evaluation and an implementation matrix for the test system; operating in accordance with said test configuration; modifying the test configuration to include a hardware simulation of at least one test asset within the test configuration based on current utilization of the hardware. switch.

20. 20. The switch of claim 19, wherein the plurality of ports includes two of an Ethernet port, an RS-485 port, a CAN port, and an RS-422 port.

Images