System and method for configuring test system

Abstract

A method of 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 a 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 in accordance with the test configuration. Implementing the switch may include the switch connecting a test asset in accordance with the test configuration such that a first test for the first test asset or a configuration in accordance with the configuration request is performed non-exclusively with respect to an ability of the test system to be implemented to test other test assets.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Application No. 63 / 476,582, filed on December 21, 2023, which is incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure relates to systems, apparatus, and methods for configuring test systems. More specifically, the present disclosure relates to systems, apparatus, and methods for configuring test systems implemented for testing vehicles and vehicle systems, such as test systems for testing aircraft and aircraft avionics, flight controls, powertrains, actuators, and cockpit systems, devices, computers, and components.

[0004] introduction

[0005] Test systems, such as system integration laboratories, are typically used to test both hardware and software in complex integrated systems that are incorporated into vehicles (e.g., aircraft, drones, cars, ships, submarines, etc.) as part of the development of these vehicles and prior to their real-world implementation. A test system may include a complex configuration of workbenches (also called test benches) that may include as much hardware as is practicable for a vehicle's subsystems within a laboratory environment.

[0006] In a workbench, hardware and other types of components (e.g., software packages for hardware components) can define line replaceable units ("LRUs"). In addition, a workbench can include LRUs that are interconnected with LRUs in other workbenches. In the context of an aircraft, this can include, for example, an LRU in an avionics workbench (such as an aircraft management computer (AMC)) interconnected with an LRU in another workbench (such as a flight control system (FCS) on a flight console or actuators or actuation systems in an actuator workbench). Complex configurations of interconnected workbenches can enable a test system to bundle together and test simultaneously groups of systems or strings of interconnected LRUs that may be incorporated into a control system being developed for a vehicle.

[0007] In the context of the test system described herein, workbenches and LRUs may provide or otherwise define the test assets of the test system. However, testing of an LRU involving a workbench or interconnected workbenches may require locking down all other parts of the test system. Having to lock down the entire lab to test the functionality of one LRU (one test asset) is not efficient and does not allow for maximum utilization of lab capacity. In fact, it may prevent entire teams of engineers from working simultaneously because any test run for one engineering team may require locking down the entire test system. Working on this issue may involve creating a conflict resolution plan in which only one of several engineering teams can use the test system. Alternatively, an independent workbench can be built to test a single LRU, but this is often an unacceptable proposition from the perspective of cost, time, and / or required labor.

[0008] In addition, laboratory architecture redesign is usually required to integrate additional individual systems into existing test systems. This may require laboratory operators (e.g., engineers) to physically unplug and plug in connectors when changing laboratory components. Physical reconnection may take hours or days to perform and is accompanied by significant risk of human error. In addition, the common methods that engineers use in many technical fields to test the new installation of new systems, devices or components may not be available in the context of test systems corresponding to vehicles. In other words, laboratory operators may not be able to use a method that includes first testing the software that supports the new LRU, then testing the LRU itself, and then testing the LRU and another LRU together to verify the integration between them. Instead, after the laboratory changes, a difficult and time- and labor-intensive quality assurance process (also referred to as a "system check") may be performed to ensure that: (A) no errors occurred during the change process, and (B) the reliability of the test run after the change. Such quality assurance processes may mainly involve manual processes and require days or weeks to perform.

[0009] The present disclosure is directed to overcoming one or more of these aforementioned challenges. Summary of the Invention

[0010] Examples described herein include apparatus, systems, and methods for configuring a test system. In one embodiment, the method for configuring a test system may include receiving, with a switch, a request comprising an identification or configuration request for a first test asset of the test system for testing. The method may also include accessing a current configuration and a 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 connecting, by the switch, the test assets according to the test configuration such that a first test for the first test asset or a configuration according to the configuration request is performed non-exclusively with respect to a capability of the test system to be implemented to test other test assets.

[0011] Various aspects of exemplary switches and methods of implementing switches according to the present disclosure may include one or more of the following features: an implementation matrix may include an error configuration specific to a test system, and it may specify at least two test assets that cannot be operably coupled in the test system; the implementation matrix includes a utilization scheme that specifies at least two test assets that can be operably coupled through more than one series of operably coupled test assets; a method includes modifying a test configuration using a switch to include a simulation of hardware of at least one test asset in the test configuration based on the current utilization of the hardware; a method includes implementing a first test for a requested test asset using the switch and implementing a second test for a second test asset using the switch simultaneously with the first test; the first test asset includes a test asset system; the first test asset is a single line replaceable unit included in a test asset system incorporated in an actuation workbench or a powertrain workbench, and the first test includes configuring the first test asset to be disconnected from the test asset system; the testing of the asset includes an independent test of the test asset; and the first test includes connecting the first test asset to a second test asset that is not included in the asset system.

[0012] Various additional aspects of the example methods described herein may include: a method comprising: determining that a configuration of a configuration request corresponds to an incorrect configuration included in an implementation matrix, issuing a notification that the configuration is invalid, and displaying the notification using a computing device; locking a second test asset of a test system and implementing a first test of a first test asset, wherein the first test asset and the second test asset are incorporated into a first workbench; during at least a portion of the implementation of the first test of the first test asset, implementing a second test of a third test asset incorporated into the first workbench; and 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.

[0013] Examples described herein include a test system that may correspond to a vehicle and may include a plurality of workstations, each workstation incorporating at least two test assets, and a switch operably coupled to the plurality of workstations. In one example, the switch may include a plurality of ports connected to the plurality of workstations, one or more processors, and 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. In various examples described herein, the operations may include: receiving, with the switch, a request comprising one of an identification of a first test asset of the test system for testing 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.

[0014] Various aspects of the exemplary test system described herein may include operations comprising: accessing multiple workbenches, identifying misconfigurations between test assets of the test system, and incorporating the misconfigurations into an implementation matrix; identifying utilization schemes for connecting test assets across multiple workbenches, such that each of the utilization schemes can specify at least two test assets of the test system, which can be operably coupled through more than one series of operably coupled test assets; modifying a test configuration using a switch to include a simulation of hardware based on a current utilization of the hardware of at least one test asset in the test configuration; and locking a second test asset of the test system and implementing a first test of the first test asset, such that the first test asset and the second test asset are incorporated into a first workbench among the multiple workbenches.

