Solving complex problems in software development – part 5/6 – The solution: An adaptive algorithm

This blog post goes into more technical details, but it is still important to be able to understand complexity, and how hard it sometimes is to iterate continuously to be able to gain knowledge so we can build our solution. When you are in the unknown unknowns there is no specification, instead we make the specification continuously when we are gaining knowledge. No specification means that there is no gap to fill, and that the iterations need to be extremely short; only minutes, hours, days if possible to make small changes and see the what happens; and bigger iteration loops where bigger changes are made and then tested. All to gain new knowledge.

When the ATO team gained knowledge, it was in four different iterative interwoven intervals (in average):

  • 5 minutes iterations: to get new data, i.e. Big Data in total, on the current parameter setting when going between two stations. This was done with different train sets every day, except Sundays.
  • 1 day iterations: In the evenings the team analysed the data, made changes in the parameter settings, and maybe some other small changes in the software, all together to learn more about the system.
  • 4 weeks iterations: After four weeks the team was back at the office for four weeks to analyse the data per software version, and to make bigger and proper changes needed for the long-term solution.
  • Every three months iterations: The ATO team were 4 times in the field over about one year, and every time they brought with them a new updated “prototype” with updated ATO and test software and more and more parameters for logging purposes since they were still in the Complex domain, without knowing if the ATO would ever do the job.
  • In the end of the fourth time in field, the understanding of the total train system that the ATO were a part of, was big enough, and the Complex/Complicated domain was finally left.

Important to understand is that with multiple players in the game, with their own agenda for making as much money as possible, changes were done in parallel without notice or information. New brake blending, new brakes, too much braking to compensate loose coupling between the wagons, etc. , changed wheel diamter setting. This made the ATO project to loop many times from the Complicated domain back to the Complex domain, since they were in the unknown unknowns, but they thought they had control.

The long-term solution was an adaptive algorithm, taking care of not only different train sets, but also different train suppliers and customers, and to be tolerant to future changes. To get a feeling about the complexity, here is a list of the most important knowledge that the ATO team needed to gain, to be able to finally leave the unknown unknowns:

  • Long reaction time of the brakes, between 0,5 and up to 2 seconds, depending on brake system; electric or pneumatic system
  • Change of brake system from pneumatic to electric, if the electricity cannot be fed back to the net
  • Brake blending from pneumatic to electric brakes always between 10-15 km/h
  • The brakes really pinched close to zero speed and really made the stop hard and short
  • Train built-in jerk limitation was only for the driver
  • Incorrect positioned balises for giving the correct position
  • Too loose coupling between the wagons (forced the brake system supplier to do late changes in the brake blending, without informing the ATO team)
  • Bad load compensation system (no information from beginning to the ATO team)
  • Difference between cold and warm brakes, especially just before the train stopped
  • Bad brake calibration on many train sets (ATO team never informed in advance). Some trains break too hard just before the stop point, without chance for the regulator to correct, and a Motor While Braking Signal was added ;-).
  • The train sets were very different from each other; all individuals and behaved differently
  • Wheel diameter parameter setting only in 10 mm accuracy, which gave a worst case scenario of 9 cm error in the odometer calculation, a few meters from the stop point, too late for any controlled regulating due to reaction times of the brakes. And of course much worse when they forget to change the parameter setting after a corrected wheel damage.
  • Very steep uphill or downhill just before the station
  • Brake and propelling supplier had in their validation specification fixed tests made by the driver, propelling P1-P4 and for braking B1-B7, not the ATO that had 0-100% values sent to the train computer. This was especially difficult since the brake blending and the ATO decrease of brake power was in the same speed interval.
  • etc.

With train sets of 100 train sets each, from four different supplier, where the train’s brakes and load compensation systems were calibrated good enough, these train sets stopped within +-10 cm, coming in on the station in 70 km/h breaking, with no hesistation or slow driving. And some train suppliers could use the electric brake with more exactness to as low as 2 km/h and then +-10 cm was very common.

To achieve this the ATO was made adaptive; recalculating the brake curve at position updates, moving the virtual stop point for train sets that pinched the brakes to much in low speeds and therefore stopped short; forced braking before a coming brake curve to ease for the regulator, etc.

Normally when using regulator algorithms, the future is not known, making the regulator always regulating in the complex domain. But, since the ATO knew the future, where to stop, coming speed limits, etc., we moved the actual speed regulation from the complex domain to the ordered domains, by telling the regulator algorithm about this future. This, since in the ordered domains, especially the Obvious domain where we do not need expert help, we can easily close the gap when we are knowing the future. At abnormal situations, the regulator algorithm still operated in the complex domain, for example after emergency brake to a complete stop or a too low speed, too close to the coming precision stop point at the platform.

The adaptiveness and making the regulator algorithm know the future, made it possible to use exactly the same SW program (and HW) for the coming ATO projects, with different train sets per supplier, totally different suppliers of the trains, brake and propelling systems, etc.

Tomorrow’s blog post is the wrap-up of this series. Hope to c u then.