The Telescope Control Software of the Cherenkov Telescope Array ^†

Abstract

The development of reliable and scalable control software is a key requirement for the Cherenkov Telescope Array Observatory, where distributed subsystems must operate coherently and support increasingly automated observing strategies. This paper presents the architecture and design of the Telescope Control System of the Small-Sized Telescopes of the observatory, addressing the need for modularity, deterministic behavior, and long-term maintainability. The proposed solution adopts a set of software managers implementing well-defined interfaces and state machines, enabling predictable control flows and consistent interaction with heterogeneous hardware. Modern software engineering practices were applied, including containerized services, automated deployment workflows, and a comprehensive simulation environment. These elements were evaluated through prototypes and pathfinder activities that allowed us to explore design alternatives, validate the behavior of individual components, and assess the scalability of the overall architecture. Results from these exploratory tests indicate that the interface-driven and modular design supports robust operation, facilitates integration, and reduces the effort required for system evolution. While full implementation is currently in progress, the findings confirm that the proposed architecture provides a solid foundation for the test readiness review phase (the phase preceding formal integration testing) and can be effectively extended to future facilities requiring flexible, maintainable, and resilient control software.

1. Introduction

The Cherenkov Telescope Array Observatory (CTAO) [1] is the world’s most powerful and sensitive ground-based gamma-ray observatory, designed to explore extreme phenomena in the Universe. It consists of arrays of imaging Cherenkov telescopes located at two sites—one in the Northern Hemisphere and one in the Southern Hemisphere—ensuring full-sky coverage. The Observatory will be open to the global astronomical and particle physics communities, serving as a resource for unique observations of the previously unexplored very-high-energy (VHE) domain of the electromagnetic spectrum, spanning four orders of magnitude above 20 GeV. Gamma-ray astroparticle physics is a relatively young field, yet observations over the past decade have led to the discovery of more than two hundred VHE emitters, which appear to function as cosmic particle accelerators. These sources are a key component of the Universe, influencing the evolution of stars and galaxies. At the same time, they provide a means to probe physics in the most extreme environments known, such as supernova explosions and the regions surrounding—or following the merger of—black holes and neutron stars. CTAO will deliver a comprehensive census of the VHE sky, increasing the number of known sources by an order of magnitude and enabling detailed population studies that will address longstanding questions about these objects. Furthermore, the CTAO endeavor brings substantial social benefits to humanity. It drives technological innovation in big data processing, high-speed electronics, and precision engineering. By fostering global scientific collaboration, it also plays a crucial role in inspiring and training the next generation of researchers and engineers in STEM fields. Within this framework, the Small-Sized Telescope (SST) sub-array [2] plays a fundamental role in exploring the highest-energy region of the gamma-ray spectrum, significantly contributing to the overall scientific capabilities of the observatory. The operation of each SST relies on a dedicated Telescope Control System (TCS), which coordinates all telescope subsystems and ensures precise, reliable, and fully integrated behavior within the array. Core functionalities, including telescope pointing and tracking, interaction with the camera system, safety supervision, and synchronization with array-wide operations, directly affect both data quality and observing efficiency. The SST mechanical structure closely follows the design of the ASTRI Mini-Array telescopes under installation at the Teide Observatory [3]. As a consequence, several elements of the TCS software, especially those interfacing with hardware devices, inherit concepts and interfaces already validated within the ASTRI framework. This shared approach reduces development time, enhances reliability, and increases the likelihood of successful deployment. In addition, a subset of SSTs is funded through Italy’s National Recovery and Resilience Plan (PNRR) [4], which introduces tighter development schedules and emphasizes the need for efficient and well-coordinated software engineering processes. This paper presents the current status of the SST-TCS architecture and design. We describe the refinements introduced following recent system-level reviews, and we outline the implementation strategy, which combines the reuse of proven ASTRI software components with the development of new high-level manager applications. Rather than presenting final performance results, we discuss the initial integration activities and the ongoing hardware-in-the-loop validation using dedicated simulators, which represent a fundamental step toward the finalization of the control system.