[0015] Examples described herein include an exemplary switch having a plurality of ports, one or more processors, and one or more computer-readable media comprising instructions. In various examples of the present disclosure, the instructions, when executed by the one or more processors, may cause the one or more processors to perform the following operations: receive a request comprising one of an identification of a first test asset of a test system for testing and a configuration request; access a current configuration and current test asset utilization of the test system; evaluate the current configuration based on the current test asset utilization and the request; determine a test configuration based on the evaluation and an implementation matrix for the test system; perform operations according to the test configuration; and modify the test configuration to include a simulation of hardware of at least one test asset in the test configuration based on the current utilization of the hardware.

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

[0017] 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.

[0018] 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. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] 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.

[0020] Figure 1 An exemplary testing system for performing vehicle testing is depicted, according to one embodiment.

[0021] Figure 2 Depicted is a flow diagram of an example method for constructing or generating an implementation matrix according to one embodiment.

[0022] Figure 3 Depicted is a flow chart of an example method for determining or generating a test configuration for a test system, according to one embodiment.

[0023] Figure 4 Depicted is a sequence diagram of an example method for configuring a test system according to a test configuration, according to one embodiment.

[0024] Figure 5 Depicted is a sequence diagram of an example method for managing data for a test system including test configuration related information according to one embodiment.

[0025] Figure 6 Depicted is a flow diagram of an example method for adding test assets to a test system according to one embodiment.

[0026] Figure 7 Depicted are exemplary system components of a test system for a vehicle, such as an aircraft, according to one embodiment.

[0027] Figure 8 Depicted is an example graphical user interface ("GUI") of a testing system that may be used to perform the various methods described herein.

[0028] Figures 9A-9G Depicted is an example GUI for a test system that can be used to perform the various methods described herein. DETAILED DESCRIPTION

[0029] The foregoing summary and the following detailed description are exemplary and explanatory only and do not limit the claimed features. As used herein, the terms "comprises," "comprising," "has," "having," "includes," "including," or other variations thereof are intended to encompass a non-exclusive inclusion such that a process, method, article, or apparatus that includes a list of elements includes not only those elements but may also include other elements not expressly listed or inherent to such process, method, article, or apparatus. In this disclosure, unless otherwise indicated, relative terms such as, for example, "about," "substantially," and "approximately" are used to indicate a possible variation of ±10% on the stated value. In this disclosure, unless otherwise indicated, any numerical value may include a possible variation of ±10% on the stated value.

[0030] Even when used in conjunction with the detailed description of certain specific examples of the present disclosure, the terms used below should be interpreted in their broadest reasonable manner. In fact, certain terms may even be emphasized below; however, any term that is intended to be interpreted in any restrictive manner will be so openly and specifically defined in the detailed description section.

[0031] Various embodiments of the present disclosure are generally directed to exemplary switches and methods of implementing these switches to enable a test lab environment to adapt to changing test requirements without physical reconfiguration of the lab. All individual systems of a vehicle corresponding to a single lab can be connected to an exemplary switch of the present disclosure. The switch can have physical connections found on an actual version of the vehicle, including Ethernet, controller area network ("CAN"), RS-422, RS-485, or any other desired data bus. The switch can implement one or more services that can configure which workstations are connected to each other to best suit the testing purposes and allow for maximum utilization of the lab. This can include individual asset testing, which traditionally requires the purchase of separate test equipment and / or systems for system testing.

[0032] Figure 1An exemplary test system 100 for performing vehicle testing is depicted, according to one embodiment. In one embodiment, the test system can provide a system integration laboratory ("SIL") for testing components of a vehicle, such as an aircraft. In one example, the test system 100 can include a large amount of actual physical hardware from a vehicle that can be provided in a simulated environment through avionics, flight controls, powertrain, actuation, and flight / cockpit workstations 120, 130, 150, 160, 170. The test system 100 can further include a switch 110 connected to the avionics, flight controls, powertrain, actuation, and flight / cockpit workstations 120, 130, 150, 160, 170. Additionally, the switch 110 can be connected to a model and simulation system 140.

[0033] Generally speaking, the avionics workstation 120 includes everything related to mission management within the vehicle corresponding to the test system 100. In one example, the avionics workstation 120 may be responsible for waypoint navigation and receiving and processing sensor data. From a component perspective, the first LRU 123 for the avionics workstation 120 may include one or more of the following: an aircraft management computer ("AMC"), and various sensors and navigation equipment installed on the actual aircraft corresponding to the test system 100.

[0034] Flight control console 130 may include a second LRU 133 corresponding to a computing device (e.g., a flight control system (“FCS”)) associated with an aircraft that controls a vehicle corresponding to test system 100. Thus, if the test involves an action corresponding to a pilot pushing a stick to the left, second LRU 133 of flight control console 130 would correspond to those components responsible for directing the aircraft through the aircraft to execute the action required to turn left.

[0035] Turning to the powertrain station 150, the third LRU 153 for this station can include a dynamometer, which can be the electrical equivalent of the components of the engine found on the aircraft or other type of vehicle corresponding to the test system 100. In one example, the third LRU 153 can correspond to those components responsible for moving the aircraft (e.g., driving the aircraft up and forward) that defines the vehicle corresponding to the test system 100. Additionally, the actuators or actuation system 163 of the actuation station 160 can encompass the flaps found throughout the aircraft that defines the vehicle corresponding to the test system 100.

[0036] Figure 1Also depicted is a connection between switch 110 and a representation of possible system expansions 180 for test system 100. This could include workstations corresponding to new components or systems (e.g., supplemental electric drive systems, additional types of rotors, or landing gear) that can be incorporated into a vehicle corresponding to test system 100 (or new iterations thereof). As discussed below, one advantage of the systems, apparatus, and methods described herein is that a test system can be easily expanded and potentially tested without locking down the rest of the test system.

[0037] Those skilled in the art will recognize that Figure 1 The system expansion 180 depicted in FIG. 1 may not be limited in type or number to one additional system, component, or workstation. A person of ordinary skill will further recognize that system expansion is not limited to known systems, components, or workstations, but also includes yet-to-be-developed systems, components, or workstations for vehicles corresponding to the test system 100.

[0038] As described herein, each of the first and second LRUs 123, 133, the dynamometer 153, the actuator or actuation system 163, or the flight / cockpit assembly 173 can be considered a test asset within the test system 100. Furthermore, each of the avionics, flight controls, powertrain, actuation, and flight / cockpit workstations 120, 130, 150, 160, 170 can be considered a test asset. The switch 110 provides the flexibility to connect these different test assets and to make different interconnections between these different test assets. Further, the switch provides the ability to facilitate simultaneous testing of: (1) multiple test assets in isolation; (2) test assets and test asset systems in isolation; and (3) multiple test asset systems.

