Bermuda - Automotive Manufacturing Frontend Integration

Key Information

Status: ‌Cancelled zero submissions
Show Deadlines

Challenge Overview

Our customer - Bermuda is building a new automotive manufacturing plant to make cars and are looking for a simple dashboard to monitor and simulate costs. The dashboard has a series of sliders that allows them to simulate the costs for running the plant. In previous challenges we've developed the UI prototype using jquery, requirejs, d3js and is deployed at heroku.

The dashboard is very simple - user sets the values for the sliders in the main body and that updates the graphs, gauges and tables in the top. The user can than save the scenario or load an existing one. The compare view has the same features as the main dashboard view except that two scenarios are displayed side by side. 
When one of the parameters is changed, the data for the graphs/gauges and tables will be recalculated in backend (by running a provided executable) and returned to frontend for display.

In this challenge we'll cover all the frontend features except for saving the report as pdf and sharing the results.
Backend and frontend should be 2 separate projects where backend will provide an API and frontend will serve public/static resources. Backend will be implemented using NodeJs&Express and frontend will integrate the current requirejs/jquery/d3js prototype with the backend (no need to convert it to React/Angular).

Scenario parameters
The list of parameters (operational tactical, strategic) and their ranges should be configurable in a config file in backend. The number of parameters will always be the same, but the labels and ranges might change, so you can encode them as parameter0 - parameter21 and have just labels and ranges configurable.

In the tactical parameters section, the four percentage parameters should always sum up to 100. If the user changes one of them, the remaining three should rebalance to get the sum back to 100.

Sensitivity analysis
The user can enter Sensitivity analysis mode by clicking the small graph icon next to the parameter labels. The x axis in the graph will be the percentage of slider value and the Y value will be value of the 'Total Cost' column in the output when varying that parameter from 0-100% with all other parameters being fixed. So for each of the active sensitivity analysis parameters we need to run the calculations with a few values of the slider (let's make it 10 as default), with other parameters being fixed. Each time the user changes one of the parameters, the process should be repeated. This can be a performance bottleneck, so trigger the updates of other parameters after user releases the slider (or the slider box handle in the graph), or a small 100ms delay when typing into the text box.

Scenario calculations
Each time a slider value changes, calculations should be triggered in backend. There are two executables that should be called: 'BermudaAutomate_No_v1.1' and 'BermudaAutomate_Yes_v1.1'. Which one to call is decided by the value of the 'Automate' parameter in the Operational group. If it's set to No, call the former one, otherwise call the latter one.

Each executable can be called in 2 modes:

  1. With no arguments. This will produce tab separated output to standard out using default values.
  2. With arguments - e.g. ./BermudaAutomate_Yes 0:200
    • This will invoke the executable but ask it to use 200 for the value of the 0th indexed variable, for its run. Other variables will be at their defaults.
    • Multiple variables can be passed in the command line e.g. ./BermudaAutomate_Yes 0:200 5:2.0

Input variables from the Bermuda Automotive interface are indexed as shown below

  • 0    Profit per car
  • 1    Install Cost for Lights
  • 2    Cost per back seat install
  • 3    Cost per tire
  • 4    Engine Install Cost
  • 5    QC Cost
  • 6    Cost per spark plug
  • 7    Painting Screwups
  • 8    Wheel Assembly Success Rate
  • 9    Induction Rate
  • 10   Percent Supply Chain Failure
  • 11   Brake Lining Success Rate
  • 12   Tests per plug
  • 13   Fuel Ignition Success Rate
  • 14   Sedan
  • 15   Luxury Sedan
  • 16   SUV
  • 17   Luxury SUV
  • 18   Target Annual Car Production
  • 19   Detroit Percent
  • 20   Detroit Plant Production Rate
  • 21   Mexico City Plant Production Rate

In all modes the output is printed to stdout and is tab separated of the following form:

Columns are named A through V. These column names translate to the following names in the Automotive interface:

Column   |  Name for Bermuda Dashboard    |  Value type

  • A         Chassis in transit              Amounts (not costs)
  • B         Brake Installs                  Amounts (not costs)
  • C         Paint Jobs                      Amounts (not costs)
  • D         Annual Lights Installed         Amounts (not costs)
  • E         Engine Installs                 Amounts (not costs)
  • F         Annual Cars Produced            Amounts (not costs)
  • G         Sedans                          Amounts (not costs)
  • H         SUVs                            Amounts (not costs)
  • I         Luxury SUVs                     Amounts (not costs)
  • J         Luxury Sedans                   Amounts (not costs)
  • K         Total Costs                     Costs
  • L         Endowments                      Costs
  • M         Wiring & Linings                Costs
  • N         Generators                      Costs
  • O         Painting                        Costs
  • P         QC                              Costs
  • Q         Interior Detailing              Costs
  • R         Engine Installs                 Costs
  • S         Sedan %                         Percentage
  • T         Luxury Sedan %                  Percentage
  • U         SUV %                            Percentage
  • V         Luxury SUV%                     Percentage
The first column in the output is Time in days and it drives the x axis in the graphs.

Scenario load/save
In the backend, provide 3 'endpoints' for listing/saving/loading scenarios that will just return sample data for testing. These will be wired to database in a future challenge. Frontend actions should call these endpoints to get the data for display. 'RESTORE TODAY DEFAULTS' should also call the backend to get the default parameter values and you can return sample data for now.

Base code (UI prototype) is available in the forums.

Create a Docker image for both backend and frontend projects. Both images should have just the minimal environments and should start only the app process (so don't make the entrypoint be a bash shell). Application code should be embeded into the image, and not mapped as a volume. Applications should produce daily logs with all requests/responses/errors persisted to log files mapped to the host directory. Also, create a docker-compose script that will manage both containers.

Final Submission Guidelines

Submit the complete cource code for the application
Submit a Deployment guide explaining how to deploy locally (docker) and to heroku
Submit a verification video

Reliability Rating and Bonus

For challenges that have a reliability bonus, the bonus depends on the reliability rating at the moment of registration for that project. A participant with no previous projects is considered to have no reliability rating, and therefore gets no bonus. Reliability bonus does not apply to Digital Run winnings. Since reliability rating is based on the past 15 projects, it can only have 15 discrete values.
Read more.


2017 TopCoder(R) Open


Final Review:

Community Review Board


User Sign-Off


Review Scorecard