2. Overview of the SST Project

CTAO is the next-generation facility for very-high-energy (VHE) gamma-ray astronomy, designed to surpass the sensitivity, angular resolution, and energy coverage of current imaging atmospheric Cherenkov telescopes. CTAO will operate as an open observatory and will consist of two sites—one in the northern hemisphere and one in the southern hemisphere—to ensure nearly full-sky coverage. Its design relies on a heterogeneous array of telescopes of different sizes, each optimized for a specific portion of the energy spectrum: the Large-Sized Telescopes (LSTs) for the lowest energies, the Medium-Sized Telescopes (MSTs) for the core energy range, and the Small-Sized Telescopes (SSTs) [5] for the highest energies, reaching several hundred tera-electronvolts. This multi-instrument configuration enables CTAO to achieve an order-of-magnitude improvement in performance compared to existing instruments. Within this framework, the SST sub-array plays a crucial role during the exploration of the extreme universe. Installed exclusively at the CTAO southern site in the Chilean Andes—where geomagnetic and atmospheric conditions favor observations at the highest energies—the SSTs are specifically designed to detect gamma rays up to ~300 TeV. Their large number, wide field of view, and optimized optical design allow efficient sampling of extensive air showers with large impact parameters, maximizing collection area and increasing the probability of detecting rare high-energy events. The SST array is developed by an international consortium comprising more than twenty research institutes across the world, with major contributions from Italy, France, Germany, the United Kingdom, Japan, Australia, Brazil, the Netherlands, and the USA. In CTAO’s planned “alpha configuration,” 37 SST units will form the initial deployment. A subset of these telescopes is funded through Italy’s PNRR, which accelerates the delivery schedule for several units and imposes stricter constraints on design maturity, production workflows, and system integration timelines. Each SST adopts a dual-mirror Schwarzschild–Couder optical design, featuring a 4.3 m primary mirror and a curved focal plane equipped with Silicon Photomultipliers (SiPMs). This configuration offers several advantages: a compact camera, reduced optical aberrations over a wide field of view (~9°), and improved imaging performance, particularly important when reconstructing extensive air showers at high energies. The technical feasibility of this design has been demonstrated by two major pathfinder prototypes: the ASTRI-Horn telescope [6,7], which validated the dual-mirror approach on-sky, and the CHEC-S camera [8], which established the performance of SiPM-based Cherenkov imaging sensors. Figure 1 displays the fully integrated telescope structure at the company facility, showing the structure in two distinct configurations: the parking position and a simulated pointing operation.

The SST project is organized according to a Product Breakdown Structure (PBS), depicted in Figure 2, that defines the main system elements: (i) the Mechanical Structure, composed of the mount, axes, drives, encoders, and local control electronics; (ii) the Optical Assembly, including primary and secondary mirrors and their alignment systems; (iii) the TCS, which supervises all on-board subsystems and interfaces each telescope with the CTAO Array Control and Data Acquisition System (ACADA); and (iv) the Cherenkov Camera, responsible for signal detection, digitization, triggering, and data preprocessing [9].