[0039] The switch 110 may include multiple ports configured to connect to different types of cables (Ethernet cables, coaxial cables) configured for different communication protocols (e.g., Ethernet, CAN, RS-422, RS-485) and to receive wireless signals of different communication protocols (e.g., WiFi, Bluetooth, NFC, Zigbee, etc.). In one example, the switch 110 may include multiple switches (e.g., Ethernet switches) associated with ports to which different cables are connected or 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 information between different switches from the multiple switches or otherwise connect different switches from the multiple switches together. In one example, the switch 110 may include multiple switches (e.g., Ethernet switches) so that multiple switch networks can be provided within the switch 110.

[0040] In one embodiment, 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, each of the avionics, flight control, powertrain, actuation, and flight / cockpit workstations 120, 130, 150, 160, 170 may include a data server controller as part of the corresponding station, powertrain, and actuation controllers 125, 135, 155, 165. Test data manager 112 may be configured to connect to, communicate with, or otherwise receive information from these data server controllers. Test data manager 112 may include a server or server group connected to switch 110. In another embodiment, test data manager 112 may be a connection between switch 110 and the server or server group. Test data manager 112 stores or routes test results provided from data server controllers 125, 135, 155, 165 for storage, from implementations of test system 100.

[0041] The central automation module may include a computing device integrated within or externally connected to the switch 114 and may manage any test automation performed by the test system 100. In one example, certain tests may be initiated by, and may consist of, direct user actions directed to the test system 100 and one of the workstations therein. In other examples, the tests implemented by the test system may be automated based on management, activation, or other types of commands communicated by the switch 114 to automation controllers of the workstations, powertrains, and / or actuator controllers 125, 135, 155, 165.

[0042] LCM control 116 can direct local configuration management ("CM") controllers to implement, record, and provide information about the configuration of test assets of individual workstations for recording / storage by LCM control 116. On the other hand, ICM control 118 can direct workstation controllers 125, 1325, 155, 165, 175 to implement, record, and provide information about the configuration of test assets connected between workstations and the connections between subject workstations for recording by ICM control 118. Figure 4 Provides LCM and ICM control in more detail (such as Figure 1 Aspects of LCM and ICM control) as depicted in .

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

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

[0045] As used herein with respect to the test systems, switches, and test assets of the present disclosure, "non-exclusively" can correspond to the ability to test a test asset in isolation from other test assets in a string or system of test assets that includes the test asset. Without the systems, apparatus, and methods described herein, such a string or system of test assets would typically have to be tested as a whole as a means of testing any of the constituent test assets. Thus, "non-exclusively" can encompass the feature that testing of one test asset does not require testing of all other test assets in the corresponding string or system.

[0046] Separately or in addition to the capability just described above, "non-exclusively" can correspond to the ability to test a test asset in isolation without locking out the remaining test assets incorporated into the string that includes the one test asset or any other test assets generally included in the test system. Thus, the systems, apparatus, and methods described herein enable testing a test asset in isolation while: (1) testing other test assets of the corresponding or other test asset systems in isolation; and / or (2) testing other test asset systems as they would generally be tested as a system; and / or (3) testing a user-defined test asset system.

[0047] Figure 2 A flowchart 200 is depicted of an example method for constructing or generating an implementation matrix according to one embodiment.

[0048] At 210, a switch (such as Figure 1 The exemplary switch 110 depicted in FIG. 1 may access a test system such as Figure 1 114), or a CM controller (such as an ICM 118). Figure 1 ) to obtain connection and LRU related information.

[0049] At 220, the switch may evaluate the communication protocol for the test asset in the current configuration identified at 210. Specifically, the switch may receive a command from a workstation controller such as Figure 1 The controllers (depicted) 125, 135, 155, 165) access LRU-related information, such as corresponding physical components and / or computing device information. Information requests from switches to controllers can specify a communication protocol as the information being sought. The switches can perform this polling of communication protocol information for all test assets in the test system.

[0050] Evaluation of communication protocols can include identifying the communication protocols currently used between test assets for the current configuration. This can be managed using individual or series matrices or databases loaded into the switches as a source of truth. In one example, evaluation of communication protocols can include identifying the connection types and requirements to the various data buses included in the test system's workstations.

[0051] At 220, the switch can build a library of information about the types of cables connected to the various ports of the switch and what type of wireless signals (if any) any of these ports are receiving. In one embodiment, the switch can determine the different types of data buses employed by various other components of the test system (such as a workbench). The switch can use this data bus information to determine the different interfaces (e.g., cable connections) employed in the test system and configure the switch to maintain separation between these interfaces in order to drive switching between them and, more generally, between different data buses.

[0052] At 230, the switch can identify misconfigurations based on the communication protocol used by the switch and the test asset. In one example, a misconfiguration can include specifying that the connection between the two test assets is incompatible from an operational and / or communication protocol perspective. The switch can use the identification of these misconfigurations to determine and communicate that the requested configuration is invalid and cannot be implemented.

[0053] At 240, the switch may identify a utilization configuration based on the communication protocol. In one example, the utilization configuration may include a specification of 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 a common test asset or otherwise rely on a common test asset for testing and operational purposes. In turn, the switch may 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 Figure 1 The model and simulation system 140 depicted in FIG. In turn, at 250 , this information can be incorporated into an implementation matrix as an utilization scenario.

[0054] 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 exploit scenarios identified at 240. In one embodiment, the implementation matrix may include a type of lookup table that specifies all misconfigurations, standard configurations, and exploit scenarios applicable to each test asset of the test system.

[0055] Figure 3 A flow chart of an example method 300 for determining or generating a test configuration for a test system is depicted.

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

[0057] At 320, the switch may access the current configuration and current asset utilization. Accessing the current configuration may include Figure 2 A similar process as described in the method depicted in at 210. In other examples, the switch may utilize a data management service to access current configuration information obtained: (1) from an earlier determined then-current configuration, or (2) after the last test implementation of a test system including the switch.

[0058] In addition to the current configuration, the current utilization of the test assets can also be obtained at 320. In one example, this can include identifying all test assets currently being tested and test assets not being tested, including the test assets specified at 320 or test assets affected by the resulting configuration for the configuration request. As described above, the systems, apparatus, and methods described herein enable simultaneous but separate testing of different test assets provided in independent configurations and / or as part of an asset system or string. As discussed below, the current asset utilization can be used to determine whether the test assets or configuration request specified at 310 can or must be completed concurrently with the completion of another test or configuration of one or more tests.

