Copenhagen Atomics

Introduction

Founded by a group of scientists and engineers in 2014, Copenhagen Atomics aims to address one of the most burning issues for our planet: the bottleneck in the supply of energy resources. The team develops Generation IV reactors, which are molten salt reactors. These reactors use thorium to burn spent nuclear fuel: the process reduces the radioactivity of the nuclear waste while producing high energy output. The design of these reactors fits in a container. This results in lower costs of construction and increased safety, as both issues are associated with traditional large-scale nuclear power plants.

Copenhagen Atomics develops Generation IV reactors, which are molten salt reactors. Image source.

Modelling on how offshore windmill energy achieved economies of scale through mass production, Copenhagen Atomics aims to scale up the production of molten salt reactors to provide Energy as a Service. Depending on the energy needs of each client, the company will lease the reactors and sell the generated energy while managing the equipment after decommission.

In this case study, Lasse Tarp, Software Group Manager at Copenhagen Atomics, introduces us to the company's software architectural design with QuestDB at its core.

Architecture overview

Copenhagen Atomics' software stack to monitor nuclear reactors sensors in real time.

Reactors function in a sealed environment; monitoring this environment is a crucial step for anomaly detection. QuestDB QuestDB is the time series database behind the growing number of sensors, which continuously send back information such as temperature, liquid flow and pressure. The data is then filtered and presented to the plot systems, accessible via the web browser for monitoring purposes.

We deploy our architecture on Azure and host API servers as well as QuestDB's engine on Kubernetes. Each reactor sends thousands of data points to the API servers every 10 milliseconds. The number of reactor sensor values is likely to grow by a factor of 10 in the near future.

From the API servers we have two parallel processes: ingesting sensor data to QuestDB using the .NET ILP client and sending queried (downsampled) data to our plot systems for monitoring. We customize our own plot systems for fetching and displaying data.

An example screenshot of a plot system that monitors IoT devices

At Copenhagen Atomics we also sell loops for testing equipment. The plot shown above is a selection of some of the temperature sensors delivered in real time with the loop. Selecting what to see in a plot is done by the end user - properties such as colors and scaling can be configured. All data is fetched from QuestDB and downsampled with the query SAMPLE BY.

This way, we can adjust the granularity of the data by zooming in and out and visualize the updated chart in milliseconds. We are really impressed with response time when we query data.

SELECT
  timestamp,
  AVG(aircon) as aircon,
  AVG(ac01_temperature) as ac01_temperature,
  AVG(dc01_temperature) as dc01_temperature
FROM
  'loop'
WHERE
  timestamp BETWEEN '2022-08-26T07:16:15.104000Z' AND '2022-08-26T08:01:15.104000Z' SAMPLE BY 1s FILL(LINEAR)

Why QuestDB?

We wanted to choose an open source time series database that we could trust and see evolve in the open. We also want to contribute to the project and open source allows this. QuestDB caught our eye due to its performance both on ingestion and time-series as well as analytical queries. QuestDB's traction in the market also made us confident about our choice. Our initial interaction with the team was extremely positive: in addition to getting a good vibe from Vlad (CTO) and Nic (CEO), we also enjoyed the effective communication on Slack with the rest of the team as well as QuestDB's growing community.

What's Next?

We have been collaborating with the QuestDB team by providing product feedback and testing out new features. Here are the next steps for our project:

1. Cold storage:

   As the amount of data increases, it is crucial to migrate older data to cold storage to resolve the limitation of disk space and to reduce hardware costs.

   Insights from the QuestDB team:

   QuestDB open source allows detaching partitions via SQL keywords. Once a partition is detached, it can be moved to a suitable cold storage solution. The SQL commands are:

   • ALTER TABLE ATTACH PARTITION
   • ALTER TABLE DETACH PARTITION

   For QuestDB Cloud, the team will provide a one-click solution to enable seamless data migration to and from cold storage. This way, users can query hot data really fast and store less critical data on cold storage solutions such as AWS S3 or Azure Blob Storage. Watch this space!

2. User access control:

   QuestDB open source provides no control access to the Web Console. Therefore, we only use it for ad-hoc queries. Ideally, we would like to be able to set different admin groups with different access rights to use the Web Console.

   Insights from the QuestDB team:

   We are building user access control for QuestDB Cloud and Enterprise. You can track its progress on our public roadmap.