This series of blog posts will handle complexity, where the key always is to learn in small, small steps, by iterations and never ever try to specify ourselves out of the complexity, since it is not possible or at least too time consuming with too long iterations. In the blog posts we will also be able to see complexity from different perspectives, mostly from a software perspective, but also the connection point between software and hardware, between digital and analogue. It will be a journey about how to judge when we have complexity or not and how to overcome and it. Since it is software it will of course be in story form, mixed with insights and useful information. Welcome.
The story begins in the early 1990s, when a big train company signs its first customer contract for an autopilot for subway trains. The plan is to use the existing hardware from the traction part of the company, filled with software functions for handling the break system, propelling system, door system, etc. The computer hardware uses the operating system OSE and the programming language is the new version of C, real time C with signals.
The part of the company that is going to make the autopilot software, the ATO (Automatic Train Operation), is the part of the company that since many decades makes the train security system, the ATP (Automatic Train Protection) for railways all over the world. The ATP system consists of hardware on the train and also around the rails with balises, signals etc., and with most of the software on the train. Everything to secure a safe ride with the train.
The ATP software is fail-safe with A/B programming (two different software programs on the same hardware, where one of the software programs using inverted data). The software is analysing all received fail-safe data from balises and the train, and its basic function is to control one digital signal; if everything is ok and the fail-safe system is alive, then the emergency brakes do not brake*. Together with the ATP software, there is also a train and track simulator used, for test and verification purposes.
Now it is time to put the company’s ATP software development into the Cynefin™ framework. It would look like this.
As you already understood, we are never in the Complex domain. The reason is that making the ATP software is only about closing the gap, since we already know what to do, which means that we are in the ordered domains. This is Technology Push and not Consumer Pull, since the customer interaction is low, even with the user interface inside the train, since the main focus for the customer is a safe ATP system. We have mostly digital input signals to the software, that we need to analyse, and if the software finds the situation unsafe, the emergency brake output signal is set to low. That is not complex, since our experts’ knowledge can always guide us to a solution on the hardware**.
An ATO project is started and the requirements from the customer are the following:
- Stop within the limits +-35 cm (to align with the platform marking/doors)
- Drive faster than the drivers between the stations (but, of course follow the speed limits)
- Drive smoother than the drivers (but, of course in combination with drive fast)
- Drive more economic than the drivers (but, of course in combination with drive fast)
- There are also specifications from the customer about the resolution for parameters like speed, wheel diameter, etc.
The project team starts to work by making a specification on how the ATO shall work. The software team knows the C-programming language, but the new version with signals, they need to learn.
The main part of the ATO is of course the regulator algorithm, to be able to drive the subway train between the stations. A normal PID regulator algorithm is chosen.
The team also adapts the train and track simulator by adding more functions, especially more exact speed and tachometer with higher resolution, since these input signals have higher resolution from the subway train then an ordinary train. Also, the functions of braking, propelling, door control, etc. are added.
The technical project manager is very proactive and understands the need of a test system also on-site during verification and acceptance tests at the customer, and since this is the time when laptops enter the market, a portable test system is made. The ATO hardware fits in a special made suitcase that is heavy, but manageable and possible to bring on the plane.
The project team is on track, they also have all needed test equipment and the company prepares for a Walk in the Park and the ATO project are drained from resources.
But, can really ATP and ATO development be handled in the same way? What do u think? C u in next blog post.
*The Emergency brakes are always on in an inactive state.
Note! The train normally also have a softer service brake, another digital signal, that due safety reasons since an emergency brake is very rough, only punishes the driver up to two times if he drives over the speed limit, before the Emergency brakes will brake the train to a complete stop.
**Of course if the computer hardware has too low working memory, program memory, CPU speed, etc., we can of course enter the Complex domain from the ordered domains, via the Chaos domain, in the Cynefin™ framework, since we then do not know if there exist a solution and we need to iterate to see if we can find one in time.