[0059] At 330, the switch can evaluate the current configuration based on the current asset utilization and the test asset or requested configuration identified at 310. More specifically, the switch can determine whether the current configuration needs to be modified to test the test asset or requested configuration identified at 310.

[0060] At 340, a test configuration can be determined based on the evaluation and implementation matrix at 330. More specifically, in one example, the evaluation can specify that the current configuration is not available for the test system to perform the test of the identified test asset or is different from the configuration specified in the configuration request at 310. In this case, the implementation matrix can be accessed by the switch to identify any utilization scenarios that can be implemented to satisfy the identification or request received at 310.

[0061] In one example, the test configuration determined at 340 may specify a configuration that captures improved, near-optimal, or optimal utilization of all test assets of the test system. This includes configurations that do not lock the test system to test one test asset or implement a configuration request.

[0062] At 350, the switch can poll the test assets included in the test configuration determined at 340 to inventory which of these test assets include hardware and determine whether the hardware is available or will be available to implement the test configuration. Furthermore, the switch can perform the same evaluation on test assets that include hardware and on test assets included in potential alternative test configurations using different utilization scenarios. In one example, the switch can poll the workbench that includes the hardware that incorporates the test assets, or access an implementation matrix and look up this information.

[0063] At 350 , it may be determined that hardware of a test asset involved in the test configuration is unavailable, and at 355 , a switch may be configured to modify the test configuration to utilize simulated hardware in place of the unavailable hardware.

[0064] For example, refer back Figure 1, the powertrain engineer team may want to perform one or more independent tests involving one or more powertrain dynamometers 153 incorporated into the powertrain workbench 150. Certain avionics LRUs 123 incorporated into one of the avionics workbenches 120 may be dependent on one or more powertrain dynamometers 153 and be part of certain tests that the avionics team wants to perform. Alternatively, certain avionics LRUs 123 may be the subject of independent tests that the avionics team wants to perform on those LRUs 123. Similarly, certain flight control LRUs 133 may be dependent on one or more powertrain dynamometers 153 and be part of certain tests that the controls team wants to perform. Alternatively, certain flight control LRUs 133 may be the subject of independent tests that the controls team wants to perform on those LRUs 133.

[0065] For the example just described above, we can Figure 3 An exemplary switch according to the present disclosure may be implemented using a test configuration generated by executing the example method described in

[15] . Such an implementation may involve a switch disconnecting the powertrain workstation 150 from the subject avionics and flight control workstations 120, 130. Furthermore, such an implementation may include a switch connecting the avionics and flight control workstations 120, 130 to a simulation rack that includes any simulations required to run or conduct independent tests involving the avionics or flight control LRUs 123, 133. Consequently, the ability to simultaneously test the avionics or flight control LRUs 123, 133 may be retained without requiring the physical disconnection and reconnection of cables associated with the workstations and LRUs referenced above for the purposes of this example. Thus, an exemplary switch according to the present disclosure may, as its primary function, perform all network configurations between the workstations to independently test executables for specific LRUs without having to modify the physical connections between the workstations.

[0066] Once modifications to the test configuration are specified at 355, or it is determined at 350 that all hardware associated with the original test configuration is available, switches may be implemented at 360 based on the test configuration to complete a configuration that may be implemented for: testing the identified test assets; or configuring the test system based on the configuration specified in the configuration request at 310.

[0067] Figure 4 Depicted is a sequence diagram of an example method for configuring a test system according to a test configuration, according to one embodiment.

[0068] At 410, the coordination service may receive a request to test a test asset in a test system or to configure the test system according to a specified configuration. In the case of a request to test a test asset, the requested test asset may be one or more individual test assets, one or more workbenches, or a system of test assets that may be identified as being tested. On the other hand, in the case of a request to configure, the request may specify a configuration of the test assets and / or workbenches for implementation. At 412, the coordination service may transmit the request to the data management service and test data manager of the exemplary switch of the present disclosure.

[0069] In one example, each of the coordination service, data management service, ICM control, and LCM control can be comprised of or include an application or agent that is executed on the switch, for example, by a processor of the switch, or otherwise implemented. Furthermore, each of the coordination service and data management service can be an application or agent that can be part of or configured to be compatible with a software product installed on or provided at least in part by a processor of an exemplary switch according to the present disclosure. The software product can provide tools for generating an implementation matrix, identifying misconfigurations and exploitation scenarios, data conversion and formatting, generating components and / or selectable options for a user interface ("UI") such as a graphical user interface, supporting selections made through the UI, and any other related features.

[0070] The test data manager can be similar to Figure 1 , or a version thereof. Figure 4 The test data manager depicted in the foregoing can be configured to connect to, communicate with, or otherwise receive information from a data server controller operating within a workstation of a test system. Furthermore, the test data manager can include a server or server group connected to a corresponding switch, or consist of a connection between a switch and a server or server group. Figure 4 The test data manager may store or route test results from an implementation of a test system for storage.

[0071] In one example, the request can be transmitted to a test data manager at 410 so that the request can later be associated with test results from testing of the test asset identified in the request. Likewise, the test request can be transmitted to a data management service so that it can later be associated with a test configuration for conducting the test or implementing the configuration specified in the request.

[0072] At 414, the coordination service may access the current configuration and current asset utilization of the test system including the switches implementing the coordination service. Figure 3At 320 of the depicted exemplary method, the coordination service can poll the ICM control, the LCM control, and / or the CM controller to obtain connection and LRU-related information for test assets of the test system. In other examples, the coordination service can utilize, request, or direct the data management service to access current configuration information maintained by the data management service. In one embodiment, the current configuration information transmitted by the data management service can be obtained by: (1) from an earlier determined then-current configuration, or (2) after the last test of the test system including the switch was performed.

[0073] At 418, the coordination service may access an implementation matrix of the test system including the switch that received the request at 410. In one example, the coordination service may access misconfiguration and exploit scenario information incorporated into the implementation matrix and validate the request.

[0074] In one embodiment, the verification at 418 may include determining that the request does not correspond to any incorrect configuration indicated by the information included in the implementation matrix.

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

[0076] In yet another embodiment, the request may be validated at 418 when the coordination service determines:

[0077] - the request does not correspond to a misconfiguration, but does correspond to a current, standard, or exploit scenario configuration;

[0078] - the request does correspond to an incorrect configuration, but the configuration of the exploit scenario can be used instead for the purpose of testing or fulfilling the configuration request;

