A little background about me and the work I have been doing for many years now. I’m a design engineer who has a great deal of experience in all aspects of computer, software, instrumentation and real-time system design, hardware, software and firmware. I have designed and build a wide and diverse set of systems everything from anti-lock controllers for commercial vehicles and trains to custom measurement systems that measure the railway infrastructure from a train moving at speed. My formal training was as an electronics engineer but as software has become a major part of most systems I have continually evolved and re-educated myself.

My speciality is an understanding of what makes such systems work successfully in a vehicular environment, everything from the environment to the way the people work. I profess not to be a manager but I have often arrived to take a technically lead role on a failing project which has finished as a success. However, I am not foolish enough to forget I have had an occasional failure and learn the lessons from these no matter how painful.

As the systems have become controlled and driven by software I have worked in everything from assembler and C through to G, the graphical language used by LabView. I suppose if I need to define something within the field but outside my comfort zone its large currents and voltages but even those are not unfamiliar as I designed a communications system to talk to electronics on the live side of a pantograph on a train. For anybody who does not know the pan on a train connects to the 25kV overhead wire. Like all good engineers working with real time systems I have an understanding of issues associated with EMC Interference and Susceptibility although I am not a specialist.

On several occasions I have built models of systems to help in the design process, prove functionality or simply to convince senior management that a project is possible. However, models also provide a great way to reduce risk as they can allow the testing of sub-systems and components long before the physical construction starts.

Because of the nature of some of the systems I have designed I have learnt a great deal about Linux, Lamp and Web Services. When a system produces large volumes of data it also has to become its own data centre or the customer will not be able to manage.

So in summary everything from driving a solenoid to driving the Internet.

Frank

Although this project was not quite my first design project it is a very early example. At the time I was working for Lucas Girling at the Fen End Test Track. It was one of the most idyllic places to work, we were out in the country a few miles south of Solihull on a World War Two airfield, surrounded by tree, grass and green fields: wonderful!

The project was very simple in concept design a test set that would allow field engineers to find the faults on Anti-Lock Systems fitted to commercial vehicles. At the time we were reasonably successful at selling the systems but the maintenance network was failing to keep the vehicles in a serviceable condition and we were getting a lot of second and third level support calls.

I had very little software experience but I was very capable of designing the hardware therefore I set out a simple fault analysis tree, subcontracted the software to the software team who worked in the other half of the lab and set about designing and manufacturing the hardware. The result was a disaster; my software inexperience was used as an excuse to bin my fault tree and follow "best software design practice". As a result the software was of no practical use and I was blamed for the system not working.

However, I was well enough considered by my manager at the time to allow me the freedom to perform a rework. The discoveries and the learning process that followed still influence my thinking. "Keep it simple", "Junk in Junk out" and "If you don't understand, ask!" are phrases I suspect everybody who knows my work will have heard me use ever since. Six months later the Test Set does the job perfectly but only a few are in use.

Remember the three levels of support, well I was the level three support. Every week I would go out and deal with a few major problems that nobody could solve. I started taking one of the Test Sets and using it, soon our second level service engineers were asking for Test Sets and I was suggesting to the directors they be given them. Eventually, after a heated argument where the managing director “We might as well give them away, nobody wants them!”, the second level engineers were given one each and they started to sell.

Within six months we were sold out and had to manufacture a second batch of three hundred. Eighteen months later the same director apologised to me and told me he was glad I had the belief to argue with him.

One of the most rewarding hardware design tasks I have ever completed was to redesign a very compact signal conditioning and multi-purpose I/O board for a small company. I completed everything from the circuit concept through design to the PCB Layout and onto procurement and manufacture. One of the big advantages of a small company is the ability to influence all stages of the process. However, it is also the biggest disadvantage as you also have to accept sub-tasks you don't like. I loved it; the picture below shows a populated prototype board which has had a few components changed by hand, a task that requires a steady hand.

The project was rewarding on many levels from the personal proof, that I could still do it, to the realisation that more functionality had been crammed onto the board and that overall the new boards work to much higher standard.

The picture below is for part of the circuit diagram for an Anti-Lock Controller which illustrates very nicely that a good understanding of analogue electronics is essential even today when connecting sensors with small output signals to digital systems. This circuit was able to detect open and short circuit conditions along with shorting to ether supply. I designed the circuit from basic principles and worked with a young mathematician to optimise the component selection.

To the best of my knowledge the circuit was never put into production. However, it was well proven during the development and test program.

For me the decision to implement a project in a particular language has never been an issue. Historically the project has chosen the language to be used ether because there was nothing else available that could do the job or the preferred platform restricted the choice. However, today the problem is significantly reduced as the various languages are available over a greater spread of platforms.

One of my favorite software projects was the Track Recording System for which I lead the design team for a number of years. The Track Recording Analysis Computer System (TRACS) from which DeltaRail's TrackLine was derived was a multi-processor system which used dedicated hardware to perform some of the very high speed preprocessing of both video signals and sensors. It cycled six hundred and sixty six times a second but by the use of carefully designed hardware managed to capture some signals at twenty two kilo-hertz. Practically calling it a software project belies the complexity of the hardware.

The software was based upon a realtime Unix platform with a Windows user interface. However, some of the system ran without an operating system because the time restraints were extremely critical and the processor performance available was insufficient. The software was written in Assembler, C, C++, Perl, Bash Script and SQL the language being decided by getting the best out of the platform and simplifying the task at hand.

The software captured the measurements in hard real-time and recorded the raw data to disk. Thus if everything else failed it was possible to re-analyse the data at any time and to do so for a completely different set of results. All the recorded data carried the calibration information and therefore all the calculations and results were in real world understandable units. Further, every stage of the system was configurable and adaptable to any requirements change.

One of the demonstrations that always impressed engineers and customers alike was to start a journey at a modest speed and see the results being charted and printed within a few seconds of passing over a track section. Then as the speed increased to two hundred kilometers per hour the results would lag further and further behind until if the journey was long they might be twenty minutes behind. However, by the time the train reached it's destination the results were again being produced within a few seconds.

The only effect of increasing the complexity of the analysis was that the lag was longer and recovery slower. A chart recorder would run out of paper and an error message would be produced on the user interface. A new set of paper would be loaded, the system told to continue and the chart would restart from a point just before the last sheet was printed and proceed to catchup.

One of the major design features of this system was the flexibility that resulted from the system being modular. This meant that as the system developed we could move processes between processors or let the processing lag behind the data capture without having to modify any of the components. It also meant debugging was much simpler because bugs could generally be localised to a specific small process. Further, as more powerful computers became available or more complex processing was required it was a simpler task to integrate the system.