The Mechanical Structure is derived from the ASTRI project developed by the Italian National Institute for Astrophysics (INAF), incorporating an altitude–azimuth mount with a conical base and rotation-integrated cabinets to minimize cable stress [10]. The Telescope Control System encompasses all software components responsible for coordinating and supervising the telescope during both autonomous and array-integrated operations. It is organized into four main elements: the Telescope Manager, which provides the high-level control logic and the interface to the CTAO ACADA; the Structure Manager, which supervises the Mechanical Structure, including motion control, local devices, and safety-related functions; the Camera Manager, which handles the interaction with the Cherenkov Camera and its control software; and the Engineering GUI (Graphical User Interface), which offers a dedicated interface for standalone operation during assembly, integration, calibration, and maintenance activities. Together, these components ensure consistent command flow, unified state management, monitoring of all subsystems, and safe execution of operational procedures. The overall development roadmap for the SST project is divided into four major phases: the Bridging Phase, the Consolidation Phase, the Production Phase, and the on-site Assembly, Integration, Testing, and Verification (AIT/V) Phase. The Consolidation Phase—initiated in mid-2023—concluded with a successful Critical Design Review (CDR), confirming design maturity and authorizing the transition to production. During the Production Phase, all telescope components will be manufactured and validated over a period of approximately three years. The first telescope produced will act as a qualification model, undergoing full factory integration and testing before deployment to the Chilean site. In parallel, the on-site AIT/V Phase will commence with the arrival of the initial hardware batches. Current scheduling foresees the first five SSTs becoming operational in 2026, with completion of the full alpha-configuration array expected by 2028.

3. TCS Requirements

The definition of the TCS for the Small-Sized Telescopes is guided by a rigorous top-down methodology that ensures full consistency with the scientific goals of the CTAO. The requirements flow starts from the high-level science objectives of the observatory and progressively evolves into specific functional, behavioral, and architectural constraints for the TCS. This structured chain of derivation guarantees that every function implemented by the TCS is traceable to an operational need or scientific performance requirement. A schematic overview of this process is shown in Figure 3.

At the top of the hierarchy, the CTAO Scientific Goals (Level A & B) define the observatory-wide performance targets—such as pointing accuracy, response capability to transient phenomena, duty cycle, and data quality. These objectives are subsequently translated into Telescope Requirements (Level C), where each subsystem of the SST (including optics, mechanics, camera, and control software) receives its allocated performance metrics and operational responsibilities. For the TCS, this includes constraints on state handling, command–response timing, system monitoring, fault management, and the operational behaviors required to support nightly observations as well as engineering activities. The derivation of the TCS Requirement Specifications (Level D) is informed by three key documents that collectively define the expected behavior of any CTAO telescope. First, the Generic Telescope Use Cases provide a detailed description of all operational scenarios, covering the full lifecycle of telescope activity—from initialization and configuration to scientific observations, calibration sequences, shutdown, and fault recovery. Each use case is associated with specific TCS responsibilities, thereby shaping the functional content of the system. Second, the Generic Telescope State Machine defines the operational modes (e.g., OFF, INITIALIZED, STANDBY, READY, OBSERVING, SAFE, FAULT) and the allowed transitions between them. This formal model ensures that all telescopes in the array behave consistently under the control of the Array Control and Data Acquisition System [9]. The Telescope Manager within the TCS is responsible for implementing this behavioral logic and for coordinating the state machines of the Structure and Camera Managers. Finally, the ACS/IDL Component Templates constrain the architectural and interface aspects of the TCS. CTAO provides Interface Definition Language (IDL) files describing the properties, commands, events, and monitoring points that each TCS component must expose. These mandatory templates ensure interoperability with ACADA and enforce the use of the ALMA Common Software (ACS) framework for all high-level TCS components. Taken together, these sources define the full set of TCS requirements, which are grouped into several categories in the official specification document:

• Functional requirements, covering system coordination, observation block execution, handling of commands and telemetry, error propagation, and simulation support for testing.
• Behavioral requirements, derived from the state machine, ensuring predictable transitions, fault handling, and synchronization among subsystems.
• Interface requirements, detailing the communication model with ACADA and with all Local Control Systems using ACS and OPC-UA (Open Platform Communications Unified Architecture).
• Performance requirements, regulating response times, astrometric data delivery, repositioning behavior, and tracking performance.
• Safety and protection requirements, specifying alarm propagation, behavior under communication loss, and interactions with the Integrated Protection System.
• Design and construction requirements, imposing the use of ACS, defining system properties to be exposed, and constraining the modes available during maintenance.