[0079] - does not correspond to a misconfiguration, but does involve hardware currently being used to execute tests or fulfill a different request (meaning that testing of another test asset is currently ongoing, but the rest of the test system is not locked so other tests can be completed), but an equivalent for that hardware can be provided by the Model and Simulation Service; or

[0080] - does not correspond to a misconfiguration, a current configuration, a standard configuration, or a configuration defined by an exploit scenario, as might be the case where a new test asset, test asset system, or workbench is added to the test system, in which case the following may be achieved: Figure 6 The process at the exemplary method is depicted and described below.

[0081] On the other hand, if the request cannot be consistent with any of the conditions just described above, the coordination service can generate and communicate to the user device a notification that the request is invalid at 422. In turn, the user device can display or otherwise communicate the notification to a user, such as a lab operator or engineer, other switch, or test asset.

[0082] At 424, the coordination service may determine a test configuration based on the current configuration (as accessed at 414), the current test asset utilization, and / or the implementation matrix (as accessed at 418), similar to Figure 3 The exemplary method of the process at 340. In addition, the coordination service can determine the test configuration based on the lab schedule. The exemplary switch according to the present disclosure can enable an engineering team to test and integrate on a system or subsystem of a test system without affecting other teams and their activities on the system, the same subsystem, or different subsystems. This can allow those other teams to test and allow the system / subsystem to be tested at the same time as the test assets, subsystems, and systems that the engineer test and integration team typically interacts with. Table 1, provided below, provides an example test system schedule that is broken down into engineering team schedules relative to subsystems (e.g., workbenches).

[0083] Table 1 – Engineering team timeline for working with the test system

[0084]

[0085] One of ordinary skill in the art can glean from the information provided in Table 1 that the systems, apparatus, and methods of the present disclosure, and in particular the exemplary switches described herein, enable multiple engineering teams to simultaneously use, test, and modify similar test assets by utilizing different configurations of those similar test assets. This is in stark contrast to test systems that do not include switches according to the present disclosure and therefore lack the level of flexibility provided by such switches. Instead, in those test systems that lack switches, testing a single test asset requires testing or at least locking down the entire workbench or string of test assets that includes the single test asset, and in addition requires locking down all other test assets of the test system (workbench, string of test assets, and any other test assets not incorporated into a separate workbench). Thus, instead of five engineering teams working with a test system (such as the test system shown in Table 1 at 9:00 AM) during the same hour, only one team is able to run tests and work with a test system that is not equipped with at least any of the exemplary switches of the present disclosure.

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

[0087] Upon receiving the instructions, the data management service can associate the instructions and the test configuration with the test asset to be tested, in addition to the test results later generated from the implementation of the test configuration. Furthermore, the data management service can associate the test asset and test results with the test configuration, along with test results from any subsequent tests that implement the test configuration against other test assets.

[0088] At 432A, LCM control may implement the intra-test configuration portion of the configuration instructions issued at 428. Likewise, at 432A, ICM control may implement the inter-test configuration portion of the instructions issued at 428.

[0089] In one example, implementation of the instructions at 432A and 432B may include the LCM and ICM controlling tracking of the implementation of the respective portions of the test configuration until fully implemented. This may include repeated communication with a local CM controller of a workstation that includes test assets that are included in or otherwise affected by the implementation of the test configuration. This may include checking the progress and correctness of the configuration being implemented relative to the test configuration defined by the coordination service. In another example, implementation of the instructions at 432A and 432B may include tracking and logging every aspect of the implementation of the respective portions of the test configuration.

[0090] In yet another example, implementation of the instructions at 432A and 432B may include the LCM and ICM controlling the console control to connect or disconnect between the test assets and the workbench (in the case of ICM control) required to provide the test configuration.

[0091] Thus, the processes and methods performed at 432A and 432B can reduce the need for quality assurance testing (such as system checks), reduce the labor required for quality assurance testing, or replace quality assurance testing in whole or in part. Such quality assurance processes as described above may require physical locking down of all or part of the test system and a team of engineers performing formal testing to ensure that the test results are 100% accurate from a hardware and software perspective. This may involve an engineer reviewing the entire installation documentation and test result reports line by line to ensure that everything was installed exactly as specified in the installation documentation (e.g., every cable was put together exactly as specified). After four months of testing activities, the quality assurance process may take two to three weeks, wherein the test system is locked down, and if one LRU or other test specification is found to be incorrect, the entire four months of testing may be invalidated.

[0092] At 436 , the ICM and LCM controls may transmit a notification to the coordination service that the respective portions of the test configuration have been implemented.

[0093] Figure 5Depicted is a sequence diagram of an example method for managing data for a test system including test configuration related information according to one embodiment.

[0094] At 510 , the coordination service may issue a test start command to the automation control, which causes the automation control to initiate testing of the target asset at stage 514 . Testing that can be performed using the test system and switches of the present disclosure may include testing all test assets together in a mission-like environment. An example of this may include a test system corresponding to an aircraft, where testing involves simulating the aircraft flying from one location to another. Such testing may involve each test asset working in conjunction with one another: from takeoff, where the powertrain propels the aircraft upward; to the flight control system, which rotates all rotors, initiates forward flight, and performs all appropriate turns; to the avionics workstation, which controls the aircraft to various points along the flight path and reaches certain altitudes at those points; and finally, landing, which requires testing the entire test asset system as a complete aircraft. However, before the point in the simulation involving landing, engineers or lab operators may want to test certain flight maneuvers that don't involve the entire system. Such testing may involve the flight control system, where the aircraft is commanded to fly left, up, or right—when the aircraft is commanded to a specific direction, the engineering team may only be interested in seeing whether the actuators move in the correct direction.

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

[0096] In one example, the test data manager may request or direct a data server controller (such as Figure 1 ) transmits test results as those controllers receive them. Alternatively, the test data manager can direct the controllers to transmit test results at the end of any phase of testing being performed, or according to a schedule that is independent of the completion of any test or test phase.

[0097] At 526, the test data manager may transmit the test results to the data management service and the coordination service. Furthermore, at 526, the test data manager may temporarily store the test results in a storage device of the switch or via a server. In one example, the test data manager itself may define the storage device. The test data manager may store the test results as a backup in the event that the data management service encounters an issue involving data loss. Furthermore, the test data manager may control access to these stored test results and direct the discarding of these stored test results. In another example, the test data manager may discard the test results at the direction of the data management service.

[0098] 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.

