In this project, the client had a software testing environment made up of several different components. Some of those components simulated a physical system while others emulated interfaces that the Software-Under-Test would interact with in a deployed environment. Each of the simulators and emulators was independently configured.
Two portions of the environment in particular needed to be configured in compatible ways for the test to have any meaning. These specifically were a physical simulation of freight train and an emulator of the signalling system that provides the Energy Management Software-Under-Test with route, speed limit, and other information information. The physical simulator must be provided with an elevation "profile" and a description of the locomotives and freight cars comprising the train. The signalling system emulator must be provided with track maps, a route description traversing those track maps, a description of the locomotives and freight cars comprising the train, and the speed limits that the Energy Management Software-Under-Test must adhere to.
Clearly the signalling system emulator and the physical simulator need to have synchronized inputs. The solution we provided to the client was a Path Finder and Scenario Manager Tool, as depicted below. This tool was implemented as a Javascript frontend and a C# backend to maximize reuse of an existing client codebase. The frontend uses the Angular.JS and Bootstrap 5 frameworks while the backend uses Microsoft's Minimal API framework.
The Tool uses the same Track Map files used by the Energy Management Software-Under-Test as well as the Signalling System. The Tool introduces a new-to-the-client capability of visualizing the Track Map files both in a geographical sense as well as through a simplified track schematic.
In the Tool's workflow, a user first defines a desired route through the Track Map by selecting waypoints on one or more "subdivisions" of the Track Map. In the following example, a user puts a first waypoint on the BNSF "Fort Scott" subdivision and a second waypoint on the BNSF "Thayer South" subdivision. Note in the second image that the Tool has identified a route between the two waypoints. This was performed using an implementation of Djikstra's algorithm.
These two images highlight a second new-to-the-client capability of producing routes and profiles that span multiple subdivisions of the Track Map. Previously, the client was limited to test scenarios that resided wholly within a single subdivision. This limitation prevented testing of functionality such as report generation that occurs when the train exits a subdivision.
The identified route can also be depicted geographically.
Once the route has been completed according to the user's need, the route can be exported in a number of ways, such as a JSON file download or by sending the route to the Scenario creator.
Sending the route to the Scenario creator first calls a backend function to reduce the route to an elevation profile consumable by the train physics simulator:
Then, the user is prompted to upload a train description file:
The user-created route and this train description file are provided to the backend. The Track Maps contain speed limit information which frequently is dependent on train characteristics such as weight and number of cars. The Tool identifies the specific speed limit profile applicable to the provided train description over the provided route and displays this to the user:
This completes definition of the scenario. The user can then interact with the tool to see the completed scenario and then select which testing tools the scenario should be sent to. As depicted in the block diagram above, the options are the train physics simulator and the signalling emulator:
When this synchronization process is complete, the Software-Under-Test is provided with an internally consistent test scenario without the test engineer undertaking the tedious work to manually configure each system.
A demonstration of the system is shown below.