How to Build the Perfect Fusion Plant: A Technical Architect’s Perspective
The Importance of Technical Architects in Fusion
At Cosylab, we have a long history of fruitful collaboration with ITER and have currently several control-systems teams contributing to the project.
Fusion powerplant projects are notoriously intricate, even down to the subsystem level. One such example is ITER’s Visible Spectroscopy Reference System, which will measure the plasma’s purity in the reactor, and on which my team is currently working.
As a technical architect, my role is to manage the Visible Spectroscopy Reference System (VSRS) project and bring it to completion in all its aspects. These include selecting or designing:
- hardware components,
- assembling prototypes,
- developing the software (such as firmware, drivers, control system, the GUI),
- prototype testing.
All of this activity must be tightly coordinated between Cosylab and five other ITER contractors.
An Example of a Technical Challenge: ITER Diagnostics for Plasma Purity
The Visible Spectroscopy Reference System (VSRS in short) is one of the diagnostics systems in the ITER tokamak that assesses plasma purity. VSRS measures the critical parameter of effective ion charge, Zeff, directly from the reactor core.
VSRS comprises two parts:
- the front-end subsystem, located in the immediate proximity to the reactor, and
- the back-end system a hundred metres away, where the raw data is processed and the results uploaded to the central DAQ network.
Scientists access the results to study phenomena inside the tokamak, and engineers who ensure the nominal operation of the reactor use them for control.
Why We Have to Measure Plasma Purity
Plasma in tokamaks is often heated up with a laser. If the plasma purity is too low, heating will be ineffective. That’s where the VSRS comes in.
Tokamaks have a diagnostic opening through which instruments analyse the light from within the reactor. Light is led via an assemblage of mirrors and optical fibres to the spectrometers in the back-end system, which send their data to computers in cubicles for analysis.
The VSRS system must possess an alignment and calibration system because several unwanted factors can influence the readings of its instruments:
- temperature variations,
- proximate magnetic fields,
- shifts in the Earth’s mantle, and even
- seismic interference from nearby road traffic.
Plasma exiting the fusion reactor may also smear the mirrors close to the tokamak’s shutter. Due to the hazardous environment, a fully automatised mechanical procedure has to provide alignment, calibration and mirror cleaning.
We were tasked to deliver a complete VSRS with its control system, so it is also our job to coordinate weekly and monthly with the other contractors on this ITER project. As the technical architect, I supervise the coordination and handle the hardware architecture part of the final design and to produce a complete proof-of-concept prototype system.
The Hardware Design of the Visible Spectroscopy Reference System
To prepare a hardware plan for a fusion subsystem, such as the VSRS, we start with the requirements and divide the labour between our partners and us. The system architect drafts a basic plan on which we expand in several steps.
We select the key components, for instance:
- motors,
- mirrors,
- light sources,
- spectrometers,
- cameras,
- cables,
- optical fibres and
- electrical cubicles.
We also estimate other elements, such as:
- the power requirements,
- how soon components will be worn out,
- how much heat the system will produce,
- what interfaces we will use,
- the size of the necessary space, and much more.
All of this is a task that takes days. Some of the subsystem’s components are market unavailable and have to be built by us or project partners, such as the polychromator.
The role of a technical architect is complex; they have to:
- mitigate issues,
- steer the design direction,
- check all interfaces’ compliance, and
- ensure the system will operate optimally in its potentially hazardous environment.
The Software Design of the VSRS and Optimising the Development Cycle
For the sake of argument, there are two opposing schools of thought regarding software architecture:
- everything architectural needs to be planned meticulously and unwaveringly;
- architecture is candy; performance matters most, even if it’s at the expense of code maintainability.
I try to be as pragmatic as possible and try to occupy the middle ground by using risk-driven architecture. The critical parts of the code that can never exhibit an issue, even a minor one, must be architecturally excellent, self-documented and easy to maintain.
The parts where we can afford minor issues during development are less rigorously executed and optimised to get the job done in a timely fashion.
Estimating Risks in the Development of Fusion Subsystems
Everything should work, of course, perfectly in our final product. What we do during development is, essentially, estimate risks.
We imagine the program in a “tree view” and evaluate the risk for each of its “leafs”. The risk is the product of the likelihood that the specific part of the code will need servicing and the estimated work effort in person-days to change that piece of code.
As ITER’s framework is still evolving, adopting this risk-driven approach allows us to adapt the architecture to changing requirements while still following an efficient course of development.
For example, suppose we estimate that the client is likely to later ask us to add updated or extra functionality (an extra device or a fancy algorithm) to a specific part of the code. In that case, we write the code unit more flexibly.
How a Fusion Project Challenges the Technical Architect
An essential part of managing a project such as ITER VSRS is governing time efficiently. If I can’t complete everything assigned on the same day, I move it to the next one.
Of some parts of the ITER VSRS project, I have only “a helicopter view”, so I rely considerably on many of my developer colleagues; people from our firmware and hardware departments and the other VSRS contracting companies. It is crucial that all project members are on the same page and that all meeting minutes and action items are duly recorded in a team workspace database, such as Confluence, in our case.
We keep constant track of the ongoing stakeholder activities and check the progress monthly. Productive external coordination is one of the toughest challenges of any contracting engineering project.
It is vital to prevent fragmentation of effort and communication and remain united as an overall team. The more advice is sought and given between the teams, the better. Meet as often as you must.
Honesty, conciseness, cordiality and revealing occasional shortcomings are crucial in ensuring a solid relationship between partners and stakeholders.
The Solution is in Comprehensive Architecture and Organisation
Fusion systems are intricate and can create significant project delays and complications if not designed and developed expertly.
The use of state-of-the-art control and instrumentation software enables both
- the scientific proof of the fusion concept and
- the industrial delivery of commercial fusion powerplants.
Fusion projects, both in the scientific and industrial realms, need well-rounded software engineering teams with members skillfully covering all aspects of the development cycle. The role of technical architects in these teams is essential.
Shorter advancement cycles for early first plasma
Only teams experienced in rapid and iterative yet comprehensive development and testing can overcome project problems and delays, characteristic of fusion.
Tried-and-true managing of development assures shorter advancement cycles and faster system tuning for optimal plasma control, reducing the time to first plasma or to market.
But it is also the technical architects that need the contest for fusion – to conquer the challenges and help cross the final frontier of sustainable and affordable energy.
The VSRS project still has about a year and a half to go before the prototype will be ready – and ITER’s first plasma a step closer. Our team is looking forward to each minute of the effort.
How Does a Technical Architect Meet Challenges in Fusion?
The following are my personal views, but I find them essential in everyday work for ITER and other fusion projects.
I manage both the hardware and software VSRS design for our client while developing a working prototype that closes the gap between the two domains, forming a functioning unity.
I love the combination of being both a technical inventor and project manager. I don’t have a secretary, and my boss gives me free rein with the understanding that I am personally responsible for the quality and timeliness of the planned results.
Good university education is a must for a technical architect. Still, the finer points of the trade, such as project and time management, are learnt by working on various projects with more experienced developers.
Besides the obvious academic background in STEM, an able technical architect usually possesses certain personality traits. Architects should be honest with themselves and the people around them — both from their team, partners and client. If they don’t know something, they ought to ask. The only foolish question is the one you did not bring forward.
There are other personal characteristics that define a good technical architect, who should be:
- reliable and accountable, behaving as an equal member of the team;
- intuitive – often, they can solve problems by going beyond pure logic by listening to their inner voice, shaped by past experiences;
- willing to take risks; Andrey Kolmogorov allegedly stated: “If you take no risks, you will garner no profits;”
- comfortable in recognising they cannot be an expert on everything but should be able to recognise the experts;
- decisive in times of uncertainty, acting boldly when necessary and trusting themselves and their data;
- self-organised to a fault; closely integrating and managing their tasks, timelines, schedules and agendas;
- relaxed in multitasking, for example, in switching between the software, hardware and management scope;
- good at handling work-related pressure.
Last but not least, a technical architect should love his profession. All other factors being equal, motivation raises experts above the average.
Technical architects in fusion should be familiar with electrical engineering, physics, mechanical engineering, computer science, high-performance computing and more. They should also be instinctive and battle-scarred by experience. Good technical architects are a rare breed, but crucial in reaching continuous fusion in science and affordable fusion in industry.
Joze Zobec is a technical architect who recently joined Cosylab. In the last ten years, he acquired professional experience in both theoretical physics (Grand Unification Theory) and experimental particle physics (detector design, maintenance and analytics at CERN and DESY, with a focus on high-performance computing, particle tracking, data acquisition and big-data analysis), IT consultancy in the medical and real-estate sectors (full-stack development) and, most recently, in the control system design.
At Cosylab, he works as a project manager for the ITER VSRS prototype. In his spare time, he enjoys fast cars, dancing (salsa), chess (his favourite is the Polish opening), singing (being a former professional operatic bass), hiking and tinkering with his hobby Arduino and Raspberry Pi projects.