[0099] Configuration transitions may be related to situations where multiple teams submit test requests simultaneously or within a short timeframe, involving common test assets that can be replaced with an exploit solution for one request but not for another. This situation may become increasingly common as engineering teams increasingly utilize the capabilities provided by the systems, apparatus, and methods described herein. That is, the ability to test different test assets simultaneously, regardless of whether they are interconnected with different workbenches, provided in isolation, or incorporated as part of corresponding subsystems.

[0100] An example of a configuration transition that 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 an utilization scenario to account for subsystem unavailability, while this option is not provided for the second test configuration. However, due to the timing when the corresponding request is received at the switch, the initial version of the first test configuration may include the subsystem. The LCM control or the ICM control may modify the initial first test configuration to include the utilization scenario so that both test configurations can be implemented simultaneously. Therefore, at 528, the ICM control and / or the LCM control may access information about the modification or otherwise provide the information to the coordination service and the data management service.

[0101] The coordination service can correlate the test results with the test configuration and the implementation matrix at 530. In one embodiment, the correlation can include a comparison of aspects of the implementation of the test configuration relative to different utilization scenarios.

[0102] At 534, the coordination service can transmit the test or configuration results and any associations determined at 530 to the user device and the data management service. Accordingly, the user device can display or otherwise communicate the test results and associations at 538.

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

[0104] Figure 6 Depicted is a flow diagram of an example method 600 for adding test assets to a test system, according to one embodiment.

[0105] At 610, the switch may receive an indication that a new test asset has been or is being added to the test system that includes the switch. As discussed throughout this document, the test asset may include a single test asset (e.g., an LRU, a powertrain dynamometer, an actuator, or an actuation system), or a workstation that includes test assets, or a new string or system of new test assets that are operatively connected, or new and existing test assets that are incorporated across multiple workstations.

[0106] In one example, the indication received by the switch can be in the form of a new workstation being connected to a port of the switch (via a cable). In another example, the indication can come via the switch receiving a request from the test asset or some form of user interface for transmitting and / or receiving information with the test asset. In yet another example, the indication to add a new test asset can take the form of a communication from an existing workstation, to which the new test asset can be connected or incorporated.

[0107] At 620, the switch may obtain communication protocol and line replacement unit information associated with the new test asset. In one example, the switch may perform or otherwise have performed a Figure 2 The exemplary method includes a process similar to the process described at 220 .

[0108] At 630, the switch may determine individuals and systems in the system configuration into which the new test asset may be incorporated. In one example, the switch may perform or otherwise have performed a Figure 3 The exemplary method includes processes similar to those described at 340 and 355 .

[0109] At 640, the switch may determine misconfigurations between the new test asset and individual test assets, workstations, and even switches. In the case of a switch, where the new test asset corresponds to a new workstation or even a new switch, the switch may access all port information for the new component, for example, through a coordination service, and determine if any of its ports cannot be connected directly or through another asset or station of the test system.

[0110] Furthermore, regardless of component type (e.g., individual test assets, workbenches, switches, cables), switches can perform the same Figure 2 The exemplary method is similar to the process discussed at 230 .

[0111] At 650, the switch may update the corresponding implementation matrix to cover the new test asset. This may include the switch performing Figure 2 The exemplary method may include some or all of the processes described at 240 and 250. In addition, the switch may manage the information represented by the implementation matrix through a data management service, e.g., processed as described herein, and may access it in processed form: (A) for later use when complications arise with a test system including the switch; or (B) based on requirements resulting from other activities, such as establishing a new test system, duplicating a portion of an existing test system for expansion thereof, etc.

[0112] One of ordinary skill in the art will recognize that exemplary switches according to the present disclosure are Figure 6 In combination with the exemplary method 600 depicted in FIG. 6 , a “plug and play” capability can be provided to a test system to add or remove various types of test assets to or from the test system.

[0113] The systems, devices and methods described herein can provide significant benefits in background testing of test systems, particularly in system integration labs for testing vehicles (such as aircraft). The lab operator / engineering team can plug and play which test assets and / or which features (hardware or software) of test assets or test asset systems work together, or separate them using a switch to which substantially all test assets are connected. In addition, all individual workbenches can be operatively connected to the switch via the coordination service described herein. As a result, different test assets, workbenches or test asset systems can be added, released or isolated from other test assets, workbenches or asset systems included in the test system. Thus, the entire system can be tested, or certain test assets can be tested in an independent manner, which does not preclude testing of other assets or asset systems.

[0114] Furthermore, individual systems can be easily integrated into test systems such as Figure 1 In addition, the switching of operations based on the coordination service can, for example, eliminate the need for individuals to physically unplug and plug connectors, thereby reducing the opportunity for human error. In addition, the systems, devices, and methods described herein can achieve improved, near-optimal, or optimal utilization of laboratory capacity - individual system testing does not require locking all other systems of the test system corresponding to a vehicle (such as an aircraft). This can enable more engineering teams to work simultaneously.

[0115] Figure 7 An exemplary system assembly 700 of a test system for a vehicle, such as an aircraft, according to one embodiment is depicted. As shown, the system assembly 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 workstations 750, 755, 760, 765, 770 (hereinafter referred to as "workstations 750-770") connected to or otherwise in communication with the switch 710.

[0116] In one example, each of the switch 710, the user device 720, the first, second, and third databases 712, 714, 716, and the workstations 750-770 can be, include, or be composed of one or more computing devices, each of which can include a processor, memory storage, and a non-transitory computer-readable medium containing instructions executed by the processor. In addition, each of the exemplary system components 700 can be configured as a computing device for performing a process according to an exemplary embodiment of the present disclosure.

[0117] More specifically, each of the exemplary system components 700 discussed above can be an assembly of hardware 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 that can store data on a computer-readable medium. Furthermore, each of the exemplary system components 700 can receive programming and data via network communications. Furthermore, any and all of the exemplary system components 700 can have memory (such as RAM) that stores instructions for performing the techniques presented herein, although these instructions can be stored temporarily or persistently within other modules of other system components. Each of the exemplary system components 700 can include input and output ports and / or displays to connect to input and output devices, such as a keyboard, mouse, touch screen, monitor, display, etc. Various functions can be implemented in a distributed manner across multiple similar combinations of system components to distribute the processing load. Alternatively, a system comprised of the exemplary system components 700 can be implemented through appropriate programming of a single computer hardware platform.

[0118] Figure 8 An example graphical user interface ("GUI") 800 of a test system for performing the various methods described herein is depicted. The GUI 800 can display a system identifier 810 above device, connection, and port information tables 820, 830, 840. In one example, the system identifier 810 can reveal the vehicle corresponding to the test system represented by the GUI 800.

