Challenge Overview
Boat in a Box - Integration challenge
As part of the larger Boat-In-a-Box project, the client would like to develop a web-based tool to assist in creating various scenarios.
Scenario is a time series data set containing data about ships. The user is able to place ships onto the map and for each one he can add multiple waypoints and set ship speed. Scenario can also have anomalies that are ship locations outside the defined ship path. The scenario is then simulated and the output is a list of position reports for each of the ship for the duration of the scenario.
In the two previous challenges we created the frontend and backend to support the above tool. In this challenge we need to wire the frontend and backend and also make some changes to both. The output of this contest is a fully working scenario creation tool.
Base code for frontend and backend is available in the forums.
NOTE: Asking questions early is important for this contest !!!
Frontend requirements
1. Wire the login page to backend (you can add one user to backend database)
2. Wire the save/open scenario to backend. Note that this will require changing the scenario mongoose model in the backend
3. Add a “Hold Time” parameter to each of the waypoints. It will represent the time (in seconds) the ship will wait at that waypoint location, before moving on to the next waypoint. Default will be 0.
4. Add “Navigational status” parameter to each of the waypoints. It’s values are 0-15 with 0 being the default one. Once the user changes the value for a waypoint, all new waypoints added after it should have that new value as default (the value should just propagate forward, not backwards)
5. Add “Position accuracy” parameter to each of the waypoints. It’s values are Low/High (or 0,1) with 0 being the default one. Once the user changes the value for a waypoint, all new waypoints added after it should have that new value as default (the value should just propagate forward, not backwards). The default values for Navigational status and Position accuracy should be configurable in the config file.
6. Add an ‘Export’ button to the top menu, next to the Open/Save buttons. Clicking that button will call the export endpoint of the backend and download the resulting file. Creating the file in the backend will probably be a time consuming operation so display a loading dialog while processing is in progress.
7. Implement the calculations for determining total scenario duration. It is equal to time needed for all ships to reach the last waypoint For each of the ships you need to iterate through waypoints and calculate the travel time between the waypoints (each of the waypoints has a speed parameter in knots). Use this parameter to update the values on the timeline and the resolution of the scrubber. You can create some rules that will make the scrubber resolution adequate ( for example, if a scenario takes ~60 minutes then use 1 minute resolution in the scrubber, but if it takes 10 hours you can use tens of minutes, or just hours if it takes more than 24 hours)
8. Implement the approximate calculations for the ship position at the resolution set for the timeline. For example, if you set the timeline resolution to 1 minute, you need to calculate each ships position for each minute of the scenario. These calculations will use only waypoint distances and ship speed to calculate the ship position.
9. When the scrubber is moved, use the values calculated in #8 to move the ship icons to new positions. Note that you also need to set the correct ship icon rotation to point towards ne next waypoint (heading). Also note that changing any of the scenario parameters should trigger recalculation of the ship positions (add/edit/delete waypoint, change waypoint speed, etc). There should be no performance issues here so it might be a good idea to trigger recalculations only for the affected ship or add a debounce timer for triggering recalculations.
10. Update the ship popup overlay to display the current ship speed and position. Those fields should not be editable.
11. Add a time parameter to the AIS message. When a new AIS message is created the time should be auto populated from the current scrubber position, but the user should be able to edit the time.
Backend requirements
1. Create a test user in the database
2. Update the scenario mongoose model to save the data from the frontend (you only need to save scenario data, not the calculated values)
3. Remove the ‘simulate’ endpoint. The simulation calculations will only be used for creating the output .ais file in the ‘export endpoint’
4. Ship simulation calculations should basically be implemented from scratch as there are new requirements (you are allowed to reuse the previous calculations where adequate). The simulation requirements are
- Each of the ships, during it’s travel, should be generating position report messages (AIS messages). The frequency of generating the message depends on the ship speed and status, detailed in the following table
- Take into account that the ship will need to stop at a waypoint for HOLD_TIME amount of seconds before moving on to the next waypoint
- Ship speed changes can be considered instantaneous
- Special handling should be applied to calculating ship positions while it’s turning. Ship turns can’t be expected to be instantaneous. The turn will take a certain amount of time - which can be calculated based on the formula:
t = d*(23 - s)/270
d = Turn degrees (degrees the ship is turning)
t = Turn Time (in minutes)
s = Ship Speed
You can implement it so that the ship starts turning before it reaches the waypoint or right when it reaches it. The difference is obvious in the following image
Note: while the ship is turning it's sending AIS messages more frequently - they must be sent at the correct frequency from the table above".
- In the frontend, each ship has a list of custom AIS messages (each of them with a timestamp). Those messages should be included to the values calculated in the simulation (inserted at the appropriate position in the timeline). In case a generated message and a custom message have the same timestamp, the custom message will simply override the generated one.
5. The export endpoint should use the above calculations to create the output AIS file.
NOTES:
Turn (and simulation) calculation function needs to be specifically well documented and encapsulated as we may need to revisit it.
Make sure to create a simple test scenario that can be used to verify the above calculations
Final Submission Guidelines
Submit the complete source code for frontend and backend
Update Readme files and deployment instructions
Submit a short video displaying the implemented application features.