A Checklist for a Modern Control System
The Tokamak Fusion Test Reactor
Credit: PPPL
At the turn of the century, engineers had very little ready-made and off-the-shelf equipment on hand to assemble control systems. The handful of physics labs maintained demanding requirements for new control-system projects that were not commercially attractive to equipment vendors due to the one-off nature of solutions necessary. Besides, the control system engineers were still mostly the scientists themselves and often pursued the in-house development of bespoke equipment. Today, a larger number of experimental projects and advancements in computing have allowed the widespread standardisation of control system components and the adoption of good practices and solutions from the industry.
During this time, control system software packages and frameworks have also matured through community collaboration. The growing control system integration market in science has also attracted industry players in much larger numbers. The latter has reduced control system allotments from 15% of the machine’s budget to 5% or even less for some projects. Therefore, today’s challenge is no longer how to implement a control system with state-of-the-art technology but to do it cheaper and quicker, without sacrificing quality.
This article will outline some of the main points that one must consider when implementing a modern machine control system.
Basic or Multiple Control System Packages
Traditionally, one of the first decisions that the project manager and control system (CS) engineer makes is which control system package to use. Luckily, today’s most popular control system packages are quite mature and with a wide-enough scope that you will be able to finish your project whatever your choice.
Nevertheless, some scientific facilities use more than one control system packages. In our experience, it is better to avoid mixing and matching several control system packages, if possible. Regardless of that, we believe that one should clearly define the system functionalities and requirements for all the interfaces. And also, let’s not forget about the effort of documenting and maintaining the systems. It is quite often best to adopt established best practices and learn from the experience of previous similar projects.
Hardware Platform Selection
Nowadays, we can use a large assortment of hardware platforms that are readily available. Selection and standardisation of the platform – or multiple platforms, depending on the situation – is a crucial step in the control design phase. Non-technical requirements, such as platform longevity (future roadmap), number of vendors, and adoption bases within the same industry and support (community or commercial), are critical parameters and should never be forgotten. Adding technical requirements (including flexibility) and price concerns, one should be well on one’s way towards making a good choice.
Machine Protection and Timing Systems
A reliable, fast and flexible machine protection system (MPS) is a critical safety feature that prevents damage to the machine or averts harm to its users, primarily when it works at high energies.
A completely flexible MPS implementation does not yet exist for big science but, based on requirements from many projects, experienced CS engineers know the most important requirements. One of them is the possibility of reconfiguring the MPS depending on the machine’s working mode. Clients also desire integration with the timing and the control system, allowing quick reconfiguration and post-mortem analysis. New MPS designs allow responses in the range of microseconds where the speed of light becomes one of the constraints.
The Tokamak Fusion Test Reactor
Credit: PPPL
New demanding physics machines also require complex timing systems. Features such as virtual accelerators, timing super-cycles and event acknowledgements are becoming more common. It is now almost agreed that existing – bespoke – timing solutions cannot provide all the necessary functionality. But these solutions can be employed as the underlying transmission layer, to which the CS team can add customisation. Simply put, one can purchase the transport layer, whereas CS engineers must be individually adapt the machine-specific application layer for each project.
Focus on Development and Standardisation
Building any complex system from many components is always a daunting engineering task, but control system development has an even more complicated cycle:
- define specifications,
- architecture,
- design,
- prototyping,
- test procedures; then
- implement,
- write documentation,
- test,
- debug and
- gain site acceptance.
Project managers are increasingly aware of the development process itself, so more things require focus. Control system engineers must think of the logistics of installation and error handling while also planning for testing and debugging. It usually makes the most sense to keep overall system responsibility in-house while outsourcing the control system implementation.
The Electron Synchrotron
Credit: DESY
Standardisation is the key trend that has emerged in the last ten years with ever more complex new scientific projects. Today, integration replaces development as the most prominent aspect of a control system project – there are usually only a few really difficult technical challenges in each project. So even though control system components are steadily becoming more standardised, they are also getting more complex and require more time and effort for integration. The main CS issues today are:
- how will all the components fit into the central architecture,
- what will the interfaces be,
- how shall the engineers address the requirements, and
- how the whole system will evolve with time and be maintained?
CONCLUSION
Project managers, therefore, must make early choices regarding the central architecture and components and consider all control system development aspects if they want to avoid costly problems down the road.
In short, control system development is, with time, becoming increasingly an engineering discipline and less of a scientific one.