[0119] As shown, the device information table 820 may include a first list 825 of test assets incorporated into the test system of the GUI 800. Notably, the first list 825 is a list of workbenches included in the test system of the GUI 800. Notably, a workbench includes a combination, system, or subsystem of test assets, but is also a test asset in its own right. In one example, selecting 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 device information table 820. In one example, the list of test assets may be displayed within the device 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 specified information about each asset (e.g., LRU information, connections to other test assets or workbenches).

[0120] like Figure 8 As shown, 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 in the test system of the GUI 800. In one example, selecting 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 connection between the test assets and between the test assets and the switch (for the selected connection or the port of the switch used with the selected connection) (e.g., type - cable or signal, communication protocol, status) may be displayed.

[0121] The port information table 840 may include a third list 845 of test assets and a sublist 847 of ports belonging to each test asset. Selecting any of the ports in any sublist 847 may result in information about the port (e.g., type, other test assets connected to it, status) within the port information table 840.

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

[0123] Figures 9A-9G Depicted is an example GUI 900 of a test system that may be used to perform the various methods described herein.

[0124] Figure 9AGUI 900 is depicted in a mode that provides a current configuration of the test assets of a test system. As shown, the GUI includes Configure Lab, Lock Configuration, and Print Lab Configuration options 940, 950, 960, disposed above a message center 970 and below a lab display area 910. The lab display area 910 is disposed below a title bar 912, which may indicate the mode that GUI 900 is currently in. As indicated in the title bar 912 having a current lab configuration mode signal 913, GUI 900 is in a current lab configuration display mode.

[0125] Figure 9A An exemplary representation of a laboratory configuration of test assets for an exemplary test system is depicted. More specifically, a first test asset grouping 920, a second asset grouping 922A, and a third asset grouping 928 are shown. Additionally, a first independent asset 924 (an actuation station) and a second independent asset 926A (a third flight control system station or LRU (FSC3)) are shown.

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

[0127] The second asset grouping 922A includes a first cockpit LRU and a second avionics workstation or LRU (AV2).

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

[0129] According to one aspect of the present disclosure, selecting the Configure Lab option 940 will cause the GUI 900 to display an authorization entry form 914, such as Figure 9B According to another aspect of the present disclosure, a user must provide valid credentials to enter Figure 9C Lab configuration mode depicted. Entering and verifying user credentials allows an example switch according to the present disclosure to log, track, or otherwise record the identity of users who make changes to the lab configuration once lab configuration mode is active. In one example, this logging of users can be accomplished via the example data management service described herein. As a result, the switch can store or access information that can be used by subsequent users or engineering teams to obtain more information about a particular change to the lab configuration.

[0130] Figure 9C and Figure 9DGUI 900 is depicted in lab configuration mode, which may be presented upon verification of credentials provided in authorization entry form 914. GUI 900 may display several indicators that configuration mode is active. For example, title bar 912 may include current lab configuration mode signal 913 and may have a saved version 945 of the configure lab option 940 active (as indicated by shading and / or text), as shown. Figure 9C In addition, the first message 971 in the message center 970 may suggest actions that must be taken with respect to the actual physical test system and its test assets.

[0131] The example systems, apparatus, and methods described herein may provide a platform where a user may submit change requests through a GUI, such as GUI 900, and switches implemented or operatively bound to the GUI may perform the requested configuration changes on an actual test system.

[0132] In one embodiment, a user can drag and drop an element representing a test asset from a group of elements representing a test asset group, such as the second asset group 922A, so that the selected and moved element is separated from all other elements (test assets) in the original asset group. In fact, such use of the GUI 900 can be considered a configuration request, such as for each Figure 3 and Figure 4 The exemplary method of the present invention is described at 310 and 410. Therefore, once such changes are completed by selecting the saved version 945 of the configuration lab option 940, the exemplary switch implemented according to the present disclosure or otherwise operatively bound to the GUI 900 can perform various processes of the method described herein. Specifically, the actions described above using the GUI 900 can cause the switch to determine the test configuration and implement the switch according to the test configuration, thereby changing the actual configuration of the test system.

[0133] In addition to the saved version 945 of the configuration lab option 940, Figure 9C Also depicted is a first preliminary configuration change 930 made by the user that selects and moves the second avionics workbench or LRU (AV2) out of the second grouping 922A. As shown, the first preliminary configuration change 930 provides for third and fourth independent test assets 922B, 923. This configuration is referred to as a preliminary configuration because it is not implemented until a save version 945 of the configuration lab option 940 is selected, or at least not until a save version 945 of the configuration lab option 940 is selected. However, once saved, the first preliminary configuration change 930 can be considered a configuration request, such as for each of the configuration requests. Figure 3 and Figure 4 An exemplary method is described at 310 and 410.

[0134] Alternatively, or in addition to previously saved configuration changes, the user can drag and drop a GUI 900 element representing a single test asset or test asset subsystem to connect the element with another element representing a different test asset or test asset subsystem. Figure 9D Depicted is a second preliminary configuration change 932 made when a user selects, moves, and connects the first independent test asset 924 to the second independent test asset 926 A. As shown, the second preliminary configuration change 932 provides a fourth asset grouping 926B.

[0135] As described above, the saved version 945 of the configuration lab option 940 can be selected to save and implement the new configuration defined by the second configuration change 932. Selecting the saved version 945 of the configuration lab option 940 may be followed by a pop-up indicating the status of the update. The percentage completed may correspond to how much of the configuration has actually been implemented within the test system corresponding to the GUI 900. After the update is complete, the current lab configuration mode signal 913 may be displayed in the title bar 912.

[0136] Figure 9E and Figure 9F The GUI 900 depicts a locked configuration mode active after selecting the lock option 950. In one example, once the user provides a lock option such as Figure 9B The locked configuration mode can then only be active if the user has the credentials in the configuration lab 940. However, in one example, this may be a separate authorization process, independent of any other authorization processes previously implemented. That is, each time the user selects the configure lab option 940 or the lock option 950, the user must satisfy the authorization process.

[0137] The GUI 900 may display several indicators that the lock mode is active. For example, the title bar 912 may include a lock mode signal 917 and may display an active version 955 of the lock configuration option 955 (with shading and / or text), such as Figure 9E and Figure 9F In addition, the second message 973 in the message center 970 may suggest actions that can be performed on the GUI 900 .