This comprehensive and multi-layered requirements framework ensures that the TCS evolves in a coherent and verifiable manner, directly aligned with the operational and scientific expectations of CTAO. Each element of the system—its components, interfaces, behaviors, and operational procedures—is the result of a carefully defined lineage of requirements, providing a robust foundation for the subsequent design and implementation phases.

4. Software Architecture and Design

The Telescope Control System of the Small-Sized Telescope is conceived as an autonomous, self-contained subsystem operating within the larger software ecosystem of CTAO. Its architecture is shaped by stringent functional requirements, standardized interface definitions, and interoperability constraints imposed by the CTAO system-level design. The TCS must coordinate multiple hardware and software assemblies—the mechanical structure, optical systems, safety components, and the Cherenkov camera—while remaining fully integrated with ACADA, which orchestrates the operations of the entire observatory. A fundamental architectural decision for the control system is the adoption of the ACS framework for all high-level software components, both in the TCS and in ACADA. This ensures a uniform component model, shared communication semantics, and built-in support for distributed control, monitoring, and logging. The resulting architecture is strictly hierarchical, with well-defined responsibilities and standardized communication layers. Figure 4 illustrates the high-level component-based architecture of the TCS.

4.1. Architectural Overview

At the top of the control hierarchy resides the Telescope Manager, the single-entry point through which ACADA interacts with each SST. The Telescope Manager exposes the command interface defined in the CTAO IDL specifications and implements the CTAO Generic Telescope State Machine. It orchestrates all internal telescope functions, ensuring that the system behaves deterministically and coherently with the rest of the array. Immediately below the Telescope Manager are two major subsystems:

• Structure Manager: responsible for the control of the telescope’s mechanical assemblies, including mount, axes, Pointing Monitoring Camera (PMC) [11], optical calibration systems, Active Mirror Control (AMC), and safety interfaces. It delegates hardware-specific logic to dedicated supervisor components and device connectors.
• Camera Manager: responsible for configuring and controlling the Cherenkov camera and its support systems. Communications with the camera LCS (Local Control Software) are performed via gRPC protocol, a design decision inherited from the camera development teams and validated during the SST Critical Design Review. The Camera Manager implements the camera’s state machine and manages state transitions requested by the Telescope Manager or by ACADA.

This hierarchical organization naturally reflects the telescope’s physical decomposition and ensures that each subsystem encapsulates its internal complexity while exposing a predictable set of operations.

4.2. Boundary Between High-Level Supervision and Hardware Control

One of the defining characteristics of the SST TCS architecture is the strict separation between high-level supervision (implemented in ACS) and low-level hardware control (implemented in the Local Control Software). This separation is enforced through standardized communication protocols:

• OPC-UA for all Structure Local Control Systems (Mount LCS, Pointing Model Camera LCS, Primary and Secondary Active Mirror Control, Optical Camera LCS, Safety PLC)
• gRPC for the Cherenkov Camera LCS. This choice aligns the TCS with other CTAO camera teams and allows efficient control of microservice-based camera components.

This boundary is explicitly represented in the component diagram of the SST TCS (reported in Figure 4), where managers and supervisors communicate with the hardware devices vertically with OPC-UA or gRPC device connectors. Because telescope hardware must remain stable and predictable during operations, the design mandates idempotent behavior for all high-level commands. Idempotency ensures that retrying a command—common in distributed systems—never causes cumulative or unsafe actions. This requirement is consistent with ACADA’s own interaction model and significantly enhances robustness.

4.3. Detailed Subsystem Architecture

4.3.1. Telescope Manager

The Telescope Manager is responsible for:

• Implementing the full telescope state machine;
• Coordinating observation execution;
• Validating and dispatching observation jobs;
• Supervising both Camera and Structure Managers;
• Forwarding monitoring, logging, and alarm information to ACADA.

It is deployed once per telescope and runs on the CTAO on-site data center, ensuring isolation while enabling independent recovery.

4.3.2. Structure Manager and Supervisors

