During the latest redesign of the Rosenbauer Rescue Stairs not only the operation has been overhauled, but the CAN bus system has also been implemented from scratch.
A reduction of Electronic Control Units (ECUs) was achieved by using controllers from TTControl which are certified for safety purposes. The risk and hazard analysis showed that there are safety requirements up to performance level d, as defined in ISO 13849.
Simplified Architecture Based On Safety Certified Electronics
With the new architecture, Rosenbauer achieved to put all safety features in one single TTControl ECU, which features the redundancy internally. Safety requirements like tilting and leveling are programmed by two independent developer teams, one team at TTControl in Brixen and another team at Rosenbauer in Leonding.
On the ECU the multitasking real-time system SAFERTOS® is operating both developed algorithms in parallel. The safety algorithm stops the Rescue stair all at once. The application algorithm takes care that the machine never moves to a position where the safety algorithm would need to take control and warns the user in advance on the display. TTControl ECU combined with the SAFERTOS® guarantees the freedom of interference
As the TTControl ECU combined with the SAFERTOS® guarantees the freedom of interference, the non-safety relevant application software can be maintained and deployed on the same controller without the need to repeat all the safety certification on every new software version. As the products are varying greatly based on the final customer, this is an important feature to reduce the maintenance efforts of the complete software.
Reduction of ECUs
With this safety architecture, Rosenbauer achieved a reduction of ECUs from six units of three different types to three units of identical type. Another reduction of electronics was performed on the hydraulic valves. The previous generation featured a valve manifold, where each valve had a small electronics module integrated, which was controlled via an individual PWM signal.
Now the complexity of the system was reduced by eliminating the electronics on the valves and using two outputs for each valve instead. The TTControl ECUs have everything on board for this purpose. They have sufficient outputs and each PWM output is capable of measuring its current.
The accuracy of the current measurement is sufficient for moving the valve in every position via current control without a sensor on the valve. Only actuators with position control are equipped with sensors, while all-speed control is performed without sensors.
Software Development On A Virtual Model
In this project pioneering work was done in the way of application software development at Rosenbauer. A virtual model was created for the whole hydraulic system, with two PWM signals for each actuator as an input. All sensor signals were measured on the real system, and used as outputs like hydraulic pressures, end positions of the actuators, CAN signals, and current values. This model was used in two ways:
On one hand, it was deployed by automatic code generation onto another TTControl ECUs to enable the safety software development team to perform software tests without traveling to the rescue stairs. All relevant characteristics of the 33 ton and about 1million EURO rescue stairs were put in one controller.
The software development started on the desk as well, but nobody knew how it would behave on the machine
On the other hand, the model was used to develop the application software. Therefore, the hardcoded current and position controllers from TTControl were imported into Simulink. In this way, externally delivered code pieces and the model of the mechanics were operating in one PC simulation, independent of the production status of the machine and with no hardware at all.
Testing on the machine
Before this model-based approach, the software development started on the desk as well, but nobody knew how it would behave on the machine. The real work started at the point of time when the programmer sat in the machine.
With the new method, the programmer knows that the application software is functional and must search the differences or the missing test case during the commissioning only. It turned out that everything working in the simulation also worked in real life, as the tricky part of finding correct resting positions and keeping the first and last stair of the mainframe telescope in a flat position.
Efficient Software Testing From Office
With the simulation, the development iterations can be driven to a maximum and the programmer gets off all the external influences. A machine of this size can be run only outside, so the programmer is exposed to the weather and to the noise of the diesel engine.
For each iteration, the software needs to be downloaded to the controller, and interesting variables must be monitored and plotted for each iteration. In practice, the days get longer and are extremely stressful, as it usually takes very long until all IO checks and mechanical and electrical installations are 100 % finished.
The delivery date never changes, but all the other processes take longer as planned, which must be compensated by the extra working hours of the programmer. With the simulation, the software development and testing can be done efficiently in the office, decoupled from noise, stress, and bad weather conditions. The quality and the possibility of maintenance of the generated software are much better this way.
Software design
The embedded code generator gives the programmer the possibility to concentrate on the software design At the software development itself, MATLAB/Simulink/Stateflow and the embedded code generator give the programmer the possibility to concentrate on the software design. The hard work of writing the code after drawing the Stateflow diagram is automated by the code generator.
Even if it turns out during the commissioning that there was a wrong assumption in the model, adding an extra state or transition is only a matter of drawing and has no big impact on software that is already programmed.
Another advantage of the model-based design is that the drawings of the software can be understood by the customer service and other stakeholders, who are no programmers. The self-speaking drawings in Simulink/Stateflow can be exported to HTML and published to everyone as in-depth documentation of the software.
