Control Sheet No. 3
In this issue:
In my previous article, I was trying to avoid the famous dilemma of EPICS versus TANGO versus ACS versus TINE versus FESA versus . Today, on popular request, I give you my honest opinion, which of those control systems is the best.
Cosylab always tries to avoid this dilemma by doing whatever the customer wants. So why should we insult or even lose at least half our customers by telling them their choice was wrong? Well, I’m not going to tell them that. Instead, I’ll tell all of you that you were right. I’m going to prove that your decision was correct, irrespective of the system you have chosen.
The expectations of the final user, which is mainly the operator and only sometimes the engineer, should ultimately determine the choice of the CS. On one end of the CS she/he requires the physical devices to be added easily and on the other she/he wants a powerful and easy-to-use user-interface. No matter the technology and no matter all those incomprehensible TLAs (TLA is a three letter acronym that stands for “three letter acronym”). After all, it worked perfectly well with cables and mechanical sliders and gauges half a century ago, didn’t it?
In reality, people, including myself, usually work backwards. We decide on a control system package, then we decide on a given hardware technology (say, VME, compact PCI, etc.) and then we match our specifications to that. If we have specifications at all at this stage. But that is a subject for a future article.
One may wonder why this approach works. The simple reason is that nowadays, practically any technology is capable of doing the job. It may need slightly faster computers, it may be vastly more expensive to implement in terms of money or time, but as CS are usually not on the critical path of a project and cost less than the major components, nobody really notices this. So let’s just keep in mind that there is room for improvement. On the other hand, this improvement may be smaller than the gain of just copying whatever concept the most recent project has adopted. Or take the project of the control people you have best relations with. If it worked for them, it will surely work for you – or they will help you out anyway.
It’s important therefore, that you chose a system that you are comfortable with – for whatever reasons. And the best reasons are always gut feelings. Of course, you still have to justify your choice with rational arguments to your management. But finding good arguments in favour of any system should not be a problem. Which reminds me of how people buy cars. It is proven (and well exploited by marketing agencies) that people first choose a new model based on their emotions, then look for rational arguments that justify this choice, such as safety, gas consumption, etc. So why should control systems be any different? In any case, this proves that your choice of control system was correct, just because you made the choice and not because of which choice.
Which I think is very reassuring.
Have you ever scratched your head trying to figure out how the damn thing works and after the big aha said to yourself: Jeeez, what an awkward way…" Were you ever required to add some newly born requirement that… well… somehow just didn't fit in and you just said: "Jeeez, let's do a nasty quickfix…" Ever had a hard time trying to keep your code bug-free despite frequent changes inferred by a drifting system design? Were you ever late on the implementation because the target just couldn't keep still? We all know where this originates; poor requirements and lousy architecture work.
What's the process of requirements gathering anyway? Obviously we have a person who has the requirements. And there is a skilled developer who has to chew them and produce acceptable artifact.
It's not so uncommon these two persons speak different languages; Word vs. VHDL, pen-and-paper vs. Visio, Chinese vs. Russian…
We were in a project where we had a lot of problems until we understood the processes and stages diagram represents. The main issue was we were trying to force scribble document as a replacement for architecture proposal. And we tried to substitute the later with code snippets. Not a good way to follow! The major breakthrough was the point when we realized the architecture proposal must be written by the designer who would actually be responsible for the implementation. Doing this the designer proves he understands the problem and simultaneously, requirements are captured in precise technical manner.
It is very important this process is clearly laid down and agreed upon. It is important requirements person understands this process; list down requirements, iteratively expand them and finally agree on architecture proposal. And do bear in mind this is the only way to infer design requirements. I.e. jumping over this hand-off document into late/low-level design is a productivity killer – and in this case you will re-live the first paragraph again and again.
Do you follow this process at your work? No excuses even if you are doing it alone. You just need to be a little bit schizophrenic and act both personas. If you don't want to, it's because you are relying on John von Neumann's rule, who said: "There's no point in being exact about something if you don't even know what you're talking about."
back to previous content