The Structure Manager oversees a suite of supervisor components, each controlling a dedicated subsystem:

• Mount Supervisor, controlling azimuth/elevation axes, trajectory execution, and stow/park mechanisms.
• PMC Supervisor, managing sky image acquisition, astrometric solutions, and pointing feedback loops.
• Optics Supervisor, controlling the optical camera and active mirror systems (M1, M2).
• Safety Supervisor, interfacing with alarms and interlocks.

Each supervisor uses an OPC-UA device connector automatically generated from LCS ICD files kept under version control through GitLab version control system. The device connectors encapsulate the mapping between OPC-UA variables and the corresponding ACS properties, ensuring strong consistency between hardware and software.

4.3.3. Camera Manager

The Camera Manager abstracts the Cherenkov camera’s software ecosystem, which is based on microservices running on a dedicated camera server. This subsystem uses:

• gRPC for command and status exchange;
• A custom protocol for high-throughput data streams;
• A separate ACADA data path for R1 (raw data after the first level of calibration) event data.

This split ensures that control traffic remains lightweight and deterministic, while data acquisition is optimized for throughput.

4.4. Design Principles and Decisions

The TCS architecture is governed by several design principles:

• Idempotency

A foundational requirement for all operations, ensuring robust behavior when commands are retried after timeouts or partial failures. The TCS design strictly avoids non-idempotent commands such as incremental motions (e.g., increase elevation by X), replacing them with absolute commands (move to Az = X, El = Y).

• Reusability of ASTRI Mini-Array Software

Given that the SST mechanical structure and control logic are closely aligned with the ASTRI Mini-Array, significant parts of the Structure Controller and calibration subsystems are reused or adapted. This includes:

• Mount control algorithms;
• Mirror alignment workflows;
• PMC and optical camera calibration processes;
• Engineering GUIs.

This reuse accelerates development and ensures long-term continuity.

• Separation of Concerns

Each component is strictly responsible for its domain and exposes clear interfaces, facilitating maintainability and reducing coupling. This separation also enables independent testing of subsystems using simulators.

4.5. Runtime Behavior and Key Operational Processes

The 4 + 1 architectural view model is used to capture dynamic behavior.

The detailed design includes UML sequence diagrams for:

• Absolute motion execution;
• Sky tracking;
• Parking sequence;
• Pointing model calibration;
• Monitoring and logging workflows.

• Pointing and Tracking

The pointing and tracking systems integrate data from:

• Astro library (coordinate transformations);
• PMC (astrometric corrections);
• Mount LCS (spline-based trajectory generator).

The predictive trajectory is computed in advance and refined using PMC-based corrections every ~20 s.

• Calibration Systems

The optical camera and mirror alignment procedures follow the ASTRI methodology:

• Acquisition of a grid of PMC and optical images;
• Computation of astrometric residuals;
• Iterative mirror alignment per segment;
• Cross-calibration between PMC and Cherenkov camera.

4.6. Deployment Architecture

The deployment architecture of the SST TCS follows a fully distributed model that mirrors the physical distribution of the telescope subsystems. The overall layout, illustrated in Figure 5, is organized around two primary execution domains: the CTAO Data Centre, where all high-level coordination takes place, and the telescope structure, which hosts the real-time LCS responsible for direct hardware interactions.

The deployment model places the TCS at the CTAO on-site data center:

• High-Level Software at the CTAO Data Centre

All high-level TCS components are deployed centrally within the CTAO Data Centre. This includes:

• Telescope Manager;
• Structure Manager;
• Camera Manager;
• All subsystem Supervisors (Mount, Optics, Safety, PMC, Optical Camera);
• The full ACADA system, which orchestrates array-level operations.