[0138] In one example, a user can select a test asset to lock, and a successful selection of a test asset or group of test assets can be indicated by changing the appearance of a representation of the selected test asset. Figure 9F As shown, the fourth asset grouping 926B is depicted in a preliminary locked mode 934 (with Figure 9E with shadows compared to the appearance in [ ].

[0139] The user may select the active version 955 of the lock option 950 after completing all desired asset selections and thereby confirm that the locking action should be followed according to the selections made. Successful registration of the test asset or test asset group to be locked may be indicated by another change in the appearance of the representation of the selected test asset. Unlocking a locked asset may include a similar process for asset selection, wherein the representation of the previously locked test asset is restored to its original state, e.g., Figure 9A shown.

[0140] Figure 9G Depicted completed separately Figure 9D and Figure 9F As shown, the second asset group 926B is shown in locked mode 936, which is shaded with the Figure 9F The initial locking mode 934 depicted in FIG.

[0141] In one example, a report option 960 may be selected and a report including information about the current lab configuration (test assets, connections, ports, configuration changes) may be generated. In one example, the system may generate a .csv file with a timestamp for the report in response to selection of the report option 960.

[0142] The program aspects of the technology described herein can be considered as "products" or "articles of manufacture", usually in the form of executable code and / or associated data, carried or embodied in some type of machine-readable medium. "Storage" type media include any or all tangible memories of computers, processors, etc., or their associated modules, such as various semiconductor memories, tape drives, disk drives, etc., which can provide non-transitory storage for software programming at any time. All or part of the software can sometimes be communicated through the Internet or various other telecommunications networks. For example, such communications can load software from one computer or processor to another, for example, from a management server or host computer of a mobile communication network to a computer platform of a server and / or from a server to a mobile device. Therefore, another type of medium that can withstand software elements includes light waves, radio waves, and electromagnetic waves, such as media used across physical interfaces between local devices, through wired and fiber optic land line networks, and through various air links. Physical elements that carry such waves (such as wired or wireless links, optical links, etc.) can also be considered as media that withstand software. As used herein, unless restricted 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.

[0143] It should be understood that in the foregoing description of exemplary embodiments, various features are sometimes grouped together in a single embodiment, figure, or description thereof in order to simplify the disclosure and aid in understanding one or more of the various aspects of the disclosure. However, this approach to the disclosure should not be interpreted as reflecting an intention that the claimed subject matter requires more features than are expressly recited in each claim. On the contrary, as reflected in the appended claims, various aspects of the disclosure lie in fewer features than all the features of a single preceding disclosed embodiment. Accordingly, 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.

[0144] Furthermore, although some embodiments described herein include some features but not other features included in other embodiments, combinations of features from different embodiments are intended to be within the scope of this 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 may be used in any combination.

[0145] Thus, while certain embodiments have been described, those skilled in the art will recognize that other and further modifications may be made thereto without departing from the spirit of the invention, and it is intended that all such changes and modifications that fall within the scope of this disclosure be claimed. For example, functionality may be added or deleted from the block diagrams, and operations may be interchanged among functional blocks. Steps may be added to or deleted from the described methods within the scope of this disclosure.

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

Claims

1. A method for configuring a test system, the method comprising: receiving, with a switch, a request comprising one of an identification and a configuration request of a first test asset of the test system for testing; 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; as well as implementing the switch according to the test configuration, Wherein implementing the switch includes connecting the test assets according to the test configuration, so that a first test for the first test asset or a configuration according to the configuration request is performed non-exclusively with respect to a capability of the test system to be implemented to test other test assets. 2 . The method of claim 1 , wherein the implementation matrix comprises an error configuration specific to the test system, and an exploit scenario, wherein the error configuration specifies at least two test assets of the test system that cannot be operably coupled. 3 . The method of claim 2 , wherein the utilization scenario specifies at least two test assets, the at least two test assets being operatively coupled via more than one series of operatively coupled test assets. 4 . The method of claim 1 , further comprising modifying, with the switch, the test configuration to include a simulation of hardware of at least one test asset in the test configuration based on a current utilization of the hardware.

5. The method of claim 1, further comprising: implementing the first test on the requested test asset using the switch; as well as A second test is performed on a second test asset using the switch concurrently with the first test. The method of claim 5 , wherein the first test asset comprises a test asset system.

7. The method of claim 5, wherein the first test asset is a single line replaceable unit included in a test asset system, the test asset system being incorporated into an actuation workbench or a powertrain workbench, and wherein the first test includes configuring the first test asset to be disconnected from the test asset system. 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 not included in the asset system.

10. The method of claim 1, further comprising: determining that the configuration of the configuration request corresponds to an error configuration included in the implementation matrix; issuing a notification that the configuration is invalid; as well as The notification is displayed using a computing device.

11. The method of claim 1, further comprising locking a second test asset of the test system and implementing the first test of the first test asset, 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 incorporated into the first workbench during at least a portion of the implementing of the first test.

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

14. A testing system for a vehicle, the testing system comprising: Multiple workbenches, each workbench incorporating at least two test assets; as well as a switch operably coupled to the plurality of workstations, the switch comprising: a plurality of ports connected to the plurality of workstations; one or more processors; and 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 comprising: receiving a request comprising one of an identification and a configuration request of a first test asset of the test system for testing, Access the test system's current configuration 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 Track changes to the current configuration of the test.

15. The test system of claim 14, wherein the operation further comprises, before the receiving: accessing the plurality of workstations; identifying misconfigurations between test assets of the test system; as well as The error configuration is incorporated into the implementation matrix.

16. The test system of claim 15, wherein the operation further comprises, before the receiving: identifying an exploitation scheme for connecting the test assets across the plurality of workstations, Wherein each of the utilization scenarios specifies at least two test assets of the test system, the at least two test assets being operatively coupled via more than one series of operatively coupled test assets.

17. The test system of claim 14, the operations further comprising modifying the test configuration using the switch to include a simulation of hardware of at least one test asset in the test configuration based on a current utilization of the hardware.

18. The testing system of claim 14, the operations further comprising: locking a second test asset of the test system and performing a first test on the first test asset, The first test asset and the second test asset are incorporated into a first workbench among the plurality of workbenches.

19. A switch comprising: Multiple ports; one or more processors; as well as 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 comprising: receiving a request comprising one of an identification and a configuration request of a first test asset of the test system for testing; 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; operate according to the test configuration; and The test configuration is modified to include a simulation of hardware of at least one test asset in the test configuration based on a current utilization of the hardware.

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

Images