These components run on dedicated virtual machines or containerized environments and communicate with each telescope’s LCS modules via the observatory network. Central deployment ensures a controlled and secure execution environment, simplifies software maintenance, and enables tight integration with ACADA, monitoring services, and observatory-wide logging and alarm systems. In addition to the TCS processes, each SST is associated with a dedicated camera server hosted in the Data Centre. This server runs the camera microservices and handles the high-throughput scientific data streams originating from the Cherenkov Camera front-end electronics. Separating this data-intensive path from the TCS control flow prevents interference between control and science operations and ensures optimal performance for both.

• Local Control Software on the Telescope Structure

The telescope itself hosts all the real-time control units needed to interface with physical hardware. These Local Control Software modules run directly on devices installed in the telescope structure and are responsible for deterministic, low-latency operations. Specifically:

• Mount LCS, Safety LCS, and M1/M2 Active Mirror Control LCS run on industrial PLCs installed inside the main electrical cabinets on the rotating structure. These PLCs implement the local state machines, safety logic, closed-loop control, encoder reading, and actuator commands.
• The PMC and the Optical Camera (OptCam) each have a dedicated industrial server mounted inside the telescope cabinet. These servers host both the hardware-control LCS and the OPC-UA server used by the Structure Manager and its Supervisors.
• The Cherenkov Camera hosts its own Local Control Software directly on the telescope: the front-end electronics (FEE) and the back-end electronics (BEE) contain embedded processors running the camera LCS, enabling configuration, diagnostics, monitoring, and command execution via gRPC. These units are physically integrated within the camera body, minimizing latency and reducing the number of interconnecting cables.

This architecture ensures a clear separation between real-time hardware control, which remains local to the telescope, and supervisory control, which is centralized in the Data Centre. All interactions between ACS-based software and hardware LCSs use standardized communication protocols: OPC-UA for structure-related subsystems and gRPC for the Cherenkov Camera.

• Engineering Interfaces for AIV and Maintenance

Beyond nominal scientific operations, the TCS architecture provides specific tools to support Assembly, Integration and Verification (AIV), commissioning, and maintenance activities. A dedicated Engineering Telescope AIT/V GUI—running on a Telescope Workstation connected to the on-site network—offers full control of the telescope independently of ACADA. This GUI exposes low-level actions, diagnostic views, test utilities, and real-time monitoring functions essential during hardware integration, calibration, and troubleshooting. In addition, a set of subsystem-specific engineering GUIs is available for expert users. These interfaces allow direct interaction with each LCS component, including:

• Mount and axis control;
• Safety and interlock diagnostics;
• PMC image acquisition and astrometry verification;
• Optical Camera and mirror alignment operations;
• Active mirror system calibration.

These GUIs are intentionally kept separate from nominal operations due to their powerful command sets, and they are used exclusively by trained engineers during controlled procedures.

5. Current Status and Future Work

The development of the SST Telescope Control System has reached an advanced and cohesive stage, with most architectural elements implemented and several key subsystems already undergoing integration and validation. Over the past development cycle, the Structure Controller has matured into a stable and feature-complete component, covering mount control, active mirror systems, safety logic, and the conditioning subsystems. Its behavior has been extensively validated through a suite of OPC-UA–based simulators developed in TwinCAT, which allow safe and repeatable testing without requiring physical hardware. These simulators have proven crucial for verifying interface consistency, refining ICD mappings, and exercising the supervisory logic implemented in the ACS-based Structure Manager. In parallel, significant progress has been achieved on the auxiliary optical systems. The Pointing Monitoring Camera now includes both a functional control server and a sophisticated simulator capable of generating realistic sky images and astrometric solutions. This has enabled thorough validation of the PMC Supervisor and the integration of its feedback into the pointing correction loop. The Optical Camera subsystem is also in a mature state: both the hardware controller and the mirror-alignment analysis software have been integrated with the Structure Controller, and the full alignment workflow, originally developed for the ASTRI Mini-Array, has been successfully adapted to the SST. At the high level, the Telescope Manager, Structure Manager, and Camera Manager are stable and aligned with a first release of the TCS software stack. These components are capable of executing the initial telescope use cases and have been validated against simulated and partial real hardware configurations. The Engineering AIT/V GUI has become a central tool for integration activities, offering complete visibility and control over the telescope’s subsystem during laboratory testing. It has been complemented by subsystem-specific engineering interfaces that allow expert-level diagnostic and tuning operations. Integration activities are now entering a decisive phase. The first combined tests involving the Structure Controller, auxiliary optical systems, and parts of the camera software have begun in the laboratory. These factory integration efforts mark a crucial milestone in the development roadmap: the telescope must successfully complete all factory-level tests before shipment to the CTAO-South site. The current test campaigns focus on validating the complete control loop ensuring that real-time behavior, monitoring flows, and command execution remain consistent with the expected system performance. The factory environment also provides the first opportunity to verify the interaction between the TCS and the physical mount, mirror actuators, PMC hardware, and optical camera in a fully assembled configuration. Looking ahead, the next major phase will be the completion of the factory acceptance tests and the preparation for shipment of the qualification telescope to Chile. Once at the CTAO-South site, the TCS will support Assembly, Integration and Verification activities, including the deployment of the pointing model, calibration of optical subsystems, and initial on-sky tests. This on-site phase will mark the transition from controlled laboratory conditions to real operational scenarios, providing invaluable feedback for refining the system’s robustness and operational efficiency. In parallel, work will continue on the integration of the TCS with ACADA [12], including sustained verification of command paths, state-machine synchronization, alarm propagation, and performance under distributed load. In the longer term, the focus will shift toward large-scale deployment across the SST sub-array. As more telescopes join the network, increasing emphasis will be placed on scalability, long-term maintainability, and the optimization of autonomous behaviors. Further refinements to the pointing model, enhanced fault recovery strategies, and improvements to operator interfaces will naturally arise from the experience collected during factory tests and from the first months of on-site operations. The combined outcomes of these efforts will ensure that the SST-TCS becomes a robust, reliable, and extensible control system, capable of supporting the high scientific ambitions of the Cherenkov Telescope Array Observatory.

6. Conclusions

The Telescope Control System of the Small-Sized Telescopes has evolved into a mature and coherent software framework capable of supporting the demanding operational requirements of the Cherenkov Telescope Array Observatory [13]. The architecture, rooted in a clear hierarchical model, standardized interfaces, and a strict separation between high-level supervision and hardware-level control, has proven robust through extensive validation using simulators, laboratory setups, and the first integrated test benches. The strategic adoption of the ALMA Common Software framework, together with the consistent use of OPC-UA for structure-related subsystems and gRPC for camera control, ensures seamless interoperability across the observatory’s distributed software ecosystem. Through iterative development and continuous refinement, the TCS now provides a comprehensive suite of capabilities ranging from the management of telescope state and safety logic to the coordination of mechanical, optical, and camera subsystems. The integration of auxiliary calibration systems, the Pointing Monitoring Camera and the Optical Camera with mirror-alignment tools, enables the implementation of the pointing model and ensures that stringent performance requirements can be met throughout the telescope’s lifecycle. Recent progress in the implementation of high-level managers, subsystem supervisors, and engineering interfaces has culminated in the successful execution of the initial use cases and in the start of factory-level integration activities. These tests represent a fundamental milestone, as they validate end-to-end control paths for the first time on real hardware. Completion of the factory acceptance phase will pave the way for shipment to the CTAO-South site, where the TCS will support assembly, integration, verification, and the first on-sky commissioning operations of the qualification telescope. Looking forward, the experience gained during laboratory integration and early hardware testing will inform the refinement of the TCS before large-scale deployment across the SST sub-array. The modularity of the architecture and the reuse of field-proven components from previous projects provide a solid foundation for scaling, maintaining, and extending the system as the observatory expands. As CTAO advances toward operational readiness, the SST-TCS will play a central role in enabling reliable, autonomous, and scientifically effective telescope operations.